Hands-On Lab: Configuring OSPF Fast Hello and Sub-Second Convergence

Lab Objective

Configure OSPF fast hello on a point-to-point link, setting a sub-second hello interval and correspondingly reduced dead timer, then simulate a link failure and measure detection time against the default 10-second hello/40-second dead timer baseline established in earlier OSPF labs.

Lab Purpose

BFD, covered in an earlier lab, is the modern preferred mechanism for fast failure detection across multiple protocols simultaneously. OSPF's own fast-hello feature predates BFD and achieves similar sub-second detection using OSPF's native hello mechanism alone, worth understanding both as a historical alternative and for environments where BFD is unavailable or unsupported.

Lab Topology

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

192.168.240.1/24            192.168.240.2/24

OSPF already established with default
timers (hello 10, dead 40)

Task 1: Verify Baseline Default Timer Behavior

Confirm the current hello and dead timer values on the interface.

Task 2: Configure OSPF Fast Hello

Configure fast-hello with a sub-second interval on both routers' interfaces.

Task 3: Verify the New Timer Values

Confirm the interface now shows the sub-second hello interval and correspondingly adjusted dead timer.

Task 4: Simulate a Link Failure and Measure Detection Time

Simulate the link going down and measure how quickly the neighbor is declared down.

Task 5: Compare Against the Default Timer Baseline

Compare the fast-hello detection time against the roughly 40-second default detection time from earlier labs.

Solution and Verification

R1# show ip ospf interface gigabitethernet0/0 | include Timer

  Timer intervals configured, Hello 10, Dead 40
-- Default timers confirmed, matching every
-- earlier OSPF lab in this series

R1(config)# interface gigabitethernet0/0
R1(config-if)# ip ospf dead-interval minimal hello-multiplier 5

R2(config)# interface gigabitethernet0/0
R2(config-if)# ip ospf dead-interval minimal hello-multiplier 5

-- "minimal" sets the dead interval to 1
-- second, and hello-multiplier 5 means 5
-- hellos are sent within that 1-second
-- window (every 200ms) -- both ends must
-- configure matching values for the
-- adjacency to remain stable

R1# show ip ospf interface gigabitethernet0/0 | include Timer

  Timer intervals configured, Hello 200 msec, Dead 1
-- Confirms the sub-second hello interval
-- (200ms) and 1-second dead interval are
-- now active

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

-- (timing the detection from this point)

R2# show ip ospf neighbor

-- (neighbor entry disappears within
--  approximately 1 second, matching the
--  configured dead interval)

R2# show logging | include OSPF

*Jun 26 09:15:03.102: %OSPF-5-ADJCHG: Process 1,
Nbr 1.1.1.1 on GigabitEthernet0/0 from FULL to
DOWN, Neighbor Down: Dead timer expired
-- Timestamp confirms detection occurred
-- roughly 1 second after the interface
-- went down, matching the configured
-- minimal dead interval precisely

-- Comparison summary:

Default timers (earlier labs): ~40 seconds
                                to detect
                                failure

Fast-hello (this lab):          ~1 second
                                to detect
                                failure

-- A roughly 40x improvement in detection
-- speed, achieved using OSPF's own native
-- hello mechanism alone, without any BFD
-- configuration at all

Key Takeaway

OSPF fast-hello achieves sub-second failure detection using only OSPF's own protocol mechanism, predating and functioning independently of BFD covered in an earlier lab — the trade-off is increased CPU and bandwidth overhead from the much more frequent hello exchange (5 hellos per second here versus once every 10 seconds by default), a cost that must be weighed against the faster detection, and one reason BFD is generally preferred in modern deployments since it decouples this overhead from the routing protocol itself.