OSPF BFD: Fast Failure Detection

OSPF BFD: Fast Failure Detection

Bidirectional Forwarding Detection (BFD) is a lightweight hello protocol that provides sub-second failure detection for OSPF adjacencies. Without BFD, OSPF relies on its own hello and dead intervals to detect neighbor failures — a process that typically takes 40 seconds with default settings. BFD reduces that to hundreds of milliseconds or less, enabling rapid rerouting when a link or neighbor fails.

This guide covers enabling BFD on OSPF interfaces in RouterOS 7, tuning detection timers, and understanding how BFD and OSPF interact on different network segment types.

How BFD Accelerates OSPF Failure Detection

OSPF detects neighbor failures by waiting for the dead interval to expire without receiving a hello. Default RouterOS 7 values are:

OSPF parameter	Default	Failure detected after
hello-interval	10s	—
dead-interval	40s	~40 seconds

With BFD enabled, OSPF delegates failure detection to the BFD subsystem. BFD operates independently of OSPF timers and can detect the loss of a neighbor in as little as 300 ms using default BFD settings (200 ms interval × 3 multiplier). When BFD declares the session down, OSPF is notified immediately and withdraws the adjacency without waiting for the dead interval.

Detection method	Typical detection time	CPU overhead
OSPF dead interval (default)	~40 seconds	Minimal
OSPF dead interval (tuned to 3×1s)	~3 seconds	Low
BFD (default 200ms × 3)	~600 ms	Low–Medium
BFD (tuned 100ms × 3)	~300 ms	Medium
BFD (aggressive 50ms × 3)	~150 ms	Higher

Aggressive OSPF hello tuning (sub-second intervals) increases hello traffic and CPU load on every OSPF interface. BFD achieves faster detection with lower per-interface overhead because BFD packets are simpler and processed more efficiently than OSPF hellos.

Enabling BFD on OSPF Interfaces

BFD for OSPF is enabled on the interface-template with use-bfd=yes. RouterOS automatically creates a BFD session for each OSPF neighbor that reaches Full adjacency on that interface.

Basic Configuration

# Enable BFD on a backbone interface
/routing ospf interface-template
add interfaces=ether1 area=backbone use-bfd=yes

# Enable BFD on an existing template
/routing ospf interface-template
set [find interfaces=ether1] use-bfd=yes

When use-bfd=yes is set, RouterOS creates a BFD peer entry automatically when the OSPF adjacency forms. The BFD session uses the same neighbor IP address that OSPF uses. When OSPF tears down the adjacency for any reason, the associated BFD session is also removed.

Enabling BFD on Multiple Interfaces

Apply use-bfd=yes to each interface where fast failure detection is required. Passive interfaces and interfaces with no OSPF neighbors do not generate BFD sessions even when the flag is set.

/routing ospf interface-template
# Core uplinks — fast failure detection needed
add interfaces=sfp-sfpplus1 area=backbone network-type=point-to-point use-bfd=yes
add interfaces=sfp-sfpplus2 area=backbone network-type=point-to-point use-bfd=yes

# Distribution LAN — broadcast segment with multiple neighbors
add interfaces=bridge-core area=backbone use-bfd=yes

# Loopback — passive, no BFD sessions created
add interfaces=lo0 area=backbone passive=yes

OSPFv3 (IPv6)

The same use-bfd=yes parameter applies to OSPFv3 interface-templates for IPv6 routing:

/routing ospf interface-template
add interfaces=ether1 area=backbone-v3 use-bfd=yes

---

Tuning Detection Timers

BFD detection time is determined by three parameters:

Parameter	Description	Default
interval	Desired transmit interval for BFD control packets	200ms
min-rx	Minimum receive interval this router can handle	200ms
multiplier	Missed-packet count before session declared down	3

Detection time = (negotiated interval) × multiplier

The negotiated interval is the maximum of the local interval and the remote’s min-rx. Both routers must agree, so configure matching values on all peers in the routing domain.

