BFD concept — Bidirectional Forwarding Detection, sub-second failure detection, control-plane independent

BFD (Bidirectional Forwarding Detection) is a lightweight, UDP-based failure detection protocol that runs between two routers. It is designed to detect a peer’s failure in sub-second intervals — typically 50-200 milliseconds — without relying on the routing protocol’s own keepalive mechanism. On VyOS 1.5 LTS / FRR 10.x, BFD is implemented as a separate daemon (bfdd) that integrates with BGP, OSPF, and static route tracking. When BFD detects a peer failure, it tears down the routing protocol session immediately, allowing the local router to converge in sub-second intervals.

This lesson walks BFD from first principles: what it is, why it exists, the three-way handshake, the transmit/receive interval and multiplier knobs, and the production use cases. The goal is the ability to read show bfd neighbors, diagnose a BFD session, and choose the right interval for the right link.

Why BFD exists — the hold-time problem

BGP and OSPF have their own keepalive mechanisms. BGP’s hold-time is 180 seconds by default; OSPF’s hello interval is 10 seconds with a dead interval of 40 seconds. These intervals are appropriate for stable links but inadequate for sub-second failure detection.

Consider an eBGP session with a 180-second hold-time. If the link drops, the local router does not know for up to 180 seconds (until the hold-time expires). The local router keeps stale routes; traffic continues to be routed to the dead peer. The blackhole lasts up to 180 seconds.

BFD solves this. BFD runs at sub-second intervals (50-200 ms typical) and detects the failure immediately. When BFD detects the failure, it tears down the BGP session — the BGP hold-time is bypassed.

The trade-off: BFD consumes CPU and bandwidth. A 50ms interval means 20 packets per second in each direction. The operator must balance failure-detection speed against the link’s capability.

BFD’s purpose and properties

BFD’s design properties:

• Lightweight. BFD packets are tiny (24-26 bytes for the control packet). The protocol has minimal processing overhead.
• UDP-based. BFD runs over UDP port 3784 (single-hop) or 4784 (multi-hop). UDP is connectionless; BFD adds its own session management.
• Control-plane independent. BFD does not rely on the routing protocol’s keepalive. BFD runs at Layer 3/4; the routing protocol runs at Layer 7. BFD detects failures at Layer 3/4 and signals the routing protocol.
• Sub-second detection. BFD can detect failures in 50ms or less when configured aggressively.
• Bidirectional. BFD verifies both directions of the path. A unidirectional failure (one side can send but not receive) is detected.
• Path-independent. BFD can run over any path — direct link, MPLS LSP, GRE tunnel, IPsec tunnel.

The key insight: BFD is not a routing protocol. BFD does not advertise routes; it does not compute paths. BFD is purely a failure detector. The routing protocol remains in charge of routing decisions; BFD only signals “the peer is gone” or “the peer is back”.

flowchart LR
  A[Router A] -->|BFD packets UDP 3784| B[Router B]
  A <-->|BGP/OSPF/static| B
  BFD[BFD daemon bfdd] -.->|peer-down signal| BGP[BGP daemon bgpd]
  BFD -.->|peer-down signal| OSPF[OSPF daemon ospfd]
  BFD -.->|peer-down signal| STATIC[Static route tracking]

  subgraph "Failure detection"
    A
    B
  end

  subgraph "Routing protocol"
    BGP
    OSPF
    STATIC
  end

The diagram shows BFD’s role. BFD runs between two routers, detecting failures. When BFD detects a failure, it signals the routing protocol (BGP, OSPF, static) which then tears down the session or withdraws the route.

The BFD three-way handshake

BFD sessions are established with a three-way handshake:

1. Router A sends BFD Control packet with state Down. The packet contains A’s discriminator (a unique 32-bit value), desired interval, and required multiplier.
2. Router B receives the packet, transitions to Init, sends BFD Control packet with state Init. The packet contains B’s discriminator and A’s discriminator (echoing A’s).
3. Router A receives B’s packet, transitions to Up, sends BFD Control packet with state Up. The session is established.

After the session is established, both routers send periodic BFD Control packets at the agreed interval. The packets contain the local discriminator and the remote discriminator (so each side knows which session the packet belongs to).

The session states:

• Down — the session is not active. No packets are being sent.
• Init — the local router has sent a packet but not yet received one from the peer.
• Up — the session is established. Periodic packets are being exchanged.
• AdminDown — the session is administratively shut down. Used for maintenance.

