BFD

Bidirectional Forwarding Detection (BFD) provides rapid, protocol-independent fault detection for forwarding paths between routers. BFD enables sub-second failure detection that routing protocols use to quickly reroute traffic when a link or neighbor becomes unavailable, significantly reducing convergence time compared to native protocol hello mechanisms.

Summary

BFD addresses the limitations of traditional routing protocol hello timers, which often require several seconds to detect neighbor failures. While OSPF, BGP, and other routing protocols include hello mechanisms for neighbor discovery and failure detection, these timers are typically measured in seconds and are insufficient for sensitive applications. BFD provides a unified, lightweight mechanism that detects failures in milliseconds, independent of the routing protocol in use.

RouterOS implements BFD as specified in RFC 5880, with support for both IPv4 (RFC 5881) and IPv6 (RFC 5883) single-hop sessions and multi-hop sessions (RFC 5883). BFD sessions can be associated with OSPF neighbors, BGP peers, RIP neighbors, and static routes to provide rapid failure detection.

The protocol operates by periodically transmitting BFD control packets between two endpoints. Each endpoint advertises its desired detection interval and receive capabilities. The session remains active as long as packets are received within the negotiated interval multiplied by the configured multiplier. When packets are missed, the session is declared down and associated routing protocols are notified immediately.

Sub-second failover summary:

Protocol	Default Detection Time	With BFD
OSPF	40 seconds (hello 10s × 4)	150–600 ms
BGP	90–180 seconds (hold timer)	150–600 ms
RIP	180 seconds (6 missed updates)	150–600 ms
Static routes	No detection	150–600 ms

Introduction

How BFD Works

BFD operates as a simple hello protocol with configurable timers. Two routers establish a BFD session by exchanging control packets containing session parameters: the desired transmit interval, required minimum receive interval, and detection multiplier. After session establishment, each router transmits BFD control packets at the negotiated interval. If a router fails to receive packets for a period equal to the negotiated interval multiplied by the detection multiplier, it declares the session down and immediately notifies registered consumers (routing protocols, static routes).

The BFD design deliberately minimizes protocol complexity. Unlike routing protocols that maintain full topology databases, BFD only verifies bidirectional reachability. This simplicity allows detection intervals measured in tens or hundreds of milliseconds, versus the seconds required by routing protocol hello mechanisms.

BFD operates in asynchronous mode in RouterOS — both endpoints periodically transmit control packets regardless of whether they have data to send.

Session Types

RouterOS supports BFD sessions triggered by routing protocols:

OSPF BFD integration automatically creates BFD sessions for OSPFv2 and OSPFv3 neighbors when the adjacency reaches Full state. Configured per interface-template, BFD sessions are automatically torn down when the OSPF adjacency drops.

BGP BFD integration creates BFD sessions for BGP peers, detecting failures far faster than the BGP hold timer. Both iBGP and eBGP peers are supported. When BFD detects a failure, BGP immediately resets the session rather than waiting for the hold timer to expire.

RIP BFD integration enables BFD for RIP neighbors, replacing RIP’s 180-second timeout with millisecond-speed detection.

Protocol Overview

BFD control packets are transmitted over UDP port 3784 (single-hop) and UDP port 4784 (multi-hop). Each packet contains session state, discriminators, and timer parameters.

State Machine

BFD implements a four-state machine governing session lifecycle:

State	Meaning
`AdminDown`	Session administratively disabled; packets from remote are discarded
`Down`	Initial state; waiting for remote to acknowledge
`Init`	Remote seen; waiting for mutual confirmation of Up
`Up`	Fully established; bidirectional reachability confirmed

Session establishment flow: both sides start in Down, transmit Down packets, transition to Init when they receive any valid BFD packet, then transition to Up when they receive an Init or Up packet from the remote. The full three-way handshake guarantees bidirectional reachability before the session is declared operational.

Timer Negotiation

Both endpoints advertise their capabilities in BFD control packets:

min-rx (required minimum receive interval): the slowest rate this router can receive

The negotiated transmit interval is max(local min-rx, remote min-rx). This ensures neither endpoint receives packets faster than it can process.

Detection time = negotiated transmit interval × detection multiplier

Example: both peers with min-rx=150ms, multiplier=3 → detection time = 450ms.

Important: Both peers must be configured with compatible values. If peers advertise different min-rx values, the slower value is used for negotiation.

Configuration

BFD Configuration Rules

BFD sessions in RouterOS are created by routing protocols (OSPF, BGP, RIP). The /routing bfd configuration menu defines rules that specify which interfaces and addresses BFD applies to, along with timer settings. Sessions are established automatically when a routing protocol (OSPF, BGP, or RIP) requests BFD for a neighbor that matches a configured rule.

