Junos BFD Liveness Detection: Timers, Adaptation & MC-LAG

Bidirectional Forwarding Detection is the smallest configuration in a Junos device and the one with the largest blast radius. A 300 ms BFD session turns a 40-second OSPF dead interval into sub-second failover; the same session with a multiplier that is too aggressive turns a single dropped packet into a flapping adjacency. This runbook explains what the Junos bfd-liveness-detection knobs actually do, how detection time is calculated, why Junos silently slows timers down, and where BFD fits (and does not fit) in an MC-LAG ICCP deployment.

How BFD detection time is calculated

BFD is a hello protocol: each side transmits at its negotiated interval and declares the neighbour down when it stops receiving. Three numbers decide everything:

• minimum-interval — sets both the transmit and receive minimum interval, 1–255,000 ms.
• multiplier — how many consecutive missed hello packets are tolerated (default 3).
• detection-time threshold — a hard override for the calculated detection time.

With minimum-interval 300 and multiplier 3 the session goes down after roughly 900 ms of silence. Juniper’s deployment guidance is 300 ms for Routing Engine based (centralised) BFD and 100 ms for distributed BFD sessions on line-card based platforms. Sessions that must survive a Routing Engine switchover with nonstop active routing (NSR) configured need minimum-interval 2500.

Configuring BFD per protocol

The statement lives under the routing protocol, not under the interface, which is why the same physical link can run 300 ms for OSPF and 500 ms for BGP.

# OSPF, global for all interfaces
set protocols ospf bfd-liveness-detection minimum-interval 300
set protocols ospf bfd-liveness-detection multiplier 3

# OSPF, per-interface override
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 bfd-liveness-detection minimum-interval 100
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 bfd-liveness-detection multiplier 4

# IS-IS, per interface
set protocols isis interface ge-0/0/1.0 level 2 bfd-liveness-detection minimum-interval 500

# BGP, per group (multihop sessions included)
set protocols bgp group EBGP bfd-liveness-detection minimum-interval 500
set protocols bgp group EBGP bfd-liveness-detection multiplier 4

# Static route tracking
set routing-options static route 10.0.0.0/8 bfd-liveness-detection minimum-interval 300

BFD for static routes is the fastest way to make a floating static route behave like a real failover path, because the route is withdrawn at BFD speed instead of waiting for ARP or ICMP probes.

Verifying a live session

show bfd session
show bfd session detail
show bfd session extensive
show bfd session address 10.0.0.2 detail

In show bfd session extensive the interesting fields are the negotiated transmit/receive intervals, the detection time, and the Adaptation counters. If the transmit interval is larger than what you configured, negotiation or adaptation — not the network — is the reason your failover is slower than the design number.

Adaptation: why your 300 ms timer became 2.4 s

Junos BFD is adaptive by default. If a session flaps more than three times in a 15-second window, the timers back off: the receive interval is doubled when the local instance caused the flap, the transmit interval is doubled when the remote instance did. This prevents a broken link from generating a packet storm, but it also quietly hides the problem — the session stays up while detection time degrades.

# Return timers to configured values
clear bfd adaptation

# Refuse to adapt at all (lab / controlled topologies)
set protocols ospf bfd-liveness-detection no-adaptation

Couple no-adaptation with a monitoring alarm on the BFD session state. On a production distribution pair, an adaptation event is a signal that something below your abstraction layer is wrong.

BFD versus ICCP liveness on MC-LAG

This is the classic misunderstanding. On a Juniper MC-LAG pair, Inter-Chassis Control Protocol runs its own TCP-based liveness detection and heartbeats between the two peers. That is the mechanism that decides whether the peer is alive and whether a split-brain situation exists. BFD, by contrast, monitors forwarding paths towards routers and hosts.

• Do not try to make ICCP faster by adding BFD to it — tune the ICCP liveness interval instead, and keep the ICCP path on a dedicated link or a stable management path.
• Do run BFD on the routing adjacencies that ride on top of the ICL/ICCP pair, so that an outage of the ICL is detected at forwarding level too.
• If BFD sessions on the ICL flap while ICCP stays up, suspect a data-plane problem (PFC, LACP hashing, one-way link) rather than a control-plane one.

Distributed Versus Centralised BFD

Where a BFD session runs decides how small its timers can be, and this is the decision deployments most often get wrong by copying a "300 ms" line out of a template. On platforms with distributed BFD — line-card based PFE, most recent MX and PTX — the hello packet is transmitted and timed by the forwarding plane, so 100 ms is achievable and failover acts at forwarding speed. On platforms where the session is driven by the Routing Engine over the internal interface, including many SRX and smaller ACX/MX, Juniper's own deployment guidance is 300 ms with a multiplier of 3: roughly 900 ms of detection.

# is this session distributed on my platform?
show bfd session detail | match "Distributed|BFD-"
show chassis forwarding-options | match bfd

