OSPF Timers: Hello and Dead Intervals Explained

OSPF hello and dead intervals are the protocol's failure detection mechanism. The hello interval sets how often a router sends hello packets on an interface; the dead interval sets how long it will wait without hearing a hello before declaring the neighbor down, tearing down the adjacency, and rerouting around it. Together they define how quickly your network notices a silent failure - one where the interface stays up but the neighbor stops talking. This article is part of our full OSPF guide, and all device output comes from a live Cisco Modeling Labs topology on IOS XE 17.18.

These two timers also gate adjacency formation. Both values ride inside every hello packet, and a router rejects hellos whose timers do not match its own interface configuration. That makes timer mismatch one of the classic reasons OSPF neighbors refuse to form, and one of the easiest to prove with a debug.

Defaults per network type

• Broadcast and point-to-point: hello 10 seconds, dead 40 seconds.
• NBMA and point-to-multipoint: hello 30 seconds, dead 120 seconds.

The dead interval defaults to four times the hello, and IOS maintains that relationship automatically: change the hello interval and the dead interval silently becomes 4x the new value unless you set it explicitly. The per-type defaults are also why mismatched network types often fail to form neighbors - a broadcast interface at 10/40 and a point-to-multipoint interface at 30/120 reject each other's hellos before anything else gets a chance to go wrong.

Checking the timers

In the lab: R1 and R2 share a LAN in area 0 (10.0.12.0/24), and R2-R3 is a /30 in area 1. show ip ospf interface shows the operational timers on any interface:

R2# show ip ospf interface Ethernet0/0
Ethernet0/0 is up, line protocol is up
  Internet Address 10.0.12.2/24, Interface ID 2, Area 0
  Attached via Network Statement
  Process ID 1, Router ID 2.2.2.2, Network Type BROADCAST, Cost: 10
  Transmit Delay is 1 sec, State DR, Priority 1
  Designated Router (ID) 2.2.2.2, Interface address 10.0.12.2
  Backup Designated router (ID) 1.1.1.1, Interface address 10.0.12.1
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    Hello due in 00:00:01
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 1.1.1.1  (Backup Designated Router)

The line that matters is Timer intervals configured, Hello 10, Dead 40, with Hello due in counting down to the next transmission. The dead timer is also visible from the other direction - the neighbor table's Dead Time column shows how long each neighbor has left before being declared down, resetting to the full dead interval every time a hello arrives:

R2# show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
1.1.1.1           1   FULL/BDR        00:00:34    10.0.12.1       Ethernet0/0
3.3.3.3           1   FULL/BDR        00:00:34    10.0.23.1       Ethernet0/1

A healthy neighbor on default timers hovers between about 31 and 40 seconds in that column. A value that keeps sliding toward zero means hellos are being lost, and you are watching an adjacency die in slow motion.

What happens on a mismatch

To demonstrate, we set ip ospf hello-interval 5 on R3's side of the /30 link while R2 stayed at the default 10. With debug ip ospf hello running on R2:

*Jul  4 23:31:44.787: OSPF-1 HELLO Et0/1: Mismatched hello parameters from 10.0.23.1
*Jul  4 23:31:49.645: OSPF-1 HELLO Et0/1: Mismatched hello parameters from 10.0.23.1
*Jul  4 23:31:54.135: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on Ethernet0/1 from FULL to DOWN, Neighbor Down: Dead timer expired
*Jul  4 23:31:54.236: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on OSPF_VL0 from FULL to DOWN, Neighbor Down: Interface down or detached

The sequence is worth reading carefully. R2 keeps receiving R3's hellos but rejects every one of them as mismatched, so from R2's perspective R3 has gone silent. The existing adjacency survives exactly as long as the dead interval, then drops from FULL to DOWN with Dead timer expired. Note the collateral damage in the last line: this lab had a virtual link running across that physical path, and it collapsed a tenth of a second later - a reminder that one bad timer change can take down more than the link you touched. (For what the FULL state means and how routers climb back to it, see OSPF neighbor states explained.)

One caution when reading that debug: Mismatched hello parameters covers more than timers. The hello also carries the subnet mask, so a mask mismatch on a broadcast network produces the identical line. If the timers check out on both sides, compare the subnet masks next.

Dead timer expired is also the log line you get when an adjacency drops on a cycle rather than dying once, and there the timers are usually innocent. If yours keeps coming back and dropping again, work out why the OSPF adjacency is flapping, which separates genuinely lost hellos from the duplicate Router ID that produces the same syslog.

Tuning timers safely

Faster failure detection means lower timers, and the configuration is one line each, per interface:

interface Ethernet0/1
 ip ospf hello-interval 5
 ip ospf dead-interval 20

Apply it to both ends of the link in the same maintenance window: the moment one side changes, its hellos are rejected by the other, so the adjacency will drop when the dead timer expires and stay down until the second side matches. In the lab we configured hello 5, dead 20 on both R2 and R3, and the interface confirms the new operational values:

R2# show ip ospf interface Ethernet0/1 | include Timer|Hello
  Timer intervals configured, Hello 5, Dead 20, Wait 20, Retransmit 5
    Hello due in 00:00:03

The neighbor returned to FULL, now with a 20 second worst-case detection time instead of 40. Sensible guardrails when tuning:

• Keep the dead interval at 3x to 4x the hello interval so a couple of lost packets do not flap the adjacency.
• Tune per link, starting with the links that matter (core interconnects, firewall handoffs), not globally.
• Going below hello 1 / dead 3 or 4 buys little and burns CPU on hello processing. If you need sub-second failover, the modern answer is BFD (bfd interval 300 min_rx 300 multiplier 3 plus ip ospf bfd), which offloads detection to a lightweight hardware-friendly session and simply tells OSPF when the neighbor dies - leaving the OSPF timers at their defaults.

Key Takeaways

• Hello interval = how often keepalives are sent; dead interval = how long silence is tolerated before the adjacency is torn down. Defaults are 10/40 on broadcast and point-to-point, 30/120 on NBMA and point-to-multipoint.
• Both values are carried in every hello and must match on both ends of a link, or the adjacency never forms (and an existing one dies when the dead timer expires).
• Verify with show ip ospf interface (Timer intervals line) and watch the Dead Time column in show ip ospf neighbor.
• Mismatched hello parameters in the debug means timers or mask - check both.
• Tune both sides in one window, keep dead at 3-4x hello, and reach for BFD instead of extreme timers when you need sub-second detection.