EIGRP long convergence problem

Titinho

Hi guys first off English is not my native language so if a make any mistakes please bear with me (any positive criticism is welcome).

Now for my problem, this is my network


I am using real gear not packettracer
so R1 and R3 are Cisco 1721 with IOS C1700-ADVIPSERVICESK9-M, Version 12.4(23).
R3 is a 2650 with IOS C2600-I-M, Version 12.2(1a).

This is R1 routing table


and R3


Now my problem is when I ping 172.20.10.1 and shutdown R2 Fa 0/0 it takes a long time (around 15-20 seconds) to do convergence, in all the material I have it says it should be less then a second

Thanks for your help and if it is hard to read I am sorry

spd3432

Can you post your R1 eigrp topology table ? I'd be willing to bet your answer will be obvious when you look at it. Coming off the serial link, you may not have a feasible successor route.

Titinho

Thanks for the fast reply ^^

Here´s R1 topology


and you are right it does not have a Feasible Successor. But I am pining from R3 that does have the Feasible Successor in the topology

R3 topology


Edit: I just used the variance command so R1 gets the Feasible Successor but it shows the same result



5 dots x 2 seconds = 20 seconds convergence time:S

drkat

since you're shutting down R2's fa0/0 - what does r2's table look like? maybe we're seeing an issue with R2 converging with the reply packet

Titinho

Here´s R2 routing table and topology

table


topology
+


thanks for the help, really appreciate it

spd3432

Putting my thoughts down --
R1 routing table says it only knows one route to R2 and that's via F0.6
R3 routing table says it can go via R1 or via the serial link.

Are you shutting down R2's F0.0 or yanking the cable? If you're doing a shutdown, then I think a "good-bye" packet gets sent (if you do a debug eigrp packets on R1 you might be able to see it). Unfortunately, neither the CCNP:Route OCG or FLG discuss the good-bye packet or its impact on the routing topology. It might cause that route to go into an "active" state causing that route to need to be re-calculated, or it might be that you're seeing the result of the default hold-times on a serial point-to-point link (5sec hello / 15sec hold).

drkat

Hmm not sure - what's show ip eigrp neighbor look like on the routers?

what is the configuration on the serial link?

it may be stuck in active, when the link goes down and you hop into R2 and do a quick show ip eigrp topology before it comes up

Titinho

spd3432 wrote: »

Putting my thoughts down --
R1 routing table says it only knows one route to R2 and that's via F0.6
R3 routing table says it can go via R1 or via the serial link.

Are you shutting down R2's F0.0 or yanking the cable? If you're doing a shutdown, then I think a "good-bye" packet gets sent (if you do a debug eigrp packets on R1 you might be able to see it). Unfortunately, neither the CCNP:Route OCG or FLG discuss the good-bye packet or its impact on the routing topology. It might cause that route to go into an "active" state causing that route to need to be re-calculated, or it might be that you're seeing the result of the default hold-times on a serial point-to-point link (5sec hello / 15sec hold).

I have tested both ways, same result.

The default hold-timer of the serial port who'd be if that was the line that fail right?. the line that goes down is a FastEthernet or am I confused?

Titinho

drkat wrote: »

Hmm not sure - what's show ip eigrp neighbor look like on the routers?

what is the configuration on the serial link?

it may be stuck in active, when the link goes down and you hop into R2 and do a quick show ip eigrp topology before it comes up

I just ran a debug eigrp fsm on R3 (the one that pings) and this is the output

