cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2780
Views
5
Helpful
10
Replies

EIGRP neighborship questions

suelange
Level 1
Level 1

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?

1 Accepted Solution

Accepted Solutions

mattcalderon
Level 4
Level 4

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

View solution in original post

10 Replies 10

mattcalderon
Level 4
Level 4

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
Hall of Fame
Hall of Fame

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

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.

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

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

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,

Congratulations on your CCIE. You deserve it!

Regards,

Sundar

Thank you Sundar!

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

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

Review Cisco Networking for a $25 gift card