Introduction:
In this document you will learn about BGP ORF (Outbound Route Filtering) capability.
What is BGP ORF Capability: It’s a feature uses BGP outbound route filter (ORF) send and receive capabilities to minimize the number of BGP updates that are sent between BGP peers. 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.
Let explain this with simple example:
In your network you have one CE router which is connected to service provider 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 you don’t want to receive all chunk of routes, process them and waste your CPU utilization. So to achieve this you will think of two options:
1) Configure output 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. Also this will increase work of service provider engineers to manually add or delete/modify filter list.
2) Another option is you can Configure inbound filter list on CE to get needed prefixes in routing table 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 .Also reduce configuration part of SP engineer. All is well but if you observe this carefully 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.
For platform support and Cisco IOS software image support use Cisco Feature Navigator at http://www.cisco.com/go/fn.
Configuration Example:
PE and CE are directly connected and PE is generating bunch of prefixes (I have configured loopbacks to generate prefixes) and a default route. Here is basic configuration of both routers.
CE | PE |
|---|---|
hostname CE ! ip cef ! interface FastEthernet1/0 ip address 10.1.1.2 255.255.255.0 no sh ! router bgp 65001 bgp log-neighbor-changes neighbor 10.1.1.1 remote-as 100 ! | hostname PE ! ip cef ! interface Loopback0 ip address 192.168.1.1 255.255.255.0 ! interface Loopback1 ip address 192.167.1.1 255.255.255.0 ! interface Loopback2 ip address 192.166.1.1 255.255.255.0 ! interface Loopback3 ip address 192.165.1.1 255.255.255.0 ! interface Loopback4 ip address 2.2.2.1 255.255.255.0 ! interface Loopback5 ip address 1.1.1.1 255.255.255.0 ! interface FastEthernet1/0 ip address 10.1.1.1 255.255.255.0 no sh ! router bgp 100 bgp log-neighbor-changes network 1.1.1.0 mask 255.255.255.0 network 2.2.2.0 mask 255.255.255.0 network 192.165.1.0 network 192.166.1.0 network 192.167.1.0 network 192.168.1.0 neighbor 10.1.1.2 remote-as 65001 neighbor 10.1.1.2 next-hop-self neighbor 10.1.1.2 default-originate ! |
Let’s verify BGP neighborship and route we learnt from PE:
CE#sh ip bgp sum | beg Nei
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.1.1.1 4 100 140 137 40 0 0 02:00:22 7
CE#
You can see CE have learned 7 routes from PE.
CE#sh ip bgp | beg Net
Network Next Hop Metric LocPrf Weight Path
*> 0.0.0.0 10.1.1.1 0 100 i
*> 1.1.1.0/24 10.1.1.1 0 0 100 i
*> 2.2.2.0/24 10.1.1.1 0 0 100 i
*> 192.165.1.0 10.1.1.1 0 0 100 i
*> 192.166.1.0 10.1.1.1 0 0 100 i
*> 192.167.1.0 10.1.1.1 0 0 100 i
*> 192.168.1.0 10.1.1.1 0 0 100 i
CE#
Now CE site engineer wants only default route and 1.1.1.0/24, 2.2.2.0/24 subnets no other subnet starts with 192.168.x.x.So as discussed above we know two ways to configure filter-list, either outbound to PE or inbound to CE; also we discussed what will be the problems. So we are configuring filter-list on inbound to CE.
Let’s 1st configure prefix-list and then apply to BGP neighbor.
CE#conf t
Enter configuration commands, one per line. End with CNTL/Z.
CE(config)# ip prefix-list FILTER_PE seq 10 permit 2.2.2.0/24
CE(config)# ip prefix-list FILTER_PE seq 15 permit 1.1.1.0/24
CE(config)# ip prefix-list FILTER_PE seq 20 permit 0.0.0.0/0
CE(config)#router bgp 65001
CE(config-router)#nei 10.1.1.1 prefix-list FILTER_PE in
CE(config-router)#end
Now verify BGP table after applying filter-list:
CE#sh ip bgp | beg Net
Network Next Hop Metric LocPrf Weight Path
*> 0.0.0.0 10.1.1.1 0 100 i
*> 1.1.1.0/24 10.1.1.1 0 0 100 i
*> 2.2.2.0/24 10.1.1.1 0 0 100 i
You can see after applying filter-list only 3 prefixes we needed in BGP table but as discussed above, PE is sending entire BGP table to CE, CE has to process all BGP updates coming from PE and then filters as per configured list which is potentially wasting CE CPU. To demonstrate let’s debug bgp updates and clear BGP updates.
CE#debug ip bgp 10.1.1.1 updates
BGP updates debugging is on for neighbor 10.1.1.1 for address family: IPv4 Unicast
CE#clear ip bgp 10.1.1.1 all
CE#
*Nov 10 23:06:05.723: BGP(0): no valid path for 0.0.0.0/0
*Nov 10 23:06:05.727: BGP(0): no valid path for 1.1.1.0/24
*Nov 10 23:06:05.727: BGP(0): no valid path for 2.2.2.0/24
*Nov 10 23:06:05.731: %BGP-5-ADJCHANGE: neighbor 10.1.1.1 Down User reset
*Nov 10 23:06:05.735: %BGP_SESSION-5-ADJCHANGE: neighbor 10.1.1.1 IPv4 Unicast topology base removed from session User reset
CE#
*Nov 10 23:06:05.739: BGP: topo global:IPv4 Unicast:base Remove_fwdroute for 0.0.0.0/0
*Nov 10 23:06:05.743: BGP: topo global:IPv4 Unicast:base Remove_fwdroute for 1.1.1.0/24
*Nov 10 23:06:05.747: BGP: topo global:IPv4 Unicast:base Remove_fwdroute for 2.2.2.0/24
*Nov 10 23:06:06.507: %BGP-5-ADJCHANGE: neighbor 10.1.1.1 Up
*Nov 10 23:06:07.079: BGP(0): 10.1.1.1 rcvd UPDATE w/ attr: nexthop 10.1.1.1, origin i, metric 0, merged path 100, AS_PATH
*Nov 10 23:06:07.083: BGP(0): 10.1.1.1 rcvd 1.1.1.0/24
*Nov 10 23:06:07.087: BGP(0): 10.1.1.1 rcvd 2.2.2.0/24
*Nov 10 23:06:07.087: BGP(0): 10.1.1.1 rcvd 192.165.1.0/24 -- DENIED due to: distribute/prefix-list;
*Nov 10 23:06:07.091: BGP(0): 10.1.1.1 rcvd 192.166.1.0/24 -- DENIED due to: distribute/prefix-list;
*Nov 10 23:06:07.095: BGP(0): 10.1.1.1 rcvd 192.167.1.0/24 -- DENIED due to: distribute/prefix-list;
*Nov 10 23:06:07.099: BGP(0): 10.1.1.1 rcvd 192.168.1.0/24 -- DENIED due to: distribute/prefix-list;
CE#
*Nov 10 23:06:07.103: BGP(0): 10.1.1.1 rcvd UPDATE w/ attr: nexthop 10.1.1.1, origin i, merged path 100, AS_PATH
*Nov 10 23:06:07.107: BGP(0): 10.1.1.1 rcvd 0.0.0.0/0
*Nov 10 23:06:07.119: BGP(0): Revise route installing 1 of 1 routes for 0.0.0.0/0 -> 10.1.1.1(global) to main IP table
*Nov 10 23:06:07.119: BGP(0): Revise route installing 1 of 1 routes for 1.1.1.0/24 -> 10.1.1.1(global) to main IP table
*Nov 10 23:06:07.123: BGP(0): Revise route installing 1 of 1 routes for 2.2.2.0/24 -> 10.1.1.1(global) to main IP table
CE#
You can also verify this using “sh ip bgp neighbors 10.1.1.1 received-routes” command.
CE#sh ip bgp neighbors 10.1.1.1 received-routes | beg Ne
Network Next Hop Metric LocPrf Weight Path
*> 0.0.0.0 10.1.1.1 0 100 i
*> 1.1.1.0/24 10.1.1.1 0 0 100 i
*> 2.2.2.0/24 10.1.1.1 0 0 100 i
* 192.165.1.0 10.1.1.1 0 0 100 i
* 192.166.1.0 10.1.1.1 0 0 100 i
* 192.167.1.0 10.1.1.1 0 0 100 i
* 192.168.1.0 10.1.1.1 0 0 100 i
Total number of prefixes 7
CE#
From the above output you can see CE is receiving 192.168.X.X prefixes, process them and then filtered it.
Let’s now apply BGP ORF and See what’s happened. The BGP ORF only supports prefix-list not route-map or any other filtering mechanism. This can be configured on a router to send or receive ORF capabilities with either the send or receive keywords. This feature can also be configured on a router to both send and receive ORF capabilities with the both keyword.
CE(config)#router bgp 65001
CE(config-router)#nei 10.1.1.1 capability orf prefix-list send
PE#conf t
Enter configuration commands, one per line. End with CNTL/Z.
PE(config)#router bgp 100
PE(config-router)#nei 10.1.1.2 capability orf prefix-list receive
Verifying after Applying ORF capability on CE, PE routers:
CE#sh ip bgp neighbors 10.1.1.1 received-routes | beg Ne
Network Next Hop Metric LocPrf Weight Path
*> 0.0.0.0 10.1.1.1 0 100 i
*> 1.1.1.0/24 10.1.1.1 0 0 100 i
*> 2.2.2.0/24 10.1.1.1 0 0 100 i
Total number of prefixes 3
CE#
PE#sh ip bgp neighbors 10.1.1.2 advertised-routes | beg Net
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.0/24 0.0.0.0 0 32768 i
*> 2.2.2.0/24 0.0.0.0 0 32768 i
Total number of prefixes 2
PE#
CE#clear ip bgp 10.1.1.1 all
CE#
*Nov 10 23:30:47.827: BGP(0): no valid path for 0.0.0.0/0
*Nov 10 23:30:47.827: BGP(0): no valid path for 1.1.1.0/24
*Nov 10 23:30:47.831: BGP(0): no valid path for 2.2.2.0/24
*Nov 10 23:30:47.835: %BGP-5-ADJCHANGE: neighbor 10.1.1.1 Down User reset
*Nov 10 23:30:47.839: %BGP_SESSION-5-ADJCHANGE: neighbor 10.1.1.1 IPv4 Unicast topology base removed from session User reset
CE#
*Nov 10 23:30:47.839: BGP: topo global:IPv4 Unicast:base Remove_fwdroute for 0.0.0.0/0
*Nov 10 23:30:47.843: BGP: topo global:IPv4 Unicast:base Remove_fwdroute for 1.1.1.0/24
*Nov 10 23:30:47.847: BGP: topo global:IPv4 Unicast:base Remove_fwdroute for 2.2.2.0/24
CE#
*Nov 10 23:30:48.755: %BGP-5-ADJCHANGE: neighbor 10.1.1.1 Up
*Nov 10 23:30:49.547: BGP(0): 10.1.1.1 rcvd UPDATE w/ attr: nexthop 10.1.1.1, origin i, metric 0, merged path 100, AS_PATH
*Nov 10 23:30:49.551: BGP(0): 10.1.1.1 rcvd 1.1.1.0/24
*Nov 10 23:30:49.555: BGP(0): 10.1.1.1 rcvd 2.2.2.0/24
*Nov 10 23:30:49.555: BGP(0): 10.1.1.1 rcvd UPDATE w/ attr: nexthop 10.1.1.1, origin i, merged path 100, AS_PATH
*Nov 10 23:30:49.563: BGP(0): 10.1.1.1 rcvd 0.0.0.0/0
*Nov 10 23:30:49.571: BGP(0): Revise route installing 1 of 1 routes for 0.0.0.0/0 -> 10.1.1.1(global) to main IP table
*Nov 10 23:30:49.575: BGP(0): Revise route installing 1 of 1 routes for 1.1.1.0/24 -> 10.1.1.1(global) to main IP table
CE#
*Nov 10 23:30:49.579: BGP(0): Revise route installing 1 of 1 routes for 2.2.2.0/24 -> 10.1.1.1(global) to main IP table
CE#
From the above output we saw that previously PE router sent the full BGP table to the CE router, and CE was processing whole updates. With BGP ORF the CE router dynamically tells the PE router what routes to filter “outbound”. This means that the CE router will only receive update messages about the prefixes that it wants.
Some more verification commands:
CE#sh ip bgp nei 10.1.1.1 | sec ORF
Outbound Route Filter (ORF) type (128) Prefix-list:
Send-mode: advertised
Receive-mode: received
Outbound Route Filter (ORF): sent;
CE#
PE#sh ip bgp neighbors 10.1.1.2 | sec ORF
Outbound Route Filter (ORF) type (128) Prefix-list:
Send-mode: received
Receive-mode: advertised
Outbound Route Filter (ORF): received (3 entries)
ORF prefix-list: 4 n/a
From above output you can see ORF mode on CE is sent and on PE is received, PE dynamically learned 3 prefix-list entries from CE.
To further check let’s add on more prefix-list entry on CE and see whether PE will dynamically learn it or not.
CE(config)#ip prefix-list FILTER_PE per 3.3.3.0/24
PE#sh ip bgp neighbors 10.1.1.2 | sec ORF
Outbound Route Filter (ORF) type (128) Prefix-list:
Send-mode: received
Receive-mode: advertised
Outbound Route Filter (ORF): received (4 entries)
ORF prefix-list: 4 n/a
PE#
BGP ORF Configuration for IOS XR:
To advertise prefix list-based Outbound Route Filter (ORF) capability to the Border Gateway Protocol (BGP) peer, use the capability orf prefix command in an appropriate configuration mode.
Example:
RP/0/0/CPU0:PE2#conf t
Tue Apr 15 03:45:59.365 TLT
RP/0/0/CPU0:PE2(config)#router bgp 65001
RP/0/0/CPU0:PE2(config-bgp)#nei 10.1.1.1
RP/0/0/CPU0:PE2(config-bgp-nbr)#address-family ipv4 unicast
RP/0/0/CPU0:PE2(config-bgp-nbr-af)#capability orf prefix ?
both Capability to RECEIVE and SEND the ORF from/to this neighbor
none No capability to RECEIVE or SEND the ORF from/to this neighbor
receive Capability to RECEIVE the ORF from this neighbor
send Capability to SEND the ORF to this neighbor
RP/0/0/CPU0:PE2(config-bgp-nbr-af)#capability orf prefix
Reference:
A very useful, but not commonly used feature was nicely explained.
Thanks Ashish. 
