Cisco Subnet An independent Cisco community View more

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

More on BGP Table Version – the most unknown, unexplained, unloved, and unused BGP concept/value that I rarely ever troubleshoot without


This is the 2nd post in the 3 part series of "Understanding the BGP Table Version".  Please visit 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

Obviously, the BGP table version in Router10 will increment because wasn't even in Router10's BGP table prior to learning about it.  So when Router10 learns about via the BGP updates (from Router21 and Router22), it will be the first time 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 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 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  You can also see that the BGP path to 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

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 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 reaches Router10, it is NOT a best path over the from Router21.  So the BGP table version doesn't change -- no new best path to  

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  

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 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 thru Router22 is best path and hence the BGP table version is incremented.  Then we get the update/withdraw from Router22 for and a new BGP best path is selected --- which is no best path because is gone.  But this is still a BGP best path change and must be reflected in the BGP table version.  


BGP(0): rcv UPDATE about -- withdrawn

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

RT: gateway changed from to


BGP(0): send UPDATE (format), next, metric 0, path 22 21 30


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

BGP(0): rcv UPDATE about -- DENIED due to: AS-PATH contains our own AS;

BGP(0): no valid path for

BGP(0): nettable_walker no best path

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

RT: delete subnet route to


RT: delete network route to


BGP(0): updgrp 1 - updates replicated for neighbors:

BGP(0): send unreachable

BGP(0): send UPDATE -- unreachable



BGP(0): rcv UPDATE about -- withdrawn

BGP(0): updgrp 1 - updates replicated for neighbors:

......... Next Blog - 

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

OpenStack:Ready for prime time?
View Comments
You Might Like
Join the discussion
Be the first to comment on this article. Our Commenting Policies