[c-nsp] Basic Etherchannel Question

[Daniel Holme]

ECMP and BFD would be far more effective if the link is layer3.

You can also do per-link BFD in a LAG but I think that's in IOS-XR only.

--Daniel Holme

On 2 Feb 2011, at 04:14, Kamal Dissanayaka <kamalasiri at gmail.com> wrote:

> Hi,
> 
> We have got Etherchannel thorugh SDH over ethernet links. LACP was the only
> way to detect failures on SDH back bone. But response time is very slow, it
> takes around 1 minute to detect failures.
> 
> Is there a way to change the LACP timers?
> 
> Thanks
> 
> Kamal
> 
> On Sun, Jan 16, 2011 at 8:01 AM, Kevin Graham <
> kgraham at industrial-marshmallow.com> wrote:
> 
>> 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/
>> 
>> _______________________________________________
>> 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/
>> 
> _______________________________________________
> 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/