OSPF Hello and Dead Intervals

OSPF Hello and Dead Intervals

An OSPF router sends Hello packets out of every interface where OSPF is enabled, at a fixed interval. That interval is the HelloInterval. When Hellos from a neighbour stop arriving for a certain length of time, the router declares the neighbour down. That length of time is the RouterDeadInterval. The two work as a pair, and both are carried inside the Hello packet.

Shortening both makes failures visible sooner, but the values have to match between neighbours: change one side only and the adjacency never comes up. This article confirms that rule in RFC 2328 and then measures, on IOS XR, what happens when the values do not match and how much faster a failure is detected when they are shortened. The other per-interface timers — the Wait timer, the retransmit interval and the transmit delay — are covered as well.

What a Hello packet carries, and what has to match

A Hello packet carries the Network Mask, HelloInterval and RouterDeadInterval configured on the sending interface. RFC 2328 Section 10.5 defines how a received Hello is processed:

Next, the values of the Network Mask, HelloInterval, and RouterDeadInterval fields in the received Hello packet must be checked against the values configured for the receiving interface. Any mismatch causes processing to stop and the packet to be dropped.

A single mismatch stops the processing and the packet is dropped. A dropped Hello never reaches the neighbour state machine, so the neighbour is never even recognised. A misconfigured timer therefore does not produce an adjacency that goes down; it produces an adjacency that never forms.

There is one exception: on point-to-point networks and on virtual links the Network Mask is ignored (Section 10.5), because a mask match carries no meaning there.

The E-bit in the Options field is checked as well. If it disagrees with the area’s ExternalRoutingCapability, the packet is dropped in the same way. That is why a router in a stub area and a router in a regular area cannot form an adjacency on the same segment. The remaining Options bits are ignored (Section 10.5). The Options field is covered in The OSPF Options Field.

The retransmit interval (RxmtInterval) and the transmit delay (InfTransDelay), on the other hand, are not carried in Hello packets and are not checked, so they may differ between neighbours.

How a change takes effect also deserves attention. The RouterDeadInterval drives a per-neighbour timer that is re-armed with the configured value every time a Hello arrives. Changing the configuration does not touch a timer that is already running: it waits out the value it was armed with, and the new value applies from the next Hello that re-arms it.

The values in the RFC are not defaults

HelloInterval 10 seconds and RouterDeadInterval 40 seconds are familiar numbers, but RFC 2328 does not define them as defaults. What Appendix C.3 gives are sample values.

Defaults that vary with the network type are also an implementation matter: on IOS XR, non-broadcast and point-to-multipoint use Hello 30 / Dead 120. Network types themselves are covered in OSPF Network Types.

IOS XR also offers dead-interval minimal hello-multiplier <count>, which spaces Hellos more finely than one second: it fixes the RouterDeadInterval at one second and sends that many Hellos within it.

The Wait timer

On a broadcast segment a router that has just enabled OSPF does not elect a Designated Router straight away. For the length of the Wait timer it listens to the Hellos of the other routers, learns who is claiming to be DR, and only then runs the election. The interface state during that period is WAITING.

Wait Timer … A single shot timer that causes the interface to exit the Waiting state, and as a consequence select a Designated Router on the network. The length of the timer is RouterDeadInterval seconds. (RFC 2328 Section 9.3)

The Wait timer is as long as the RouterDeadInterval and has no setting of its own. Set Dead to 40 seconds and Wait is 40 seconds; set it to 3 and Wait is 3.

It does not always run to expiry. Section 10.5 states that a Hello from a router already claiming to be the Designated Router schedules the BackupSeen event on the receiving interface. Waiting is left on that event, so a router joining a segment that already has a DR moves on without waiting for the Wait timer to expire. A full-length wait happens only when the routers start at the same time.

Point-to-point interfaces elect no DR and therefore never use the Wait timer. The election itself is covered in DR and BDR.

RxmtInterval and InfTransDelay

RxmtInterval is how long a router waits before sending an LSA again when no acknowledgement (LSAck) comes back. The same value is used for retransmitting Database Description and Link State Request packets. A router keeps retransmitting at this interval while the packets go unanswered, so the value should be well above the round-trip delay, yet large enough to avoid needless retransmissions.

