Re: EtherChannel mode ON ? Any catch?

From: Marko Milivojevic <markom_at_ipexpert.com>
Date: Wed, 6 Oct 2010 20:10:45 -0400

Yeah, I neglected to mention that LACP can be used as poor-man's BFD
:-). Very effectively, too.

--
Marko Milivojevic - CCIE #18427
Senior Technical Instructor - IPexpert
FREE CCIE training: http://bit.ly/vLecture
Mailto: markom_at_ipexpert.com
Telephone: +1.810.326.1444
Web: http://www.ipexpert.com/
On Wed, Oct 6, 2010 at 18:10, Ivan Walker <ivan_at_itpro.co.nz> wrote:
> I would also add that using LACP can be useful when end-to-end connectivity
> is not reflected in the link status of the interface - for example - using
> media converters or perhaps a QinQ service.
>
> LACP control packets are sent at 30 second intervals after bundling and give
> and end to end check. B Using "lacp rate fast" this is reduced to 1 second
> (much more useful) B Note that the dead time is 3x the hello time...
> B Unfortunately last time I looked I think only the high end switches
> supported the fast timers :-(
>
> Ivan
>
> On 6/Oct/2010 11:37 p.m., Marko Milivojevic wrote:
>>
>> With "on", you're running the risk of bridging loops if other end is
>> misconfigured. If that risk is acceptable and ~2s of initial negotiation
>> delay of LACP/PAgP isn't, use it.
>>
>> I would suggest you use LACP.
>>
>> --
>> Marko Milivojevic - CCIE #18427
>> Senior Technical Instructor - IPexpert
>>
>> Free CCIE Training: http://bit.ly/vLecture
>>
>> Mailto: markom_at_ipexpert.com
>> Telephone: +1.810.326.1444
>> Community: http://www.ipexpert.com/communities
>>
>> :: Sent from my phone. Apologies for errors and brevity. ::
>>
>> On Oct 5, 2010, at 19:35, Tech Guy<autechguy_at_gmail.com> B wrote:
>>
>>> Hi GS,
>>>
>>>
>>> LACP takes some time to negotiate, while mode ON does not require it,
>>> and hence gives a better convergence time. I am not sure if there's
>>> any issue with using EtherChannel mode ON, instead of LACP (apart from
>>> user-misconfig issues). This is not clear in the DOC CD configuration
>>> guide.
>>>
>>> More specifically, if we have two Cisco switches, and need to
>>> configure ether-channel between them, would you recommend mode ON or
>>> LACP (open standard). E.g. issue with mode ON such as one link is
>>> recognised as UP at one end, but as DOWN by the switch at the other
>>> end.
>>>
>>>
>>> Appreciate your feedbacks.
>>>
>>>
>>>
>>>
>>> http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_44_se/configuration/guide/swethchl.html#wp1275503
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Understanding EtherChannels
>>> These sections describe how EtherChannels work:
>>>
>>> B EtherChannel Overview
>>>
>>> B Port-Channel Interfaces
>>>
>>> B Port Aggregation Protocol
>>>
>>> B Link Aggregation Control Protocol
>>>
>>> B EtherChannel On Mode
>>>
>>> B Load Balancing and Forwarding Methods
>>>
>>> EtherChannel Overview
>>> An EtherChannel consists of individual Fast Ethernet or Gigabit
>>> Ethernet links bundled into a single logical link as shown in Figure
>>> 34-1.
>>>
>>> Figure 34-1 Typical EtherChannel Configuration
>>>
>>>
>>>
>>> The EtherChannel provides full-duplex bandwidth up to 800 Mb/s (Fast
>>> EtherChannel) or 8 Gb/s (Gigabit EtherChannel) between your switch and
>>> another switch or host.
>>>
>>> Each EtherChannel can consist of up to eight compatibly configured
>>> Ethernet ports. All ports in each EtherChannel must be configured as
>>> either Layer 2 or Layer 3 ports. The number of EtherChannels is
>>> limited to 48. For more information, see the "EtherChannel
>>> Configuration Guidelines" section. The EtherChannel Layer 3 ports are
>>> made up of routed ports. Routed ports are physical ports configured to
>>> be in Layer 3 mode by using the no switchport interface configuration
>>> command. For more information, see the Chapter 10, "Configuring
>>> Interface Characteristics."
>>>
>>> You can configure an EtherChannel in one of these modes: Port
>>> Aggregation Protocol (PAgP), Link Aggregation Control Protocol (LACP),
>>> or On. Configure both ends of the EtherChannel in the same mode:
>>>
>>> B When you configure one end of an EtherChannel in either PAgP or LACP
>>> mode, the system negotiates with the other end of the channel to
>>> determine which ports should become active. Incompatible ports are
>>> suspended. Beginning with Cisco IOS Release 12.2(35)SE, instead of a
>>> suspended state, the local port is put into an independent state and
>>> continues to carry data traffic as would any other single link. The
>>> port configuration does not change, but the port does not participate
>>> in the EtherChannel.
>>>
>>> B When you configure an EtherChannel in the on mode, no negotiations
>>> take place. The switch forces all compatible ports to become active in
>>> the EtherChannel. The other end of the channel (on the other switch)
>>> must also be configured in the on mode; otherwise, packet loss can
>>> occur.
>>>
>>> If a link within an EtherChannel fails, traffic previously carried
>>> over that failed link moves to the remaining links within the
>>> EtherChannel. If traps are enabled on the switch, a trap is sent for a
>>> failure that identifies the switch, the EtherChannel, and the failed
>>> link. Inbound broadcast and multicast packets on one link in an
>>> EtherChannel are blocked from returning on any other link of the
>>> EtherChannel.
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net
Received on Wed Oct 06 2010 - 20:10:45 ART

This archive was generated by hypermail 2.2.0 : Mon Nov 01 2010 - 06:42:05 ART