EIGRP neighborship questions

Answered Question
Mar 26th, 2008

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?

I have this problem too.
0 votes
Correct Answer by mattcalderon about 8 years 8 months 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.
Jon Marshall Wed, 03/26/2008 - 08:37

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

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

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

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

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

Kevin Dorrell Fri, 05/23/2008 - 10:09

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