Configuring BFD Timers via a Template

RouterOS BFD templates define shared timer settings that apply to all sessions using that template.

# Create a BFD template for OSPF peers
/routing bfd template
add name=ospf-bfd interval=200ms min-rx=200ms multiplier=3

This produces a detection time of 600 ms with default settings (200 ms × 3).

For faster detection on stable links:

# Aggressive: 300 ms detection on stable core links
/routing bfd template
add name=ospf-fast interval=100ms min-rx=100ms multiplier=3

For links with variable latency or marginal reliability:

# Conservative: 1.5 s detection — avoids false positives on WAN links
/routing bfd template
add name=ospf-wan interval=500ms min-rx=500ms multiplier=3

Recommended Timer Guidelines

Environment	Interval	Multiplier	Detection time	Notes
Data center core	100ms	3	300ms	Stable hardware, low jitter
Campus distribution	200ms	3	600ms	Reasonable for switched Ethernet
WAN / MPLS PE-CE	300–500ms	3–5	0.9–2.5s	Variable latency, avoid flaps
Wireless backhaul	500ms	5	2.5s	Higher jitter, avoid false positives

Do not deploy sub-100 ms intervals without benchmarking CPU load on all routers involved. On multi-session deployments, fast BFD timers multiplied across many peers can become a significant CPU consumer.

---

BFD on Different OSPF Network Types

BFD behavior is the same across network types — it creates a per-neighbor session once the OSPF adjacency reaches Full. However, the number of sessions and their addressing differs.

Point-to-Point Links

On point-to-point links, exactly one BFD session is created per interface. This is the most common and reliable use case for BFD.

/routing ospf interface-template
add interfaces=ether1 area=backbone network-type=point-to-point use-bfd=yes

One OSPF adjacency → one BFD session → sub-second failure detection for that link.

Broadcast Segments

On broadcast segments (Ethernet LANs), OSPF forms Full adjacency only with the DR and BDR. DROther routers form 2-Way state with other DROthers but do not reach Full. BFD sessions are only created for Full adjacencies.

/routing ospf interface-template
add interfaces=bridge-core area=backbone use-bfd=yes

On a segment with one DR, one BDR, and two DROthers:

• DR: creates BFD sessions with BDR and both DROthers (3 sessions)
• BDR: creates BFD sessions with DR and both DROthers (3 sessions)
• Each DROther: creates BFD sessions with DR and BDR only (2 sessions)

If the DR fails, BFD on the BDR and DROthers detects the failure and notifies OSPF before the dead interval expires. The BDR promotes to DR immediately.

Verifying Which Adjacencies Have BFD Sessions

# Show OSPF neighbors and their adjacency state
/routing ospf neighbor print detail

# Show all BFD sessions — dynamically created ones include the source protocol
/routing bfd peer print detail

BFD sessions created by OSPF appear in the peer list with protocol=ospf. Sessions not in the Up state indicate a detection problem or neighbor that has not yet reached Full adjacency.

---

Verification

Confirming BFD is Active on OSPF Interfaces

# Show interface-templates — confirm use-bfd=yes is set
/routing ospf interface-template print detail

# Show active OSPF interfaces
/routing ospf interface print detail

Checking BFD Session State

# List all BFD peers with current state
/routing bfd peer print detail

# Monitor sessions in real-time
/routing bfd peer monitor [find]

A healthy session shows state: up. Sessions in down or init state indicate that BFD has not established bidirectional communication with that peer.

BFD Session Counters

# Session statistics — verify packets are being exchanged
/routing bfd session print stats

The packets-sent and packets-received counters should both be incrementing. A packets-lost counter consistently increasing alongside session flaps indicates an unstable path.

Confirming Negotiated Detection Time

BFD negotiates the actual transmit interval between peers. The detection time in use equals the negotiated interval × multiplier on that session, visible in the peer print detail output.

