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 <[email protected]> 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 < > [email protected]> 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 <[email protected]> >> wrote: >> >>> On Sat, Jan 15, 2011 at 10:33 AM, Phil Mayers <[email protected] >>> 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 [email protected] >>> https://puck.nether.net/mailman/listinfo/cisco-nsp >>> archive at http://puck.nether.net/pipermail/cisco-nsp/ >> >> _______________________________________________ >> cisco-nsp mailing list [email protected] >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ >> > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