# on a Routing Engine based design, resist going below 300 ms
set protocols ospf bfd-liveness-detection minimum-interval 300
set protocols ospf bfd-liveness-detection multiplier 3

The failure mode of ignoring this is subtle. Aggressive timers work in a lab with no control-plane load, then flap at 3 a.m. when a switchover, a commit or a route storm pushes the Routing Engine past its scheduling budget. The session drops, the adjacency resets, and the incident is filed as a network problem when it is really a resource problem.

Tuning for Failover Speed Without Flapping

Five knobs and one line of arithmetic decide whether BFD helps you or hurts you.

Detection time is the smaller of the two sides' calculated values, because each side proposes its own interval × multiplier and the session uses the negotiated result. A local 300 ms/3 session peering with a remote 500 ms/3 negotiates 500 ms transmit and 1500 ms detection — three times worse than designed. If you need sub-second failover, both ends must agree, and checking only your own configuration is the classic half-migration bug.

Multihop BFD and the Loopback Problem

Single-hop BFD requires directly connected ends and validates that the packet arrived on the expected interface with the expected TTL. For BGP sessions between loopbacks across a routed path, or eBGP across a firewall, you need multihop BFD, which relaxes that check and requires an explicit TTL.

# multihop BFD for a loopback-to-loopback iBGP session
set protocols bgp group IBGP type internal
set protocols bgp group IBGP local-address 192.0.2.1
set protocols bgp group IBGP neighbor 192.0.2.2 multihop ttl 255
set protocols bgp group IBGP bfd-liveness-detection minimum-interval 300
set protocols bgp group IBGP bfd-liveness-detection multiplier 4

# confirm single-hop versus multihop in the session output
show bfd session extensive | match "Multihop|TTL"

Multihop sessions are inherently less reliable: they ride the very path they are monitoring and cannot distinguish "the link died" from "the route changed". Use them where you must, and prefer single-hop BFD on the physical links underneath whenever the topology allows it.

BFD on MC-LAG Systems: What Actually Detects Failure

On a Juniper MC-LAG pair, ICCP runs its own liveness mechanism between the peers and the inter-chassis link carries the data plane between them. BFD and ICCP are complementary, not interchangeable, and conflating them produces two specific mistakes.

• Do not add BFD inside ICCP. ICCP liveness is tuned with the ICCP liveness interval and backup liveness detection; layering BFD on top adds a second failure signal without adding speed. Tune the ICCP timers, and put the ICCP path on a dedicated link or the most stable path available.
• Do run BFD on the routing adjacencies that ride across the ICL. If OSPF runs over the inter-chassis link, BFD on those interfaces detects a data-plane failure of the ICL far faster than IGP hellos, which is what prevents the pair from forwarding into a black hole.
• Backup liveness detection is the safety net. When ICCP is up but the ICL data path is degraded, backup-liveness-detection — with its own interval and multiplier — is the mechanism that decides the peer is no longer forwarding. BFD sessions on the ICL flapping while ICCP stays up is the classic symptom of exactly this state.

# ICCP has its own liveness mechanism — BFD is not the control mechanism for it
set protocols iccp peer 192.0.2.9 local-ip-address 192.0.2.1
set protocols iccp peer 192.0.2.9 liveness-detection minimum-interval 500
set protocols iccp peer 192.0.2.9 liveness-detection multiplier 3
set protocols iccp peer 192.0.2.9 backup-liveness-detection minimum-interval 500

# BFD belongs on the routing protocols riding over the ICL
set protocols ospf area 0.0.0.0 interface ae0.0 bfd-liveness-detection minimum-interval 300

Monitoring a BFD Deployment

BFD's failure modes are quiet, so telemetry matters more than configuration. Alert on four things.

1. Adaptation counters in show bfd session extensive. Any non-zero value means the system has backed off your configured timers, which is a signal to investigate rather than a nuisance to clear.
2. Session state transitions via SNMP or streaming telemetry (jnxBfdSessionState). Alert on down events, and separately on flaps: a session that drops and returns in 30 seconds is a very different problem from one that stays down.
3. Negotiated interval drift. Compare the configured minimum-interval with the negotiated transmit interval in the session output — a gap means the peer is not configured the way you believe it is.
4. Correlated ICCP and BFD drops. When both move together, suspect the physical path (PFC, LACP hashing, a one-way link) rather than either protocol.

# the three commands that answer most BFD tickets
show bfd session
show bfd session extensive | match "Detection|Adaptation|Transmit|Receive"
show configuration protocols | display set | match bfd

Troubleshooting Checklist

Related reading on this site: MC-LAG ICCP failure scenarios and LACP System ID behaviour, MC-LAG design, ICCP liveness and ICL hold timers, the ICCP/BFD/LACP deep dive and layer 1 interface flapping troubleshooting.

原文链接：https://www.juniper.net/documentation/us/en/software/junos/ospf/topics/topic-map/configuring-ospf-fault-detection-using-bfd.html