3.3.l Implement and troubleshoot bidirectional forwarding detection

3.3.l Implement and troubleshoot bidirectional forwarding detection

Bidirectional forwarding detection (BFD) is an open protocol defined in RFC 5880.

BFD utilizes small UDP keep alives that are processed by asics for sub second convergence (versus using sub second hello rate that goes to control plane)

If the device uses software CEF and does not have asics BFD can still run in software.

Has an average failure detection of 150ms

Thus with the lowest possible settings, BFD can miss 3x hellos before considering a neighbor dead

BFD is independent of 4 things:
media, encapsulation, topology, routing protocol

Again this is in contrast to using fast hellos in our routing protocols which could negatively impact cpu performance.

BFD process can be used my multiple routing protocols, which cuts down on the load. The idea is that these protocols register with BFD via some commands applied to their processes.

BFD notifies the uper layer protocols of failure such that they can react faster and still keep their default settings of hello times.

BFD cannot be run on a pure L2 link as it uses UDP and IPv4 to communicate.

BFD supports the following protocols:
Static routes

The configuration is 2 part:
1. Enable bfd on the interfaces
2. Register the protocol with BFD


int g0/1
bfd interval 50 min_rx 50 multiplier 3

50 is the lowest possible value in terms of MS, and a multiplier (hold time) of 3x is the lowest value

Then go into the routing protocol of choice and enable it

router eigrp 1
bfd all-interfaces

per int:

bfd interface 


router ospf 1
bfd all-interfaces


neighbor x.x.x.x fall-over bfd


2 ways globally or per int:
per int:
int g0/1
standby 1 ip x.x.x.x
standby bfd


standby bfd all-interfaces


router isis 0
bfd all-interfaces

Only one BFD session is used for all of these.

static route:

ip route static bfd  x.x.x.x
ip route x.x.x.x x.x.x.x  

You might be wondering why I included the interface as well? Well BFD for static routes requires both.

On a broadcast media like Ethernet, you can have multiple neighbors across the same segment. So 3 neighbors could be on 1 interface.

img 5ac0299b70a1e

BFD Packet:

img 5ac0299feaabf

BFD rides over UDP port 3784

img 5ac029a5f37c9

note: BFD also used 3785 for echo packets

How it starts:
When BFD is configured or activated on just one side and the routing protocol is configured to use bfd, the side sends the UDP control packets to the next hop of the other side. It uses UDP port

img 5ac029bdacbc1

3784. If only once side is configured with it, you will see ICMP type 3 code 3 (port unreachable) messages until the other side starts to listen for that port.

Then once both sides are configured for BFD and the routing protocols register with BFD, eventually we see both sides send each other these packets with the session state of UP:

img 5ac029c6065ba

Then they start the keep alives to their own IPs, which just look like regular UDP packets, they aren't decoded as they probably take meaningless data

img 5ac029cac392b

If you look closer at these packets, you will notice that they go from to, what...

This is the actual echo. The goal is when R1 generates the packet it goes from R1 to R2, and then R2 gets it in the data plane and loops the packet back and sends it to R1. This is the secret sauce to how BFD is able to utilize sub millisecond hellos without punting the packets to the CPU!

This assumes that you disable ICMP redirects, configuring BFD automatically does this for you.
The only thing really processed by the control plane are the BFD control messages that wireshark decodes. These go about 2 times every second.

side note:
This is actually called BFD Echo mode and is the default on Cisco gear. It can be disabled with the interface command “no bfd echo”.
When this is done BFD in turn just sends BFD control packets and just utilizes the CPU/control plane and is not done in hardware.

img 5ac029d150689


When a routing protocol registers with BFD you will get a bfd session created message.

Then when the session is actually considered up, you will get another sys log message stating so.

img 5ac029d751ed2

IF BFD packets are missed 3x times then BFD alerts the routing protocol, which in tern brings down the session.

img 5ac029dd49de4

We then see this under the BFD neighbors

img 5ac029e2818e4

To check which protocols are CONFIGURED but not necessarily active for BFD use:

show bfd neighbors detail

img 5ac029e83cd75

BFD is supported in IPv6 however it does not support all of the protocols that IPv4 does currently.

You should check to confirm that your platform actually utilizes the asics and not the software.
How would you check?

show bfd neighbors detail will tell you “session host:

img 5ac029edecaab

BFD across multiple hops is supported with a different configuration, it's known as BFD multihop (because technically regular bfd does not support it)

Leave a comment