BGP Prefix-Based Outbound Route Filtering (ORF)

An inbound prefix-list on a customer edge router stops unwanted routes from entering the RIB, but it does not stop the provider edge from sending them: every prefix still crosses the link, still consumes BGP update processing, and still costs memory for the session. BGP prefix-based Outbound Route Filtering flips the direction of that filter, letting the receiver push its prefix-list to the sender so the sender never advertises the unwanted routes at all. This article explains the ORF capability negotiation, the IOS configuration, and the interoperability caveats that decide whether it is worth deploying.

How ORF works

ORF uses the BGP send and receive capabilities defined in RFC 5291 and the prefix-based ORF type defined in RFC 5292. The router that wants less traffic advertises the ORF capability in send mode; the peer receives it in receive mode and applies the prefix-list as an outbound policy for that neighbour. Updates to the filter are propagated as ORF entries inside the existing BGP session - no reconfiguration is needed on the remote side once the capability is negotiated.

The practical effect: filtering happens at the source, so the downstream router is not spending CPU parsing and discarding updates that its policy will reject anyway. On a router that receives a partial view from a large provider, that is a measurable reduction in memory and churn.

Configuration on the receiver

Device(config)# ip prefix-list FILTER seq 10 permit 192.168.1.0/24
Device(config)# router bgp 100
Device(config-router)# address-family ipv4 unicast
Device(config-router-af)# neighbor 192.0.2.1 remote-as 64500
Device(config-router-af)# neighbor 192.0.2.1 capability orf prefix-list send
Device(config-router-af)# neighbor 192.0.2.1 prefix-list FILTER in
Device(config-router-af)# end

The prefix-list FILTER in line is what makes this work: ORF only transmits filters that already exist as an inbound policy on the session. Configuring the capability without an inbound prefix-list sends nothing. Use both instead of send when you also want to honour ORF entries from the peer, and receive on a device that should apply filters pushed by its neighbour.

Verification

Device# show ip bgp neighbors 192.0.2.1
  ...
  Outbound route filtering capability advertised
  Outbound route filtering capability received (prefix-list)

Device# show ip bgp neighbors 192.0.2.1 prefix-filter
ip prefix-list FILTER seq 10 permit 192.168.1.0/24

If the capability is advertised but the received/rejected counters never move, the peer has not negotiated ORF - some implementations support only the VPN prefix-based ORF type, and some route-reflector designs suppress the capability entirely.

Interoperability and operational caveats

• Both sides must support prefix-based ORF. Mixed-vendor sessions frequently do not, and unsupported capability simply falls back to normal inbound filtering - so keep the local prefix-list in place as the safety net.
• ORF entries consume session resources and count toward neighbour limits on some platforms; a very long filter list is better expressed as a broader ORF plus local filtering.
• ORF is not a substitute for prefix filters on the far side. The remote operator can always change their policy, and the capability is negotiated per address family.
• Because filters are exchanged in-band, an operator changing the local prefix-list immediately changes what the peer advertises. Review the operational meaning of a prefix-list edit before committing it.

When to use it

The best candidates are edge routers that take partial routes (default plus a handful of customer or internet prefixes), CE-PE sessions with a narrow expected prefix set, and any session where a large unwanted prefix range is being carried and discarded. Inside a single AS with a consistent policy a route-reflector plus local filtering is simpler and more predictable.

Related: Prefix-list and route-map BGP filtering, BGP route reflector cluster-id, and BGP timers: hold, keepalive and MRAI.

原文链接：https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/15-s/irg-15-s-book/irg-oubound-route-filtering.html