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

I cannot honestly imagine troubleshooting BGP without understanding the BGP table version.  I use it all the time.  Sometimes it is just a quick “eyeballing” of it to check to see if all the BGP table versions are in sync…. or if there is work to be done.  I see people “eyeballing” the up/down time for a BGP peer when they are troubleshooting.  And sometimes I see them quickly eyeball the InQ/OutQ columns.  But I rarely ever see anyone using the BGP table version.  And, honestly, I just can’t imagine not eyeballing all 4 of those – up/down, InQ, OutQ, BGP table version.  It is these 4 that I use to give me the “whole picture” when I’m troubleshooting.  

Out of those 4 that I use ALL the time, BGP table version is the least known, least explained, and least used.  I’m going to break “Understanding the BGP Table Version” into 3 blogs – the first 2 for introduction to it and then the 3rd for using it when troubleshooting.  I will need to make certain assumptions of your BGP knowledge, so sorry about that.  

Understanding the BGP Table Version – Part 1: Introduction

Understanding the BGP Table Version – Part 2: More Introduction

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

First let’s look at how information gets into the local BGP table.  When we get updates from our BGP peers, we put those updates into our local BGP table.  Also when we have local route origination, we are also put that information into our local BGP table.   From that BGP table we then run the BGP Best Path Decision Making Algorithm and 1 Best Path is chosen.

So let’s see it in an example of what actually happens.

Below we have 3 routers – Router10, in AS 10.  Router21 in AS 21.  And Router22 in AS22.  Router10 and Router21 are eBGP peered with each other using their directly connected link.  Router10 and Router22 are also eBGP peered with each other also using just their directly connected link.  

These will be simple “neighbor” statements using no route-maps, no filters, etc. 

Neighbors Just Came Up – No Prefixes Learned Yet

As we can see from the result of show ip bgp summary, on Router10, we have learned nothing so far from our 2 eBGP neighbors (notice that far right hand column “State/PfxRcd” is “0”).  

Now notice also that the “BGP table version”  is “1”.  That the “main routing table version” is “1” and that the “TblVer” (table version) column for each of the BGP neighbors is also a “1”.  I used to honestly wonder why we didn’t just start with BGP table version 0.  If the BGP table is empty and no best path is selected, why isn’t it a zero?   I have finally let it go and accepted that it just is what it is. 

Router21 Advertise’s its Loopback into BGP

Let’s go to Router21 and advertise it’s loopback (21.21.21.21/32) into BGP.  

As we can see from the result of show ip bgp summary, on Router10, we have learned one prefix from neighbor 10.10.21.2 (Router21). 

Now notice also that the “BGP table version”  is “2”.  That the “main routing table version” is “2” and that the “TblVer” (table version) column for each of the BGP neighbors is also a “2”.   

So what EXACTLY happened?  Let’s take this step by step.

1) Update comes in

2) INFO put in BGP TABLE

3) BGP Best Path Algorithm Run

4) ACT on Any New Best Paths

When the BGP Best Path Algorithm is run, it will yield a new BGP best path to 21.21.21.21/32.  What do I mean when I say to “ACT on Any New Best Paths”?   Obviously two things need to happen after we have come up with a new BGP best path —

1) we need to update our RIB (main routing table) to reflect this new best path

2) we need to inform all our BGP neighbors about this new best path

AND we need to know and keep track of insuring we did the above two things.  — enter BGP TABLE VERSION!!!!    

The BGP table is stored in a radix tree based on table version number.  It is very efficient to say “show me every node on the tree with a table version between X and Y”.  This makes it easy to walk subset of the tree to update a peer, the RIB, etc.