/routing bfd peer print detail
# Look for: interval (negotiated transmit), min-rx, multiplier, state

---

Troubleshooting

BFD Sessions Not Creating After Enabling use-bfd

BFD sessions are only created when the OSPF adjacency reaches Full state. Confirm neighbor state first:

# Confirm OSPF neighbor has reached Full
/routing ospf neighbor print

If neighbors are stuck at ExStart, Exchange, or Loading, fix the OSPF adjacency before expecting BFD sessions to appear.

Sessions Stuck in Down or Init

A session that does not reach Up indicates that BFD control packets are not being received. Check reachability and firewall rules:

# Verify IP connectivity to the peer
/ping 10.0.0.2

# BFD control packets use UDP port 3784 — verify firewall allows them
/ip firewall filter print where dst-port=3784

Ensure that BFD is also enabled on the peer router’s OSPF interface. If only one side has use-bfd=yes, the BFD session will remain in Down state.

Session Flapping

Frequent Up/Down transitions indicate intermittent packet loss or an unstable physical link:

# Check physical layer errors
/interface ethernet monitor ether1 once

# Increase multiplier to tolerate transient loss
/routing bfd template set ospf-bfd multiplier=5

Increasing the multiplier from 3 to 5 (for example) allows five consecutive missed packets before declaring the session down, reducing sensitivity to brief bursts of loss without significantly increasing worst-case detection time.

Routing Table Not Updating After BFD Failure

If BFD detects a failure but the routing table does not update promptly, verify that the OSPF integration is correctly tied to BFD:

# Confirm use-bfd=yes on the interface-template
/routing ospf interface-template print detail

# Check OSPF log for adjacency events
/log print where topics~"ospf"

# Check BFD log for session state changes
/log print where topics~"bfd"

The log should show BFD session down followed immediately by an OSPF adjacency down event when the integration is working correctly.

---

Full Example: Core Router with BFD-Enabled OSPF

A router with two point-to-point core links and a distribution LAN, using BFD for fast failure detection on all OSPF interfaces.

                    [core-router]
                   /             \
        sfp-sfpplus1           sfp-sfpplus2
        (p2p, Area 0)          (p2p, Area 0)
          10.0.0.1/30            10.0.0.5/30
          BFD 100ms×3            BFD 100ms×3
                │                      │
           [router-a]             [router-b]
                    \             /
                  bridge-core (Area 0)
                  10.1.0.0/24
                  BFD 200ms×3

# BFD templates
/routing bfd template
add name=bfd-core  interval=100ms min-rx=100ms multiplier=3
add name=bfd-lan   interval=200ms min-rx=200ms multiplier=3

# OSPF instance and areas
/routing ospf instance
add name=ospf1 version=2 router-id=10.0.0.1

/routing ospf area
add name=backbone area-id=0.0.0.0 instance=ospf1

# Interface templates — BFD enabled on all active OSPF interfaces
/routing ospf interface-template
# Core uplinks: point-to-point, fast BFD
add interfaces=sfp-sfpplus1 area=backbone network-type=point-to-point use-bfd=yes
add interfaces=sfp-sfpplus2 area=backbone network-type=point-to-point use-bfd=yes
# Distribution LAN: broadcast, standard BFD
add interfaces=bridge-core area=backbone use-bfd=yes priority=200
# Loopback: passive, no BFD
add interfaces=lo0 area=backbone passive=yes

After adjacencies form, verify all BFD sessions reach Up:

/routing bfd peer print detail
# Expected: three sessions (two p2p peers + DR/BDR on LAN), all state: up

/routing ospf neighbor print
# Expected: all neighbors at Full state

---

Related Documentation

• OSPF — OSPF fundamentals, LSA types, neighbor states, and area design
• OSPF Configuration — Multi-area setup, DR/BDR election, and route redistribution
• OSPF Area Types — Stub, totally stubby, and NSSA configuration
• BFD — BFD protocol reference: static sessions, BGP integration, timers, and echo mode