Skip to content
Log in Sign up My account

1.8 Bidirectional Forwarding Detection

Blueprint 1.8: Describe Bidirectional Forwarding Detection

  • The problem BFD solves and how it relates to routing protocol timers
  • Session establishment, states and discriminators
  • Asynchronous mode and the echo function
  • Timers, negotiation and detection time
  • Client protocols: OSPF, EIGRP, BGP, static routes and others

The verb is describe, so expect conceptual questions: what BFD does, how fast it detects a failure with given timers, what echo mode changes, and which protocols can use it. ENARSI being a troubleshooting exam, you should also recognise the output of a BFD session that is down or was never registered. This page gives you both, plus a short lab.

The problem: slow failure detection

Routing protocols detect a dead neighbour in one of two ways:

  1. The interface goes down. Fast, because the routing process is told immediately. This only works when the failure is on the local physical link.
  2. Hellos stop arriving. Slow, because the protocol waits for its dead or hold timer.
Protocol Default hello / keepalive Default dead / hold time
OSPF (broadcast, point-to-point) 10 s 40 s
EIGRP (LAN and fast links) 5 s 15 s
BGP 60 s 180 s

Many failures leave the local interface up: a Layer 2 switch or a provider Ethernet service between the routers, a fault in the far router's forwarding plane, a unidirectional fibre problem. During the dead interval, traffic is black-holed.

graph LR
  R1["R1 Gi0/1<br/>10.1.2.1"] -- "link stays up" --- SW["Provider or<br/>campus switch"]
  SW -. "this link fails" .- R2["R2 Gi0/1<br/>10.1.2.2"]
  R1 -. "OSPF waits 40 s<br/>BFD 50 ms x 3 = 150 ms" .-> R2

Tuning the routing protocol timers down (for example OSPF fast hellos) is possible, but each protocol does it separately, in its own process, often on the route processor CPU. BFD (RFC 5880, single-hop IP in RFC 5881) is one lightweight hello protocol, shared by every routing protocol that asks for it, and designed to run at millisecond intervals, often in the forwarding hardware.

How a BFD session works

BFD has no discovery mechanism and builds no routes. A client protocol (OSPF, EIGRP, BGP and so on) that already knows about a neighbour asks BFD to monitor it. BFD creates one session per neighbour per interface, and every client that cares about that neighbour shares the session. When the session goes down, BFD notifies all registered clients, and each one tears down its adjacency immediately and reconverges.

Item Value
Transport UDP
Single-hop control packets Destination port 3784
Echo packets Destination port 3785
Multihop control packets (RFC 5883) Destination port 4784
Single-hop TTL Sent with TTL 255 and checked on receipt (GTSM-style protection)
Version 1 (Cisco IOS also supports the pre-standard version 0)

Discriminators and states

Each end picks a unique local discriminator (LD) for the session and learns the peer's value as the remote discriminator (RD). show bfd neighbors displays them as LD/RD. An RD of 0 means this router has never received a valid packet from the peer.

The session moves through four states with a three-way handshake:

graph LR
  AD["AdminDown"] --> D["Down"]
  D -->|"receive Down"| I["Init"]
  D -->|"receive Init"| U["Up"]
  I -->|"receive Init or Up"| U
  U -->|"detection time expires<br/>or receive Down"| D
  I -->|"detection time expires"| D

The State column in show bfd neighbors is the local state; RH/RS shows the remote state ("remote heard" and the state it reported). A session that is down at one end and Init at the other means packets flow in one direction only, which points to a filter or a unidirectional link.

Asynchronous mode and the echo function

Asynchronous mode Echo function
What is sent BFD control packets, to UDP 3784 at the peer Echo packets addressed to the sender's own IP, sent to the peer's MAC, UDP 3785
Who processes the packet The peer's BFD process Nobody; the peer's forwarding plane simply routes it back
What it tests That the peer's BFD process is alive and reachable The full forwarding path through the peer and back
Interval used for detection The negotiated control interval The local bfd interval value
Control packets while active At the configured interval Slowed down to the BFD slow timer (bfd slow-timers, default 1000 ms on IOS)
Cisco IOS default Always used Enabled by default when BFD is configured on an interface; disable with no bfd echo