InfTransDelay is the estimated number of seconds it takes to send a Link State Update packet out of the interface. The value is not a delay the router waits out: it is added to the LS age of the LSAs it sends.

The LSA’s LS age must be incremented by InfTransDelay (which must be > 0) when it is copied into the outgoing Link State Update packet (until the LS age field reaches the maximum value of MaxAge). (RFC 2328 Section 13.3 (5))

An LSA ages in every router’s database and is removed when it reaches MaxAge (3600 seconds). Adding the estimated propagation time at each hop keeps the LS age on the receiving side from lagging behind the real elapsed time. Retransmissions are incremented the same way. How LSAs age is covered in LSAs and the LSA Header.

Verification on real hardware

Test environment

Three Cisco IOS XR (XRd 26.1.1) routers in a line, every link in area 0. R1 - R2 is left as broadcast, which is the XR default, while R2 - R3 uses network point-to-point. The broadcast side shows the Wait timer and the DR election, and the difference from the point-to-point side is visible in the same lab.

Timers are changed on the R1 - R2 segment only. Failures are produced by shutting R2’s Gi0/0/0/0. The XRd nodes in CML do not pass a one-sided shutdown to the other end, so R1 never sees a link-down event and can only notice through the expiry of its dead interval — which is exactly what this article measures.

Detection time is measured as the difference between the time R2 committed the shutdown (%MGBL-CONFIG-6-DB_COMMIT) and the time dead timer expired appeared in R1’s syslog. Packets are captured on R1 - R2, one capture per step.

Test steps

The sections below are grouped by what they show rather than by step order.

Defaults and what a Hello carries (step 0)

R1’s broadcast interface:

RP/0/RP0/CPU0:R1#show ospf interface GigabitEthernet0/0/0/0
Sun Sep 20 10:10:33.102 UTC

GigabitEthernet0/0/0/0 is up, line protocol is up 
  Internet Address 10.0.12.1/24, Area 0, SID 0, Strict-SPF SID 0
  Label stack Primary label 0 Backup label 0 SRTE label 0
  Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 10
  Transmit Delay is 1 sec, State BDR, Priority 1, MTU 1500, MaxPktSz 1500
  Forward reference No, Unnumbered no,  Bandwidth 1000000 
  RIB LC sync Yes
  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

Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 holds four of the timers and Transmit Delay is 1 sec the fifth. Wait is the same 40 seconds as Dead, exactly as RFC 2328 Section 9.3 requires.

The capture of the same segment shows the interval and the contents of R1’s Hellos.

2.276440000	10	40
12.176787000	10	40
21.764556000	10	40
31.156717000	10	40
40.301282000	10	40
49.969146000	10	40
59.584214000	10	40
69.460619000	10	40
78.661895000	10	40
88.573858000	10	40
97.972222000	10	40
107.009482000	10	40
116.017467000	10	40
125.619933000	10	40
134.874212000	10	40
144.475683000	10	40
154.106094000	10	40
163.821549000	10	40
172.895834000	10	40
182.265681000	10	40
191.764102000	10	40
201.062415000	10	40
210.804844000	10	40
220.282603000	10	40
229.725371000	10	40
239.311555000	10	40
249.170974000	10	40
258.900427000	10	40

The columns are seconds since the start of the capture, HelloInterval and RouterDeadInterval. A Hello goes out about every 10 seconds, carrying the configured 10 and 40, and the receiver checks those against its own configuration.

Mismatched values prevent the adjacency (steps 1 to 3)

hello-interval 30 is applied to R1’s Gi0/0/0/0 only.

RP/0/RP0/CPU0:Sep 20 10:14:06.480 UTC: config[69019]: %MGBL-CONFIG-6-DB_COMMIT : Configuration committed by user 'cisco'. Use 'show configuration commit changes 1000000001' to view the changes. 
RP/0/RP0/CPU0:Sep 20 10:14:38.026 UTC: ospf[1035]: %ROUTING-OSPF-5-ADJCHG : Process 1, Nbr 2.2.2.2 on GigabitEthernet0/0/0/0 in area 0 from FULL to DOWN, Neighbor Down: dead timer expired, vrf default vrfid 0x60000000 

