Routing Policy and Firewall Filters
Policy structure
policy-statement NAME { term NAME { from { ... } then { ... } } }. Match conditions in from include protocol, prefix-list, route-filter (with exact, longer, orlonger, upto /n, prefix-length-range), community, as-path, neighbor and interface. Actions in then include accept, reject, next term, next policy, metric, preference, local-preference, community add or delete, next-hop and as-path prepend. Terms are evaluated top to bottom; the first accept or reject ends evaluation; a term with no action falls through to the next term; if no term matches, the route is rejected by default.
Where policies apply
Import and export per protocol: set protocols bgp group NAME import POLICY and export POLICY; set protocols ospf export POLICY. A list of policies is evaluated in order. Export controls what you advertise; import controls what enters the RIB and is the usual place to set local-preference or filter prefixes received.
Firewall filters
Family specific (inet, inet6, mpls, ethernet-switching), stateless and ordered. term 10 from { source-address; destination-address; protocol; destination-port; tcp-flags; source-prefix-list } then { accept | discard | reject | count NAME | log | policer NAME | next term }. Packets matching no term are discarded by the filter's implicit default. Apply with set interfaces ge-0/0/0 unit 0 family inet filter input FILTER. A loopback (lo0) filter protects the Routing Engine.
Traps
- Forgetting the implicit discard at the end of a firewall filter.
- Treating filters as stateful; they are not, so return traffic needs its own term.
- reject sends ICMP unreachable, discard drops silently.
- Writing a policy term with from but no then accept and expecting the route to be accepted.
Rule of thumb
Policy governs routes in the control plane; filters govern packets in the data plane.