Bidirectional Forwarding Detection

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.

Echo Mode

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 Configuration

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.

IGP Configuration

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

BGP Configuration

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
2.2.2.2           1   FULL/DR         00:00:37    10.1.2.2        FastEthernet0/0
3.3.3.3           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 1.1.1.1 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 1.1.1.1 on FastEthernet0/1 from FULL to DOWN,
 Neighbor Down: BFD node down

Final Thoughts

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.