31.5 seconds after the commit the adjacency goes down with dead timer expired. R2 loses it in the same way at 10:14:41.086. Each side is dropping the other’s Hellos, so each waits out its own dead interval.

Neither router has stopped sending. The capture contains:

10.0.12.2	10	40
10.0.12.2	10	40
10.0.12.2	10	40
10.0.12.1	30	120
10.0.12.2	10	40
10.0.12.2	10	40
10.0.12.2	10	40
10.0.12.1	30	120
10.0.12.2	10	40
10.0.12.2	10	40

R1 keeps sending 30 / 120 and R2 keeps sending 10 / 40 (17 and 52 packets respectively over the whole step). The packets arrive; the receiver throws them away because the values differ.

R1’s neighbour table is empty.

RP/0/RP0/CPU0:R1#show ospf neighbor
Sun Sep 20 10:18:51.283 UTC

Not one neighbour is listed. The adjacency has not gone down — the neighbour is not being recognised at all.

R1’s timers are worth a look too.

  Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5

Only hello-interval 30 was configured, yet Dead and Wait became 120 seconds. IOS XR keeps Dead at four times Hello automatically — the same factor RFC 2328 suggests with “some multiple of the HelloInterval (say 4)”.

Step 2 applies the same hello-interval 30 to R2, the values match again and the adjacency returns. Step 3 then restores Hello on both sides and sets dead-interval 20 on R1 alone.

  Timer intervals configured, Hello 10, Dead 20, Wait 20, Retransmit 5
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

HelloInterval is 10 on both, but RouterDeadInterval is 20 against 40. The adjacency goes down here too: HelloInterval is not the only field that is checked.

Note that in steps 1 and 3 the time from the commit to the adjacency going down does not match the configured value.

Step 3 took 118 seconds because a timer that is already running keeps the value it was armed with — 120 seconds, from step 2. The new value applies from the next Hello that is accepted, and here the Hellos are being dropped, so it never takes over. Do not predict the time to failure from the value you just configured.

Time to detection (steps 4, 6 and 11)

With the values matching on both sides, the next question is how the length of the dead interval affects how quickly a failure is noticed. R2 shuts Gi0/0/0/0 and the syslog timestamps give the time until R1 notices.

The syslog line from step 4:

RP/0/RP0/CPU0:Sep 20 10:40:23.177 UTC: ospf[1035]: %ROUTING-OSPF-5-ADJCHG : Process 1, Nbr 2.2.2.2 on GigabitEthernet0/0/0/0 in area 0 from FULL to DOWN, Neighbor Down: dead timer expired, vrf default vrfid 0x60000000 

Every figure is shorter than the dead interval itself. The dead timer has been running since the last Hello arrived, so time has already passed when the interface goes away. With the defaults the result lands somewhere between 30 and 40 seconds; with Dead 3, between 2 and 3.

Until R1 notices, the adjacency counts as up and the route towards R3 stays in place — packets keep being sent to a destination that cannot be reached. The ping taken while the link was still down loses every packet:

Success rate is 0 percent (0/50)

Shortening the dead interval is exactly this: shortening the window in which traffic is dropped without OSPF noticing.

Fast hello (step 10)

dead-interval minimal hello-multiplier 3 was applied to both ends.

   dead-interval minimal hello-multiplier 3

  Timer intervals configured, Hello 333ms, Dead 1, Wait 1, Retransmit 5

The display becomes Hello 333ms, Dead 1, Wait 1, with the HelloInterval in milliseconds. The RouterDeadInterval carried in the Hello is 1 second, so the other end needs the same configuration.

Step 11 measured 0.50 seconds. It is under one second for the same reason as before: part of the interval had already elapsed since the last Hello.

The transmit delay is added to the LS age (step 7)

transmit-delay 10 was applied to R1’s Gi0/0/0/0, together with cost 11 in the same commit so that R1 would rebuild its Router-LSA. The Link State Updates R1 sent:

31	1.1.1.1	19
33	1.1.1.1	3600
35	1.1.1.1	10

The third row is the rebuilt Router-LSA and its LS age is 10. A freshly built LSA starts at 0; the InfTransDelay of 10 is added as it goes out.

With the transmit delay back at its default in step 8, the same operation sends an LSA with an LS age of 1.

