Understanding the BGP Table Version – Part 2: More Introduction to BGP Table Version

This is the 2nd post in the 3 part series of “Understanding the BGP Table Version”.  Please visit http://www.networkworld.com/community/node/80089 to review part 1.  

Last we left our network, we had the below 3 routers and a BGP table version of 4 in Router10.

Add Router30 and Advertise It’s Loopback into BGP

Let’s add another router – Router30 and it’s loopback address 30.30.30.30/32.

Obviously, the BGP table version in Router10 will increment because 30.30.30.30/32 wasn’t even in Router10’s BGP table prior to learning about it.  So when Router10 learns about 30.30.30.30/32 via the BGP updates (from Router21 and Router22), it will be the first time 30.30.30.30/32 is in Router10’s BGP table, so when BGP best path is run, …. Voila!  New best path!  Hence the BGP table version has to increment.

Prior to Router30 coming online and advertising 30.30.30.30/32 to Router21, the BGP table version was 4 and the State/PfxRcd column for Router21 and Router22 were both 2.  Now Router10 shows that it has received 3 prefixes from Router21 and Router22, clearly indicating that we learned 30.30.30.30/32 from both.  Router10 then runs BGP best path on the 2 and picks the one best path.  Since we have not modified anything, it will go with the shortest AS path thru Router21.

Below we can see this has happened.  

We can look at the BGP table in Router10 and see the 2 paths to get to 30.30.30.30/32.  You can also see that the BGP path to 30.30.30.30/32 thru Router21 has the “>” next to it, indicating that the BGP best path algorithm picked this one.  

We can then see that BGP table version 5 is now “stamped” on 30.30.30.30/32.

Withdrawing A Prefix

Now that we have the basics in place… let’s take this to the next level and see what happens on a withdraw.  

Let’s go to Router30 and stop advertising it’s loopback into BGP and see what happens.  

QUESTION:  We were at BGP table version 5 prior to doing this.  What do you expect the BGP table version to be after the withdraw?

ANSWER: ???  …….

…… Answer:  7?  Huh?

That was interesting.  We removed one prefix and the BGP table version went up by two – from 5 to 7.  Ummmm… why??

Let’s add it back in again and see what happens.  

So, when we removed it….. the BGP table version went up by 2.  But when we added it back, it only went up by one.

So let’s think about the adding first.  

STEP 1) Router30 Advertises to Router21.

When we add it to Router30, Router30 advertised it to its eBGP neighbor, Router21 as can be seen below.

STEP 2) Router21 Advertises to Router10 and Router22

Router21 then advertises it to Router10 and Router22 as can be seen below.

STEP 3) Router22 Advertises to Router10 

Router22 then advertises it to Router10 as can be seen below.

So Router10 gets it twice… but the BGP table version only went up once.  

Question: Why?

Answer: Timing.

We learned 30.30.30.30/32 from Router21 BEFORE we learned about it from Router22.  AND we didn’t do anything to prefer Router22’s advertisement. So when Router22’s advertisement of 30.30.30.30/32 reaches Router10, it is NOT a best path over the 30.30.30.30/32 from Router21.  So the BGP table version doesn’t change — no new best path to 30.30.30.30/32.  

Question: So why, when it is removed does the BGP table version change twice?  

Simple Answer:

Router10 gets the withdraw from Router21 first.  

Router10 removes this from its BGP table and voila path advertised by Router22 becomes new best path – incrementing the BGP table version by 1.

Router10 then gets the withdraw from Router22 for 30.30.30.30/32.  

Router10 removes this from its BGP table and voila best path change again.  Except that this time the best path change is that we have no best path.

Let’s put debugs on and watch.  

As we can see from the debugs below, we receive the BGP update to withdraw 30.30.30.30/32 from Router21 PRIOR to getting that update/withdraw from Router22.  So first we process the withdraw from Router21 and update our BGP table.  We run best path and, for a brief moment in time, the path to 30.30.30.30/32 thru Router22 is best path and hence the BGP table version is incremented.  Then we get the update/withdraw from Router22 for 30.30.30.30/32 and a new BGP best path is selected — which is no best path because 30.30.30.30/32 is gone.  But this is still a BGP best path change and must be reflected in the BGP table version.  

Router10#

BGP(0): 10.10.21.2 rcv UPDATE about 30.30.30.30/32 — withdrawn

BGP(0): Revise route installing 1 of 1 routes for 30.30.30.30/32 -> 10.10.22.2(main) to main IP table

RT: 30.30.30.30/32 gateway changed from 10.10.21.2 to 10.10.22.2

RT: NET-RED 30.30.30.30/32

BGP(0): 10.10.21.2 send UPDATE (format) 30.30.30.30/32, next 10.10.21.1, metric 0, path 22 21 30

BGP- ATF: EVENT 30.30.30.30/32 RIB update MODIFY

BGP(0): 10.10.22.2 rcv UPDATE w/ attr: nexthop 10.10.22.2, origin i, originator 0.0.0.0, path 22 10 21 30, community , extended community

BGP(0): 10.10.22.2 rcv UPDATE about 30.30.30.30/32 — DENIED due to: AS-PATH contains our own AS;

BGP(0): no valid path for 30.30.30.30/32

BGP(0): nettable_walker 30.30.30.30/32 no best path

RT: del 30.30.30.30/32 via 10.10.22.2, bgp metric [20/0]

RT: delete subnet route to 30.30.30.30/32

RT: NET-RED 30.30.30.30/32

RT: delete network route to 30.0.0.0

RT: NET-RED 30.0.0.0/8

BGP(0): updgrp 1 – 10.10.21.2 updates replicated for neighbors: 10.10.22.2

BGP(0): 10.10.21.2 send unreachable 30.30.30.30/32

BGP(0): 10.10.21.2 send UPDATE 30.30.30.30/32 — unreachable

BGP- ATF: EVENT 30.30.30.30/32 RIB update DOWN

BGP- ATF: EVENT 30.0.0.0/8 RIB update DOWN

BGP(0): 10.10.22.2 rcv UPDATE about 30.30.30.30/32 — withdrawn

BGP(0): updgrp 1 – 10.10.21.2 updates replicated for neighbors: 10.10.22.2

……… Next Blog – 

Understanding the BGP Table Version – Part 3: Using It When Troubleshooting