03-26-2008 08:18 AM - edited 03-05-2019 09:59 PM
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?
Solved! Go to Solution.
03-26-2008 08:26 AM
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
03-26-2008 08:26 AM
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
03-26-2008 08:37 AM
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
03-26-2008 08:41 AM
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.
05-23-2008 06:36 AM
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
05-23-2008 07:17 AM
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
05-23-2008 09:31 AM
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
05-23-2008 09:57 AM
Kevin,
Congratulations on your CCIE. You deserve it!
Regards,
Sundar
05-23-2008 10:19 AM
Thank you Sundar!
05-23-2008 10:09 AM
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
R1#show run int f0/0.12
Building configuration...
Current configuration : 197 bytes
!
interface FastEthernet0/0.12
encapsulation isl 12
ip address 172.16.12.1 255.255.255.0
no ip redirects
ip hello-interval eigrp 200 3
ip hold-time eigrp 200 10
no snmp trap link-status
end
Now set R2 with timers 30/100
R2#show run int f0/0
Building configuration...
Current configuration : 156 bytes
!
interface FastEthernet0/0
ip address 172.16.12.2 255.255.255.0
ip hello-interval eigrp 200 30
ip hold-time eigrp 200 100
duplex auto
speed auto
end
Now lets look at R1's view of its neighbor:
R1#show ip eigrp neighbor f0/0.12
IP-EIGRP neighbors for process 200
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 172.16.12.2 Fa0/0.12 74 00:00:25 12 200 0 6
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:
R2#show ip eigrp neighbor f0/0
IP-EIGRP neighbors for process 100
IP-EIGRP neighbors for process 200
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 172.16.12.1 Fa0/0 8 00:00:35 8 200 0 9
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
05-25-2008 04:22 AM
I've done a better write up of this experiment in my blog:
http://dorreke.wordpress.com/2008/05/25/eigrp-timers-solution/
The diagram still doesn't look how I want it, but I'm working on it.
Kevin Dorrell
Luxembourg
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide