BFD: Bidirectional Forwarding Detection.

This article is about explaining what BFD is and where you can use it.

BFD’s RFC 5880 offers a good quote on the goal of BFD: ‘The goal of Bidirectional Forwarding Detection (BFD) is to provide low-overhead, short-duration detection of failures in the path between adjacent forwarding engines, including the interfaces, data link(s), and, to the extent possible, the forwarding engines themselves.’

Basically, the whole purpose of BFD is to verify connectivity between a pair of systems. Because BFD was developed as a very low overhead protocol, it is possible to detect failures very quickly without taking up a lot of resources. Many vendors have been able to make BFD run in hardware, even on their low end systems. This means that BFD packets will not hit the routing engine and the performance price to pay for fast detection becomes extremely low .

Besides being designed with low-overhead in mind, BFD was also designed to be used as a service to various other protocols. BFD offers a common method to manage timers for various protocols.


BFD is often called a liveness detection protocol. This is because BFD will not take any action itself when a loss of connectivity between two systems is detected. You could say that BFDs sole purpose is to verify connectivity between a pair of systems. The protocols using BFD can rely on the connectivity information BFD provides them with. A lot of vendors allow the use of BFD to detect failures for OSPF, IS-IS, BGP, RSVP and static routes.

Take a look at the following example:


Here you can see two routers. They are running OSPF and they have formed a neighbor relationship across an Ethernet switched network. The OSPF timers have been left at their default, so on this point-to-point link, a 10 second hello timer will lead to a detection time of 40 seconds. Any intermediate component that fails can potentially generate up to 40 seconds of down-time. However, the routers are also running BFD and they are configured to send a BFD packet every 100ms. A multiplier of 3 has been configured for BFD, so the time it takes the routers to detect that the path to neighboring system is down is 300ms.

Now, let’s say the path between the two routers is interrupted because the link between the intermediary switches has failed:


Instead of having to wait for the OSPF Dead interval to pass by, BFD will detect this failure in 300ms. It will present this information to OSPF allowing OSPF to declare the neighbor as dead. With a 10 second Hello interval, OSPF is able to take actions to bypass the failed link within 300ms.

Another example where BFD can come in quite handy is when systems rely on several other layer 3 devices to reach their neighbor. This can be the case for IBGP or EBGP multihop sessions that traverse multiple layer 3 devices:


BGP has a minimum hold-time of 0 or at least 3 seconds. By using BFD, the hold-time of 0, actually stopping the exchange of keepalives between the BGP peers, becomes an option.

One last option I wanted to mention is one that is overlooked very often. BFD can also be used in combination with a static route:


So instead of using a ping or a tracking mechanism, BFD packets exchanged in hardware between two systems can offer an extremely fast detection time.

Every vendor offers their own implementation of BFD and the implementation can very between the different models and software levels. To see what is possible on your own equipment, check out your vendors documentation. For more on the BFD protocol there are several RFCs you can read. RFC 5880 is about the protocol. RFC 5882 is about where you can use it and references several other RFCs on BFD as well.

For some Juniper configuration examples, check this out.