BGP–ORF Outbound Route Filtering

image

ORF is a BGP capability that would help customers that want to filter some BGP routes from their SP doing this filter in more efficient way.

In our traditional ways of inbound  filtering (route-maps, prefix lists, distribute lists..etc.) we have to receive the routes from the peer and then filter them form entering our routing table, this can be ok if you don’t have a large number of updates but the current 400K + routes in the global routing table this might not be the most efficient way of doing it since you will be receiving the 400K routes, process them and then accept the routes that you need from the SP, a better way of doing this is using the ORF capability which simply means that one peer instructs (send) the other peer the routes that it needs before that peer even sending it so we will both save on our routers processes and our bandwidth

let’s see what happens with and without the ORF

configuration

R1

interface Loopback0
 ip address 1.1.0.1 255.255.255.0
!
interface Loopback1
 ip address 1.1.1.1 255.255.255.0
!
interface Loopback2
 ip address 1.1.2.1 255.255.255.0

interface Loopback3
 ip address 1.1.3.1 255.255.255.0

interface FastEthernet0/0
 ip address 10.1.12.1 255.255.255.0
!
router bgp 100
 no synchronization
 bgp log-neighbor-changes
 network 1.1.0.0 mask 255.255.255.0
 network 1.1.1.0 mask 255.255.255.0
 network 1.1.2.0 mask 255.255.255.0
 network 1.1.3.0 mask 255.255.255.0
 neighbor 10.1.12.2 remote-as 200

R2

interface FastEthernet0/0
 ip address 10.1.12.2 255.255.255.0
 
router bgp 200
 no synchronization
 bgp router-id 2.2.2.2
 bgp log-neighbor-changes
 neighbor 10.1.12.1 remote-as 100

Setup is straight forward, R1 advertised its loopback addresses to R2 through BGP in this scenario R1 is the PE and R2 is the CE routers

Now let’s imagine that we don’t actually need all these routes on R2 and we need to filter some of them maybe we will just keep the 1.1.0.0/24 subnet and filters everything else. we can simply achieve this using prefix list  on R2 to accept the routes that we want

On R2

R2(config)#ip prefix-list ALLOWED_IN permit 1.1.0.0/24
R2(config-router)#neighbor 10.1.12.2 prefix-list ALLOWED_IN in 

After clearing the BGP session we should see only 1.1.0.0/24 in R2 routing table

R2(config)#do sh ip bgp
BGP table version is 10, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.0.0/24       10.1.12.1                0             0 100 i

However if we checked the BGP table before any filtering, we would see that R2 received these routes and processed them before filtering them

To see this we can debug ip bgp updates and then clear the BGP session

*Mar  1 00:37:39.175: BGP(0): 10.1.12.1 rcvd UPDATE w/ attr: nexthop 10.1.12.1, origin i, metric 0, path 100
*Mar  1 00:37:39.183: BGP(0): 10.1.12.1 rcvd 1.1.3.0/24 -- DENIED due to: distribute/prefix-list;
*Mar  1 00:37:39.187: BGP(0): 10.1.12.1 rcvd 1.1.2.0/24 -- DENIED due to: distribute/prefix-list;
*Mar  1 00:37:39.191: BGP(0): 10.1.12.1 rcvd 1.1.1.0/24 -- DENIED due to: distribute/prefix-list;
*Mar  1 00:37:39.195: BGP(0): 10.1.12.1 rcvd 1.1.0.0/24
*Mar  1 00:37:39.251: BGP(0): Revise route installing 1 of 1 routes for 1.1.0.0/24 -> 10.1.12.1(main) to main IP table
*> 1.1.0.0/24       10.1.12.1                0             0 100 i

As we can see from the debug output, as we expected the four prefixes were received from R1 then processed before 3 prefixes were filtered as per our prefix-list. This might be OK when we have few routes but not very efficient when we have 400K prefixes in the global routing table. ORF can assist with this issue, it is simply a capability that BGP routers can negotiate so that one neighbor can signal the other neighbor that it only needs certain routes

