{"id":5091,"date":"2026-03-22T14:26:31","date_gmt":"2026-03-22T14:26:31","guid":{"rendered":"https:\/\/geekmungus.co.uk\/?p=5091"},"modified":"2026-03-22T14:26:31","modified_gmt":"2026-03-22T14:26:31","slug":"bgp-test-lab-part-17-bgp-with-bidirectional-forwarding-detection-bfd","status":"publish","type":"post","link":"https:\/\/geekmungus.co.uk\/?p=5091","title":{"rendered":"BGP Test Lab – Part 17 – BGP with Bidirectional Forwarding Detection (BFD)"},"content":{"rendered":"\n
In previous articles, we have mentioned the use of BFD – Bidirectional Forwarding Detection. RFC 5880.<\/p>\n\n\n\n
Essentially BGP failure detection is slow by design and for good reason when you are dealing with truly massive networks. BFD exists to make it fast, but also while being safe too.<\/p>\n\n\n\n
As was discussed in previous articles BGP detects failures slowly, by default the Keepalive Timer is 60 seconds, the Hold Timer is 180 seconds. Which means if a link silently fails, i.e. it stays up (no TCP reset) but stops forwarding traffic it may take up to 180 seconds for BGP to declare the neighbour dead and start to re-route traffic. Behaviour such as this is fine for Internet-Scale stability but is not fine for Data Centres, Core Networks or Low-Latency environments.<\/p>\n\n\n\n
As mentioned before, you can tweak the Keepalive and Hold Timers to reduce this time, but the shorter the time, the more “twitchy” your network becomes to failed or flapping links. <\/p>\n\n\n\n
BFD (Bidirectional Forwarding Detection) can be used to resolve these issues. It is a lightweight protocol, which is designed specifically to detect link\/forwarding failures, and it is independent of any routing protocol, meaning you can use it with BGP, OSPF, EIGRP or even static routes, and provides an extremely fast (potentially sub-second) protocol. <\/p>\n\n\n\n
Put in simple terms BFD is a heartbeat protocol that various routing protocols (such as BGP, OSPF or EIGRP) can subscribe to be informed of if a neighbour is dead, long before the mechanisms of the actual routing protocol kick in.<\/p>\n\n\n\n
BFD does not exchange routes, it just says: \u201cForwarding to this neighbour is working\u201d or \u201cForwarding is broken\u201d, the routing protocol above, then acts based on this.<\/p>\n\n\n\n
Topology<\/h1>\n\n\n\n
We will be setting up BFD between Router K and Router L, because these are the only two Routers we have that are sufficiently new to have software support for BFD!<\/p>\n\n\n\n<\/figure>\n\n\n\n
Topology Changes<\/h1>\n\n\n\n
We had a problem with Router K, so it needed to be replaced, so the port numbers had to change, the configuration needed to be re-applied and use different ports, however the rest of the configuration on Router F and Router L remained as it was.<\/p>\n\n\n\n
So now everything is configured, we’re ready to start the BFD configuration, but before that, let’s find out how it actually works.<\/p>\n\n\n\n
How does it work?<\/h1>\n\n\n\n
BFD has two main modes of operation, asynchronous mode<\/strong> (most common) and demand mode<\/strong>. We’ll start with asynchronous mode<\/strong>, this works similar to the hello and Hold Down Timers, BFD continuously sends hello packets (BFD control packets), when a number of them are not received, it signals to any “subscribed” routing protocol (above) and those tear down the BGP neighbour or OSPF adjacency etc. without having to wait for the normal BGP, OSPF (or whatever) timer to expire.<\/p>\n\n\n\n
Demand mode<\/strong> is different, rather than constantly sending control packets (hello packets), BFD instead just using some other method such as monitoring the receive and transmit statistics of the interface, in normal operation, even if the link is idle, the statistics would be constantly incrementing (albeit slowly) due to the hello packets of the routing protocol, if it stops seeing activity, it deems the link failed, and signals to the routing protocol and that tears down the session.<\/p>\n\n\n\n
Additionally, there is something called echo mode<\/strong>, this where a router sends a BFD echo packet, which the receiver then returns without processing them, if the sender stops getting these echo packets back, it knows there is a problem and signals to the routing protocol (above) the issue and that then tears down the session. You might want to use echo mode to reduce the load on the control plane of the Router(s), when using echo mode (optional), part of the monitoring is offloaded to the data plan (rather than the control plane), which means these echo packets are returned to the sender without requiring the remote Router’s control plane to be utilised.<\/p>\n\n\n\n
Example Configuration<\/h1>\n\n\n\n
OK, so let’s try this out and see what happens. We’re going to configure BFD on the eBGP peering between Router K and Router L.<\/p>\n\n\n\n
When we activate BFD, we need to activate BFD first on the VLAN that is used for the point to point link between the two routers; otherwise BFD will show up saying it is “Administratively Down”.<\/p>\n\n\n\n
We must disable that BGP Neighbour (peering) first, then configure, then re-enable, after which BFD is enabled, of course you must do this on both sides of the link before BFD will actually be able to work correctly. At this stage we are going with the default settings, which means a TX\/RX Interval of 1000ms (1 Second), then a Multiplier of 3, meaning it will wait for 3 failed BFD Hello’s before it deems there is an issue, i.e. 3 seconds, much quicker than our BGP Keepalive and Hold Timer which means up to 180 seconds before BGP can detect an issue.<\/p>\n\n\n\n
That’s all you need to configure, now we can verify and see what BFD is doing.<\/p>\n\n\n\n
If we run the following on both routers:<\/p>\n\n\n\n
show bfd session<\/code><\/pre>\n\n\n\n
We get an output like:<\/p>\n\n\n\n<\/figure>\n\n\n\n
OK, so looking into this we can see that BFD is enabled on the RK-RL VLAN, and that it has subscribed a client in this case BGP to this BFD session.<\/p>\n\n\n\n
Going a bit deeper by running: show bfd session detail<\/strong>, we see:<\/p>\n\n\n\n<\/figure>\n\n\n\n
There are a few interesting things to mention in this output, you’ve obviously got the common things like the interface and neighbour IP addresses, but its some of the others.<\/p>\n\n\n\n
Session Type<\/h3>\n\n\n\n
Single Hop in this case, because the two routers are directly connected, however if the BFD was flowing through one or more intermediate devices, this would become “multi-hop”.<\/p>\n\n\n\n
Discriminator<\/h3>\n\n\n\n
The discriminator is an important part of BFD. A discriminator allows for the transmitting Router to identify each of the multiple BFD sessions which may be running on the same interface and or between the same pair of systems. Without this a transmitting Router would not be able to identify each of the BFD sessions it is sending, and additionally a receiving Router would not either.<\/p>\n\n\n\n
\n
My Discriminator (MY_DISC or Local Discriminator)\u00a0<\/strong>– A unique, non-zero discriminator value generated by the BFD sending router (Router K in the outputs above).\u00a0<\/li>\n\n\n\n
Your Discriminator (YOUR_DISC or Remote Discriminator)<\/strong>\u00a0– The discriminator received from the remote router, remote system (Router L in the outputs above). This field is the received value of My Discriminator (from the remote router, Router L in this example), or is zero if that value is unknown.<\/li>\n<\/ul>\n\n\n\n
In our example the My Discriminator (MY_DISC or Local Discriminator)<\/strong> for Router K is set to 1, the Your Discriminator (YOUR_DISC or Remote Discriminator)<\/strong> of Router L is also set to 1 too. But this is not essential. They can be different, because the Your Discriminator (Remote Discriminator) is generated by the remote router, Router L in this instance and could be any random number.<\/p>\n\n\n\n<\/figure>\n\n\n\n
Local Diag and Remote Diag<\/h3>\n\n\n\n
These are diagnostic codes that can give you an idea of the cause of any BFD failure. A diagnostic code specifying the local router’s reason for the last transition of the state from UP to DOWN or some other state.<\/p>\n\n\n\n
In our example we can see these are both showing 0 (for no diagnostic), if however I was to disable the port between Router K and Router L, this would read 7 (for administrative down).<\/p>\n\n\n\n
Simulate a Failure – with BFD<\/h2>\n\n\n\n
Now we have BFD enabled, let’s see what happens during a failure, we’ll then repeat the test with BFD turned off, so you can see the difference.<\/p>\n\n\n\n
We’ll shut down the link between Router K and Router L with: disable port 104.<\/strong><\/p>\n\n\n\n
Looking at Router L, we see the following immediately<\/strong>, the BFD Session is showing down, and the BGP Neighbour has transitioned to the IDLE state immediately, well within no more than 3 seconds or so.<\/p>\n\n\n\n<\/figure>\n\n\n\n<\/figure>\n\n\n\n
Liven up the link again, and then we’ll test without BFD enabled.<\/p>\n\n\n\n
Simulate a Failure – without BFD<\/h2>\n\n\n\n
We’ll first turn off BFD, remember you need to disable the BGP Neighbour (peer) configuration, then turn off BFD, then re-enable the BGP Neighbour again.<\/p>\n\n\n\n
We’ll now re-run the test and disable the link between Router K and Router L, then see how long it takes now we don’t have BFD monitoring the link.<\/p>\n\n\n\n
We’ll shut down the link between Router K and Router L with: disable port 104.<\/strong><\/p>\n\n\n\n<\/figure>\n\n\n\n
If we run a: show\u00a0bgp\u00a0neighbour 192.168.100.65 we see the following, the output has been cut to focus on the important bit(s):<\/p>\n\n\n\n<\/figure>\n\n\n\n
We had a stopwatch running, and it took just over 45 seconds for the BGP Neighbour to move the ESTABLISHED state to the IDLE state, during which Router K and Router L would both think that this was a valid and working path and would be attempting to send traffic down it. In our example we only have a single link between these two routers, but if there were multiple routes between these routers, or between the AS Red and AS Purple, then for that period of time connectivity would have been disrupted (for 45 seconds) until the network determined this path was no longer valid and re-routing traffic via a different route between the two networks, not ideal, therefore showing the value of BFD in these kinds of situations!<\/p>\n\n\n\n
Examining the output above, specifically the bits highlighted in red, we can see the state “IDLE”, the Hold Timer being 45 seconds, hence why it determined the failure within about 45 seconds, rather than the default of 180 seconds! Then we have the state information, and we can see that the reason that the state changed was due to the “Hold Timer Expired”, which was obviously the case being that the link was down and three Keepalive messages would have been missed.<\/p>\n\n\n\n
Before going any further, we’ll re-enable BFD on Router K and Router L, and bring the link back up and running.<\/p>\n\n\n\n
Tweak Settings<\/h2>\n\n\n\n
You’ll notice that there are some settings that can be tweaked with regard to BFD, you adjust these on the VLAN, rather than the BGP Neighbour configuration, the output below shows you want kind of settings you can tweak.<\/p>\n\n\n\n<\/figure>\n\n\n\n
The authentication allows you to specify a password to be used for authentication of the BFD session, depending on your environment you may want this configured to ensure that your BFD session is set with who you expect it to be, especially useful when crossing an AS boundary, where you don’t have visibility or control over the other end of a link (also running BFD).<\/p>\n\n\n\n
The other three are fairly self-explanatory, but these are the Receive Interval<\/strong> and Transmit Interval<\/strong>; so the rate at which the BFD packets are sent and expected to be received at, the default being 1000ms (1 second), the Detection Multiplier<\/strong> is the number of these Receive Intervals that can be missed before BFD decides that the link is down and notifies any subscribing protocols (such as BGP).<\/p>\n\n\n\n
Its also worth mentioning BFD Hardware Assist (on Extreme Networks XOS), which allows for the BFD process to be offloaded to hardware, rather than operating in software; the benefit of this is that now you have the ability to shorten the intervals yet further (if you need to), to only a few milliseconds if required, which if you were attempting to do this without Hardware Assist, risks false positives due to the fluctuations of latency if\/when the Router CPUs get busy.<\/p>\n\n\n\n
![\"\"](\"https:\/\/geekmungus.co.uk\/wp-content\/uploads\/2026\/03\/image-111-1024x709.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/geekmungus.co.uk\/wp-content\/uploads\/2026\/03\/image-112.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/geekmungus.co.uk\/wp-content\/uploads\/2026\/03\/image-113.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/geekmungus.co.uk\/wp-content\/uploads\/2026\/03\/image-114.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/geekmungus.co.uk\/wp-content\/uploads\/2026\/03\/image-115.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/geekmungus.co.uk\/wp-content\/uploads\/2026\/03\/image-116.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/geekmungus.co.uk\/wp-content\/uploads\/2026\/03\/image-117.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/geekmungus.co.uk\/wp-content\/uploads\/2026\/03\/image-118.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/geekmungus.co.uk\/wp-content\/uploads\/2026\/03\/image-119.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/geekmungus.co.uk\/wp-content\/uploads\/2026\/03\/image-120.png\")
<\/figure>\n\n\n\n