*May 8 03:27:28.798: DUAL: rcvquery: 10.255.255.0/30 via 10.255.255.5 metric 42949 67295/4294967295, RD is 30720
*May 8 03:27:28.802: DUAL: send REPLY(r1/n1) about 10.255.255.0/30 to 10.255.255.5
*May 8 03:27:28.802: DUAL: rcvquery: 192.168.1.0/24 via 10.255.255.5 metric 429496 7295/4294967295, RD is 30720
*May 8 03:27:28.802: DUAL: send REPLY(r1/n1) about 192.168.1.0/24 to 10.255.255.5
*May 8 03:27:28.810: DUAL: rcvupdate: 10.255.255.8/30 via 10.255.255.5 metric 4294 967295/4294967295
*May 8 03:27:28.810: DUAL: Find FS for dest 10.255.255.8/30. FD is 28160, RD is 28 160
*May 8 03:27:28.814: DUAL: 0.0.0.0 metric 28160/0
*May 8 03:27:28.814: DUAL: 10.255.255.5 metric 4294967295/4294967295 found Dmi n is 28160
*May 8 03:27:28.814: DUAL: Removing dest 10.255.255.8/30, nexthop 10.255.255.5
*May 8 03:27:28.826: DUAL: Removing dest 10.255.255.0/30, nexthop 10.255.255.5
*May 8 03:27:28.826: DUAL: Removing dest 192.168.1.0/24, nexthop 10.255.255.5
*May 8 03:27:30.962: DUAL: rcvquery: 172.20.10.0/24 via 10.255.255.9 metric 429496 7295/4294967295, RD is 158720
*May 8 03:27:30.962: DUAL: Find FS for dest 172.20.10.0/24. FD is 158720, RD is 15 8720
*May 8 03:27:30.962: DUAL: 10.255.255.9 metric 4294967295/4294967295
*May 8 03:27:30.966: DUAL: 10.255.255.5 metric 2297856/128256 found Dmin is 22 97856
*May 8 03:27:30.966: DUAL: send REPLY(r1/n1) about 172.20.10.0/24 to 10.255.255.9
*May 8 03:27:30.966: DUAL: RT installed 172.20.10.0/24 via 10.255.255.5
*May 8 03:27:30.966: DUAL: Send update about 172.20.10.0/24. Reason: metric chg
*May 8 03:27:30.966: DUAL: Send update about 172.20.10.0/24. Reason: new if
*May 8 03:27:30.990: DUAL: Removing dest 172.20.10.0/24, nexthop 10.255.255.9


this happens around 5 to 8 seconds after the interface goes down

Titinho

EDIT: found the problem it was the combination of me not totally understanding how EIGRP detects the convergence and only showing you the logical network topology .

R1 actually is connected to R2 and R3 by a switch and with sub-interfaces, so when I disconnect the cable it it has to wait for the hold-down timer to expire to later report to R3 (the pinging router) that the route went down

thanks for your help, and I am sorry for wasting your time, at least I will never forget about how EIGRP detects lost routes XD

MickQ

Many lessons learned, so it's not a waste of time

lantech

That's an interesting topology. Why do you have it connected that way?

Titinho

for the sole purpose of testing EIGRP routing redundancy, originally R1 and R3 we're not directly connected, also I had more loopback interfaces on all the routers for IP summarization (not the automatic one)

vishaw1986

Hey ,

Firstly your both network diagram are diff in your first post .

Taking your first network diagram for explanation :

when we check the topology table for the R1 we found that the Loopback address is coming from the R2 only not from the R3 .
So when you shut Down the R1 interface , R1 will put that route into the active state and start sending Queries to the neighbors for the that particular address . Thats why it take convergence time .

Now Question is why R3 is not sending the Loopback route to R1 ? because if u check the topology table for R3 you will see the route is coming from both R1 and R2 . As R3 F0 interface is connected to R1 on which R3 is receiving route from the R1 . so because of EIGRP Split Horizon rule R3 in not sending route to R1 on the same interface . To disable this use no ip split-horizon eigrp asno. interface command . This is basically loop prevention method .

Hope this explanation will help you .

Titinho

Ho, I did not know split-Horizon whas used in EIGRP, I thought it was only for RIP.

Thanks I am learning a lot ^^

networker050184

This is in dynamips correct? NEVER use dynamips to test things like this. You will find yourself chasing your tail. This relies heavily on your computers CPU which can have many outside influences and not very realistic.

zrockstar

networker050184 wrote: »

This is in dynamips correct? NEVER use dynamips to test things like this. You will find yourself chasing your tail. This relies heavily on your computers CPU which can have many outside influences and not very realistic.

Says he is using real gear on first post

networker050184

Sorry busy Tuesday!