skip to content

In OSPF, what do Hello packets do, and how do the Hello and Dead intervals decide that a neighbour has gone?

level: juniorimportance: should knowfreq 42%

answer

  1. keepalive plus discovery
  2. your own ID in their list
  3. inactivity timer reset per Hello
  4. dead interval a multiple of Hello

basics

~20 s

OSPF Hellos, sent every HelloInterval, discover neighbours, prove two-way communication and carry DR election data. Each Hello received restarts that neighbour's RouterDeadInterval timer; if the timer expires with no Hello heard, the neighbour is declared Down.

solid answer

~50 s

Every OSPF interface sends a Hello every `HelloInterval` seconds; on broadcast and point-to-point links it goes to the multicast group AllSPFRouters, `224.0.0.5`. The Hello carries the sender's Router ID, area, both timers, its Router Priority, its view of the DR and BDR, and the Router IDs of every neighbour it has heard within the last `RouterDeadInterval`. Seeing your own Router ID in that list proves the link works both ways. Each Hello received restarts that neighbour's inactivity timer, which runs for `RouterDeadInterval`; if it fires, the neighbour drops straight to Down and any adjacency with it is torn down. RFC 2328 gives 10 s as a *sample* LAN Hello and says the dead interval should be some multiple of it, "say 4" — so the familiar 10/40 pair is an example, not a mandate — but both values must match on every router sharing the link.

go deeper

for a junior

Know that Hellos discover neighbours and act as a keepalive, and that silence for the whole dead interval, not one lost Hello, brings a neighbour down.

for a middle

Explain the inactivity timer that each Hello restarts, the own-ID-in-the-list check that separates Init from 2-Way, and why both timers must match on the link.

for a senior

Reason about the detection window a timer pair gives, why the RFC's 10 and 40 seconds are samples, and why fast detection is better delegated than tuned down.

for a principal

Weigh detection speed against false failures and protocol load across many links, and decide where an external liveness protocol earns its operational cost.

## What a Hello is for OSPF (Open Shortest Path First, RFC 2328 for IPv4) is a link-state routing protocol: routers build a shared map of the network and compute paths over it. Before any of that, a router has to know **who is on the other end of each link**. That is the job of the **Hello protocol**. Hello packets are OSPF packet type 1 and do three things: - **Discovery** — on links that can multicast, a router announces itself so neighbours appear without configuration. - **Bidirectional check** — a Hello lists every neighbour the sender has heard recently; a router that finds its own Router ID in a neighbour's list knows the link works in both directions. - **Keepalive** — Hellos keep arriving for as long as the neighbour is alive, so their absence is the failure signal. On broadcast and NBMA networks the Hello also carries the information used to elect the Designated Router (DR) and Backup Designated Router (BDR). ## What a Hello carries | Field | Meaning | |---|---| | Router ID, Area ID | in the OSPF header: who sent it and which area the link belongs to | | `Network Mask` | the sender's mask for the link (ignored on point-to-point links and virtual links) | | `HelloInterval` | seconds between this router's Hellos | | `RouterDeadInterval` | seconds of silence before a neighbour is declared down | | `Options` | capability bits, including the E-bit that marks a stub area | | `Rtr Pri` | 8-bit Router Priority used in the DR election | | `Designated Router`, `Backup Designated Router` | the sender's current view, by interface IP address | | `Neighbor` list | Router IDs heard within the last `RouterDeadInterval` | Hellos are sent to `224.0.0.5` (AllSPFRouters) on broadcast networks and physical point-to-point links, and as unicasts to configured neighbours on NBMA networks. OSPF itself rides directly on IP as protocol number 89. ## The two timers - **`HelloInterval`** — how often the router speaks. A smaller value detects failures sooner but costs more protocol traffic. RFC 2328 Appendix C offers **sample** values: 10 s for a local area network, 30 s for an X.25 public data network. - **`RouterDeadInterval`** — how long the router tolerates silence. The RFC says it "should be some multiple of the HelloInterval (say 4)". A 40-second dead interval with a 10-second Hello is that example, which many implementations adopt as their default; it is not a number the protocol mandates. Both values are written into every Hello, and a receiver **drops** any Hello whose two values differ from its own interface's settings. They are properties of the link, not of one router. ## What happens when the dead interval expires Each neighbour has an **inactivity timer** of `RouterDeadInterval` seconds: 1. A Hello arrives from the neighbour and the timer restarts from zero. 2. Hellos keep arriving every `HelloInterval`, so the timer never reaches its limit. 3. The neighbour fails silently — a crashed process, a one-way fibre, a filter. 4. No Hello restarts the timer; when it fires, the neighbour state machine receives the `InactivityTimer` event and the neighbour goes straight to **Down**, whatever state it was in. 5. Any adjacency with that neighbour is torn down, and the router reports the change to the rest of the area in its own link-state advertisements (how that change spreads is the link-state flooding procedure). Because the timer restarts at the **last Hello received**, detection is not a fixed delay. With a 10 s Hello and a 40 s dead interval, a failure just after a Hello is detected about 40 s later; a failure just before the next Hello was due is detected about 30 s later. The window is roughly `RouterDeadInterval − HelloInterval` to `RouterDeadInterval`. ## Why the bidirectional check matters Hearing a neighbour does not mean it hears you. A link can fail in one direction only. OSPF therefore separates two states: **Init** (I hear you) and **2-Way** (I see myself in your Hello, so you hear me too). If a neighbour's Hello stops listing this router, the event `1-WayReceived` pushes the neighbour back to Init. No adjacency is built on a one-way link. ## Common misconceptions - The 10/40 pair is a sample and a common default, not a protocol constant. - Missing one Hello does nothing; only expiry of the whole dead interval brings a neighbour down. - Hellos never stop after start-up: they are the ongoing keepalive. - Faster failure detection is usually done by a separate protocol such as Bidirectional Forwarding Detection (RFC 5880) rather than by shrinking OSPF's own timers, since tiny dead intervals risk dropping healthy neighbours under load.

  • Why does an OSPF Hello list the neighbours the sender has heard, rather than just announcing the sender?
    Because hearing a neighbour proves only one direction. A router that finds its own Router ID in a neighbour's Hello knows its own Hellos are arriving too, so it moves the neighbour from Init to 2-Way. If its ID later disappears from that list, the `1-WayReceived` event pushes the neighbour back to Init, and no adjacency is built over a one-way link.
  • Why not simply set a one-second dead interval to detect OSPF neighbour failures quickly?
    Very short dead intervals turn a brief control-plane stall or a few lost Hellos into a false neighbour failure, tearing down adjacencies and forcing recomputation across the area. Sub-second detection is usually handed to Bidirectional Forwarding Detection (RFC 5880), a lightweight protocol that tells OSPF when a forwarding path dies, while OSPF's own timers stay conservative.

saying these in an interview costs you the question

  • OSPF neighbours can use different Hello intervals; each simply adapts to the other's.
  • RFC 2328 mandates a 10-second Hello and a 40-second dead interval.
  • Missing a single Hello makes OSPF declare the neighbour down immediately.
  • Hellos are only exchanged at start-up to find neighbours, then they stop.
  • Hearing a neighbour's Hello proves the link works in both directions.