EIGRP neighborship questions

Answered Question
Mar 26th, 2008
User Badges:
  • Bronze, 100 points or more

I am reading CCNP BSCI from Stewart in prep for test.


It lists three criterion for neighborship to form: K values must match, AS# must match, and a "hello" must be recieved. It does not talk about the hello or hold time values. Mustn't those also match?



Correct Answer by mattcalderon about 9 years 1 month ago

It is possible for two routers to become EIGRP neighbors even though the hello and hold timers do not match. The hold time is included in the hello packets so each neighbor should stay alive even though the hello interval and hold timers do not match.


From this doc:


http://www.cisco.com/warp/public/103/eigrp-toc.html#topologytable



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Correct Answer
mattcalderon Wed, 03/26/2008 - 08:26
User Badges:
  • Silver, 250 points or more

It is possible for two routers to become EIGRP neighbors even though the hello and hold timers do not match. The hold time is included in the hello packets so each neighbor should stay alive even though the hello interval and hold timers do not match.


From this doc:


http://www.cisco.com/warp/public/103/eigrp-toc.html#topologytable



Jon Marshall Wed, 03/26/2008 - 08:37
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Hi


Just to add to Matt's post.


It is possible but if you have different hold times and hello intervals set on router interfaces that share a common subnet then your adjancencies will keep going up and down because one router does not send a hello before the other's timeout expires.


So although they will form an adjancency probably not a good idea in a lot of cases :-)


Jon

mattcalderon Wed, 03/26/2008 - 08:41
User Badges:
  • Silver, 250 points or more

Jon is exactly right on that point. You should know exactly what the implications are of changing such parameters. Rule of thumb on hold timers and hello intervals is the hold should be 3x that of the hello.

Kevin Dorrell Fri, 05/23/2008 - 06:36
User Badges:
  • Green, 3000 points or more

Jon,


AFAIK, there is a subtle and little-known aspect to this story.


When a router sands a Hello, one field of the Hello packet tells the neighbor how long to hold the adjacency. So, when I send a Hello, it does not matter how the neighbor's dead timer is configured, it is how my dead timer is configured that matters.


The result is that you can actually change the Hello timer and dead timer in a router config without even knowing what values the neighbor has configured, so long as the values you configure are consistent between themselves.


This, of course, is totally unlike OSPF, where the timers have to match exactly. Or RIP, where your hello timers must be tailored to the neighbors' dead timers.


Kevin Dorrell

Luxembourg


lamav Fri, 05/23/2008 - 07:17
User Badges:
  • Blue, 1500 points or more

Thats really interesting, Kevin. So, its as if router A tells router B how long to wait before declaring him dead (dead interval). And router B tells router A what his dead interval is, too, and his time may differ.


But, as long as each router holds his end of the bargain and sends a Hello before HIS own dead interval is reached, the adjacency should stay up. Yes?


Victor

Kevin Dorrell Fri, 05/23/2008 - 09:31
User Badges:
  • Green, 3000 points or more

Yes, that's right. I wish I had my console logs from when I tried this, but if I remember right I had something like router A with (Hello=3, dead=10), and router B with (Hello=20, dead=60). I'll have to check it out to make sure I didn't dream it tho' !


Doyle Fig 7-24 on page 290 shows the EIGRP parameters TLV, which includes the hold time.


Kevin Dorrell

Luxembourg

sundar.palaniappan Fri, 05/23/2008 - 09:57
User Badges:
  • Green, 3000 points or more

Kevin,


Congratulations on your CCIE. You deserve it!


Regards,

Sundar

Kevin Dorrell Fri, 05/23/2008 - 10:09
User Badges:
  • Green, 3000 points or more

I couldn't resist. I modified the lab I had loaded on the stack at the moment. Here it is:


First, set R1 with timers 3/10

</p><p>R1#show run int f0/0.12</p><p>Building configuration...</p><p></p><p>Current configuration : 197 bytes</p><p>!</p><p>interface FastEthernet0/0.12</p><p> encapsulation isl 12</p><p> ip address 172.16.12.1 255.255.255.0</p><p> no ip redirects</p><p> ip hello-interval eigrp 200 3</p><p> ip hold-time eigrp 200 10</p><p> no snmp trap link-status</p><p>end</p><p>

Now set R2 with timers 30/100

</p><p>R2#show run int f0/0</p><p>Building configuration...</p><p></p><p>Current configuration : 156 bytes</p><p>!</p><p>interface FastEthernet0/0</p><p> ip address 172.16.12.2 255.255.255.0</p><p> ip hello-interval eigrp 200 30</p><p> ip hold-time eigrp 200 100</p><p> duplex auto</p><p> speed auto</p><p>end</p><p>

Now lets look at R1's view of its neighbor:

</p><p>R1#show ip eigrp neighbor f0/0.12</p><p>IP-EIGRP neighbors for process 200</p><p>H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq</p><p>                                            (sec)         (ms)       Cnt Num</p><p>0   172.16.12.2             Fa0/0.12          74 00:00:25   12   200  0  6</p><p>

See how the hold time is way up, in stite of the fact we configured 10 seconds here. This is the hold timer we configured in R2. So for the sake of completeness, let's look at R2's view of R1:

</p><p>R2#show ip eigrp neighbor f0/0</p><p>IP-EIGRP neighbors for process 100</p><p>IP-EIGRP neighbors for process 200</p><p>H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq</p><p>                                            (sec)         (ms)       Cnt Num</p><p>0   172.16.12.1             Fa0/0              8 00:00:35    8   200  0  9</p><p>

I think I'll add that to my blog if I get some time this evening ... it is quite a useful test. And I can post with the correct formatting.


Kevin Dorrell

Luxembourg


Actions

This Discussion