Bidirectional Forwarding Detection (BFD) is a UDP-based protocol that provides fast (very fast!) routing protocol independent detection of layer-3 next hop failures. BFD can be used to replace the routing protocol timers with a fast and reliable failure detection mechanism. BFD also provides low-overhead detection of faults even on interfaces that don’t support failure detection of any kind, such as Ethernet, virtual circuits, tunnels and MPLS Label Switched Paths.
Introduction to BFD
The inner workings of the BFD protocol resemble the hello mechanisms used in most of today’s routing protocols, with a few exceptions. BFD packets can be processed on interface modules, whereas routing protocol hello packets are always processed by the control plane. BFD tests bidirectional communication. The hello protocol that EIGRP uses has been known to have issues with detecting unidirectional connections. Finally, BFD packets are typically smaller than keepalive packets from routing protocols. (24bytes + headers)
The Bidirectional Forwarding Detection protocol supports two primary modes of operation, asynchronous mode and demand mode. Although Cisco only supports BFD in asynchronous mode, which depends on the sending of control packets between two systems to activate and maintain BFD neighbor sessions between routers. In order for a BFD session to be created, you must configure BFD on both systems. Once a BFD session has been established and timer negations are complete, BFD peers send BFD control packets that act in the same manner as an IGP hello protocol to detect liveliness, but at a more accelerated rate. Also, Cisco devices will only use one BFD session for multiple client protocols. For example, if a network is running OSPF and EIGRP across the same link to the same peer, only one BFD session will be established, and BFD will share session information with both routing protocols.
BFD is a forwarding path failure detection protocol. BFD can detect failures, but the routing protocol must take action to bypass a failed peer.
One option you may wish to configure is Echo Mode, which works with asynchronous BFD. Echo packets are sent by the forwarding engine and forwarded back along the same path in order to perform detection—the BFD session at the other end does not participate in the actual forwarding of the echo packets. The echo function and the forwarding engine are responsible for the detection process, therefore the number of BFD control packets that are sent out between two BFD neighbors is reduced. And since the forwarding engine is testing the forwarding path on the remote (neighbor) system without involving the remote system, there is an opportunity to improve the interpacket delay variance, thereby achieving quicker failure detection times than when using BFD Version 0 with BFD control packets for the BFD session.
BFD timers are configured under each interface with the bfd interval [send-timer] min_rx [receive-timer] multiplier [number] command. The send-timer specifies the frequency of BFD packets originated by the router, the receive-timer the minimum interval between packets accepted from BFD peers. The multiplier number is the number of BFD packets that can be lost before the BFD peer is declared down. If you want to use the BFD echo mode, you should configure bfd slow-timers to specify the interval at which the control packets are sent and bfd echo on the interface to enable BFD echo mode.
BFD adjacency will not form if the send-timer on one peer is lower than the receive-timer on another peer.
Router(config)#bfd slow-timers 3000 Router(config)#interface fa0/0 Router(config-if)#bfd interval 100 min_rx 100 multiplier 3 Router(config-if)#bfd echo
Due to BFD’s low overhead it’s fairly common to use BFD timers in the milliseconds range. Although the lowest value allowed by Cisco’s IOS is 50 milliseconds.
After you’ve configured BFD on individual interfaces you have to tell the routing protocols to use it. In most cases, there’s no reason the routing protocols would not want to use BFD wherever possible; the only command you have to use in these scenarios is the bfd all-interfaces command.
Router(config)#router eigrp 65501 Router(config-router)#bfd all-interfaces
If you want to be more specific, you can enable/disable BFD on a per interface basis. While the commands may vary, with OSPF we use the ip ospf bfd [disable] interface configuration command.
Router(config)#interface fa0/0 Router(config-if)#ip ospf bfd Router(config-if)#bfd interval 100 min_rx 100 multiplier 3
As with our IGP, BGP can use BFD to detect failures of directly connected neighbors. Neighbors must be on a directly connected subnet (multi-hop is not supported). BFD is configured per-neighbor with the neighbor fall-over bfd command. The following configuration uses BFD to detect failures of two BGP neighbors.
Router(config)#router bgp 65001 Router(config-router)#neighbor 198.19.8.1 remote-as 65022 Router(config-router)#neighbor 198.19.8.1 fall-over bfd Router(config-router)#neighbor 172.16.0.12 remote-as 65001 Router(config-router)#neighbor 172.16.0.12 update-source Loopback0 Router(config-router)#neighbor 172.16.0.12 fall-over bfd
Testing BFD Failures
I setup a quick and dirty lab to show how fast BFD can, and will failover on an Ethernet circuit. I have 3 routers, all connected via FastEthernet running OSPF. Times are synchronized using NTP to ensure log messages are accurate. The following output demonstrates the OSPF connections from R1 to R2, and R3. Only the connection between R1 and R2 has BFD configured.
R1#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 18.104.22.168 1 FULL/DR 00:00:37 10.1.2.2 FastEthernet0/0 22.214.171.124 1 FULL/BDR 00:00:37 10.1.3.3 FastEthernet0/1 R1#show bfd neighbor OurAddr NeighAddr LD/RD RH/RS Holddown(mult) State Int 10.1.3.1 10.1.3.3 1/2 Up 0 (3 ) Up Fa0/1
You may also want to check out the show bfd neighbors details command. It will show you which protocols have registered with BFD.
Obviously in my example, without BFD configured on fa0/0, failure-detection relies exclusively on OSPF hello timers. Hence it took R0 almost 30 seconds I shut down the interface to realize R2 was gone.
R0#show clock *19:52:11.122 UTC Fri May 21 2010 R1(config)#int fa 0/0 R1(config-if)#shut R1(config-if)# 19:52:13.115: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down R2# 19:52:42.643: %OSPF-5-ADJCHG: Process 1, Nbr 126.96.36.199 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Dead timer expired
With BFD in place, the situation is entirely reversed… R3 detected that R1 was gone before R1 generated the syslog message indicating that the interface had been shutdown.
R1(config)#int fa 0/1 R1(config-if)#shut R1(config-if)# 20:04:10.204: %OSPF-5-ADJCHG: Process 1, Nbr on FastEthernet0/1 from FULL to DOWN, Neighbor Down: Interface down or detached 20:04:12.202: %LINK-5-CHANGED: Interface FastEthernet0/1, changed state to administratively down R3# 20:04:10.511: %OSPF-5-ADJCHG: Process 1, Nbr 188.8.131.52 on FastEthernet0/1 from FULL to DOWN, Neighbor Down: BFD node down
As you can see, BFD is a seriously fantastic protocol. Its one of my favorite tools when working with WISPS since so many radios don’t take interfaces down when links fail, not to mention the fact that its fairly common for WISPS to use switches in between their routers and radios to isolate them even further from lightening damage.
If you want to try this at home, you’ll need an ISR running a fairly recent IOS. I used 12.4(24)T for my examples. If you wish to take a look at the Cisco BFD Configuration Guide, it can be found here. As always, if you have any comments or questions, please feel free to leave me a comment below and I’ll get back with you as soon as I can.
Network engineer currently servicing the enterprise data center market. I started working on networks in the ’90s and still feel like that was just a few years ago. Jack of all trades, master of none; I love to learn about everything. Feel free to ask me about photography, woodworking, nhra, watches, or even networking! — For feedback, please leave a comment on the article in question, and I’ll gladly moderate it several weeks later. For everything else including fan mail or death threats, contact me via twitter.