BFD with OSPF — ip ospf bfd, sub-second OSPF failure detection, faster SPF

OSPF’s dead-interval is 40 seconds by default (4x the 10-second hello-interval). If the link drops, the local router does not know for up to 40 seconds. The local router keeps the dead neighbour in its LSDB; SPF is delayed; traffic continues to be routed through the dead neighbour. BFD solves this by detecting failures in sub-second intervals and signalling OSPF to tear down the adjacency immediately. When BFD+OSPF are integrated, the OSPF neighbour drops within ~150-300ms of the link failure, and SPF recalculates within seconds.

This lesson walks the OSPF+BFD integration on VyOS 1.5 LTS: how to enable BFD on an OSPF interface, how BFD bypasses the dead-interval, how to reference a BFD profile, and the operational commands to validate. The goal is the ability to enable BFD on any OSPF interface, choose the right interval, and validate the integration is live.

Why integrate BFD with OSPF

OSPF without BFD has a 40-second failure detection window. For most production use cases, this is acceptable but not ideal:

• Sub-second failover for critical links — a 40-second blackhole on a critical link means 40 seconds of traffic being routed into a void.
• Faster SPF — when a neighbour drops, OSPF must run SPF to recalculate the shortest path. The faster the neighbour drops, the faster SPF runs.
• Reduced LSDB churn — the dead neighbour’s LSAs age out of the LSDB after 40 seconds. With BFD, the dead neighbour’s LSAs are flushed immediately.

BFD reduces the failure detection time to sub-second intervals. The OSPF neighbour drops within ~150-300ms of the link failure. SPF recalculates within seconds. The LSDB is updated immediately.

The trade-off: BFD consumes CPU and bandwidth. The operator must balance failure-detection speed against the link’s capability.

Enabling BFD on an OSPF interface

On VyOS 1.5 LTS, BFD on an OSPF interface can be enabled in two ways:

Method 1 — under protocols ospf interface:

set protocols ospf interface eth0 bfd

Method 2 — under interfaces ethernet:

set interfaces ethernet eth0 ip ospf bfd

Both methods achieve the same result. The choice is operator preference; the rendered FRR configuration is the same.

To use a specific BFD profile:

set protocols ospf interface eth0 bfd profile 'FAST'

Or:

set interfaces ethernet eth0 ip ospf bfd profile 'FAST'

The full configuration example:

set protocols bfd profile FAST interval '50'
set protocols bfd profile FAST min-rx '50'
set protocols bfd profile FAST multiplier '3'
set protocols ospf area 0 network '192.0.2.0/24'
set protocols ospf interface eth0 bfd profile 'FAST'

The OSPF interface is configured with BFD and references the FAST profile.

sequenceDiagram
  participant A as Router A
  participant B as Router B
  participant OSPF as OSPF daemon
  participant BFD as BFD daemon
  participant LSDB as Link-State Database

  Note over A,B: Initial — link up, OSPF Full, BFD Up
  A->>B: BFD packet (interval 50ms)
  B->>A: BFD packet (interval 50ms)
  Note over A,B: Link drops
  A->>B: BFD packet — NO RESPONSE
  Note over A: BFD detects failure after 150ms (3x missed)
  BFD->>OSPF: neighbour-down signal
  OSPF->>LSDB: Flush dead neighbour's LSAs
  Note over OSPF: SPF recalculates
  Note over A: Routes via dead neighbour removed

The diagram shows the failure detection and teardown sequence. When the link drops, BFD detects the failure in 150ms; BFD signals OSPF; OSPF tears down the adjacency and flushes the dead neighbour’s LSAs; SPF recalculates.

Per-interface BFD overrides

The OSPF interface allows per-interface BFD overrides:

set protocols ospf interface eth0 bfd profile 'DEFAULT'
set protocols ospf interface eth0 bfd interval '100'
set protocols ospf interface eth0 bfd min-rx '100'

The interface uses the DEFAULT profile as the base but overrides interval and min-rx to 100ms. The detection time becomes 100ms * 3 = 300ms.

This is useful when the operator wants different BFD parameters for different interfaces without creating multiple profiles.

How the configuration is applied

The VyOS OSPF node generates the FRR OSPF configuration on commit. The rendered FRR configuration:

interface eth0
  ip ospf bfd profile FAST
!
router ospf
  network 192.0.2.0/24 area 0
!
bfd
  profile FAST
    interval 50 min-rx 50 multiplier 3
!

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

How the result is validated

show ip ospf neighbor detail
show ip ospf neighbor <router-id>
show ip ospf interface eth0
show bfd neighbors
show bfd peer <ip>
show configuration commands | match bfd
vtysh -c 'show ip ospf neighbor detail'
journalctl -u frr
journalctl -u bfdd

The first command shows all OSPF neighbours with full detail (including BFD status). The second shows a specific neighbour. The third shows the OSPF interface state. The fourth shows the BFD session state. The fifth shows the per-peer BFD state. The sixth shows the configuration. The seventh shows the FRR-level OSPF state. The eighth and ninth show the OSPF and BFD logs.

The expected output of show ip ospf neighbor detail:

 Neighbor 192.0.2.2, interface eth0, interface index 2
  In the area 0.0.0.0 via interface eth0
  Neighbor priority is 1, State is Full, 6 state changes
  ... [BFD: status Up, profile FAST, detection 150ms] ...
  DR is 192.0.2.1, BDR is 192.0.2.2
  Options 42 *|-|*|-|-|E|-
  Dead timer due in 37s
  ...

The operator should see BFD: status Up in the output for the integration to be live. If BFD: status Down, the integration is not active.

How it fails

The production failure modes the engineer must recognise:

• OSPF neighbour not using BFD. The bfd clause is missing on the interface. The fix: add the BFD clause.
• BFD up but OSPF not using BFD. The bfd clause is on the interface but the BFD profile is not referenced correctly. The fix: verify the profile name.
• OSPF neighbour drops but BFD says up. BFD is not detecting the failure (asymmetric routing, BFD peer misconfigured). The fix: verify BFD is detecting failures.
• BFD flap causes OSPF flap. The BFD interval is too aggressive; the link cannot sustain the packet rate. The fix: increase the interval.
• OSPF neighbour goes down but SPF does not recalculate. A bug or misconfiguration. The fix: clear the OSPF process or check the OSPF configuration.

Rollback

OSPF+BFD changes are configuration changes. The standard rollback paths:

• rollback N; commit; save to revert any configuration changes.
• delete protocols ospf interface <intf> bfd to disable BFD on an OSPF interface.
• delete interfaces ethernet <intf> ip ospf bfd to disable BFD at the interface level.
• delete protocols bfd profile <name> to remove a profile.
• delete protocols bfd peer <ip> to remove a peer.

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 interfaces.

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 OSPF+BFD on the firewall side. The OSPF lessons vyos-xix-01-ospf-basics and vyos-xxii-01-neighbour-stuck cover the OSPF neighbour adjacency. The lesson vyos-xxxii-01-bfd-concept covers the BFD protocol; vyos-xxxii-02-bfd-config covers the BFD configuration. The lesson vyos-xxxii-03-bfd-with-bgp covers the BGP+BFD integration.

Quiz