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.
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 18.104.22.168/32.
Obviously, the BGP table version in Router10 will increment because 22.214.171.124/32 wasn’t even in Router10’s BGP table prior to learning about it. So when Router10 learns about 126.96.36.199/32 via the BGP updates (from Router21 and Router22), it will be the first time 188.8.131.52/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 184.108.40.206/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 220.127.116.11/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 18.104.22.168/32. You can also see that the BGP path to 22.214.171.124/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 126.96.36.199/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.
We learned 188.8.131.52/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 184.108.40.206/32 reaches Router10, it is NOT a best path over the 220.127.116.11/32 from Router21. So the BGP table version doesn’t change — no new best path to 18.104.22.168/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 path advertised by Router22 becomes new best path – incrementing the BGP table version by 1.
- Router10 then gets the withdraw from Router22 for 22.214.171.124/32.
- 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