The evidence in show bfd neighbors: the State column shows Up, Down, Init, or AdminDown. A session in Down is not active; a session in Up is exchanging packets.

The transmit/receive interval and multiplier

BFD’s failure detection is governed by two knobs:

• Transmit interval — how often the local router sends BFD packets to the peer. Default in VyOS 1.5 LTS: 50ms.
• Receive interval (min-rx) — the minimum interval at which the local router is willing to receive BFD packets from the peer. Default: 50ms.
• Multiplier (detect-multiplier) — how many packets can be missed before the session is declared down. Default: 3.

The detection time is transmit-interval * multiplier. With the defaults, the detection time is 50ms * 3 = 150ms — BFD declares the peer down after 150ms of silence.

The knob in VyOS:

set protocols bfd profile FAST interval '50'
set protocols bfd profile FAST min-rx '50'
set protocols bfd profile FAST multiplier '3'

The profile is a reusable BFD configuration. The peer references the profile.

How BFD integrates with the routing protocol

BFD does not directly tear down the routing protocol session. Instead, BFD signals the routing protocol when it detects a failure. The routing protocol then handles the teardown:

• BGP — when BFD signals peer-down, BGP tears down the BGP session. The hold-time is bypassed; the session drops immediately. The local router removes all routes from the peer.
• OSPF — when BFD signals neighbour-down, OSPF tears down the neighbour adjacency. The local router runs SPF and removes the routes through the dead neighbour.
• Static route — when BFD signals peer-down, the static route tracking mechanism removes the route from the RIB. The local router uses an alternative route (or drops the traffic).

The integration is per-protocol. The operator enables BFD on a BGP peer with neighbor <ip> bfd; on an OSPF interface with ip ospf bfd; on a static route with set protocols static route <prefix> next-hop <ip> bfd.

How the result is validated

show bfd neighbors
show bfd peers
show bfd peer <ip>
show bfd profile
show bfd session
show ip bgp neighbors <ip> bfd
show ip ospf neighbor detail
journalctl -u bfdd
tcpdump -nn -i any udp port 3784

The first command shows all BFD sessions. The second shows the BFD peer configuration. The third shows the per-peer BFD state. The fourth shows the BFD profiles. The fifth shows the BFD session state. The sixth shows the BGP+BFD integration. The seventh shows the OSPF+BFD integration. The eighth shows the BFD daemon log. The ninth shows the packet-level BFD exchange.

The operator who runs these commands has full visibility into BFD’s behaviour.

How it fails

The production failure modes the engineer must recognise:

• BFD session in Down. The BFD packets are not being exchanged. The most common cause: a firewall is blocking UDP 3784/4784. The fix: open the firewall.
• BFD session in Init. The local router has sent a packet but not received one from the peer. The most common cause: the peer’s BFD is not configured or is in a different VRF.
• BFD session flapping. The session is up briefly then down briefly then up again. The most common cause: the interval is too aggressive for the link’s capability. The fix: increase the interval.
• BFD session up but routing protocol not using BFD. The BFD session is established but the routing protocol’s session is not torn down on BFD failure. The fix: enable the BFD integration on the routing protocol side.
• BFD CPU saturation. The interval is too aggressive for the CPU. The fix: increase the interval.

Rollback

BFD changes are configuration changes. The standard rollback paths:

• rollback N; commit; save to revert any configuration changes.
• delete protocols bfd profile <name> to remove a BFD profile.
• delete protocols bgp <asn> neighbor <ip> bfd to disable BFD on a BGP peer.
• delete protocols ospf interface <intf> bfd to disable BFD on an OSPF interface.

The operator who enables BFD should know how to disable it. The canonical pattern: enable BFD, validate the session is stable, then enable BFD on additional peers.

Production discipline

Cross-course references

The Linux course’s XIX-Linux-NetFoundations covers the kernel UDP stack. The OPNsense course’s XXX-OPNsense-DynamicRouting covers the equivalent FRR BFD on the firewall side. The BGP lessons vyos-xxiv-03-bgp-timers and vyos-xxxi-01-session-states cover the BGP hold-time and FSM. The OSPF lessons cover the OSPF hello/dead intervals. The lesson vyos-xxxii-03-bfd-with-bgp covers the BGP+BFD integration in detail.

Quiz