BFD: when a link is up and dead at the same time

Bidirectional Forwarding Detection (BFD) is a small Hello protocol between two forwarding engines that notices a path has stopped carrying packets, including when both interfaces stay up, long before a routing protocol's own timers would. After reading, you can compute a detection time from the two timers and the multiplier, read a session in FRRouting field by field, choose which protocol should be its client, and say where BFD itself can be fooled.

View as Markdown

An interface that is up reports on its own port, not on whether packets still reach the far router. Bidirectional Forwarding Detection (), defined in (RFC) 5880, fills that gap: two systems exchange small packets at a negotiated rate, and when enough stop arriving the path is declared down and the protocols that asked are told. You meet it wherever , or a static route must drop a dead neighbour faster than their own timers allow. After reading, you can name the failures BFD exists for, compute a detection time, read a session in FRRouting, choose its client, and recognise where BFD itself is fooled.

Up and dead: what the port does not report

RFC 5880 states the limit of signalling: "there are media that do not provide this kind of signaling (such as ), and some media may not detect certain kinds of failures in the path, for example, failing interfaces or forwarding engine components" (RFC 5880, section 1). Three classes follow.

The one-way fault: packets pass one way only, on a fibre pair or higher up. BFD's definition of up excludes it: "A path is only declared to be operational when two-way communication has been established between systems" (section 3). A mismatched maximum transmission unit () can cause it too (RFC 9764, section 4.3).

The far end hidden behind a Layer 2 path: a switch or a 's Ethernet service keeps the local port up after the far router has gone, and Ethernet signals nothing across it. BFD travels inside the protocol it protects and is marked like the data, so that it shares the data's fate (RFC 5882, section 6).

The stuck forwarding plane with a live control plane: RFC 5880 gives it a diagnostic, code 4, Forwarding Plane Reset, sent when the far end can no longer rely on the local forwarding state (RFC 5880, section 6.8.15). In all three, routing keeps sending traffic into a black hole.

Hellos notice, slowly

Routing protocols do not wait for the interface to drop; their Hellos catch the silence, late: "Networks use relatively slow 'Hello' mechanisms, usually in routing protocols, to detect failures when there is no hardware signaling to help out" (RFC 5880, section 1).

The familiar numbers are not all standard defaults. For OSPF, RFC 2328 gives "Sample value for a local area network: 10 seconds" for the HelloInterval and, for the RouterDeadInterval, "This should be some multiple of the HelloInterval (say 4)" (RFC 2328, appendix C.3). Ten times four is 40 seconds, which FRRouting (FRR) documents as its own default (FRRouting documentation, OSPFv2). BGP has no Hello, only KEEPALIVE messages that keep a hold timer from expiring, and "The suggested default value for the HoldTime is 90 seconds" (RFC 4271, section 10); one or two seconds must be rejected (section 6.2).

Tuning has a floor, for OSPF and for Intermediate System to Intermediate System (IS-IS): "OSPF has a minimum detection time of two seconds, and has a minimum detection time of one second" (RFC 5882, section 10.1). Against BFD at FRR's defaults, 900 ms (FRRouting documentation, BFD), a 40-second dead interval is about 44 times slower and a 90-second hold time 100 times. How each protocol reacts is in dynamic routing compared.

What BFD is

"BFD is a simple Hello protocol that, in many respects, is similar to the detection components of well-known routing protocols" (RFC 5880, section 3). It carries no routes and discovers nothing: an application, such as OSPF after finding a neighbour, asks for a session (section 3.1). It belongs in the forwarding engine; running it in the control engine is allowed but may miss some failures (section 2). There is one session per path and data protocol, so IPv4 and IPv6 need two (RFC 5881, section 2), and clients of the same neighbour share one (RFC 5882, section 4.4).

The control packet

The mandatory section is 24 bytes (RFC 5880, section 4.1); under UDP and IPv4 it makes a 52-byte packet and a 70-byte Ethernet frame. The values below are an Up session at 300 ms, computed from the field definitions:

Bytes	Field	Example value
0	Version (3 bits), Diagnostic (5 bits)	`0x20`: version 1, diagnostic 0
1	State (2 bits), flags P F C A D M	`0xc0`: Up (`0x40` Down, `0x80` Init, `0xc8` Up with C set)
2	Detect Mult	`0x03`
3	Length	`0x18` (24)
4 to 7	My Discriminator	nonzero, chosen by the sender
8 to 11	Your Discriminator	the peer's value, or zero while unknown
12 to 15	Desired Min TX Interval	`00 04 93 e0` (300000 µs)
16 to 19	Required Min RX Interval	`00 04 93 e0`
20 to 23	Required Min Echo RX Interval	`00 00 00 00` (will not loop echo)

The states are 0 AdminDown, 1 Down, 2 Init and 3 Up. The diagnostic says why the last session ended, such as 1, Control Detection Time Expired, or 3, Neighbor Signaled Session Down. Poll and Final carry parameter changes, and the C bit, Control Plane Independent, means the sender's BFD runs in the forwarding plane and survives disruption (RFC 5880, section 4.1).

