Hands-On Lab: Configuring BFD for Fast Failure Detection

This hands-on lab configures Bidirectional Forwarding Detection between two routers and links it to OSPF, dramatically reducing failure detection time compared to relying on OSPF's own hello and dead timers alone.

BFD ConfigurationSub-Second Failure DetectionBFD Protocol Integration

~3 min read · Updated Sep 26, 2026

Lab Objective

Configure BFD sessions between two routers, link BFD to an already-running OSPF process, and compare the failure detection time using BFD against OSPF's own default hello/dead timer mechanism from earlier in this series.

Lab Purpose

OSPF's default dead timer of 40 seconds, discussed extensively earlier in this series, is far too slow for many modern networks where sub-second failover is expected. Rather than aggressively tuning every routing protocol's own timers individually, BFD provides a single, lightweight, protocol-independent failure detection mechanism that multiple routing protocols can share.

Lab Topology

R1 ---- Gi0/0 ------------------ Gi0/0 ---- R2

192.168.230.1/24            192.168.230.2/24

OSPF already established between R1 and R2,
default timers (hello 10, dead 40)

Task 1: Verify Baseline OSPF Failure Detection Time

Simulate a link failure without BFD and note approximately how long OSPF takes to detect it and remove the neighbor.

Task 2: Configure BFD on Both Interfaces

Enable BFD on the shared Gi0/0 interfaces on both routers, with an aggressive interval.

Task 3: Link BFD to the OSPF Process

Configure OSPF to use BFD for failure detection on this interface, rather than relying solely on its own hello/dead timers.

Task 4: Verify the BFD Session Is Up

Confirm a BFD session establishes between the two routers independently of OSPF's own neighbor state.

Task 5: Simulate a Failure Again and Compare Detection Time

Simulate the same link failure and observe the dramatically faster detection and OSPF neighbor removal.

Solution and Verification

-- Baseline test: link failure without BFD

R1(config)# interface gigabitethernet0/0
R1(config-if)# shutdown

-- (approximately 40 seconds later, based
--  on the default dead timer)
R1# show ip ospf neighbor
-- (neighbor disappears only after roughly
--  40 seconds have elapsed)

R1(config-if)# no shutdown

R1(config)# interface gigabitethernet0/0
R1(config-if)# bfd interval 150 min_rx 150 multiplier 3

R2(config)# interface gigabitethernet0/0
R2(config-if)# bfd interval 150 min_rx 150 multiplier 3

-- 150ms interval with a multiplier of 3
-- means a failure is detected within
-- roughly 450ms, dramatically faster than
-- OSPF's own 40-second dead timer

R1(config)# router ospf 1
R1(config-router)# bfd all-interfaces

R2(config)# router ospf 1
R2(config-router)# bfd all-interfaces

R1# show bfd neighbors

NeighAddr        LD/RD    RH/RS    State   Int
192.168.230.2    1/1      Up/Up    Up      Gi0/0
-- BFD session established independently --
-- this session monitors the link's health
-- directly, separate from OSPF's own hello
-- exchange

R1(config)# interface gigabitethernet0/0
R1(config-if)# shutdown

-- Detection now occurs within roughly
-- half a second

R1# show ip ospf neighbor
-- (neighbor already gone, confirmed by
--  checking almost immediately after the
--  shutdown, rather than waiting anywhere
--  near 40 seconds)

Key Takeaway

BFD operates as an independent, lightweight session that OSPF (or any BFD-integrated protocol) simply asks about, rather than each routing protocol needing its own aggressively tuned hello/dead timers — this separation means the same BFD session can simultaneously accelerate failure detection for multiple protocols running on the same link (OSPF, EIGRP, BGP) without needing to individually configure aggressive timers in each protocol separately.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Configuring EIGRP Stub Routing

This hands-on lab configures a branch router as an EIGRP stub, verifying it advertises only its own connected and summary routes while the hub router correctly avoids querying the stub during a topology change elsewhere in the network.

Continue

Hands-On Lab: Configuring EIGRP Named Mode

This hands-on lab reconfigures a classic EIGRP setup into EIGRP named mode, organizing address-family and interface-specific configuration into a more structured hierarchy, and verifies functional equivalence with the classic configuration style used throughout earlier EIGRP labs in this series.

Continue

Hands-On Lab: Configuring ERSPAN Across a Routed Network

This hands-on lab configures Encapsulated RSPAN (ERSPAN) to mirror traffic across a Layer 3-routed network rather than a single Layer 2 trunk, extending the RSPAN concept from the previous lab beyond the boundaries of a single VLAN or switched domain.

Continue

Hands-On Lab: Configuring RSPAN Across Switches

This hands-on lab configures Remote SPAN (RSPAN) using a dedicated RSPAN VLAN carried across a trunk, allowing traffic mirrored on one switch to be monitored by a capture device connected to an entirely different switch, extending the local SPAN concept covered in an earlier lab across the network.

Continue

Hands-On Lab: Configuring In-Service Software Upgrade (ISSU) on a Stack

This hands-on lab performs an In-Service Software Upgrade across a StackWise stack, upgrading each member's IOS image one at a time while the stack continues forwarding traffic throughout, verifying zero downtime compared to the disruptive reload approach used in earlier IOS upgrade labs.

Continue

Hands-On Lab: Configuring Cisco Catalyst StackWise Traditional Stacking

This hands-on lab configures traditional Catalyst stacking (StackWise) across three switches using stack cables, contrasting its single-tier, chassis-proximity requirement against the StackWise Virtual pair covered in the previous lab, which allows switches to be located much farther apart.

Continue