Bidirectional Forwarding Detection (BFD) is a system that can find broken links between two routers that are next to each other within milliseconds or even microseconds. There is a way for most routing systems to find down links. In OSPF, there are hello packets and the dead period. In EIGRP, there are hello packets and a holddown timer. These systems are slow to figure out when something has gone wrong because they depend on the control plane. But networks that handle real-time data, like VoIP, need convergence times that are very short. The only thing that comes close is the way that routing algorithms reduce timers, but BFD is always faster.
BFD was made to move quickly. Some interface modules or line cards can handle its packets, so there isn’t a lot of extra work to do. BFD works without routing protocols, but once it’s up and running, you can tell the routing protocols to use BFD instead of their own methods to find links that aren’t working. When compared to routing protocols, which work in the control plane, BFD works in the forwarding plane.
The best thing that could be done to stop BFD would be to use the IGP detection mechanisms and make their timers as short as possible. BFD still has these benefits over the limited IGP timer implementation:
- Even with capabilities in the sub-second range, BFD is still faster.
- It is possible to utilize BFD as the failure detection method for any of the supported protocols like EIGRP, IS-IS, OSPF because it is a generic technique.
- It is possible that minimizing IGP timers will require more CPU resources than BFD, which is because certain components of BFD can be moved to the data plane.
This means that BFD is turned on at both the interface and protocol levels. For a BFD session to be made, BFD needs to be set up on both computers. Once there is a BFD session, BFD timers are set, and at the agreed upon time, the BFD peers will start sending BFD control packets to each other.
There are two ways that BFD can work: asynchronous and demand forms. In asynchronous mode, BFD keeps sending hello packets, which are also known as BFD control packets. If you don’t receive some of them, the session ends. This is similar to the hello and holddown timers. As of now, none of the vendors offer poll-based demand mode. In order for asynchronous mode to work, BFD must be turned on and working on both ends of the link.
It doesn’t matter how many Layers 3 routing protocols rely on the BFD process in the Cisco implementation; it only runs once. For Cisco BFD to work, CEF must also be turned on. For BFD to work, the devices that are running it must be no more than one hop away from each other. Keep in mind that this changed in IOS 15.3.
Echo Mode for BFD
You can use echo mode in both modes. Although BFD echo packets are sent down the forwarding path by devices, the BFD session on the receiving end is not involved in the actual forwarding process. While this does increase the time it takes to notice a link failure, it decreases the amount of control packets that need to be sent out because no processing needs to happen at the distant end. The default setting is to enable BFD echo mode. Ingress interface filtering of BFD echo packets is something you must avoid at all costs.
You won’t need to transmit BFD control packets as often when using echo mode because it may move fast without halting the CPU and it will detect any outage. At this point, the slow-timer becomes useful. The frequency of BFD control packets, not echo packets, is reduced by lowering the slow-timer. A default value of 2000 ms is used for the slow timer. The slow timer is illustrated below with an example. Here, Echo is enabled, but keep in mind that this is how iOS often works.
R10(config)# bfd slow-timer 15000
R10(config)# interface GigabitEthernet0/1
R10(config-if)# bfd echo
It is the class class-default command that is responsible for matching BFD packets. It is therefore the responsibility of the user to ensure that there is sufficient bandwidth available in order to avoid the loss of BFD packets as a result of oversubscription happening.
Configuration of the BFD
As shown below, you first enable BDF on an interface.
R10(conf)# interface GigabitEthernet0/1
R10(conf-if)# bfd interval <milliseconds> min_rx <milliseconds> multiplier <MULTIPLIER>
R1(conf-if)# end
The multiplier in BFD is responsible for determining the minimum number of consecutive packets that is allowed to be missed before a session is considered to be down.
The BFD is not beneficial on its own, in all honesty. In order for BFD to be of any use, it is necessary to enable another client or protocol to use it for connection failure notification. Protocols such as OSPF, EIGRP, BGP, IS-IS, and HSRP are examples of optional protocols.