Asynchronous mode is the base mode and is always present. The echo function rides on top of an asynchronous session that is already up. Because the peer only forwards echo packets, echo reduces the CPU load on the peer and tests the data plane rather than the control plane. Echo can be active in one direction and not the other.

Cisco recommends no ip redirects on interfaces that use BFD echo. Echo packets arrive at the peer and are sent back out the interface they arrived on, which would otherwise make the peer generate ICMP redirects. Echo also requires the peers to be directly connected; it is not used for multihop sessions.

Exam trap

With echo active, the detection time is set by the echo interval and multiplier, and the control packets drop to the slow timer of about one second. show bfd neighbors details then shows MinTxInt and MinRxInt of 1000000 (microseconds). That is not a misconfiguration. Look for the line "Session state is UP and using echo function with N ms interval".

Timers and detection time

interface GigabitEthernet0/1
 bfd interval 50 min_rx 50 multiplier 3
Parameter Meaning
interval Desired minimum transmit interval: how often this router wants to send
min_rx Required minimum receive interval: the fastest rate this router can accept
multiplier Detect multiplier: how many consecutive packets can be lost before the session is declared down

Each side advertises its values in every control packet, and the session uses the slower of the two:

  • R1 transmits at the larger of R1's interval and R2's min_rx.
  • R1's detection time is R2's multiplier times the larger of R1's min_rx and R2's interval.

With identical values on both ends this simplifies to interval x multiplier. 50 ms x 3 = 150 ms. With 300 ms x 3 the detection time is 900 ms.