# Create a BFD configuration rule for a directly connected peer
/routing bfd configuration add addresses=10.0.0.2/32 interfaces=ether1

# Create a BFD rule with custom timers
/routing bfd configuration add \
    addresses=10.0.0.2/32 \
    interfaces=ether1 \
    min-rx=200ms \
    multiplier=3

# View BFD configuration rules
/routing bfd configuration print detail

Note: The addresses parameter requires CIDR notation (e.g., 10.0.0.2/32). A rule without addresses or interfaces specified applies to all peers.

OSPF BFD Integration

Enable BFD on OSPF interface templates to accelerate adjacency failure detection:

# Create OSPF instance and area
/routing ospf instance add name=default version=2 router-id=10.0.0.1
/routing ospf area add name=backbone area-id=0.0.0.0 instance=default

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

# Enable BFD on multiple interfaces at once
/routing ospf interface-template add \
    interfaces=ether1,ether2,ether3 \
    area=backbone \
    use-bfd=yes

# Verify BFD is active on OSPF interfaces
/routing ospf interface-template print detail

When the OSPF adjacency on a BFD-enabled interface reaches Full state, RouterOS automatically creates a corresponding BFD session. If the BFD session goes down before the OSPF dead timer fires, OSPF immediately tears down the adjacency and recalculates routes — without waiting for the dead interval.

OSPFv3 (IPv6) uses the same /routing ospf menu. Configure a separate instance with version=3:

/routing ospf instance add name=ospf-v3 version=3 router-id=10.0.0.1
/routing ospf area add name=backbone-v3 area-id=0.0.0.0 instance=ospf-v3
/routing ospf interface-template add \
    interfaces=ether1 \
    area=backbone-v3 \
    use-bfd=yes

Note: RouterOS v7 manages both OSPFv2 and OSPFv3 under the same /routing ospf menu. There is no separate /routing ospf-v3 menu. The instance version parameter (2 or 3) distinguishes them.

BGP BFD Integration

Configure BFD for BGP connections to detect peer failures in milliseconds instead of the hold timer interval (typically 90 seconds):

# Enable BFD on a BGP connection directly
/routing bgp connection add \
    name=ebgp-isp \
    remote.address=203.0.113.1 \
    remote.as=65000 \
    local.role=ebgp \
    use-bfd=yes

# Enable BFD on a BGP template (applies to all connections using this template)
/routing bgp template add \
    name=ibgp-core \
    as=65000 \
    router-id=10.0.0.1 \
    use-bfd=yes

/routing bgp connection add \
    name=core-1 \
    remote.address=10.0.0.2 \
    remote.as=65000 \
    local.role=ibgp \
    templates=ibgp-core

/routing bgp connection add \
    name=core-2 \
    remote.address=10.0.0.3 \
    remote.as=65000 \
    local.role=ibgp \
    templates=ibgp-core

# Verify BGP BFD status
/routing bgp connection print detail

BFD applies identically to both iBGP and eBGP connections.

RIP BFD Integration

Enable BFD for RIP to replace RIP’s 180-second timeout with millisecond detection:

# Create a RIP instance (required before adding interface-templates)
/routing rip instance add name=default

# Enable BFD on a RIP interface template
/routing rip interface-template add interfaces=ether1 instance=default use-bfd=yes

# Verify RIP interface BFD status
/routing rip interface-template print detail

Static Routes with Gateway Monitoring

For static route gateway monitoring, use check-gateway=ping or check-gateway=arp. BFD-based gateway monitoring for static routes is not available in this RouterOS version:

# Primary default route with ICMP gateway monitoring
/ip route add dst-address=0.0.0.0/0 gateway=10.0.0.1 check-gateway=ping distance=1

# Backup route
/ip route add dst-address=0.0.0.0/0 gateway=10.0.0.2 check-gateway=ping distance=2

For dual-ISP failover with faster detection, use BFD via a routing protocol (BGP) rather than static routes.

Monitoring BFD Sessions

Viewing Session State

# List all BFD configuration rules
/routing bfd configuration print

# Detailed view of BFD rules
/routing bfd configuration print detail

# View active BFD sessions (created by routing protocols)
/routing bfd session print

# Detailed session view
/routing bfd session print detail

BFD sessions appear in /routing bfd session print when a routing protocol (OSPF, BGP, RIP) creates them for an active neighbor.

Verifying Protocol Integration

# Confirm OSPF interfaces have BFD active
/routing ospf interface-template print where use-bfd=yes

# Check OSPF neighbors — BFD-enabled adjacencies show faster convergence
/routing ospf neighbor print detail

# Confirm BGP connections have BFD active
/routing bgp connection print where use-bfd=yes

