[nsp] LACP recovery times

Scott.Keoseyan@BroadWing.com Scott.Keoseyan@BroadWing.com
Mon, 23 Sep 2002 15:19:57 -0500


Hi List!

I know this is the service-provider list, and probably not a lot of people
deal with this, but I had a question come up the other day regarding
Ethernet survivability and I was looking for some input from some people.

Which Ethernet strategy is going to afford the better recovery time when
using cisco switches and trying to determine a connectivity scheme,
802.3ad-LACP/Etherchannel or 802.1w-RSTP/Uplinkfast?  

Essentially what I am looking at is whether is would be best to load-balance
VLANs across two separate 1-gig trunks to two switches, or send them all
across an etherchannel connection to one switch using two connections.  I
realize that sending to two different switches gives me a higher level of
resilience, but I have to weigh that versus the expense of discovering which
VLANs on which trunks are producing how much traffic and then determining
which trunk to assign them to, and then worrying about whether it would
matter if one of the connections dropped because the load may exceed the one
remaining link anyhow.  It might just be cheaper/better/faster to push all
the traffic down one set of connections bonded with LACP... or is it?  

While I was weighing this, it hit me that one strategy could recover faster
than the other, but I am unsure which... in the limited testing I've done
with RSTP, I've noted about a 2 second recovery time for RSTP, that is, it
takes about 2 seconds for the VLANs to stop using their primary uplink to
the root that died and start using the secondary path.

Is there a 3rd option with Cisco switches that affords better recovery?
Ethernet APS???  I know Extreme has it.

Any comments would be appreciated.

thanks,

Scott
 +++The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material.  Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited.   If you received
this in error, please contact the sender and destroy any copies of this
document.+++