2	1.1.1.1	1

The default is one second, so one is what gets added. The transmit delay is not a delay the router waits out but a number of seconds added to the age of the LSA.

The retransmit interval (steps 8 and 9)

Observing a retransmission requires acknowledgements to stop coming back. R1 was given timers lsa min-arrival 5000, which discards a newer instance of the same LSA that arrives within 5 seconds, without acknowledging it (this lower bound is MinLSArrival in RFC 2328; see OSPF Convergence Timers (SPF / LSA Throttling)). R2’s cost was then changed six times in quick succession so that its Router-LSA was rebuilt again and again.

In step 8 the retransmit interval is still the default of 5 seconds. The LSUs sent by R2, in time order:

102.633657000	224.0.0.5	0x8000000f
106.534294000	224.0.0.5	0x80000010
110.234042000	224.0.0.5	0x80000011
113.932585000	224.0.0.5	0x80000012
118.033225000	224.0.0.5	0x80000013
122.094134000	224.0.0.5	0x80000014
126.879320000	10.0.12.1	0x80000014
250.791779000	224.0.0.5	0x80000005

The ones sent to 224.0.0.5 are ordinary flooding; the one sent to 10.0.12.1 is a retransmission aimed at R1. Sequence number 0x80000014 went out at 122.09 seconds, was never acknowledged, and was sent again to R1 at 126.88 seconds — 4.79 seconds later.

Step 9 puts retransmit-interval 3 on R2’s Gi0/0/0/0 only and repeats the same operation.

100.301614000	224.0.0.5	0x80000015
104.002211000	224.0.0.5	0x80000016
106.801556000	10.0.12.1	0x80000016
108.301127000	224.0.0.5	0x80000017
111.300962000	10.0.12.1	0x80000017
111.701380000	224.0.0.5	0x80000018
114.583642000	10.0.12.1	0x80000018
115.201295000	224.0.0.5	0x80000019
118.202095000	10.0.12.1	0x80000019
119.171071000	224.0.0.5	0x8000001a
122.022539000	10.0.12.1	0x8000001a

Pairing the identical sequence numbers gives 2.80, 3.00, 2.88, 3.00 and 2.85 seconds — about three seconds.

Nothing was configured on R1. The retransmit interval is not carried in Hellos and is not checked, so changing one side is enough. That is the practical difference from HelloInterval and RouterDeadInterval.

The Wait timer (steps 12 and 13)

The OSPF process was restarted on R1 alone, while R2 kept running as the DR.

RP/0/RP0/CPU0:Sep 20 11:47:47.225 UTC: sysmgr_control[69574]: %OS-SYSMGR-4-PROC_RESTART_NAME : User cisco (vty0) requested a restart of process ospf at 0/RP0/CPU0 
RP/0/RP0/CPU0:Sep 20 11:47:59.963 UTC: ospf[1035]: %ROUTING-OSPF-5-ADJCHG : Process 1, Nbr 2.2.2.2 on GigabitEthernet0/0/0/0 in area 0 from LOADING to FULL, Loading Done, vrf default vrfid 0x60000000 

The adjacency reached FULL 12.7 seconds after the restart. The Wait timer is 40 seconds, so it did not run to expiry: the Hello from R2, already claiming to be the DR, raised BackupSeen and the interface left Waiting.

Both processes were then restarted at the same time, so that neither router was claiming to be the DR. Taken right after the restart:

RP/0/RP0/CPU0:R2#show ospf interface brief

Sun Sep 20 11:54:10.822 UTC

* Indicates MADJ interface, (P) Indicates fast detect hold down state

Interfaces for OSPF 1

Interface          PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Lo0                1     0               2.2.2.2/32         1     LOOP  0/0
Gi0/0/0/0          1     0               10.0.12.2/24       10    WAIT  0/1
Gi0/0/0/1          1     0               10.0.23.2/24       10    P2P   1/1

The broadcast interface Gi0/0/0/0 is in WAIT while the point-to-point Gi0/0/0/1 is in P2P. Only the broadcast side uses the Wait timer; the point-to-point side elects no DR and does not wait.

R1 in more detail:

RP/0/RP0/CPU0:R1#show ospf interface GigabitEthernet0/0/0/0

