An Export Policy That Filtered Nothing

Because a policy-statement is only a filter where you make it one. Unmatched routes fall off the end and continue down the policy chain.

Route evaluation in TO-ISP:

• 198.51.100.0/24 matches our-block → then accept → advertised.
• 10.0.0.0/16 and 192.168.50.0/24 match no term.
• The statement has no default action, so those routes fall through to the next policy in the chain. TO-ISP is the only export policy configured, so the next step is the default BGP export behaviour, which is to advertise.

So the policy added a permit for one prefix and removed nothing - it was never a filter.

Fix - terminate the policy explicitly:

policy-statement TO-ISP {
    term our-block {
        from route-filter 198.51.100.0/24 exact;
        then accept;
    }
    term deny-all {
        then reject;
    }
}

A policy-level then reject; outside the terms achieves the same thing and is easy to read. Either way, the intent ("only this prefix") must be expressed as an explicit deny at the end, because the Junos default when a policy runs out of terms is permissive.

import and export are relative to the local router, not to the neighbor's perspective.

• import on r1's ISP-A neighbor filters routes that r1 accepts from ISP-A. It has no effect whatsoever on what r1 sends.
• export on r1's ISP-A neighbor filters routes that r1 sends to ISP-A.

The team wanted to suppress an outbound prefix, so the anti-RFC1918 logic belongs in the export policy - either folded into TO-ISP (preferred, one place to reason about) or applied as the neighbor's export policy. Putting it in import meant it was evaluated against ISP-A's routes, where 10.0.0.0/16 never appears.

One placement caution: a neighbor-level export policy supersedes the group-level export policy for that neighbor rather than being chained after it. If you split the logic across group and neighbor level, the group policy silently stops applying to that neighbor - keep the whole export decision in one policy and confirm with show bgp neighbor.

• show route advertising-protocol bgp <ISP-A-neighbor-ip> - the definitive outbound list: exactly the prefixes r1 is sending that peer right now. This is the command that would have caught the problem on day one.
• show route receive-protocol bgp <ISP-A-neighbor-ip> - the inbound counterpart; useful to confirm that NO-RFC1918 applied in the import direction only ever saw ISP-A's routes.
• show bgp neighbor <ISP-A-neighbor-ip> - shows which Import and Export policies are actually in effect for that neighbor, and whether a neighbor-level policy has overridden the group-level one.
• test policy TO-ISP 10.0.0.0/16 - evaluates a specific prefix against the policy and shows which term matched (or that no term matched, i.e. fall-through). Run this for each prefix you care about before committing; it is the cheapest possible unit test for a policy.
• show route 10.0.0.0/16 detail - shows where the route came from and which policy accepted or rejected it locally.

A good working rule: any time you write a policy whose intent is restrictive, prove it with test policy on at least one prefix that should match and one that should not, and confirm the result in show route advertising-protocol bgp after commit.