# View active BGP sessions
/routing bgp session print detail

# Check static routes using gateway monitoring
/ip route print where check-gateway=ping

Log Monitoring

BFD state changes are logged and can be monitored in real time:

# Watch BFD log entries
/log print follow where topics~"bfd"

# View recent BFD events
/log print where topics~"bfd"

Log entries show session transitions:

bfd,info BFD session to 10.0.0.2 changed state from up to down
bfd,info BFD session to 10.0.0.2 changed state from down to up

Properties

BFD Configuration Parameters

Parameter	Default	Description
`addresses`	(all)	CIDR-notation peer address filter (e.g., `10.0.0.2/32`). Omit to match all peers on the specified interfaces
`interfaces`	(all)	Interface filter. Omit to match all interfaces
`min-rx`	200ms	Minimum receive interval this router can handle
`multiplier`	3	Missed-packet count before session declared down (2–10)
`disabled`	no	Disable this configuration rule

Session Status Flags

Flag	Description
`U`	Session is up (bidirectional reachability confirmed)
`I`	Session is inactive

Examples

Data Center Sub-Second Failover (OSPF)

Configure OSPF with BFD for fast failover on spine-leaf links:

# BFD configuration rule: 200ms × 3 = 600ms detection time
/routing bfd configuration add interfaces=ether1,ether2 min-rx=200ms multiplier=3

# OSPF configuration
/routing ospf instance add name=default version=2 router-id=10.0.1.1
/routing ospf area add name=backbone area-id=0.0.0.0 instance=default

# Enable BFD on all spine-facing interfaces
/routing ospf interface-template add \
    interfaces=ether1,ether2 \
    area=backbone \
    use-bfd=yes

# Verify BFD sessions come up after OSPF adjacencies reach Full
/routing bfd session print detail
/routing ospf neighbor print

With this configuration, a link failure is detected when BFD misses multiplier packets at the negotiated min-rx interval, and OSPF recalculates within milliseconds.

ISP BGP with BFD (eBGP)

Reduce ISP link failure detection from 90 seconds to under 600ms:

# BFD configuration rule for ISP interface
/routing bfd configuration add addresses=203.0.113.1/32 interfaces=ether1 \
    min-rx=200ms multiplier=3

# BGP connection with BFD
/routing bgp connection add \
    name=isp-primary \
    remote.address=203.0.113.1 \
    remote.as=65000 \
    local.role=ebgp \
    use-bfd=yes

# Monitor: when ISP link fails, BGP session drops faster than hold timer
/routing bfd session print detail
/routing bgp session print detail

Multi-Router iBGP with BFD

Apply consistent BFD to all iBGP route-reflector clients:

# BGP template with BFD
/routing bgp template add \
    name=rr-client \
    as=65000 \
    router-id=10.0.0.1 \
    use-bfd=yes

# Connect all route-reflector clients using the template
/routing bgp connection add name=rr-client-1 remote.address=10.0.1.1 remote.as=65000 local.role=ibgp templates=rr-client
/routing bgp connection add name=rr-client-2 remote.address=10.0.1.2 remote.as=65000 local.role=ibgp templates=rr-client
/routing bgp connection add name=rr-client-3 remote.address=10.0.1.3 remote.as=65000 local.role=ibgp templates=rr-client

Troubleshooting

Session Not Establishing

Check peer reachability — BFD requires IP connectivity before session establishment. Verify routes and allow UDP port 3784 (single-hop) or 4784 (multi-hop) in firewall rules:

# Test basic connectivity
/ping 10.0.0.2

# Verify route to peer exists
/ip route print where dst-address~"10.0.0.2"

# Check firewall — BFD is local traffic (input chain, not forward)
/ip firewall filter print where protocol=udp dst-port=3784,4784

Verify BFD configuration rule matches the peer:

# Check that addresses and interfaces in your rule match the routing protocol peer
/routing bfd configuration print detail

The addresses filter in the BFD configuration rule must match the routing protocol’s peer address, and interfaces must match the interface where the peer is reachable.

Verify routing protocol has BFD enabled:

# OSPF
/routing ospf interface-template print where use-bfd=yes

# BGP
/routing bgp connection print where use-bfd=yes

Verify configuration is not disabled:

/routing bfd configuration print where disabled=yes

Sessions Stuck in Init or Down

Both sides must agree to transition to Up. Common causes:

Firewall blocking BFD packets in one direction only
One peer is not running BFD at all

# Check current state of all sessions
/routing bfd session print detail

# Capture BFD packets to verify bidirectional flow
/tool sniffer quick interface=ether1 port=3784 duration=10

Frequent Session Flaps

Rapidly toggling sessions indicate packet loss or timer misconfiguration:

