Multihop BFD
Single-hop BFD checks one link between directly connected neighbours. Sometimes the thing you care about is several hops away: a BGP session between loopback addresses (see BGP between loopbacks), or a peer across a provider's network. Multihop BFD (UDP port 4784) checks the whole path between two addresses, whichever way it currently goes.
The lab adds one, between R1's and R2's loopbacks (192.0.2.1 and 192.0.2.2, announced in BGP), as a configured BFD peer with a source address. It uses its own profile, MULTIHOP, with 1-second intervals and a 3-second detection time.
The slower timers are deliberate. A multihop session's path can change: when link A failed, the loopback route moved from link A to link B. If the multihop session detected failure faster than the network can reroute (here, about a second), it would flap on every single-link failure. Give multihop BFD a detection time comfortably longer than your network's reconvergence.
In the lab, cutting link A took link A's single-hop session down, while the multihop session stayed up (its uptime carried on counting) and the route to R2's loopback moved to link B.
Minimum TTL: 254 is a safety check. A multihop BFD packet may cross a router or two, but one with a much lower TTL came from too far away, and could be spoofed, so it's ignored.
set protocols bgp address-family ipv4-unicast network '192.0.2.1/32'
set protocols bfd profile MULTIHOP interval transmit '1000'
set protocols bfd profile MULTIHOP interval receive '1000'
set protocols bfd profile MULTIHOP interval multiplier '3'
set protocols bfd peer 192.0.2.2 multihop
set protocols bfd peer 192.0.2.2 source address '192.0.2.1'
set protocols bfd peer 192.0.2.2 profile 'MULTIHOP'- Line 1: The loopback, so R2 can reach it over either link.
- Lines 2–4: A slower profile: 1 s × 3.
- Lines 5–7: A configured multihop session between the loopbacks.
vyos@R1:~$ show bfd peers brief
Session count: 3
SessionId LocalAddress PeerAddress Status Profile
========= ============ =========== ====== =======
1019056413 10.0.12.5 10.0.12.6 up FAST
1607721972 192.0.2.1 192.0.2.2 up MULTIHOP
4181564441 10.0.12.1 10.0.12.2 up FAST
vyos@R1:~$ show bfd peer 192.0.2.2
peer 192.0.2.2 multihop local-address 192.0.2.1 vrf default
ID: 1607721972
Remote ID: 2935791227
Active mode
Minimum TTL: 254
Status: up
Uptime: 14 second(s)
Diagnostics: ok
Remote diagnostics: ok
Peer Type: configured
RTT min/avg/max: 0/0/0 usec
Profile: MULTIHOP
Local timers:
Detect-multiplier: 3
Receive interval: 1000ms
Transmission interval: 1000ms
Transmission interval (actual with jitter): 860ms
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: 50ms- Line 6: Loopback to loopback, with the MULTIHOP profile.
- Line 9: No interface: it follows whatever path routing chooses.
- Line 13: Packets arriving with a TTL below 254 are ignored.
- Line 18: configured: created by the BFD configuration itself.
- Line 26: 3 seconds to detect a failure.
root@r1-container:~# ip link set eth0 nomaster # cut link A again
vyos@R1:~$ show bfd peers brief
Session count: 3
SessionId LocalAddress PeerAddress Status Profile
========= ============ =========== ====== =======
1019056413 10.0.12.5 10.0.12.6 up FAST
1607721972 192.0.2.1 192.0.2.2 up MULTIHOP
4181564441 10.0.12.1 10.0.12.2 down FAST
vyos@R1:~$ show bfd peer 192.0.2.2 | match "Status|Uptime|Diagnostics"
Status: up
Uptime: 45 second(s)
Diagnostics: ok
vyos@R1:~$ show ip route 192.0.2.2/32
Routing entry for 192.0.2.2/32
Known via "bgp", distance 20, metric 0, best
Last update 00:00:06 ago
Flags: Selected
Status: Installed
* 10.0.12.6, via eth1, weight 1- Line 9: Link A's session is down, and still listed: its BGP neighbour still exists.
- Lines 11–13: The multihop session never noticed: up for 45 seconds and counting.
- Lines 14–20: Because the route to R2's loopback had already moved to link B.
Check your understanding
Why should a multihop BFD session use slower timers than the single-hop sessions under it?
- Its path can change. If it detects failure faster than the network reroutes, every single-link failure makes it flap.
- Multihop BFD packets are bigger.
- Multihop BFD runs over TCP.
- The TTL check makes it slower.