In our case, this simply means that R1 can signal R2 to send it only 1.1.0.0/24 so it can save on it’s bandwidth and processing, The ORF can be configured as send received or both. in our case R2 is signalling R1  to receive some routes so ORF is send, R2 should be configured as receive

on R1

R1(config-router)#neighbor 10.1.12.2 capability orf prefix-list receive

R2

R2(config-router)#neighbor 10.1.12.1 capability orf prefix-list send 

Running the same debug

*Mar  1 00:52:06.275: BGP(0): 10.1.12.1 rcvd UPDATE w/ attr: nexthop 10.1.12.1, origin i, metric 0, path 100
*Mar  1 00:52:06.283: BGP(0): 10.1.12.1 rcvd 1.1.0.0/24
*Mar  1 00:52:06.375: BGP(0): Revise route installing 1 of 1 routes for 1.1.0.0/24 -> 10.1.12.1(main) to main IP table

Comments

Post a Comment

Popular posts from this blog

BPDU Filter vs BPDU Guard

        Today we will try to explore the difference between these 2 options, BPDU guard and BPDU filter We know that BPDU are used to communicate between switches in L2 networks  to ensure loop free topology. BPDU Guard is used to protect our access (or trunks incase of servers) ports from receiving undesired BPDU packets, this feature is helpful in enforcing your network boundary in access layer BPDU Guard can be enabled on global configuration as well as under the interface configuration BPDU Filter on the other hand is used to filter BPDU packets outbound when configured  in global configuration (after sending 11 BPDU out ) and will filter BPDU inbound/outbound when configured under the interface level To better understand these two features, let’s use this simple topology R1 is connected to SW1 through F0/0 to have R1 send and receive BPDU we will simple configure bridging group 1 on the router and we will join the bridge group when desired to test our configuration BPDU
Read more

BGP Weight Attribute

Image
Before we start the lab let's see the BGP path selection process If the path specifies a next hop that is inaccessible, drop the update. •Prefer the path with the highest weight. •If the weights are the same, prefer the path with the largest local preference. •If the local preferences are the same, prefer the path that was originated by BGP running on this router. •If no route was originated, prefer the route that has the shortest AS_path. •If all paths have the same AS_path length, prefer the path with the lowest origin code (where IGP is lower than EGP, and EGP is lower than incomplete). •If the origin codes are the same, prefer the path with the lowest MED attribute. •If the paths have the same MED, prefer the external path over the internal path. •If the paths are still the same, prefer the path through the closest IGP neighbor. •Prefer the path with the lowest IP address, as specified by the BGP router ID. I read this on CCIE Pursuit blog We Love Oranges As O
Read more

OSPF–Point To Multipoint Non-Broadcast

Image
Using same setup that we have been using in the last 3 posts, we will change the network type to point-to-multipoint Non-Broadcast we will also add a Ethernet link between R2 and R3 and enable OSPF on it Our final configuration should be something like this R1 interface Serial0/0   no ip address   encapsulation frame-relay   no frame-relay inverse-arp ! interface Serial0/0.123 multipoint   ip address 10.1.123.1 255.255.255.0   ip ospf network point-to-multipoint non-broadcast   ip ospf 1 area 0   frame-relay map ip 10.1.123.2 102   frame-relay map ip 10.1.123.3 103 !          router ospf 1   router-id 1.1.1.1   log-adjacency-changes   neighbor 10.1.123.2   neighbor 10.1.123.3 R2 interface Serial0/0   no ip address   encapsulation frame-relay   no frame-relay inverse-arp ! interface Serial0/0.123 multipoint   ip address 10.1.123.2 255.255.255.0   ip ospf network point-to-multipoint non-broadcast   ip ospf 1 area 0   frame-relay map ip 10.1.123.1 201 R3 interface
Read more