Course contents

Module 2: OSPF OperationLesson 2.2 (2 of 4 in this module)6 of 29 in the OSPF course

OSPF Hello and Dead timers

The Ethernet port is still up, but the router at the far end has stopped sending OSPF messages. How long should its neighbour keep trusting it? Two timers answer that question—and a mismatch can stop the routers becoming neighbours in the first place.

Intermediate · 12 min read

Technical definition

Hello interval and Router Dead interval The Hello interval controls periodic Hello transmission. The Router Dead interval is the inactivity period after which a neighbour is declared down without an accepted Hello.

A working link needs repeated evidence

Use the same area-0 link as the Router ID lesson: R1 Gi0/1 is 10.0.12.1/30 and R2 Gi0/0 is 10.0.12.2/30. Both use the OSPF point-to-point network type on Ethernet; RIDs are 1.1.1.1 and 2.2.2.2. The port addresses deliver link traffic; the RIDs identify the neighbours. Assume addressing, area, authentication and MTU already agree.

A Hello is an OSPF discovery and maintenance packet, not a user ping. With a Hello interval of 10 seconds, each router periodically sends it. The Dead interval of 40 seconds limits how long a neighbour can remain silent. An accepted Hello refreshes the receiver’s inactivity countdown.

Both ends advertise the same Hello and Dead values
Both ends advertise the same Hello and Dead valuesThe two routers use separate local countdowns. Each accepted Hello refreshes the receiving router’s neighbour inactivity timer. Area 0 point-to-point Ethernet: R1 Gi0/1 10.0.12.1/30 and R2 Gi0/0 10.0.12.2/30. R1 advertises Hello 10 seconds and Dead 40 seconds. R2 advertises Hello 10 seconds and Dead 40 seconds; other adjacency requirements are assumed correct.R1R2Hello 10 · Dead 40Hello 10 · Dead 40Gi0/1 · .1Gi0/0 · .2Link subnet: 10.0.12.0/30 · all timers in secondsMatching timers are necessary, not the only check

On small screens, swipe sideways or focus the diagram and use the arrow keys.

The two routers use separate local countdowns. Each accepted Hello refreshes the receiving router’s neighbour inactivity timer.

Matching Hello and Dead values are required, but they do not prove that every other neighbour setting is correct. Also check area, authentication and the other requirements taught in neighbour formation. These timers do not replace database exchange or verify an application’s end-to-end path.

Read the configured intervals before changing them

These examples use the ordinary second-based OSPFv2 interface commands on Cisco IOS/IOS XE, without fast-Hello or BFD configuration. Verify support and output on your lab image. Typical Cisco broadcast and point-to-point defaults are Hello 10 / Dead 40 seconds; non-broadcast defaults commonly use 30 / 120. Read the interface output instead of guessing from the cable type.

Example output
R1#show ip ospf interface GigabitEthernet0/1
GigabitEthernet0/1 is up, line protocol is up
  Internet Address 10.0.12.1/30, Area 0
  Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
  Neighbor Count is 1, Adjacent neighbor count is 1

Read Hello 10 as the send interval and Dead 40 as the configured inactivity limit. The Wait and Retransmit fields have other roles; do not mistake either for the neighbour’s remaining lifetime. On R2, inspect Gi0/0 rather than copying R1’s interface name.

Example output
R1#show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           0   FULL/  -        00:00:36    10.0.12.2       GigabitEthernet0/1

Dead Time 00:00:36 is the countdown remaining at that instant. It is not the configured interval and it is not the neighbour’s uptime. In this simplified case, about four seconds have passed since R1 last accepted R2’s Hello. A later accepted Hello moves the countdown back towards 40 seconds.

Why a failure does not mean a fresh 40-second wait

Count from the last accepted Hello, not the cable fault
Count from the last accepted Hello, not the cable faultAn idealised local timeline with no carrier-down or other faster failure signal. If a fault happens just after the last Hello, detection is near 40 seconds; if it happens later, part of that interval has already elapsed. R1 last accepts R2's Hello at time zero. The next Hellos, expected at 10, 20 and 30 seconds, do not arrive. With Dead 40 seconds, R1 declares the neighbour down at time 40 if no other failure signal occurs. A new accepted Hello before expiry restarts the timer.0 sHello accepted10 sNo Hello20 sNo Hello30 sNo Hello40 sDead expiresR1’s view of R2 · Hello 10 s / Dead 40 s

On small screens, swipe sideways or focus the diagram and use the arrow keys.

An idealised local timeline with no carrier-down or other faster failure signal. If a fault happens just after the last Hello, detection is near 40 seconds; if it happens later, part of that interval has already elapsed.

