seamless etherchannel

[benjaminriggenbach]

Hello.

I have the simple question if a etherchannel (LACP or PAgP) with 2 links can switch seamlessly to 

the other link if one fails?

By seamless i mean in a few milliseconds, that no drop out by a voip stream would be hearable.

thank you in advance.

Ben

[Hulk8647]

When a link fails, EtherChannel redirects traffic from the failed link to the remaining links in less than one second. This convergence is transparent to the end user, no sessions are dropped.

You can also configure your EtherChannel as ON and ON on both ends (unconditional), this also speeds up the convergence a little bit.

[benjaminriggenbach]

Hey Hulk8647

ok, so your answer is basically that, what i learned.

i'm glad so far :-)

unfortunately my audio drops up to 3 seconds if i unplug one link.

it sometimes does not drop, i assume this is when i pinch the one where currently no load is.

Am i right that spanning tree does not have any affect to these single interface links, since the

line protocol on the port-channel interface never goes down?

i took your advice and tried it with the config ON - ON.

no change there.

here are my configs:

switch *SLNE-SWG-02* is a Catalyst 3750g running ios 12.2

switch *Switch* is a Catalyst 2960L running ios 15.2

[Hulk8647]

You're correct. STP wouldn't have any effect on the individual links within the channel. It' sees it as one. I dont think there is any way to manipulate the convergence speed of the links any faster though. It's already pretty fast, matter of fact, it can failover between 250 milliseconds up to 2 seconds. I believe like you said, it might depends on the load that you already have on the link thats about to fail.

[benjaminriggenbach]

that's too bad..

since the load is not too heavy (one voip stream) i have the feeling that it should switch quite fast.

so my other guess is, that the device (it is a device used in live music busines) who receives the stream

causes the longer drop because ist does not receive a clock packet in a split second and it tries to

"refind" it somehow instead of just "waiting" for the next one to come.

Is there a way to measure the consistency of the etherchannel if one link fails?

i obviously tried it with my whole chain of devices since this is what matters to me, but i want to find out

if it is really maybe the audio devices and not the etherchannel itself.

i wanted to try it with internet radio but there is a way too long buffertime so that it probably would

never fail anyway.

thanks for your help so far.

[Dennis Mink]

from a spanning tree point of view the port channel is the interface it operates on, not the physical interfaces that are its members, so asfar as I can see, no spanning tree calculation should take place if you unplug one of the two links

[Hulk8647]

So you're having the etherchannel between these two switches? If so, you could tare down the etherchannel and play with RSTP, manually configure your times for sub-second convergence to the other link?

[benjaminriggenbach]

Yes the etherchannel is between these 2 switches.

I will not be able to test the RSTP adjustment in next few days i guess but i will consider that as an option

as soon as possible.

thank you

[Joseph W. Doherty]

I'm surprised to read your sequence of posts. I always understood EtherChannel link fail over was supposed to be relatively fast, as in SONET fail over fast.

An example of why I believe that can be found in: https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/XE3-8-0E/15-24E/configuration/guide/xe-380-configuration/channel.html
which has: "Note The port channel link failure switchover for the Catalyst 4500 series switch was measured at 50 milliseconds, which provides SONET-like link failure switchover time."

Perhaps, though, this isn't true on all Cisco devices that support EtherChannel or it's a bug in your particular switch/IOS combination.

[Hulk8647]

I've read on couple cisco posts that the fail over is 250 milliseconds

[benjaminriggenbach]

Hey.

So i wasn't able to figure it out for 100% until now.

I really think the audio device itself does another delay because it wants to refind a clock source

and that can take these few seconds.

Since i had to find a solution i was able to solve it with the redundancy of the audio protocol.

In this case i need to kind of terminate the signal at the other end with a similar device.

Like i said, this is not the usual use of IT equipment what we do in our business :-)

Thank's for the advices.