Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 

BGP ORF (Outbound Route Filtering) Capability

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.

 

ORF.jpg

 

 

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:

BGP Prefix-Based Outbound Route Filtering

Version history
Revision #:
1 of 1
Last update:
‎11-11-2013 12:35 AM
Updated by:
 
Labels (1)
Comments
New Member

Nice and one of the easiest ways to filter down the required routes with low resource consumption.. Thanks for sharing..

Gold

Hello Vijay,

Thanks for your positive comment.

Regards,

Ashish Shirkar

A very useful, but not commonly used feature was nicely explained.

Thanks Ashish. smiley

New Member

First: A perfect example. 
Second: Your explanation is very clear. 
Third: Many thanks

Any hint if ORF also works with AS Path filtering?

New Member

Very clear - Well done !