Sunday, December 30, 2007

CCIE BGP ORF

This days I am a little slow on article writing as I am in the final lap before my lab exam (wish to pass..) ok that was on a personal note. Now on a hopefully helping note, i had a little bit difficulty understanding first the logic behind ORF but when the coin dropped then I started hearing a voice in my head saying tada... So here it how it goes, the real BGP full table is currently almost 250K path entries, now you have connection to 3 ISP's and you want for example to get from your Backbone ISP the full table and from your other ISP's only partial table, you then face with a dilemma should I develop my human bagging skills to ask nicely from each ISP's to filter on his side specifically for you and what you will probably get as answer is "NO" or if he is nice then "NO". So now you face with a problem you can get from each of the ISP's the full table and filter on your side but it will not solve the performance and resource intensive problem you wanted to avoid. or you can call the nice person in the ISP side and ask him just to put neighbor capability orf prefix-list recive and on your side: neighbor capability orf prefix-list send note: that this will reset your BGP peer relationship, after that you will create your Prefix Filter now lets say you want to only recive the 2 class B subnets all you need to do is: ip prefix-list FILTER-FULL-TABLE seq 5 permit 187.0.0.0/16 ip prefix-list FILTER-FULL-TABLE seq 10 permit 198.0.0.0/16 ip prefix-list FILTER-FULL-TABLE seq 15 deny 0.0.0.0/0 le 32 ! ! under the BGP process ! router bgp neighbor prefix-list FILTER-FULL-TABLE in ! This will result in filtering the BGP table on your ISP side so you will not even get the table to filter it, it is cool not?! as it is allowing you to create filters on the ISP side without him to do any thing. Here is a small example from my home lab: R3 is peering with R1 and R1 is advertising some prefixes now R3 want to filter them but not on his side: !R3 before ORF ! router bgp 100 no synchronization bgp log-neighbor-changes neighbor 150.1.1.1 remote-as 200 neighbor 150.1.1.1 password CISCO neighbor 150.1.1.1 update-source Loopback0 ! R3#sh ip bg BGP table version is 193, local router ID is 150.1.3.3Status 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 *> 150.1.0.0/21 150.1.1.1 0 0 200 i *> 150.1.1.0/24 150.1.1.1 0 0 200 i *> 167.13.0.0 150.1.1.1 0 0 200 i *> 167.13.135.0/24 150.1.1.1 0 0 200 i *> 205.90.31.0 150.1.1.1 0 200 254 ? *> 220.20.3.0 150.1.1.1 0 200 254 ? *> 222.22.2.0 150.1.1.1 0 200 254 ? ! Here is R1 before: R1#sh ip bg nei 150.1.3.3 ad BGP table version is 16, local router ID is 150.1.1.1Status 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 *> 150.1.0.0/21 0.0.0.0 32768 i *> 150.1.1.0/24 0.0.0.0 0 32768 i *> 167.13.0.0 0.0.0.0 32768 i *> 167.13.135.0/24 0.0.0.0 0 32768 i *> 205.90.31.0 192.10.1.254 0 0 254 ? *> 220.20.3.0 192.10.1.254 0 0 254 ? *> 222.22.2.0 192.10.1.254 0 0 254 ? ! router bgp 200 no synchronization bgp log-neighbor-changes network 150.1.1.0 mask 255.255.255.0 network 167.13.135.0 mask 255.255.255.0 aggregate-address 150.1.0.0 255.255.248.0 aggregate-address 167.13.0.0 255.255.0.0 neighbor 150.1.3.3 remote-as 100 neighbor 150.1.3.3 password CISCO neighbor 150.1.3.3 next-hop-self ! NOW: I would like to filter on R1 the following so I will not even get prefixes" 167.13.135.0/24 150.1.1.0/24 222.22.2.0/24 So I am setting on ! R1 (the ISP side for that example) router bgp 200 neighbor 150.1.3.3 capability orf prefix-list receive ! ! R3 (the client side) router bgp 100 neighbor 150.1.1.1 capability orf prefix-list send neighbor 150.1.1.1 prefix-list FILTER-DUP in ! and the following prefix list ip prefix-list FILTER-DUP seq 5 deny 167.13.135.0/24 ip prefix-list FILTER-DUP seq 10 deny 150.1.1.0/24 ip prefix-list FILTER-DUP seq 11 deny 222.22.2.0/24 ip prefix-list FILTER-DUP seq 15 permit 0.0.0.0/0 le 32 ! now be prepared for the TADA.. R3#sh ip bg BGP table version is 194, local router ID is 150.1.3.3Status 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 *> 150.1.0.0/21 150.1.1.1 0 0 200 i *> 167.13.0.0 150.1.1.1 0 0 200 i *> 205.90.31.0 150.1.1.1 0 200 254 ? *> 220.20.3.0 150.1.1.1 0 200 254 ? So Up to now it looks normal that the filter was done on our side and when applied it was filtering incoming prefixes, but no! See R1 Advertisements: R1#sh ip bg nei 150.1.3.3 ad BGP table version is 16, local router ID is 150.1.1.1Status 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 *> 150.1.0.0/21 0.0.0.0 32768 i *> 167.13.0.0 0.0.0.0 32768 i *> 205.90.31.0 192.10.1.254 0 0 254 ? *> 220.20.3.0 192.10.1.254 0 0 254 ? and no there is no prefix list on R1, belive me: R1#sh ip bg nei 150.1.3.3 ... Outbound Route Filter (ORF): received (4 entries) Sent Rcvd Prefix activity: ---- ---- Prefixes Current: 4 0 Prefixes Total: 4 0 Implicit Withdraw: 0 0 Explicit Withdraw: 0 0 Used as bestpath: n/a 0 Used as multipath: n/a 0 ... ORF prefix-list: 3 I hope that was a little eye open on this issue :-)
Post a Comment