There’s a lot of conversations going on in a network. Updates, keep-alives, heartbeats, hello’s…

BGP can be among the most aggressively chatty protocols on the network. Like the chatty stranger who sits next you on the train, BGP speakers love to talk about all the topics that interest them, regardless of whether you want to hear it or not. While the stranger on the train might like telling you about their family that’s coming to visit, their back injury from tennis, or how the CIA is tracking them through their fillings, BGP neighbours will tell you about all this things they love the most; prefixes.

Imagine a scenario where an internet provider (the PE) is peering with an enterprise (the CE). The provider has a lot of prefixes to share, but the customer only wants a few of them. There are two primary options which could be considered.

Firstly, the provider could filter their routes before sending them to the customer. This results in less prefixes being advertised (which is great for the resources on the CE router), but there are likely to be many service calls for any changes, and the customer has limited control over what changes are being made. On top of that, providers don’t generally like to customise their filtering rules on a per-customer basis.

The second option would be for the CE router to do the filtering. The PE still sends all their routes, and the CE uses a prefix-list to filter out the ones it doesn’t want. While this is good for the customer, as they retain control over the filtering, there is a higher impact to performance, as the routes still have to be received and processed.

So far it sounds like a tradeoff between control and performance. Fortunately, there is a better way.

Outbound Route Filtering (ORF) is a way to the customer to create a prefix-list for filtering, and then send the list to the provider. The provider’s PE router will then only send the routes that match the list. This is good for providers, as it has a low overhead. It’s great for customers as well, as they still have control, but don’t have to worry about all the processing and resource usage that comes with additional routes. Essentially, ORF is a way of improving option 2.

There is a small catch though. Both the PE and the CE need to be capable of supporting ORF, and both need to be configured to use it per neighbour. The best option is to discuss this with the provider before using it, to confirm they support it. So what happens if the PE or CE does not support ORF? In this case, you’re back to deciding whether you favour control or performance.

As the configuration in the next section shows, prefix-lists are the only mnethod for filtering with ORF (so, no route-maps or access-lists). Additionally, each neighbour can be configured with the ability to send a prefix-list (typically a CE requirement), receive a prefix-list (typically a PE requirement), or the ability to both send and receive.

Enabling ORF requires two basic steps:

1. Configuring/applying a filter list
2. Enable ORF for each neighbour

Normal prefix filtering is configured first. With this configuration, the neighbour (PE) sends a list of prefixes to the CE, and the CE filters out the prefixes it does not want.

ip prefix-list ALLOWED_NET permit 10.10.10.0/24
neighbor 200.200.200.200 prefix-list ALLOWED_NET in

When ORF is enabled (per neighbour), the prefix list that’s used to filter inbound routes is sent to the neighbour. The neighbour then filters the prefixes before they are sent, which reduces the load on the CE router.

The send option advertises to the neighbour that this router is capable of sending a prefix list. Other options are receive (which should be configured on the PE end) and both.

neighbor 200.200.200.200 capability orf prefix-list send

To show this in action, routers R1 and R2 have been configured with minimal BGP configuration. R1 is advertising 172.16.10.0/24, which R2 is filtering out with a prefix-list.

The show ip bgp neighbors received-routes command confirms that R2 receives the route from R1. The show ip bgp command confirms that R2 filters it out.

R2#sh ip bgp neighbors 10.0.0.1 received-routes 
BGP table version is 2, local router ID is 192.168.100.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *   172.16.10.0/24   10.0.0.1                 0             0 100 i

Total number of prefixes 1 


R2#sh ip bgp
BGP table version is 2, local router ID is 192.168.100.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>  192.168.100.0    0.0.0.0                  0         32768 i

ORF can then be configured as previously shown. R2 has the send capability, to send it’s prefix-list. R1 has the receive capability, to receive the prefix-list.

The configuration can be verified with the show ip bgp neighbors | section ORF

R2#show ip bgp neighbors 10.0.0.1 | section ORF
    Outbound Route Filter (ORF) type (128) Prefix-list:
      Send-mode: advertised
      Receive-mode: received
  Outbound Route Filter (ORF): sent;

After this configuration is in place, R1 does not send the route, meaning that R2 does not have to filter it.

R2#show ip bgp neighbors 10.0.0.1 received-routes 

Total number of prefixes 0