# Widen timers to reduce false positives
/routing bfd configuration set [find] min-rx=500ms multiplier=5

# Check for physical layer errors
/interface ethernet monitor ether1 once

# Monitor interface traffic load
/interface monitor-traffic ether1 once

On high-utilization links, BFD control packets may be delayed. Either widen timers or implement QoS to prioritize BFD traffic (DSCP CS6).

Routing Protocol Not Reacting to BFD Down

BFD session goes down but OSPF/BGP stays up:

# Verify BFD is enabled on the specific interface/connection
/routing ospf interface-template print detail where use-bfd=yes
/routing bgp connection print detail where use-bfd=yes

# Confirm BFD configuration rule covers the routing protocol peer address
/routing bfd configuration print
/routing ospf neighbor print
/routing bgp session print

# Check logs for BFD state change notifications
/log print where topics~"bfd"

The BFD configuration rule must cover the address used by the routing protocol neighbor. If the rule specifies addresses=10.0.0.2/32 but OSPF uses a different interface address, the integration will not function.

Verification Commands Reference

# BFD configuration rules
/routing bfd configuration print detail

# Active BFD sessions
/routing bfd session print detail

# OSPF neighbors with BFD
/routing ospf neighbor print detail

# BGP connections with BFD
/routing bgp connection print where use-bfd=yes

# Active BGP sessions
/routing bgp session print detail

# BFD-related log entries
/log print where topics~"bfd"

Performance Considerations

Timer Selection

Environment	min-rx	Multiplier	Detection Time	Use Case
Data center	50–100ms	3	150–300ms	Spine-leaf, low-latency
Campus/LAN	100–200ms	3	300–600ms	Standard fast failover
WAN/MPLS	200–500ms	3–5	600ms–2.5s	Handles latency variation
Satellite/high-latency	500ms–1s	3	1.5–3s	Avoids false positives

Start with conservative values (200ms, multiplier 3) and tune faster only after verifying stability under realistic traffic load.

CPU Impact

Each BFD session requires packet processing at the configured interval. On routers with many sessions and fast timers, CPU utilization can become significant:

# Monitor CPU utilization
/system resource print

# Count active BFD sessions
/routing bfd session print count-only

Use slower timers for less critical paths, and reserve fast timers (≤100ms) only for links where sub-second failover is genuinely required.

Security Considerations

BFD control packets lack authentication in the RouterOS implementation. A spoofed BFD Down packet could force route reconvergence.

Restrict BFD traffic by source address — accept BFD packets only from known peer addresses (use chain=input since BFD is locally terminated):

# Accept BFD from known peers
/ip firewall filter add chain=input protocol=udp dst-port=3784 \
    src-address-list=bfd-peers action=accept comment="Allow BFD from peers"

# Drop all other BFD
/ip firewall filter add chain=input protocol=udp dst-port=3784 \
    action=drop comment="Block unexpected BFD"

# Populate the peer list
/ip firewall address-list add list=bfd-peers address=10.0.0.2
/ip firewall address-list add list=bfd-peers address=10.0.0.3

Monitor for anomalies — unexpected session flaps may indicate spoofed packets or network issues:

/log print where topics~"bfd"

Deploy on trusted interfaces — avoid enabling BFD on customer-facing or untrusted interfaces. Use BFD on infrastructure links (management, backbone) only.

Best Practices

Configure BFD rules before enabling protocols — create /routing bfd configuration rules that cover your peer addresses and interfaces before enabling use-bfd=yes on OSPF/BGP/RIP.
Match timers on both peers — mismatched min-rx values cause asymmetric negotiation. Agree on standard values across the routing domain.
Start conservative, tune carefully — begin with 200ms intervals and multiplier 3. Reduce intervals only after confirming stability under load.
Enable on all critical adjacencies — OSPF backbone interfaces and eBGP peering sessions all benefit from BFD. The overhead is low.
Investigate flapping sessions immediately — a repeatedly flapping BFD session indicates an underlying problem (physical errors, congestion, misconfiguration). Do not simply widen timers without understanding the cause.
Use chain=input for firewall rules — BFD control packets are locally terminated (not forwarded). Firewall rules protecting BFD must be placed in the input chain.
Log and alert on session changes — integrate BFD log entries with a monitoring system (Netwatch, SNMP, syslog) to detect intermittent path issues before they cause sustained outages.

OSPF - OSPF routing protocol configuration and BFD integration
OSPF BFD - Detailed OSPF BFD integration guide
BGP BFD and Graceful Restart - BGP BFD integration and graceful restart
RIP - RIP routing protocol with BFD integration
Route Selection and Filters - Static route configuration and gateway monitoring
VRRP - Virtual Router Redundancy Protocol for gateway redundancy

BFD

BFD