Four states and a three-way handshake

On a single hop both sides are Active and send first, with Your Discriminator zero (RFC 5881, section 3). They start slowly: "When bfd.SessionState is not Up, the system MUST set bfd.DesiredMinTxInterval to a value of not less than one second (1,000,000 microseconds)" (RFC 5880, section 6.8.3). The receive rules then move the session (section 6.8.6):

Local state	Hears	Becomes
Down	Down	Init
Down	Init	Up
Init	Init or Up	Up
Up	Down	Down, diagnostic 3

Going down is a handshake too: a session declared Down cannot come back until the far end has signalled Down itself, which makes the exchange three-way (RFC 5880, section 6.1). AdminDown holds the peer in Down but says nothing about the forwarding path (section 6.2).

Two timers, a multiplier and the arithmetic

Each direction is negotiated separately and continuously, and no sender may go faster than its receiver accepts, so the slower side sets the rate (RFC 5880, sections 6.8.2 and 6.8.7). Each packet leaves up to 25 per cent early, a random jitter, so at 300 ms packets go every 225 to 300 ms.

Detection time is never carried; each receiver computes it: "In Asynchronous mode, the Detection Time calculated in the local system is equal to the value of Detect Mult received from the remote system, multiplied by the agreed transmit interval of the remote system (the greater of bfd.RequiredMinRxInterval and the last received Desired Min TX Interval)" (RFC 5880, section 6.8.4). When it passes without a packet, the session goes Down with diagnostic 1.

Remote Desired Min TX	Local Required Min RX	Remote Detect Mult	Agreed interval	Detection time
300 ms	300 ms	3	300 ms	900 ms
300 ms	200 ms	3	300 ms	900 ms
300 ms	1000 ms	3	1000 ms	3000 ms
100 ms	100 ms	9	100 ms	900 ms
50 ms	50 ms	3	50 ms	150 ms
16.7 ms	16.7 ms	3	16.7 ms	50.1 ms

The second row is FRR's own worked example (FRRouting documentation, BFD). RFC 7419 proposes 100 ms by 9 in place of 3 by 300 ms, lists the common intervals hardware should support, from 3.3 ms to 1 s, and calls 50 ms a "widely deployed interval" (RFC 7419, section 3 and appendix A).

Asynchronous, demand and echo

Asynchronous mode, the periodic exchange above, is mandatory (RFC 5882, section 9). Demand mode lets a system that verifies connectivity another way ask its peer to stop sending, leaving detection to the implementation's heuristics (RFC 5880, section 3.2); on both ends without echo it can leave a failed path undetected (FRRouting documentation, BFD). The Echo function sends packets the far end loops back through its forwarding path: "The Echo function has the advantage of truly testing only the forwarding path on the remote system" (RFC 5880, section 3.2). Echo uses UDP port 3785 (RFC 5881, section 4), needs a nonzero Required Min Echo RX Interval from the peer, and "the Echo function MUST NOT be used over multiple hops" (RFC 5883, section 3).

On the wire: one hop, many hops, a bundle

Single-hop, multihop and Link Aggregation Group (LAG) sessions differ in port and protection (RFC 5881, section 4; RFC 5883, section 5; RFC 7130, section 2.2):

Case	UDP destination port	Protection
Single hop	3784 (echo 3785)	Time to Live 255, sent and checked
Multihop	4784	authentication
LAG member (micro-BFD)	6784	one session per member

On a single hop the source port is between 49152 and 65535, fixed per session, and without authentication "all BFD Control packets for the session MUST be sent with a Time to Live () or Hop Limit value of 255" (RFC 5881, sections 4 and 5); anything else received is discarded. A packet that crossed a router arrives lower, so off-link senders are shut out. That is the Generalized TTL Security Mechanism (), and "GTSM is not a substitute for authentication mechanisms" (RFC 5082, section 1). Across several hops the TTL proves nothing, so RFC 5883 says implementations should use cryptographic authentication there (RFC 5883, section 6).

On a LAG, "Running a single BFD session over the aggregation without internal knowledge of the member links would make it impossible for BFD to guarantee detection of the physical member link failures" (RFC 7130, section 1). Micro-BFD therefore runs on every member, to the Media Access Control (MAC) address 01-00-5E-90-00-01; a member carries traffic only once its sessions are Up (sections 2.3 and 3). The bundle itself is in link aggregation.

What the routing protocol does with the answer

"BFD should be viewed as having an advisory role to the protocol or protocols or other network functions with which it is interacting, which will then use their own mechanisms to effect any state transitions" (RFC 5882, section 2). On Down, OSPF tears down the neighbour, an External BGP (EBGP) session is torn down unless a graceful restart is under way, and a static route is withdrawn (sections 5, 10.1.2 and 10.2); BGP then sends Cease subcode 10, BFD Down (RFC 9384, section 3). Clients ignore a move to AdminDown (RFC 5882, section 4.2).

