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 192.168.0.0/30 subnet.
EIGRP
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 192.168.0.2 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.
OSPF
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 192.168.0.2 area 0 from FastEthernet0/0 192.168.0.2 OSPF: Mismatched hello parameters from 192.168.0.2 OSPF: Dead R 40 C 60, Hello R 10 C 15 Mask R 255.255.255.252 C 255.255.255.252
IS-IS
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 192.168.0.1 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.
Summary
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
Comments
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.
thanks
May 28, 2009 at 7:39 a.m. UTC
it really helped me.
thanks.
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?
March 15, 2011 at 8:33 p.m. UTC
Ecologu,
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! :)