Junos Export Policy: The Name Is Not the Match Condition

Somebody named a policy EXPORT-STATIC, attached it, and now wonders why a prefix from the VPN routing instance never reaches the far end. The name has no effect on selection. A policy is a definition plus an attachment, and what it exports is decided by its match conditions, its ordered terms and the context that uses it. Read those three in that order and the mystery usually collapses into one term that never matched.

The name is a label, not a condition

Junos does not interpret policy names. A policy that would sensibly be called static export might match protocol static, or it might match an address prefix, or it might match nothing and accept everything on the way through. The label is documentation written by whoever created it, and it is exactly as trustworthy as that person's memory of the intent.

Treat a surprising export result as a request to read the definition, not as evidence that the attachment is broken. Read the definition and let it contradict the label.

Find the attachment before the terms

A correct definition attached in the wrong place changes a different exchange. Establish which routing instance, protocol and neighbour or group actually references the policy, because a policy attached under one BGP group does not affect another, and a policy attached to the instance does not necessarily apply to every protocol inside it. Junos distinguishes these levels, and a missing export at the group level is common when the intent was expressed at the instance level.

Write the attachment path down before you read a single term. Half of these investigations end there, with the definition untouched and the export statement moved. Note the difference in the change log so nobody reverts it as a mistake.

Terms evaluate in order, and the first decision wins

Terms run from first to last, and a term that accepts or rejects is a terminating decision. A later term that looks like the intended exception never runs if an earlier term already decided the route's fate, which is why a policy can read correctly from top to bottom and still behave contrary to the intent. Check the order against the route you care about, not against the order in which the terms were typed.

A term that omits its action does not terminate; evaluation continues to the next term, and the eventual outcome depends on what follows and on the applicable default. That is a genuinely useful construct and a reliable source of surprise when it is unintentional.

An example that exports only static routes, with the attachment on the group:

policy-options {
    policy-statement EXPORT-STATIC {
        term statics { from protocol static; then accept; }
    }
}
protocols bgp group TO-PEER { export EXPORT-STATIC; }

A prefix learned by OSPF rather than configured as a static route fails the match and falls through, whatever the policy is called.

Actions change a copy, not the original route

Policy actions operate on the route as it is evaluated for that advertisement, which is a copy rather than the entry in the routing table. A local show route can therefore display a route with one set of attributes while the exported version carries different ones, and the original is not rewritten by the export. That distinction explains several arguments about whose output is correct: both are, and they describe different objects. Say which view you are quoting whenever two engineers disagree about a route attribute.

Accept and reject are terminating decisions; attribute changes are not necessarily so. Do not assume that setting a community ends the policy, because evaluation may continue into terms you did not consider.

Compare the advertised view with the expectation

Use the protocol-specific view on the actual peer, such as show route advertising-protocol bgp 192.0.2.1, and read it in the right routing-instance context. A route present in a VRF has not necessarily passed the export policy, and a route that appears in the advertised output has not necessarily been accepted by the far side. Those are three separate states and they fail differently.

Accept the design with one prefix that must be advertised and one that must remain local. That gives the policy a contract you can test, and it avoids the alternative fix of broadening the export until a single named route finally appears.