"In general, it is best for the protocol at the lowest point in the hierarchy to interact with BFD" (RFC 5882, section 4.4): with Internal BGP (IBGP) over OSPF, OSPF listens and heals the path. With the C bit set both ways, a failure means forwarding stopped, so a graceful restart is abandoned to avoid a black hole (section 4.3.1). An adjacency should not form when both sides want BFD but the session cannot come up (section 4.1); FRR's neighbor ... bfd strict enforces that for BGP.

Where it misfires

Aggressive timers on a busy router compete for the central processing unit (CPU): "It is possible for systems with a large number of BFD sessions and/or very short packet intervals to become CPU-bound" (RFC 5880, section 7), and a starved session flaps a stable adjacency. Policers and shapers harm BFD when their timescale nears the detection time, and a firewall that drops it fails the session (section 7).

Control-plane BFD can pass while forwarding fails: RFC 5882 accepts the risk "since a simultaneous failure or restart of the forwarding plane will not be detected" (RFC 5882, section 4.3.2).

Equal-cost multipath () is a limit, not a strength: "This may result in a BFD session being in the Up state while some traffic may be dropped or otherwise negatively impacted along some component links" (RFC 9764, section 4.5), and no standard mechanism exercises every member over multiple hops. A LAG running micro-BFD on one side only is likely to lose traffic (RFC 7130, appendix A).

An attacker controlling the link can "forward only the BFD packets but nothing else (causing the link to be falsely declared up). This attack cannot be prevented by BFD" (RFC 5880, section 9). TTL checks and authentication stop forgeries from elsewhere, not that.

Configured on one side only, a session sends once a second and never comes Up (RFC 5880, section 6.8.3), unless the peer accepts unsolicited BFD by policy (RFC 9468, Abstract). A gateway that stops forwarding with its port up is the same failure seen from a host: see first-hop redundancy.

How to see it

FRR runs BFD in its bfdd daemon. Illustrative configuration after FRR's examples:

bfd
 profile fast
  receive-interval 150
  transmit-interval 150
 !
 peer 192.0.2.1
  profile fast
  no shutdown
 !
!
router bgp 65530
 neighbor 192.0.2.1 remote-as 65531
 neighbor 192.0.2.1 bfd

With the default multiplier of 3 the profile detects in 450 ms; FRR's defaults are 300 ms each way. OSPF attaches with ip ospf bfd, a static route with ip route A.B.C.D/M A.B.C.D bfd (FRRouting documentation, BFD). show bfd peers prints, in FRR's documented sample with addresses changed:

peer 192.0.2.1 local-address 192.0.2.2 vrf default interface veth1
ID: 1
Remote ID: 0
Active mode
Status: down
Downtime: 5 second(s)
Diagnostics: ok
Remote diagnostics: ok
Peer Type: configured
RTT min/avg/max: 0/0/0 usec
Profile: myprofile
Local timers:
Detect-multiplier: 3
Receive interval: 300ms
Transmission interval: 300ms
Transmission interval (actual with jitter): 970ms
Detection timeout: 3000ms
Echo receive interval: 50ms
Echo transmission interval: disabled
Remote timers:
Detect-multiplier: 3
Receive interval: 1000ms
Transmission interval: 1000ms
Echo receive interval: disabled

ID is My Discriminator; Remote ID: 0 means nothing has been heard. Diagnostics: ok is diagnostic 0. Detection timeout: 3000ms is 3 times the larger of local receive (300 ms) and remote transmit (1000 ms): the session is not Up, so both run the one-second rate, and 970 ms is one second less jitter. For a session stuck Down, check that the far end sends, that nothing drops UDP 3784 or lowers the TTL, and that authentication matches (RFC 5880, section 6.8.6).

A capture shows the packet table's fields, one second apart until Up, then at the agreed interval. The BFD timer calculator computes both directions of a session from the six configured numbers and decodes a captured packet field by field, Sizing BFD timers works through the arithmetic, and the Python playground checks a single product (3 * max(300, 1000)). The Packet Capture Plan Builder helps choose where to capture UDP 3784 when only one end is Down, and the Flow Path Reasoner names the boxes between two routers.

What to remember

BFD calls a path up only when packets flow both ways, so it catches one-way faults, hidden far ends and stopped forwarding planes.
Routing Hellos do detect these failures, slowly: 40 seconds is RFC 2328's 10-second sample times four and FRR's default; 90 seconds is RFC 4271's suggested .
Detection time is the remote Detect Mult times the larger of local Required Min RX and remote Desired Min TX: 3 times 300 ms is 900 ms.
A session not yet Up sends once a second, and the slower side always sets the pace.
BFD only advises; the protocol lowest in the hierarchy should listen, and AdminDown is not a failure.
Single hop uses UDP 3784 and TTL 255, multihop UDP 4784 and authentication, a LAG one session per member on 6784.
One session over ECMP can stay Up while a member drops traffic, and an attacker who forwards only BFD defeats it.