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:
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 eigrp: globally: <pre>router eigrp 1 bfd all-interfaces
bfd interface <int>
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 exit
standby bfd all-interfaces
router isis 0 bfd all-interfaces
Only one BFD session is used for all of these.
ip route static bfd <int> x.x.x.x ip route x.x.x.x x.x.x.x <int> <next hop ip>
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.
BFD rides over UDP port 3784
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
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:
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
If you look closer at these packets, you will notice that they go from 192.168.1.2 to 192.168.1.2, 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.
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.
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.
IF BFD packets are missed 3x times then BFD alerts the routing protocol, which in tern brings down the session.
We then see this under the BFD neighbors
To check which protocols are CONFIGURED but not necessarily active for BFD use:
show bfd neighbors detail
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:
BFD across multiple hops is supported with a different configuration, it’s known as BFD multihop (because technically regular bfd does not support it)