Take R1’s last accepted Hello as time zero. If no further Hello arrives and no other failure signal occurs, the 40-second inactivity timer expires at about time 40. A fault at time 7 leaves roughly 33 seconds on that timer, not a new 40 seconds. The exact observed time also depends on scheduling and the failure mechanism.

A local carrier-down indication can reveal a failure before inactivity expiry. The timeline deliberately keeps the local port up to isolate silent-neighbour detection. After detecting loss, route recalculation and forwarding recovery take additional work; the Dead interval is not a guarantee for total application recovery time.

The cable works, but the timers disagree

Now change only R2 to Hello 5 / Dead 20 while R1 stays at 10 / 40. R1 may receive packets from R2, but their advertised timer values fail the compatibility check. An established adjacency can be lost after this change; a new one cannot form with the mismatch. Sending more frequent Hellos on one side does not solve the disagreement.

Hellos arrive, but the timer values do not agree
Hellos arrive, but the timer values do not agreeThis is a protocol mismatch even though the cable and IP addressing work. Repair both timer values on the affected link, then verify adjacency. Area 0 point-to-point Ethernet: R1 Gi0/1 10.0.12.1/30 and R2 Gi0/0 10.0.12.2/30. R1 advertises Hello 10 seconds and Dead 40 seconds. R2 advertises Hello 5 seconds and Dead 20 seconds, so the Hellos fail the timer compatibility check.R1R2Hello 10 · Dead 40Hello 5 · Dead 20Gi0/1 · .1Gi0/0 · .2Link subnet: 10.0.12.0/30 · all timers in secondsTimer mismatch prevents neighbour formation

On small screens, swipe sideways or focus the diagram and use the arrow keys.

This is a protocol mismatch even though the cable and IP addressing work. Repair both timer values on the affected link, then verify adjacency.

Compare show ip ospf interface on both ends and inspect each interface configuration. Restore the intended pair on R2 or coordinate the same new pair on both routers. Check for other faults if the values agree but the adjacency still fails; timer mismatch is a finding from evidence, not a diagnosis based only on a missing neighbour.

Change both values on both ends

For an isolated lab, choose 5 / 20 to observe a shorter inactivity window. Plan for adjacency interruption while the two sides temporarily differ. Configure both values explicitly; do not depend on a software image deriving the desired Dead interval after a Hello change.

configure terminal interface GigabitEthernet0/1 ip ospf hello-interval 5 ip ospf dead-interval 20 end

On R1: apply the planned timer pair to the OSPF router-facing interface.

configure terminal interface GigabitEthernet0/0 ip ospf hello-interval 5 ip ospf dead-interval 20 end

On R2: apply the same pair to its port on this link. Interface names differ; timer values agree.

Verify Hello 5 and Dead 20 in each interface’s operational output. Then check the neighbour returns to Full and required destination and return routes recover. Compare the countdown across several readings rather than demanding an exact fixed value.

Shorter intervals generate more Hellos and leave less tolerance for loss or delayed processing. Choosing an aggressive timer is a design trade-off, not a free performance improvement. Subsecond fast-Hello and BFD features have separate support and compatibility requirements; this lab does not enable them.

Restore the baseline and prove recovery

configure terminal interface GigabitEthernet0/1 no ip ospf hello-interval no ip ospf dead-interval end

On R1: remove both overrides. On R2 use Gi0/0 and remove the same two overrides. Verify the resulting defaults on this point-to-point link.

Check 10 / 40 on both ends, Full, and the lab’s route/traffic checks. Removing only one override can leave a different pair than intended. Save the intended final configuration after verification.

Try it: predict, observe and explain

  1. Record each router’s interface type, configured timer pair, neighbour state and remaining Dead Time.
  2. In the isolated lab, change only R2 to 5 / 20. Compare both operational interfaces, diagnose the mismatch and restore 10 / 40. Do not reset the process to hide the mismatch.
  3. Coordinate 5 / 20 on both ends and verify Full. Explain why the smaller countdown does not measure total application convergence.
  4. Restore both baseline overrides as described above and verify the effective values and traffic. For a silent-loss experiment, define how the local port stays up; a shutdown exercise tests a different failure signal.

Check your reasoning

Predict · scenario 1

R1 uses 10/40 and R2 uses 5/20. The link pings successfully. What should you fix first?

Predict · scenario 2

The last accepted Hello was at t=0. A silent fault occurs at t=7. Dead is 40 seconds and no faster signal occurs. When is expiry expected?

Predict · scenario 3

A neighbour row shows Dead Time 00:00:16 after configuring 5/20. Is 16 the configured Dead interval?

References and software scope

Protocol checks and timers: RFC 2328, sections 9.5, 10.5 and C.3. Cisco references: reading show ip ospf interface and interface timer commands. Outputs are authored examples, not device captures; inspect actual output for the selected image.