cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1281
Views
0
Helpful
9
Replies

eigrp convergence over gig-e

Julio Garcia
Level 1
Level 1

I have a bit of a problem with convergence times and i was wondering if anyone can help.

i have an eigrp network of 5 nodes, one node (lets call it X) has a destination to network on other end of the network , one link is preferred, the other link is a feasible successor

here is #sh ip eigrp topology


P 192.168.50.48/30, 1 successors, FD is 33330
        via 10.100.100.58 (33330/30770), GigabitEthernet0/20
        via 10.100.100.62 (35840/33280), GigabitEthernet0/22

when i shut down gi 0/20 gracefully using #shutdown command,  the video stream i am running pretty much cuts over instantly , i just get a glitch for an instant.

so this is brillant and i like but...

when i pull out the ethernet cable gi 0/20 out , ie non gracefully  , the video takes 4-5 secs to come back.

i am using eigrp settings, hello = 1 , holdtime = 3

does anyone know why a graceful shutdown is superior to pulling the cable out , and is there anyway i can improve my convergence ?

many thanks!

9 Replies 9

Jon Marshall
Hall of Fame
Hall of Fame

Rob

Not sure what exactly is happening. Is EIGRP peering on a physical interface or on a SVI. Is this on a L3 switch or a router ?

As for fast detection, providing your device supports it, you may want to look at BFD for EIGRP -

BFD for EIGRP

Jon

Hi ,

Its physical Gig-e

im sure the same would happen if it was the physical interface that transports vlans for  svi .

Im just a bit confused why a graceful shutdown is so much faster to converge.

Rob

Don't know to be honest. It may be that doing a "shutdown" on the interface allows the router to know that it can immediately switch to the feasible successor whereas pulling the cable means the router has a delay in reaslising it has lost the connection but that is purely conjecture as i have nver tested this. It would be interesting to see what would happen if the connection was serial and not ethernet.

Jon

Hi Jon,

thanks for your reply, i think u are most probably right , the issue of shutdown probably gets rid of neighbour and everything else associated with it , whereas breaking the link needs holdtimes etc  , its just a bit annoying because in a production environment -- only the latter happens!

was wondering if anyone knows whether it is possible i could do some kind of ip sla , and then use that as a trigger to automatically shut down port?

i dont think i could do that on a production network would be too scared to hand over such power to automatic process but is it feasible?

Hi Rob,

You can try to change the interface keepalive timer to 1, see if that helps the convergence time.

Regards,

Lei Tian

Peter Paluch
Cisco Employee
Cisco Employee

Rob,

Can you provide a picture of your topology - how the routers are interconnected - and the location of the source and receiver of the videostream? Knowing it might help us understand better what's going on.

Best regards,

Peter

hi Lei,

puting keepalive to 1 sec doesnt help , i have just tried it.

i had a look around and aparently 3 keepalives are send at 1 sec intervals before interface is declared down , which is the same as my eigrp hold-time of 3 secs , so unfortunately is the same in practice

Peter, i will draw out a diagram.

Hello Rob,

it would be wise to provide also platform model and IOS image running.

Two possible tools to speed up convergence can be:

BFD for EIGRP as suggested by Jon

or 802.1ah OAM frames (OSI layer2)

the latter should be supported on ME switches, the first one is supported on SW based routers with recent IOS images or in high end devices like C7600.

see

http://www.cisco.com/en/US/docs/switches/metro/me3400/software/release/12.2_50_se/configuration/guide/swoam.html#wp1109519

Also it would be useful to know if the videostream is sent using multicast or it is an unicast flow?

Hope to help

Giuseppe

Hi Guisppe,

Thanks for reply,

Yes i am doing multicast stream routing using sparse mode.

I have found a solution to this using OSPF and 1 sec dead time , with 250ms hello  which is v fast failover when i take cable , about 1 sec.

unfortunately the interfaces i am using do not support bfd.

Review Cisco Networking for a $25 gift card