Category Archives: BFD

Bidirectional Forwarding Detection (BFD)

Bidirectional Forwarding Detection
– A detection protocol designed to provide fast forwarding path failure detection times for all media types, encapsulations, topologies, and routing protocols.
– Sub-second detection of a problem between our neighbors.
– The quick we detect a problem between our neighbors the quicker we can converge around it.

Supported Software Version (
1. IOS XE 16.6.2

Prerequisites for BFD
1. Cisco Express Forwarding and IP routing must be enabled on all participating routers.
2. One of the IP routing protocols supported by BFD must be configured on the routers before BFD is
deployed. You should implement fast convergence for the routing protocol that you are using. See the
IP routing documentation for your version of Cisco IOS software for information on configuring fast convergence. See the Restrictions for Bidirectional Forwarding Detection section for more information on BFD routing protocol support in Cisco IOS software.

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 Version
Version 0 – No echo mode
Version 1 – Default w/ echo mode

– BFD timers are configured under each interface with the bfd interval [send-timer] min_rx [receive-timer] multiplier [number] command.

Router(config)#interface fa0/0
Router(config-if)#bfd interval 100 min_rx 100 multiplier 3
Router(config-if)#bfd echo

IGP BFD Configuration

Router(config)#router eigrp 65501
Router(config-router)#bfd all-interfaces

Router(config)#interface fa0/0
Router(config-if)#ip ospf bfd
Router(config-if)#bfd interval 100 min_rx 100 multiplier 3
Router(config)#router ospf 10
Router(config-router)#bfd all-interfaces

Router(config)#router bgp 65001
Router(config-router)#neighbor remote-as 65022
Router(config-router)#neighbor fall-over bfd
Router(config-router)#neighbor remote-as 65001
Router(config-router)#neighbor update-source Loopback0
Router(config-router)#neighbor fall-over bfd

Testing BFD Failures
R1#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface 1 FULL/DR 00:00:37 FastEthernet0/0 1 FULL/BDR 00:00:37

R1#show bfd neighbor
OurAddr NeighAddr LD/RD RH/RS Holddown(mult) State Int 1/2 Up 0 (3 ) Up Fa0/1

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
19:52:13.115: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down

19:52:42.643: %OSPF-5-ADJCHG: Process 1, Nbr 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.

What are the caveats?
Two main ones:
BFD can have high resource demands depending on your scale.
BFD is not visible to Layer 2 bundling protocols. (Ethernet LAGs or POS bundles)

My final verdict:
Typically we need bfd if we have 2 routers interconnected, BFD is very flexible protocol that can be easily to pullout or deploy. But, using this feature we should be aware of its resources demand. In the case that BFD is not support, By manually tweaking hello timer we can still achieve smooth detection.