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 :-)
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment