If you've ever wondered how a router notices its neighbor died in milliseconds instead of the tens of seconds a routing protocol would take on its own, the answer is almost certainly BFD. RFC 5881 defines how BFD runs across a single IP hop — the most common deployment by far — and it's the quiet workhorse behind fast failover in nearly every serious ISP, data center fabric, and SD-WAN edge on the planet.

The problem. OSPF, IS-IS, and BGP all have their own liveness timers, but those timers were designed conservatively. OSPF's default dead interval is 40 seconds; BGP's default hold timer is 90 or 180 seconds. On a link that just failed silently — say, a fiber cut behind a media converter that keeps the Ethernet interface "up" — traffic blackholes for a minute or more before anyone notices. You could crank the protocol timers down, but each protocol reimplements liveness differently, none of them cheaply, and aggressive timers spook the control plane. What was needed was a single, protocol-agnostic, cheap hello mechanism that could be pushed into hardware or ASIC-level fast paths.

The design. BFD is essentially a stripped-down UDP-based hello protocol. Two systems establish a session, negotiate a desired transmit interval and a detection multiplier, then trade tiny control packets at that rate. If Detect Mult × Interval passes without a packet, the session is declared Down and any client protocol (OSPF, BGP, static routes, LDP, etc.) gets an immediate "neighbor gone" notification. Typical deployments run 50 ms intervals with a multiplier of 3, giving 150 ms failure detection — orders of magnitude faster than any routing protocol's native mechanism.

Single hop specifics. RFC 5881 nails down the transport rules for the one-IP-hop case. Control packets use UDP destination port 3784, with a source port from the ephemeral range 49152–65535. Crucially, packets are sent with TTL/Hop Limit = 255 and the receiver must verify that value equals 255 on ingress. This is the GTSM trick (RFC 5082): anything that traversed a router would have a decremented TTL, so a 255 on arrival proves the packet came from a directly connected neighbor. It's a cheap, elegant defense against off-path spoofing.

Why it lives in hardware. The packets are deliberately tiny and the state machine is deliberately trivial (Up, Down, Init, AdminDown). This lets vendors offload BFD entirely to line-card CPUs or even NPUs, so control-plane load stays flat even at 3.3 ms intervals across hundreds of sessions. A router can lose its main CPU to a bug and BFD keeps humming — which is exactly why "graceful restart" interacts with BFD in careful, documented ways.

Where you touch it. If you run BGP with neighbor X.X.X.X fall-over bfd on Cisco, bfd-liveness-detection on Junos, or bfd enable in FRR, you're using RFC 5881. Every leaf-spine fabric that converges in sub-second time is leaning on it. MPLS TE fast-reroute triggers off it. Even Kubernetes-adjacent projects like Calico use BFD to accelerate BGP failover between nodes.

A bit of history. Dave Katz (Juniper) and Dave Ward (then Cisco) started drafting BFD around 2003 in the IETF's bfd working group. The original draft was refreshingly short and, unusually, went through very few structural revisions before publication — proof that when a protocol solves exactly one problem and refuses to grow, it can stay lean. Companion RFCs 5880 (the base protocol), 5882 (generic application), and 5883 (multihop) round out the family, but 5881 is the one that runs on almost every link you've ever pinged across a serious network.