The premiere source of truth powering network automation. Open and extensible, trusted by thousands.

NetBox is now available as a managed cloud solution! Stop worrying about your tooling and get back to building networks.

Hello timer behaviors

By stretch | Wednesday, May 14, 2008 at 12:13 a.m. UTC

Interior gateway routing protocols (IGPs) have varying intervals at which they send hello packets to neighbors. Ideally, neighbors should have matching hello and hold intervals, but some protocols will allow neighbors with mismatched timers to form an adjacency. Assume a lab of two routers, Router1 and Router2, directly connected via their Fa0/0 interfaces and addressed in the subnet.


By default, EIGRP sends hellos every 5 seconds on LAN interfaces and every 60 seconds on WAN interfaces; the hold timer is three times the hello timer (15 or 180 seconds, respectively). We can adjust the hello interval per interface with:

Router(config-if)# ip hello-interval eigrp 

After configuring Router1 with a hello interval of 10 seconds, and leaving Router2 at its default setting of 5 seconds, we can issue the show ip eigrp neighbors command to observe that an adjacency is still successfully formed:

Router2# show ip eigrp neighbors
IP-EIGRP neighbors for process 100
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                        (sec)         (ms)       Cnt Num

0             Fa0/0              8 00:05:54   40   240  0  2

However, remember that Router2's dead interval is 15 seconds (three times its hello interval). If we were to raise Router1's hello interval above Router2's dead interval, Router2 would not receive hello packets soon enough and would declare the adjacency down after fifteen seconds.

Read on to see how OSPF and IS-IS neighbors handle mismatched timers.


By default, OSPF uses a 10-second hello timer and 40-second hold timer on broadcast and point-to-point links, and a 30-second hello timer and 120-second hold timer for all other network types. An interface's hello timer can be adjusted:

Router(config-if)# ip ospf hello-interval 

If we set Router1 to use a hello timer of 15 seconds and leave Router2 at its default setting of 10 seconds, they will not form an adjacency. Note that this behavior is different from EIGRP. If we enable OSPF hello packet debugging with debug ip ospf hello, the router reports mismatched hello parameters (specifically the hello and dead intervals):

OSPF: Rcv hello from area 0 from FastEthernet0/0
OSPF: Mismatched hello parameters from
OSPF: Dead R 40 C 60, Hello R 10 C 15  Mask R C


By default, IS-IS uses a 10-second hello interval and 30-second dead interval, with the exception of a broadcast segment's designated router, which sends hellos at one-third the normal interval (every 3.3 seconds). We can adjust the hello interval on an interface with:

Router(config-if)# isis hello-interval  [level-1 | level-2]

To minimize confusion regarding the special-case DR timer mentioned, assume the link between the two peers has been configured as point-to-point (isis network point-to-point is applied to both interfaces). After configuring Router1 with a hello timer of 15 seconds and leaving Router2 at its default of 10 seconds, we see that the adjacency successfully forms similar to EIGRP.

Router2# show isis neighbors detail

System Id      Type Interface IP Address      State Holdtime Circuit Id
Router1        L1L2 Fa0/0     UP    37       00
  Area Address(es): 49.0001
  SNPA: c200.6876.0000      
  State Changed: 00:02:58
  Format: Phase V

Router1 has a hold timer of 45 seconds (three times 15 seconds) and Router2 has a hold timer of 30 seconds (three times 10 seconds). Thus, if Router2 misses two hellos from Router1 (spanning a total of 30 seconds), it will declare the adjacency dead before Router1.


Our experiments have shown that neighbors with mismatched hello timers will happily form adjacencies under EIGRP and IS-IS, but not OSPF. While one could argue this is a drawback of OSPF, I view it as a sanity-checking feature. Adjacencies between peers with timers configured too far apart will drop at what seem to be random intervals, which can make troubleshooting a nightmare. For this reason, peers should always be configured with matching timers.

Posted in Routing


Kevin Dorrell
May 21, 2008 at 11:55 a.m. UTC

There is one point about the EIGRP case that is not widely known: that when you configure the hello interval is not linked to the neighbors dead interval, but to your own. Why is that? It is because the hello packet actually carries the dead interval with it.

In other words, router A says "Hello router B, I am going to send you hellos every 3 seconds, so hold me for 15." For this case, router A has a configured Hello interval of 3 seconds and a dead interval of 15.

Try it. Configure router A with hello=3, dead=15, and router B with hello=60, dead=180. The adjacency should still stay up, despite what it looks like.

Kevin Dorrell Luxembourg

May 21, 2008 at 1:09 p.m. UTC

That's a good observation; the hold timer is indeed communicated explicitly in hello packets. Unfortunately it is not updated automatically when the hello timer is increased.

For the curious, the EIGRP hold timer is adjusted in interface configuration mode with "ip hold-time eigrp ".

June 2, 2008 at 6:08 p.m. UTC

Nice Job Man!

June 11, 2008 at 6:50 p.m. UTC

Really helpful to me. I was struggling to find default hello intervals for broadcast and non broadcast domains. it really helped me.


Hari Krishna
May 28, 2009 at 7:39 a.m. UTC

it really helped me.


June 12, 2009 at 6:10 a.m. UTC

Your notes is very high

August 27, 2009 at 11:12 a.m. UTC

this is very helpful for me. because i confuse on ospf and eigrp timer

September 18, 2010 at 8:51 p.m. UTC

I don't understand why Cisco is so inconsistent about the IOS commands:

We have 3 protocols with 3 different commands for changing the hello timer:

ip hello-interval eigrp

ip ospf hello-interval

isis hello-interval

All of them are interface commands, so why not use the same syntax?

Mikkel Shinn
March 15, 2011 at 8:33 p.m. UTC


From a conceptual perspective, the EIGRP command is the (very) odd one out. The OSPF command follows the protocol (IP) > feature (OSPF) > setting (hello-interval) order that's common for IOS configuration. The IS-IS command omits the protocol part because IS-IS normally runs over CLNP on layer 2, rather than IP on layer 3.

August 23, 2011 at 9:34 p.m. UTC

good job jeremy! :)

Comments have closed for this article due to its age.