Diving into the BGP Table

First a Look at the Local BGP Table

Before we begin… let’s take a look at the BGP table. One would assume (rightly so) that anything called the “BGP table version” probably is tied somehow to the BGP table. 🙂

What information is in the BGP table?  How did it get there?

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 also put that information into our local BGP table.

So the BGP table gets

• updates from BGP peers
• local route origination

It is from that BGP table that the BGP Best Path Decision Making Algorithm gets run and 1 Best Path is chosen.

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

The Topology

Below we have 3 routers:

• Router10, in AS 10
• Router21 in AS 21
• 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 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”.
• “main routing table version” is “1”
• “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.

Router 21 Advertises Its Loopback into BGP

Router21 has had its loopback added to BGP.  As such, Router21 will now advertise its loopback (21.21.21.21/32) out to Router10.

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).

R21 Learns One Prefix, Table Version Goes to 2

Now notice also that the

• “BGP table version”  is “2”
• “main routing table version” is “2”
• “TblVer” (table version) column for each of the BGP neighbors is also a “2”.

Step By Step

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.  This is where the BGP Table Version enters the picture.  🙂

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 the 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.

Updating the RIB

One piece of work is to update the RIB.  Once we have done that we increment the main routing table version.  

Updating Each and Every BGP Peer

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 size-able 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 Advertises its Loopback into BGP

Router22 has had its loopback added to BGP.  As such, Router22 will now advertise its loopback (22.22.22.22/32) out to Router10.

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 then going to do the following
   • 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 

Router10 has now had its loopback added to BGP.

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 every time 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 loopback.

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 In This Series

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

Understanding the BGP Table Version – Part 3: BGP Table Version & Troubleshooting