Sun Sep 20 11:54:05.591 UTC

GigabitEthernet0/0/0/0 is up, line protocol is up 
  Internet Address 10.0.12.1/24, Area 0, SID 0, Strict-SPF SID 0
  Label stack Primary label 0 Backup label 0 SRTE label 0
  Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 10
  Transmit Delay is 1 sec, State WAITING, Priority 1, MTU 1500, MaxPktSz 1500
  Forward reference No, Unnumbered no,  Bandwidth 1000000 
  RIB LC sync Yes
  No designated router on this network
  No backup designated router on this network
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    Hello due in 00:00:06:723
    Wait time before Designated router selection 00:00:36

The state is WAITING with no DR and no BDR yet. The remaining time appears as Wait time before Designated router selection — 36 seconds at this moment.

RP/0/RP0/CPU0:Sep 20 11:54:45.754 UTC: ospf[1035]: %ROUTING-OSPF-5-ADJCHG : Process 1, Nbr 2.2.2.2 on GigabitEthernet0/0/0/0 in area 0 from LOADING to FULL, Loading Done, vrf default vrfid 0x60000000 

With both routers restarting together, FULL took 47.6 seconds: the full 40-second Wait timer, the election, and then the database exchange. The same operation takes 12.7 seconds or 47.6 seconds depending on whether a DR is already present.

Design notes

• A shorter dead interval detects failures faster, but an adjacency also drops when Hellos merely fail to arrive. Fast hello is more sensitive to packet loss and to momentary control-plane delays. If the goal is only to detect link failures quickly, BFD has fewer side effects than tightening OSPF timers
• Changing a timer does not re-arm the timer that is already running. Step 3 shows a case where the time to failure cannot be predicted from the value just configured
• The Wait timer cannot be configured. To shorten the wait before a DR election, the only value available is the RouterDeadInterval, which is the same value that governs failure detection

Verification configs and show output

Every step collects the following files from all three routers, kept separate per router. The verification config is the ..._run.txt file (the final state is the one from the last step).

The running-config of the final state (step 13) is back to the defaults, with no Hello, Dead, retransmit interval or transmit delay configured.

Step 0: Initial state (defaults)

Step 1: hello-interval 30 on R1 only

Step 2: hello-interval 30 on R2 as well

Step 3: Hello back to default on both, dead-interval 20 on R1

Step 4: R1 back to default, R2 shuts Gi0/0/0/0

Step 5: R2 back up, hello 1 / dead 3 on both

Step 6: R2 shuts Gi0/0/0/0 again

Step 7: Timers back to default, transmit-delay 10 and cost 11 on R1

Step 8: timers lsa min-arrival 5000 on R1 (retransmit interval left at default)

Step 9: retransmit-interval 3 on R2

Step 10: dead-interval minimal hello-multiplier 3 on both

Step 11: R2 shuts Gi0/0/0/0 (fast hello)

Step 12: Back to defaults, OSPF process restarted on R1 only

Step 13: OSPF process restarted on R1 and R2 at the same time (final state)

Packets were captured on R1 - R2, one capture per step.

References

Related articles

• What Is OSPF
• OSPF Router ID
• OSPF Packet Types and Header Format
• OSPF Authentication
• OSPF Neighbor States
• OSPF Options Field
• OSPF DR and BDR
• OSPF Network Types
• OSPF Cost (Metric)
• OSPF External Routes (Redistributing Static Routes)
• OSPF RFC1583 Compatibility (External Route Selection Rules)
• OSPF Multiple Areas and the ABR
• OSPF Virtual Links
• OSPF Stub and Totally Stubby Areas
• OSPF NSSA and Totally NSSA
• OSPF Default Route
• OSPF Route Summarization
• OSPF LSAs and the LSA Header
• OSPF Hello and Dead Intervals
• OSPF Convergence Timers (SPF / LSA Throttling)
• OSPF LSA Refresh and Pacing
• OSPF router-LSA (type 1)
• OSPF network-LSA (type 2)
• OSPF summary-LSA (type 3)
• OSPF ASBR summary-LSA (type 4)
• OSPF AS external-LSA (type 5)
• OSPF NSSA External-LSA (Type 7)