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 :-)

Mary Christmas and Happy New Year

To all of you that study during the holidays and thinking they are the only one, well you are not alone. Our dedication to the goal is what Differentiate us, an expert is not the one that know all, it is the one that is most dedicated to find the best solution and do what ever it takes. So Mary Christmas and Happy New Year to all of you out there :-) Now let ABBA Continue from here....

CCIE EIGRP METRIC

One of the annoying fileds in my opinion is calculation, I hate them! in my mind it is just in the way of the cool stuff. but unfurtunetly to get to the cool stuf you need to calculate.

so I would like to start by giving you a little review and may be more indepth look over EIGRP Metric, as we all should know EIGRP is a Hybrid Routing Protocol that use a Composite Metric in his DUAL Diffusing Update Algorithm. the Composite metric is composed (good word selection :-)!?) from K Values.

K1 K2 K3 K4 K5

K1 = Bandwidth = 1 meaning it is used in the calculation by default.

K2 = load = 0 you gust it, meaning that is not participating in the calculation by default.

K3 = Delay = 1 you can take it from here

K4 = Reliability = 0

K5 = MTU = 0

the K values tells us if the value is participating in the calculation or not and what is the weight of the value, meaning that if you set K1 to 3 then it means that the weight of K1 will be 3 times more "important" or in other words it will take the BW * 3.

So now we know what are the "K" Values we need to know how to calculate:

well I will not endolge you with long version of the formula as it is hardly ever use (by hardly I mean I never seen it fully used).

Metric = [256 * (10^7/BW) + 256 * (Accumulated Delay)]

in the attached picture I draw a small network to demonstrate what I mean to get from R1 to R3 netwrok 3.3.3.0/24

you have the following options:
R1 -> R2 -> R3
The lowes bandwith in that path is 64Kbps
The Delay is 20000 for the 64Kbps link 100 for the 100 Mbps linke and another 100 for the 3.3.3.0/24 network link also 100Mbps = 20200 microseconds delay.

so now lets put all into the formula:

Metric = [256 * (10^7/BW) + 256 * (Accumulated Delay)]
Metric = [256 * (10^7/64) + 256 * (20000 + 100 + 100)]
Metric = [256 * (156250) + 256 * (20200)]
Metric = [40000000 + 5171200]
Metric = 45171200 = FD Feasable Distance (I will Talk about this in a bit)

R1 -> R4 -> R3

Metric = [256 * (10^7/BW) + 256 * (Accumulated Delay)]
Metric = [256 * (10^7/64) + 256 * (20000 + 1000 + 100)]
! note that now you have 1000 in the path as it is a regular 10 Mbps Ethernet
Metric = [256 * (156250) + 256 * (21100)]
Metric = [40000000 + 5401600]
Metric = 45401600 = FD

R1 -> R2 -> R4 -> R3
Metric = [256 * (10^7/BW) + 256 * (Accumulated Delay)]
Metric = [256 * (10^7/64) + 256 * (20000 + 20000 + 20000 + 100)]
Metric = [256 * (156250) + 256 * (60100)]
Metric = [40000000 + 15385600]
Metric = 55385600 = FD

R1 -> R4 -> R2 -> R3 I think you should do it now, you should get the point of the calculation

Now that have an idea how to calculate we need to see what route is preferd, in that senarion it is easy but in complex networks this basics can help us understand the proccess (leave the calc to the router).

FD as I was mentioning this Feasable Distance is the Metric that our router see from his outgoing interface to the point he wish to go, also caled end-to-end metric.

AD Advertised Distance that is the Distance we recive from our directly connected neighbor for the path we wish to go.

so for FD of R1 ->R2 ->R3 we get an AD of R2->R3.

FS Feasible Successor is the Router that is chosen by us to be the next hop to the Destination Prefix.

FC Feasible Condition is a rule that tells us in a very logical way to select a FS he must send to us an AD that is lower then the FD.

if we received from R4 for example a AD higher then the FD that we had already in our topology table to get to R3 then we would not consider him to be a Feasible Successor.

so final step lets take the Paths and FD and Calculate the AD and see what path sould we go as I am already exited where to go from now:

Now our AD for the Paths sent to R1:

R2 -> R3
Metric = [256 * (10^7/BW) + 256 * (Accumulated Delay)]
Metric = [256 * (10^7/100000) + 256 * (100 + 100)]
Metric = [256 * (100) + 256 * (200)]
Metric = [25600 + 51200]
Metric = 76800 = AD
Metric = 45171200 =FD

R4 -> R3
Metric = [256 * (10^7/BW) + 256 * (Accumulated Delay)]
Metric = [256 * (10^7/64) + 256 * (20000 + 100)]
Metric = [256 * (156250) + 256 * (20100)]
Metric = [40000000 + 5145600]
Metric = 45145600 = AD
Metric = 45401600 = FD

R1 -> R2 -> R4 -> R3
Metric = [256 * (10^7/BW) + 256 * (Accumulated Delay)]
Metric = [256 * (10^7/64) + 256 * (20000 + 20000 + 20000 + 100)]
Metric = [256 * (156250) + 256 * (60100)]
Metric = [40000000 + 15385600]

Metric = 55385600 Here we can clearly see that there is not way that this route can meet the FC.
So we have a winner:
Metric = 76800 = AD
Metric = 45171200 =FD

to get to R3 3.3.3.0/24 R1 will take the path R1 ->R2 -> R3.
if it will fail then the path R1 ->R4->R3 will be taken as he still qualified to meet then FC for FS

FS Feasible Successor the second path in the topology that is set only of FC are met.

I hope this was an intersting article :-)