R1 config R2 config R1 detects R2 failure in about
50 / 50 / 3 50 / 50 / 3 150 ms
50 / 50 / 3 250 / 250 / 3 750 ms (R2 sends every 250 ms)
100 / 100 / 5 100 / 100 / 3 300 ms (uses R2's multiplier of 3)

On IOS XE you can also put the timers in a reusable template:

bfd-template single-hop FAST
 interval min-tx 50 min-rx 50 multiplier 3
!
interface GigabitEthernet0/1
 bfd template FAST

Exam trap

Timers on an interface do not start a session. BFD only creates a session when a client protocol registers for that neighbour. An interface with bfd interval and no client shows nothing in show bfd neighbors.

Client protocols

Client Enable per interface or neighbour Enable for all
OSPFv2 ip ospf bfd on the interface bfd all-interfaces under router ospf; exclude one with ip ospf bfd disable
OSPFv3 ipv6 ospf bfd or ospfv3 bfd on the interface bfd all-interfaces under the OSPFv3 process
EIGRP classic bfd interface Gi0/1 under router eigrp bfd all-interfaces under router eigrp
EIGRP named bfd under af-interface Gi0/1 bfd under af-interface default
BGP neighbor 10.1.2.2 fall-over bfd Per neighbour or peer group; multihop eBGP or iBGP uses fall-over bfd multi-hop with a multihop template
Static routes ip route static bfd Gi0/1 10.1.2.2, then a normal static route via that next hop
Others IS-IS, HSRP, VRRP and other features can register too

Both ends must run BFD for the neighbour. If only one side registers, that side sends control packets that are never answered, its session stays down, and the client keeps the adjacency up using its own timers. A BFD session that never came up does not tear down anything, so the misconfiguration is silent until a failure takes 40 seconds to detect instead of 150 ms.

interface GigabitEthernet0/1
 bfd interval 100 min_rx 100 multiplier 3
 ip ospf bfd

interface GigabitEthernet0/1
 bfd interval 100 min_rx 100 multiplier 3
router eigrp CORE
 address-family ipv4 unicast autonomous-system 100
  af-interface GigabitEthernet0/1
   bfd

interface GigabitEthernet0/1
 bfd interval 100 min_rx 100 multiplier 3
router bgp 65001
 neighbor 10.1.2.2 remote-as 65002
 neighbor 10.1.2.2 fall-over bfd

interface GigabitEthernet0/1
 bfd interval 100 min_rx 100 multiplier 3
ip route static bfd GigabitEthernet0/1 10.1.2.2
ip route 10.20.0.0 255.255.0.0 GigabitEthernet0/1 10.1.2.2

Exam trap

BFD makes failure detection faster, not convergence by itself. After BFD reports the neighbour down, the protocol still has to find an alternate path: an OSPF SPF run, an EIGRP feasible successor or query, a BGP best-path run. If there is no alternate path, BFD only makes the outage start sooner. It also does nothing for a neighbour that is alive but sending bad routes.

Verification and failure symptoms

R1# show bfd neighbors

IPv4 Sessions
NeighAddr                              LD/RD         RH/RS     State     Int
10.1.2.2                                 1/2          Up        Up        Gi0/1

R1# show bfd neighbors details
(output trimmed)
NeighAddr                              LD/RD         RH/RS     State     Int
10.1.2.2                                 1/2          Up        Up        Gi0/1
Session state is UP and not using echo function.
OurAddr: 10.1.2.1
Local Diag: 0, Demand mode: 0, Poll bit: 0
MinTxInt: 100000, MinRxInt: 100000, Multiplier: 3
Received MinRxInt: 100000, Received Multiplier: 3
Registered protocols: OSPF CEF
Uptime: 00:06:12

Values in the details are in microseconds: 100000 is 100 ms. "Registered protocols" is the line to check when a client is missing. The Local Diag field uses the RFC 5880 diagnostic codes; the ones to recognise are 1 (control detection time expired), 2 (echo function failed) and 3 (neighbour signalled session down).

When BFD takes an OSPF neighbour down, the adjacency log shows the reason:

%OSPF-5-ADJCHG: Process 1, Nbr 10.255.255.2 on GigabitEthernet0/1 from FULL to DOWN, Neighbor Down: BFD node down
Symptom Likely cause
show bfd neighbors empty No client registered on this router (timers alone), or no bfd interval on the interface
Session Down, RD 0 on one side Peer is not running BFD for this neighbour, or BFD packets are filtered
Down at one end, Init at the other One-way loss: an ACL, CoPP policy or unidirectional link drops packets in one direction
Session flaps while the routing adjacency is otherwise fine Timers too aggressive for the CPU or link, often on virtual routers; raise the interval or multiplier
Failover slower than expected Peer uses slower timers (negotiation picks the slower side), or BFD never came up and the protocol timers are being used
Session up but client still slow Client not registered; check "Registered protocols"

Exam trap

An interface ACL or a CoPP policy that permits the routing protocol but not UDP 3784 and 3785 leaves the routing adjacency up and BFD down. Nothing looks broken until the next silent failure. When you write infrastructure ACLs or CoPP classes, include BFD with the routing protocols.

Lab: measure the difference, then break it

Topology: two IOSv routers with an IOSvL2 switch between them, so that a failure beyond the switch leaves R1's interface up. Use access ports in VLAN 1 on SW1.

graph LR
  R1["R1<br/>Lo0 10.255.255.1"] -- "Gi0/1 .1  10.1.2.0/30" --- SW1["SW1 IOSvL2<br/>Gi0/1 and Gi0/2 access VLAN 1"]
  SW1 -- "10.1.2.0/30  .2 Gi0/1" --- R2["R2<br/>Lo0 10.255.255.2"]

Build

  1. Address the link and loopbacks. Run OSPF area 0 on both routers with network 10.0.0.0 0.255.255.255 area 0.
  2. Turn on timestamps with milliseconds on R1: service timestamps log datetime msec.
  3. Without BFD, shut SW1's port toward R2 (Gi0/2). Note the time on SW1, then watch R1's log. The OSPF adjacency goes down when the dead interval expires, up to 40 seconds later. Bring the port back up and wait for FULL.
  4. On both routers, configure Gi0/1 with bfd interval 100 min_rx 100 multiplier 3, no bfd echo and ip ospf bfd. Echo is disabled here so that the timers you configure are the ones that set detection time, and to avoid echo on a virtual platform.
  5. Verify with show bfd neighbors details: state Up, MinTxInt 100000, Registered protocols OSPF.
  6. Repeat step 3. R1 now logs "Neighbor Down: BFD node down" about 300 ms after the port is shut.
  7. Save the configuration on both routers: copy running-config flash:bfd-good.cfg.

Break and fix

  1. Fault: on R2, apply an infrastructure ACL that someone wrote without BFD:

    ip access-list extended INFRA-IN
 permit ospf any any
 permit icmp any any
interface GigabitEthernet0/1
 ip access-group INFRA-IN in
    • Symptom: OSPF stays FULL and pings work, but a failure test is slow again.
    • Diagnosis: show bfd neighbors does not show Up. R2 never receives R1's control packets, so R2 stays Down, while R1, which still hears R2, does not reach Up either. show access-lists INFRA-IN shows no line for UDP.
    • Fix: add permit udp any any eq 3784 and, if echo is used, permit udp any any eq 3785 above the implicit deny. Use host addresses in production.
    • Fault: on R2, change Gi0/1 to bfd interval 999 min_rx 999 multiplier 3.
    • Symptom: the session is Up, but failure detection on R1 takes about 3 seconds.
    • Diagnosis: show bfd neighbors details on R1 shows Received MinRxInt 999000 and the transmit interval negotiated to 999 ms. The slower side wins.
    • Fix: align the timers. Exam scenarios often describe this as "BFD is up, but failover still takes seconds".
    • Fault: on R2, remove ip ospf bfd and configure router ospf 1, bfd all-interfaces, then interface GigabitEthernet0/1, ip ospf bfd disable.
    • Symptom: same as an unregistered client: R1's session to 10.1.2.2 is down with RD 0, and R2 shows no session.
    • Diagnosis: the per-interface disable overrides the process-wide command. Check show running-config interface GigabitEthernet0/1 on R2 and show bfd neighbors details on R1, where OSPF is registered but the remote discriminator stays 0.
    • Fix: remove ip ospf bfd disable.

Quick check

Two routers run bfd interval 50 min_rx 50 multiplier 3 with echo disabled. About how long after the far router stops responding is OSPF told?

About 150 ms: three missed packets at 50 ms intervals. BFD then signals OSPF, which drops the adjacency immediately instead of waiting for the 40-second dead interval.

What is the main difference between BFD asynchronous mode and the echo function?

In asynchronous mode each router's BFD process sends control packets that the peer's BFD process must receive and process. With echo, a router sends packets addressed to itself that the peer simply forwards back, so echo tests the peer's forwarding plane and puts almost no load on the peer's CPU. Echo needs an asynchronous session already up and is used only between directly connected peers.

Name four client protocols or features that can register with BFD on IOS XE.

Any four of: OSPFv2, OSPFv3, EIGRP, BGP, IS-IS, static routes, HSRP, VRRP.

References

  • RFC 5880 (BFD), RFC 5881 (BFD for IPv4 and IPv6 single hop), RFC 5882 (generic application of BFD), RFC 5883 (BFD for multihop paths): rfc-editor.org
  • Cisco IOS XE IP Routing configuration guide, "Bidirectional Forwarding Detection" chapter: search on cisco.com
  • Cisco Live On-Demand Library: search "BFD" and "fast convergence"
  • Related practice: BFD with OSPF and BGP diagram, Sim 08 fault 3