[c-nsp] Basic Etherchannel Question

[Kevin Graham]

Absolutely go LACP. One-way, misconfigured or otherwise broken interfaces in a bundle are handled implicitly and done with explicit signaling to each side (i.e. Both will see it as an independent or broken port rather than just shutdown).

This is can also trivially monitored via the LAG-MIB, saving sone additional time in the troubleshooting cycle.

[sent from my mobile]

On Jan 15, 2011, at 10:12 AM, Keegan Holley <keegan.holley at sungard.com> wrote:

> On Sat, Jan 15, 2011 at 10:33 AM, Phil Mayers <p.mayers at imperial.ac.uk>wrote:
> 
>> On 01/15/2011 12:42 AM, Peter Rathlev wrote:
>> 
>>> On Fri, 2011-01-14 at 18:50 -0500, Keegan Holley wrote:
>>> 
>>>> Just wondering what the general consensus was on hard coding vs.
>>>> negotiating
>>>> etherchannels.  I've always hard coded them and viewed the negotiation
>>>> protocols as a possible point of failure.
>>>> 
>>> 
>>> We always use LACP, since an unconditional port-channel connected to
>>> something that's not a port-channel might lead to problems. I view it a
>>> little like GE auto-negotiation -- I can't see a reason for not using
>>> it.
>>> 
>> 
>> At one time the Cisco "fast convergence" SRND recommended channel mode of
>> "on" because it was a bit quicker bringing links up. We followed that
>> advice, but TBH I've been reconsidering it lately.
>> 
>> To an extent it depends on what *kind* of etherchannel you're talking
>> about. If it's router->router and you control the fibre patching, a
>> mis-patch is less likely.
>> 
>> But if it's towards an edge server, where mis-patching gets more likely,
>> LACP seems like a no-brainer.
>> 
>> 
> I'm less concerned with connecting to the wrong device than with diagnosing
> failures.  I've seen issues where a link in a hardcoded etherchannel stops
> passing traffic but is not removed from the channel since there is no
> negotiation protocol running.  Would dynamic protocols help here or is it
> not worth the risk?  Just to be clear I'm talking about LACP, but I assume
> PAGP is capable of the same.
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/