Outbound Route Filtering (ORF)

ORF

ORF allows you to build a prefix-list on a router, then send it to a BGP peer. The BGP peer then apply it as an Outbound filter towards the original router. Configuring this feature can help reduce the amount of system resources required for generating and processing routing updates by filtering out unwanted routing updates at the source.

The default route distribution model for BGP deployments is “send everything everywhere,” and then filter unwanted information at the receiving peer based on the local routing policy. Network operators desire the opposite, a mechanism to restrict routing information from reaching their node (router) to avoid such filtering. To overcome this challenge, Outbound Route Filtering (ORF) was introduced.

For ORF to function, ORF capability should be exchanged between the participating peers. The BGP ORF capability is announced with the capability code of 3 with variable capability length.

The BGP ORF capability provides two types of filtering mechanisms:

  1. Prefix-based ORF
  2. Extended community (route target)-based ORF

BGP ORF Format

An ORF entry has the format <AFI/SAFI, ORF-type, Action, Match, ORF-value>.

  • AFI/SAFI: Provides a coarse granularity control by limiting the ORF to only the routes whose NLRI matches the “AFI/SAFI” component of the ORF.
  • ORF-Type: Determines the content of the ORF-value.
  • Action: Controls the handling of the ORF request by the remote peer.
    • Action can be one of ADD, REMOVE, and REMOVE-ALL.
      • ADD adds an ORF entry to the Outbound Route Filter on the remote peer;
      • REMOVE deletes a previously installed ORF entry on the remote peer;
      • REMOVE-ALL deletes the previously installed entries in the specified ORF on the remote peer.
  • Match: Used when support of matching granularity on a per ORF entry basis is needed, in which case the “Match” component can be one of PERMIT or DENY.
    • The semantics of PERMIT is to ask the peer to pass updates for the set of routes that matches the ORF entry.
    • The semantics of DENY is to ask the peer not to pass updates for the set of routes that matches the ORF entry.

ORF entries are carried within BGP ROUTE-REFRESH messages and can be distinguished between normal ROUTE-REFRESH messages, such as those not carrying ORF entries, by using the message length field within the BGP message header.

A single ROUTE-REFRESH message can carry multiple ORF entries, although they will all share the same AFI/SAFI and ORF-type.

Prefix-Based ORF

This feature is generally implemented between a PE and a CE router. An ISP usually advertises a full BGP table or a default route or a subset of the BGP table, but the ISPs do not generally implement any kind of complex outbound filtering toward their customers. Most of the times, the CE router has to do most of the filtering using inbound filters, which is again not a good method because the routes are already received by the CE router before they are filtered, and thus the resources have been consumed.

After ORF capability is exchanged, an operator on the CE router defines a set of prefix-list entries of required routes and advertises it toward PE. The PE then adds that prefix list in its outbound filter along with its existing outbound route filter (if any).

Limitations:

  • Only works with eBGP neighbors.
  • Configured per-address family.
  • Distribute lists & IP Access lists are not supported.
  • ORF doesn’t support multicast.

Example:

A CE router which is connected to ISP PE router and forming EBGP neighborship with it. CE router only want to receive limited number of prefixes along with default route from PE because we don’t want to receive all chunk of routes, process them and waste your CPU utilization. So to achieve this we have two options:

  1. Configure outbound filter on PE to restrict prefixes that CE don’t want: This will work but there is one problem, in future, if your CE need addition specific routes for any reason like path manipulation you will need to open service request with service provider and wait for them to complete.
  2. Second option, configure inbound filter list on CE to get needed prefixes in RIB and filter unwanted coming from PE: This will work like charm, customer managing CE router can have control on what prefixes they want to keep and what they don’t. All is well but you will find one issue in this design. Even you have configure inbound filter list on CE, PE is still advertising all chunk routes to CE and CE has to look out every prefixes coming from PE and then filter them as per configuration, Imagine what will happen if your CE receive 50k or 1lk routes. Here BGP ORF capability feature can make difference. When you configure BGP ORF, CE router filter-list will dynamically learn by PE routers and PE will only advertise those prefixes which CE router needs.

As previously stated, before ORF messages are exchanged, the ORF capability should be negotiated. The ORF capability can be negotiated using the command neighbor ip-address capability orf [receive | send | both].

Route Filtering Without ORF

  • Two prefix lists are configured on the CE2 router for neighbors on PE4 and PE5, allowing three prefixes from each side.
  • When the prefix list is applied in the inbound direction and a soft clear of the BGP table using the clear bgp ipv4 unicast * soft in command is performed on the CE router, the CE2 router performs the filtering and denies all the other prefixes that do not match the prefix list.

If a large number of prefixes are being advertised by PE, a lot of inbound filter processing happens on the CE router as those routes are already advertised by PE and received by CE. The inbound filtering only saves some resources when installing the prefixes in the BGP table and the routing information base (RIB).

				
					// CE2
ip prefix-list FROM-PE4 seq 5 permit 192.168.100.0/24
ip prefix-list FROM-PE4 seq 10 permit 192.168.102.0/24
ip prefix-list FROM-PE4 seq 15 permit 192.168.104.0/24
!
ip prefix-list FROM-PE5 seq 5 permit 192.168.101.0/24
ip prefix-list FROM-PE5 seq 10 permit 192.168.103.0/24
ip prefix-list FROM-PE5 seq 15 permit 192.168.105.0/24
!
router bgp 300
 neighbor 172.16.42.4 remote-as 100
 neighbor 172.16.52.5 remote-as 100
 !
 address-family ipv4
  neighbor 172.16.42.4 activate
  neighbor 172.16.42.4 prefix-list FROM-PE4 in
  neighbor 172.16.52.5 activate
  neighbor 172.16.52.5 prefix-list FROM-PE5 in
 exit-address-family
				
			

Route Filtering With ORF

  • Notice that the PE routers PE4 and PE5 advertise the ORF capability with ORF type receive, whereas the CE2 advertises as send.
  • The CE2 router configures the inbound prefix list to filter the prefixes being received from the PE routers PE4 and PE5.
				
					// PE4 (IOS)
router bgp 100
 address-family ipv4 vrf ABC
  neighbor 172.16.42.2 capability orf prefix-list receive

// PE5 (IOS XR)
router bgp 100
 vrf ABC
  neighbor 172.16.52.2
   address-family ipv4 unicast
    capability orf prefix receive
    commit

// CE2 (IOS)
router bgp 300
 address-family ipv4 unicast
  neighbor 172.16.42.4 capability orf prefix-list send
  neighbor 172.16.52.5 capability orf prefix-list send
				
			

After the ORF capability is negotiated, the CE router advertises the inbound prefix-list to the respective PE routers. Use the command show bgp vrf ABC all neighbors ip-address received prefix-filter to view the received prefix-list filter on the PE router.

With ORF, the result remains the same for the prefixes in the BGP table (that was previously achieved using an inbound prefix list on the CE router) and the RIB. But in the background, there is a major difference in processing done by the CE and the PE routers. With the debug output, notice that only three prefixes are received and processed for the neighbor 172.16.42.4, which is as per the prefix filter on the PE4 router.

In case you need to re-adjust the prefix-list, you need to ensure that CE router sends the new filter to PE and perform a route-refresh by issuing clear ip bgp ip-address in prefix-list prefix-list-name. PE router will then apply the new filter, and send to CE router a BGP UPDATE message.

Note: Cisco IOS and IOS XR do not support extended community-based ORF.

Tags:

Leave a Reply

Related Post