We all know BGP is the routing protocol of choice for the internet. It's also heavily used in the private WAN space and certainly has its uses in the enterprise.
However it has one big hurdle: Convergence time. Left to it's defaults on Cisco gear it's going to be 180 seconds, which is fine for the internet, but no good for a lot of private production networks.
So here's our scenario; we work for a manufacturer, and they purchase a company that makes a component of our existing products. The manufacturing engineers want to start merging various functions of the two assembly lines, we don't care about the ins and outs, we only care about how to connect the two assembly lines. The only issue is the IT department is no where near ready to merge the two networks so we're going to use BGP between the networks. During testing it was found that the very long convergence times of BGP following a failure on the primary circuit were simply unacceptable for the assembly line engineers.
Here's our topology:
Each routers IP corresponds with the router ID, eg R2's IP addresses all end in .2 no matter what the subnet.
In the current set up, R6 can ping R1 via the primary circuit on the left. The secondary circuit is being "downgraded" by the way of AS prepending on the BGP neighbours.
To show the in the default state of BGP how long the failover is, here is a GIF of R6 pinging R1 and me shutting down Gi0/1 on R2.
That is just a crazy amount of time!
How can we fix this? Well, we could tweak the BGP timers to reduce the time significantly, but you'll never get it low enough to be considered "near instant". The best option we have in this scenario is BFD!
BFD (or Bidirectional Forwarding Detection) is an open standard defined in RFC5880. It fills a function not provided by many of the physical media we use today such as ethernet which is fault detection. BFD is a point to point protocol and can be used on physical media such as an ethernet cable between two devices or a logical "virtual circuit" such as a layer 2 EoMPLS link.
The protocol works by creating a BFD session between two endpoints and then sending a consistent stream of "hellos" to each other and replying back. If a reply is not received in the configured amount of time the link is considered down. The important thing about this process is that it is sub-second.
Let's configure it!
Let's load up R2. I'm going to enter interface gi0/1 and configure BFD with one command:
R2>en R2#conf t Enter configuration commands, one per line. End with CNTL/Z. R2(config)#int gi0/1 R2(config-if)#bfd interval 50 min_rx 50 multiplier 3
Let's match up the values we are putting here with the RFC. So the value after "interval" is the "min_tx" and the second value is obviously the "min_rx". The multiplier is how many BFD packets we miss before considering the link down.
When we configure two devices with BFD, the settings do not need to be the same but it makes it simpler if they are! During the initial BFD neighbourship formation these values are negotiated and the highest (or slowest) time will win. We'll demonstrate this with our two routers. R2 is going to be configured with 50, but we'll configured R4 with 75 and we will look at which it picks.
R2#show bfd neighbors details IPv4 Sessions NeighAddr LD/RD RH/RS State Int 172.16.24.4 1/1 Up Up Gi0/1 Session state is UP and using echo function with 75 ms interval.
It picked 75! This is because if we have two routers of differing capabilities (maybe age or just vendor support) then there's no good expecting a packet every 50ms if the other side can only send every 75ms.
Now we want to register BGP with BFD so we can use BFD to tell BGP when a link has failed, instead of relying on BGPs hold-timers. This is done under the neighbour config and is incredibly simple:
R2(config)#router bgp 100 R2(config-router)#neighbor 172.16.24.4 fall-over bfd R4(config)#router bgp 200 R4(config-router)#neighbor 172.16.24.2 fall-over bfd
That's all! Let's look at the ping test again!
We only lost 1 packet in this ping! This is a much better improvement over the previous test!
It really is that simple to decrease failover time with BFD, and it is much less resource intensive than decreasing the BGP timers as it's specifically designed for this purpose!
What's really cool about this to me in my personal experience, BFD on many times has been the difference between people noticing a major WAN failure and not. With BFD enabled in scenarios like this, it's barely enough of a gap for it to be noticeable on phone calls and certainly not on video calls meaning less time dealing with complaints and more time spent dealing with the actual fault while the users happily use the backup!