Mar 272013
A Multihomed customer will receive probably the whole BGP table from both service providers. He will then filter out routes inbound from the service provider. This kind of construct is flexible and scalable in the sense of less administrative burden.
The routers from the provider side have to send the complete BGP table, which must be then received and processed by the customer router, which then filters about 90% of the routes probably with a filter list. There is a lot of waste of resources which could be utilized elsewhere.
If the customer router could dynamically request a subset of routes from the provider will be the optimum solution to this problem. This situation could be solved with outbound route filtering (RFC 5291). The idea is to send the prefix list which the customer uses to filter towards the provider. Then the provider will filter the routes outbound.
Router R2 receives 4 networks via BGP 1.1.0/24, 1.1.1/24, 1.1.2/24 and 1.1.3/24. It then filters the networks 1.1.2/24 and 1.1.3/24 networks inbound with a prefx-list. The debug ip bgp updates in displays the effect.
BGP(0): 10.0.12.1 rcvd UPDATE w/ attr: nexthop 10.0.12.1, origin i, metric 0, path 1BGP(0): 10.0.12.1 rcvd 1.1.3.0/24 -- DENIED due to: distribute/prefix-list;BGP(0): 10.0.12.1 rcvd 1.1.2.0/24 -- DENIED due to: distribute/prefix-list;BGP(0): 10.0.12.1 rcvd 1.1.1.0/24BGP(0): 10.0.12.1 rcvd 1.1.0.0/24BGP(0): Revise route installing 1 of 1 routes for 1.1.0.0/24 -> 10.0.12.1(main) to main IP tableBGP(0): Revise route installing 1 of 1 routes for 1.1.1.0/24 -> 10.0.12.1(main) to main IP tableR1#sh ip bgp neighbors 10.0.12.2 advertised-routesBGP table version is 5, local router ID is 1.1.3.1Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S StaleOrigin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path*> 1.1.0.0/24 0.0.0.0 0 32768 i*> 1.1.1.0/24 0.0.0.0 0 32768 i*> 1.1.2.0/24 0.0.0.0 0 32768 i*> 1.1.3.0/24 0.0.0.0 0 32768 iTotal number of prefixes 4Now let’s make R2 to send the prefix list towards R1 so that it will only send the unfiltered prefixes. The capability ORF must be exchanged between the 2 routers when they form a neighborship.
R1#sh run | section bgprouter bgp 1 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.0.12.2 remote-as 2 neighbor 10.0.12.2 capability orf prefix-list receive no auto-summaryR2#sh run | section bgp router bgp 2 no synchronization bgp log-neighbor-changes neighbor 10.0.12.1 remote-as 1 neighbor 10.0.12.1 capability orf prefix-list send neighbor 10.0.12.1 prefix-list FILTER_R1_PREFIXES in no auto-summaryR1#sh ip bgp neighbors 10.0.12.2 advertised-routesBGP table version is 5, local router ID is 1.1.3.1Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S StaleOrigin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path*> 1.1.0.0/24 0.0.0.0 0 32768 i*> 1.1.1.0/24 0.0.0.0 0 32768 iTotal number of prefixes 2R1#sh ip bgp neighbors 10.0.12.2 received prefix-filter
Address family: IPv4 Unicast
ip prefix-list 10.0.12.2: 1 entries
seq 5 permit 1.1.0.0/23 ge 24Now we can see that R1 only sends those routes unfiltered by R2… which indeed is a cool feature as it saves lots of router resources.