Junos Multihop BFD for BGP Failover

BGP's own keepalive timer is measured in seconds, and the smallest sensible hold time is about nine seconds; most production deployments run far slower. When an upstream path breaks, a multihop eBGP session between loopbacks can stay nominally "up" long enough for a traffic blackhole to be noticed by users before the protocol reacts. Multihop BFD closes that gap by running liveness detection independently of the BGP session, over a different destination port and with sub-second timers. This article covers how Junos decides single-hop versus multihop, a working configuration, and the verification output that proves detection is actually sub-second.

Single-hop and multihop are different protocols in practice

Single-hop BFD runs over UDP port 3784 and assumes the peer is one hop away, so the TTL is fixed at 255 and the session is verified against the interface. Multihop BFD uses UDP port 4784, can cross routers, and validates the path with a configurable TTL. Because of that difference, a session that works over a directly connected link will not necessarily come up between loopbacks.

Junos chooses the mode automatically. If the BGP neighbour is directly connected, BFD is single-hop; if the neighbour is reached through other routers, BFD is multihop. When you configure local-address on the group, the local-address check is included in that determination, which is exactly what you want for loopback-based peering.

Configuring multihop BFD for BGP

set protocols bgp group EBGP-MH type external
set protocols bgp group EBGP-MH local-address 1.1.1.1
set protocols bgp group EBGP-MH multihop ttl 3
set protocols bgp group EBGP-MH bfd-liveness-detection minimum-interval 300
set protocols bgp group EBGP-MH bfd-liveness-detection multiplier 3
set protocols bgp group EBGP-MH bfd-liveness-detection session-mode multihop
set protocols bgp group EBGP-MH bfd-liveness-detection no-adaptation
set protocols bgp group EBGP-MH neighbor 3.3.3.3 peer-as 65100

minimum-interval 300 with multiplier 3 gives roughly a 900 ms detection time — fast enough to move traffic before a human notices, slow enough to survive a single dropped packet on a loaded link. no-adaptation prevents Junos from negotiating to slower timers than you asked for, which is important when the peer is more conservative than your design.

session-mode multihop is normally unnecessary because Junos derives it, but stating it explicitly is a useful defensive habit for two reasons: it documents intent for the next engineer, and it prevents a surprising single-hop session if the topology changes so the peer becomes directly reachable.

Adding a hold-down for flapping peers

set protocols bgp group EBGP-MH neighbor 3.3.3.3 holddown-interval 2000

Hold-down delays the notification to BGP after BFD has already seen the session bounce, which avoids handing the routing table a burst of up/down churn during a marginal link. It is only supported on eBGP neighbours and must be configured on both ends; if you use it on a multihop session, the group needs a local-address.

Receiving direction: IBGP

set protocols bgp group INTERNAL type internal
set protocols bgp group INTERNAL local-address 1.1.1.1
set protocols bgp group INTERNAL bfd-liveness-detection minimum-interval 200
set protocols bgp group INTERNAL bfd-liveness-detection multiplier 3

For IBGP and multihop eBGP, the statement can sit at the group level so every neighbour inherits it. On a route-reflector mesh that is usually the right default; per-neighbour timers only when one peer genuinely needs different detection.

Verifying the session

show bfd session
show bfd session detail
show bfd session extensive | match "Multihop|Interval|Detect"
show bgp neighbor 3.3.3.3 | match -i bfd

The session output shows the address pair, the Up or Down state, and the transmit interval actually in use; a value higher than configured means a peer is asking for slower timers and adaptation was allowed. The BGP neighbour output should show BFD attached to that specific neighbour. If BFD is configured but no session appears, check that the forwarding path to the peer loopback exists — multihop BFD cannot come up before routing does, so a chicken-and-egg situation on a fresh build is normal and resolves once the IGP converges.

Pair BFD with a sane interface-level policy: hold-time and damping stop a marginal optic from generating hundreds of BGP churn events, as described in Junos interface flapping: hold-time and damping. For MC-LAG designs where BFD also backs ICCP liveness, the timer budget is shared and needs more care — see MC-LAG ICCP failure scenarios and liveness.

原文链接：https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/bfd-liveness-detection-edit-protocols-bgp.html