Understanding the BGP Table Version – Part 2: BGP Table Version in Action

Understanding the BGP Table Version – Part 2: BGP Table Version in Action

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

**This blog is a formatting cleanup and update to a previous blog I posted in 2012 on NetworkWorld.

This is the 2nd post in the 3 part series of “Understanding the BGP Table Version”. If you haven’t already read part 1, I would strongly recommend reading it prior to this post.

Understanding the BGP Table Version – Part 1: Introduction to BGP Table Version

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 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 best path change again.  Except that this time the best path change is that we have no best path.

……… Next Blog – 

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