BFD Basics: Fast Failure Detection for BGP and Static Routes

Disclosure up front: I run IPYE, a company that leases IP space. It gets one short paragraph at the end; the rest is plain networking.

When a link fails cleanly, the interface goes down and routing reacts at once. Many failures are not clean: a switch or media converter in the middle keeps the link light on while packets stop flowing, a line card stops forwarding without dropping the interface, or a remote process hangs. In those cases the router learns of the problem only when a protocol timer runs out. BGP's default hold time is commonly 90 or 180 seconds, depending on the implementation, which is a long time to send traffic into a black hole. Bidirectional Forwarding Detection (BFD) exists to shrink that to a fraction of a second or a few seconds. This article explains how BFD works, how to configure it, and when it causes more harm than good. Examples use AS64496, AS64511, and 2001:db8:ffff::/64.

What BFD is

BFD (RFC 5880) is a lightweight hello protocol, independent of any routing protocol. Two systems exchange small control packets at a negotiated rate over a path. If a system stops receiving them for a set time, it declares the path down and tells the routing protocols that registered an interest. BGP, OSPF, IS-IS, and static routes can all use it, so one fast detector can serve many protocols.

Two things make it effective. The packets are tiny and simple, so implementations can run them frequently, sometimes in a router's forwarding hardware instead of its control CPU. And BFD tests the forwarding path between the two systems, not just the routing process, which is why it catches failures that the link state does not.

The timers

Each side advertises two intervals: the minimum interval at which it wants to transmit, and the minimum at which it is willing to receive. The actual rates are negotiated, and the slower side wins. A third parameter, the detect multiplier, says how many consecutive packets can be missed before the session is declared down. The detection time is roughly the multiplier times the negotiated interval.

Interval	Multiplier	Detection time
1000 ms	3	about 3 s
300 ms	3	about 900 ms
100 ms	3	about 300 ms
50 ms	3	about 150 ms

Shorter is not always better. A multiplier of 3 is a common starting point, and an interval of 300 ms is a reasonable one for software-based implementations.

Transport details

For the common single-hop case, RFC 5881 specifies that BFD control packets use UDP destination port 3784, over both IPv4 and IPv6, and that the TTL (or hop limit) is set to 255. The receiver checks that value, which restricts packets to the directly attached neighbour in the same way as the generalised TTL security mechanism. For paths that cross more than one hop, such as an iBGP session between loopbacks, RFC 5883 uses UDP port 4784. An optional echo function, on UDP port 3785, makes the remote system loop packets back through its forwarding plane. Do not forget these ports in firewall rules: if BFD packets are filtered, the sessions never come up, or they flap.

Configuring BFD with BGP (FRR example)

bfd
 profile fast
  detect-multiplier 3
  receive-interval 300
  transmit-interval 300
 exit
exit

router bgp 64496
 neighbor 2001:db8:ffff::1 remote-as 64511
 neighbor 2001:db8:ffff::1 bfd
 neighbor 2001:db8:ffff::1 bfd profile fast

FRR runs bfdd as a separate daemon and needs it enabled in the daemons file. In BIRD, the BFD protocol is defined separately, and a BGP protocol uses it with bfd on;, with the timers in the protocol bfd block. The names and syntax of options vary between versions, so verify against your documentation. Both ends have to be configured; BFD only starts when the peer also wants it.

To inspect the result:

show bfd peers            # FRR: state, intervals, uptime
show bgp neighbors 2001:db8:ffff::1 | include BFD

A session in state Up with the negotiated intervals you expect is what you want to see. Down or AdminDown, together with the diagnostic code, indicates why a session is not up.

When BFD is the wrong tool

• Aggressive timers on a busy CPU. If the router handles BFD in software and is busy, delayed packets can lead to false "down" events, and BFD then causes the flapping it was meant to prevent. Begin with conservative timers, and tighten only after observing stability.
• Paths that legitimately jitter. Wireless links, congested tunnels, and long-haul circuits with variable delay do poorly with sub-second timers.
• Where recovery is not faster. Detecting a failure in 300 ms is pointless if the rest of the network takes 30 seconds to converge, or if there is no alternate path. In that case BFD gives you an earlier failure and nothing more.
• Bundles of links. In link aggregation, a BFD session over the logical interface may not notice a single member failing. RFC 7130 defines BFD on individual member links of a bundle for that purpose, where the hardware supports it.

Interaction with other features

BFD speeds up reaction to failure but does not stop instability. If a link bounces regularly, BFD makes each bounce visible faster. The article on route flapping describes what to do about the sources. It also interacts with graceful restart: some implementations declare BFD down while a neighbour is restarting its control plane, which cancels the benefit of graceful restart, so test combinations before relying on them.

Practical advice

1. Use BFD on links where a middle device can hide failures, and where you have a real alternative path.
2. Start with a 3x multiplier and a moderate interval, and confirm both ends agree.
3. Allow UDP 3784 (and 4784 for multihop) in firewall rules, and restrict them to your neighbours.
4. Alert on BFD sessions leaving Up, in the same dashboard as BGP state.
5. Review after any hardware change, since hardware offload can change what timers are safe.

Used selectively, BFD turns a minute-long blackhole into a sub-second reroute.

About IPYE

IPYE (https://my.ipye.com) leases IPv4, IPv6, and ASN space; a /48 IPv6 block is free for the first year. LOA, ROA, rDNS, and WHOIS are handled by IPYE. Locations: Los Angeles, New York, Ashburn, Salt Lake City, London, Amsterdam, and Frankfurt. Questions: [e-mail].

Disclosure: I run IPYE