BFD configuration — protocols bfd, peer configuration, transmit/receive interval, multiplier

BFD configuration on VyOS 1.5 LTS is structured around profiles — reusable parameter sets that can be referenced by multiple peers. A profile defines the transmit/receive interval, the multiplier, the echo mode, and the multi-hop flag. A peer references a profile. The operator can override profile parameters per-peer when needed.

This lesson walks the BFD configuration tree, the profile vs peer configuration, the transmit/receive interval and multiplier knobs, echo mode, and the operational commands to validate. The goal is the ability to configure BFD for any link, choose the right interval for the right scenario, and validate the configuration is live.

The BFD configuration tree

set protocols bfd
  ├── profile <name>
  │     ├── interval <ms>
  │     ├── min-rx <ms>
  │     ├── multiplier <count>
  │     ├── echo-mode
  │     ├── echo-interval <ms>
  │     └── passive
  └── peer <ip>
        ├── interval <ms>
        ├── min-rx <ms>
        ├── multiplier <count>
        ├── echo-mode
        ├── echo-interval <ms>
        ├── passive
        ├── profile <name>
        ├── multihop
        ├── src <ip>
        └── vrf <name>

The configuration tree has two main branches:

• profile — reusable parameter sets. The operator creates a profile with the desired parameters and references it from one or more peers.
• peer — a specific BFD peer. The peer references a profile (or defines its own parameters inline). The peer can override any profile parameter.

The canonical pattern: define a profile per use case (e.g., FAST for low-latency fibre, SLOW for VPN tunnels, DEFAULT for typical use). Reference the profile from peers.

Profile configuration

The canonical profile for low-latency fibre:

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

The three knobs:

• interval — how often the local router sends BFD packets. 50ms means 20 packets per second.
• min-rx — the minimum interval at which the local router is willing to receive BFD packets. The negotiation picks the slower of the two sides’ min-rx values.
• multiplier — how many packets can be missed before the session is declared down. 3 is the typical production value.

The detection time is interval * multiplier. With the above profile, the detection time is 50ms * 3 = 150ms.

For typical fibre (less aggressive):

set protocols bfd profile DEFAULT interval '200'
set protocols bfd profile DEFAULT min-rx '200'
set protocols bfd profile DEFAULT multiplier '3'

Detection time: 200ms * 3 = 600ms.

For VPN tunnels or slow links:

set protocols bfd profile SLOW interval '500'
set protocols bfd profile SLOW min-rx '500'
set protocols bfd profile SLOW multiplier '3'

Detection time: 500ms * 3 = 1500ms.

Peer configuration

The peer references a profile:

set protocols bfd peer 192.0.2.2 profile 'FAST'

This is the simplest peer configuration. The peer uses the FAST profile’s parameters.

The peer can override any profile parameter inline:

set protocols bfd peer 192.0.2.2 profile 'DEFAULT'
set protocols bfd peer 192.0.2.2 interval '100'
set protocols bfd peer 192.0.2.2 min-rx '100'

The peer uses DEFAULT as the base but overrides interval and min-rx to 100ms.

Multi-hop peers

For BFD peers that are not directly connected (e.g., across a routed network), the operator uses the multihop flag:

set protocols bfd peer 192.0.2.2 profile 'FAST'
set protocols bfd peer 192.0.2.2 multihop
set protocols bfd peer 192.0.2.2 src 192.0.2.1

The src clause specifies the source IP for the BFD packets. The multihop flag enables BFD for multi-hop paths.

Multi-hop BFD uses UDP port 4784 instead of 3784. The multi-hop flag is required.

Echo mode

Echo mode is a one-way failure detection mechanism. The local router sends BFD echo packets to the peer; the peer loops them back. If the local router does not receive the echo back within the echo-interval, the local router declares the path down.

Echo mode is useful when the local router wants to detect a unidirectional failure (one side can send but not receive) without requiring the peer to run BFD. The peer just needs to loop the packets back.

set protocols bfd peer 192.0.2.2 echo-mode
set protocols bfd peer 192.0.2.2 echo-interval '100'

The echo-interval is typically 100ms (the canonical value).

Echo mode has caveats:

• The peer must loop the packets back. Most routers do this by default; some require explicit configuration.
• Echo mode only detects failures in one direction (the echo path). It does not detect failures in the return path.
• Echo mode can be combined with the standard BFD handshake for bidirectional detection.

The canonical production pattern: use the standard BFD handshake for bidirectional detection; use echo mode when the peer does not support BFD.

Passive mode

Passive mode is the opposite of active mode. In active mode, the local router initiates the BFD handshake. In passive mode, the local router waits for the peer to initiate.

set protocols bfd peer 192.0.2.2 passive

Passive mode is useful when the operator wants the local router to listen for BFD but not initiate. The canonical use case: the local router is behind a stateful firewall and cannot initiate the handshake but can respond to one.

How the configuration is applied

The VyOS BGP node generates the FRR BFD configuration on commit. The rendered FRR configuration for the example above:

bfd
  profile FAST
    interval 50 min-rx 50 multiplier 3
  !
  peer 192.0.2.2
    profile FAST
    multihop
    no shutdown
  !
!

The operator confirms the rendered configuration with vtysh -c 'show configuration' | grep -A 20 bfd.

How the result is validated

show bfd profile
show bfd peers
show bfd peer <ip>
show bfd neighbors
show configuration commands | match bfd
vtysh -c 'show bfd neighbors'
journalctl -u bfdd
tcpdump -nn -i any udp port 3784
tcpdump -nn -i any udp port 4784

The first command shows all configured profiles. The second shows all configured peers. The third shows the per-peer state. The fourth shows the active BFD sessions. The fifth shows the operator’s BFD configuration. The sixth shows the FRR-level BFD state. The seventh shows the BFD daemon log. The eighth shows the single-hop BFD packets. The ninth shows the multi-hop BFD packets.

How it fails

The production failure modes the engineer must recognise:

• BFD session in Down because of firewall. UDP 3784/4784 is blocked. The fix: open the firewall.
• BFD session in Down because the peer does not run BFD. The peer does not have BFD configured. The fix: configure BFD on the peer or use echo mode.
• BFD session flapping because of interval too aggressive. The link cannot sustain 20 packets per second. The fix: increase the interval.
• BFD session up but routing protocol not using it. The BFD session is established but the routing protocol does not have BFD integration enabled. The fix: enable BFD on the routing protocol side.
• Multi-hop BFD failing because of asymmetric routing. The BFD packets take a different path than the routing protocol’s packets. The fix: ensure symmetric routing or use single-hop BFD.
• Echo mode failing because the peer does not loop packets back. The peer’s hardware or software does not support BFD echo. The fix: disable echo mode or configure the peer to loop packets back.

Rollback

BFD configuration 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 profile.
• delete protocols bfd peer <ip> to remove a peer.
• delete protocols bgp <asn> neighbor <ip> bfd to disable BGP+BFD integration.
• delete protocols ospf interface <intf> bfd to disable OSPF+BFD integration.

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 lesson vyos-xxxii-01-bfd-concept covers the BFD protocol. The lessons vyos-xxxii-03-bfd-with-bgp, vyos-xxxii-04-bfd-with-ospf, and vyos-xxxii-05-bfd-with-static cover the routing protocol integrations.

Quiz