cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

850
Views
0
Helpful
4
Replies
Highlighted
Beginner

EIGRP long convergence problem

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

topo.jpg



I am using a home lab 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

R1.jpg

R1 topology

r1topo.jpg

R2

R2.jpg

R2 topology

R2 topo.jpg

and R3

R3.jpg

R3 Topology

r3topo.jpg


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

result.jpg


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

Everyone's tags (3)
1 ACCEPTED SOLUTION

Accepted Solutions
Hall of Fame Expert

Re: EIGRP long convergence problem

Hello Agostinho,

looking at your network diagram and your show output commands we see the following:

the destination network of your ping test is the R2 loopback address 172.20.10.1

I suppose your ping test is started from R1.

The best path ( = successor in EIGRP terms) is via Fas0.6 from R1.

During the ping test from R1 you shut R2 fas0 interface that leads to R1.

How is R1 connected to R2?  I see that on R1 you have two Vlan based subinterfaces one Fas0.6 connecting to R2 and Fas0.7 connecting to R3.

It is clear that you have a LAN switch in the middle interconnecting R1 to R2 and to R3 with all the router Fastethernet ports connected to  different switch ports.

So, when R2 fas0 interface is disabled, R1 fas0 and fas0.6 interfaces is still up/up.

EIGRP hello timer is 5 seconds and EIGRP hold time is 15  seconds. R1 detects R2 failure when the EIGRP hold time expires that is within 15 seconds.(after 15 seconds from last received EIGRP hello)

After that, R1 declares down the neighbor with R2 and looks for an alternate route to 172.20.10.1.

The alternate path is via R3 but it cannot be used immediately, because it is not a backup path ( not a  feasible successor in EIGRP terms).

So you should see with appropriate debug commands that R1 goes active for the prefix sends out an EIGRP query and receives a reply from R3 and only at that point it installs the alternate route and ping is successful again.

The main reason is the use of the LAN switch in the middle. Then there are some specifics about EIGRP behaviour that I haven't detailed.

EIGRP is very fast when a backup route is ready to be used in the EIGRP topology table ( feasible successor).

From the point of view of R1 it has no feasible successor for the route 172.20.10.1 via R3, because R3 EIGRP metric (advertised distance in EIGRP terms) is greater then the best metric on link R1-R2 (called feasible distance in EIGRP terms)   a serial link compared to a Fast ethernet link greater delay and a lower bandwith that increases the metric.

Hope to help

Giuseppe

4 REPLIES 4
Hall of Fame Expert

Re: EIGRP long convergence problem

Hello Agostinho,

looking at your network diagram and your show output commands we see the following:

the destination network of your ping test is the R2 loopback address 172.20.10.1

I suppose your ping test is started from R1.

The best path ( = successor in EIGRP terms) is via Fas0.6 from R1.

During the ping test from R1 you shut R2 fas0 interface that leads to R1.

How is R1 connected to R2?  I see that on R1 you have two Vlan based subinterfaces one Fas0.6 connecting to R2 and Fas0.7 connecting to R3.

It is clear that you have a LAN switch in the middle interconnecting R1 to R2 and to R3 with all the router Fastethernet ports connected to  different switch ports.

So, when R2 fas0 interface is disabled, R1 fas0 and fas0.6 interfaces is still up/up.

EIGRP hello timer is 5 seconds and EIGRP hold time is 15  seconds. R1 detects R2 failure when the EIGRP hold time expires that is within 15 seconds.(after 15 seconds from last received EIGRP hello)

After that, R1 declares down the neighbor with R2 and looks for an alternate route to 172.20.10.1.

The alternate path is via R3 but it cannot be used immediately, because it is not a backup path ( not a  feasible successor in EIGRP terms).

So you should see with appropriate debug commands that R1 goes active for the prefix sends out an EIGRP query and receives a reply from R3 and only at that point it installs the alternate route and ping is successful again.

The main reason is the use of the LAN switch in the middle. Then there are some specifics about EIGRP behaviour that I haven't detailed.

EIGRP is very fast when a backup route is ready to be used in the EIGRP topology table ( feasible successor).

From the point of view of R1 it has no feasible successor for the route 172.20.10.1 via R3, because R3 EIGRP metric (advertised distance in EIGRP terms) is greater then the best metric on link R1-R2 (called feasible distance in EIGRP terms)   a serial link compared to a Fast ethernet link greater delay and a lower bandwith that increases the metric.

Hope to help

Giuseppe

Beginner

EIGRP long convergence problem

Thanks for such a detail reponse.

I am actulay pingin from R3 that those have the FS, but I asume the delay in the convergence is becouse of the same reason,untile R1 reports that route down it will not converge?

Hall of Fame Expert

EIGRP long convergence problem

Hello Agostinho,

yes it should be the same as the best route to 172.20.10.1 is via R1 from the point of view of R3.

Hope to help

Giuseppe

Beginner

EIGRP long convergence problem

Thanks Giuseppe, I was going nuts trying to figure it out

CreatePlease to create content
Content for Community-Ad
July's Community Spotlight Awards