If there is a change to one BGP best path then first we increment the BGP table version to reflect that we have a new best path.  We now know there is work to be done.  Once we have done this work we keep track of the fact that we have done this.  One piece of work is to update the RIB.  Once we have done that we increment the main routing table version.  Another piece of work is to update each and every BGP peer that we have.  THAT is the BGP table version column that you see associated with each and every BGP peer when you do show ip bgp summary.   AND if there is a LOT of new best paths to tell them about you will probably see a decent sized delta between our current BGP table version and the BGP table version associated with that BGP peer.  If there is a sizeable enough difference, you may also see the OutQ column reflecting that it is sending updates out to this neighbor.  Eventually, the OutQ column should quiet back down and the BGP table version for that BGP peer should be in sync with the main BGP table version.  

How do we know what prefixes to send?  That is the wicked cool, but very simplistic thing,  each best path gets “tracked” or “timestamped”, if you will, with the BGP table version associated with that new best path change.  So check it out.  If, on Router10, you do a show ip bgp 21.21.21.21 you will notice that it has a “version 2” associated with it.  SO when Router10 updates Router22 it knows that Router22 needs “all” new best paths since table version 1.  This is just the one best path change – which has the “version 2” on it.  

Router22 Advertise’s its Loopback into BGP

Let’s go to Router22 and advertise it’s loopback (22.22.22.22/32) into BGP.  

So let’s talk about what is going to happen.

1) Router10 is going to get a BGP update from Router22 advertising about 22.22.22.22/32

2) Router10 is going to put this update into its BGP table

3) Router10 is going to run the BGP Best Path Algorithm

4) Router10 is going to yield a new best path for 22.22.22.22/32

5) Router10 is going to

• increase it’s BGP table version by 1 since it found 1 new best path
• locally “stamp” 22.22.22.22/32 with BGP table version 3
• update the RIB (main routing table) with this new best path (and increment the table version associated with it)
• update each BGP neighbor with this new best path (and increment the table version associated with each neighbor as we do the work)

We can see below that all the “work” has been done and tracked and all the table versions are in sync.  

Router10 Locally Originates a Prefix 

Let’s now advertise into BGP Router10’s own loopback address.  

1) INFO put in BGP TABLE

2) BGP Best Path Algorithm Run

3) ACT on Any New Best Paths

So let’s talk about what is going to happen.

1) Router10 is going to locally originate a route to its Loopback 10.10.10.10/32 and put it into its BGP table

2) Router10 is going to run the BGP Best Path Algorithm

3) Router10 is going to yield a new best path for 10.10.10.10/32

4) Router10 is going to

• increase it’s BGP table version by 1 since it found 1 new best path
• locally “stamp” 10.10.10.10/32 with BGP table version 4
• update the RIB (main routing table) with this new best path (and increment the table version associated with it)
• update each BGP neighbor with this new best path (and increment the table version associated with each neighbor as we do the work)

eBGP Peer Router21 and Router22

Let’s have a little more fun.  Right now it seems that everytime we add something to the BGP table, our BGP table version goes up.  Of course, that doesn’t always happen.  In our case what we put into the BGP table has thus far been the BEST path cause it is also the ONLY valid path.  So let’s connect Router21 to Router22.  Since we are doing eBGP, this means that Router21 will also tell Router10 about Router22’s loopback.  And Router22 will also tell Router10 about Router21’s looback.  

Question: Will the BGP table version number increase on Router10?

Answer: ????   ………

…… Answer: No.  

Why should the BGP table version change?  There are no new best paths.

Summary of Introduction

As we have seen, the BGP table version increases by 1 for every new BGP best path, not for every received BGP update/advertisement.  The BGP table version ONLY increments when the is a change to a BGP best path.  For this very reason you can see how using the BGP table version for troubleshooting is exceedingly helpful.    

Troubleshooting high CPU?  Check your BGP table version.  Is it constantly increasing?  Well, then you have new BGP best paths and you are just doing the “work” of keeping all your BGP peers “up to date” on the latest and greatest best paths.  If the rate of best path changes is higher than you are expecting, then you need to figure out WHY you keep having best path changes.

……… Next Blogs – 

Understanding the BGP Table Version – Part 2: More Intro

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