RE: Design reasons for LACP active versus on

Is there any chance you could translate that into something understandable?

Was it you are blaming EC on on plugging cables into wrong switches?

tv

-----Original Message-----
From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
Joseph L. Brunner
Sent: Friday, May 22, 2009 3:07 PM
To: Joe Astorino; 'Sadiq Yakasai'; 'Chris Breece'
Cc: ccielab_at_groupstudy.com
Subject: RE: Design reasons for LACP active versus on

I can say wholeheartedly NEVER USE ON!!!! I ran into a frame-loss situation
that caused more downtime/lossed trading revenue than
An 18-wheeler of 6509's with sup 720's cost... we talking thousands of
transactions were bought/sold wrong due to a simple error.

On -> on
On -> on

Type channel being accidentally 1/2 going to the wrong switch... every so
often data communications dropped and weird things happed...

I learned that night catos also has "show channel" (which helped us see the
drops) than just "show port channel" which didn't

Very very very nasty issue (especially if you are not there to see the
fiber)

So I always teach my students, TRUNK ON, PORT CHANNEL DYN DESIRABLE, or
ACTIVE

-Joe

-----Original Message-----
From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of Joe
Astorino
Sent: Friday, May 22, 2009 4:13 PM
To: 'Sadiq Yakasai'; 'Chris Breece'
Cc: ccielab_at_groupstudy.com
Subject: RE: Design reasons for LACP active versus on

Chris makes a good point about stackwise situations -- I had the same
scenario come up in a production environment with a stack of 3750 switches.
They wanted to expand bandwidth going back to the core, but there were not
enough uplinks on a single switch. It does work!

Regards,

Joe Astorino
CCIE #24347 (R&S)
Sr. Support Engineer - IPexpert, Inc.
URL: http://www.IPexpert.com
 
-----Original Message-----
From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
Sadiq Yakasai
Sent: Friday, May 22, 2009 10:38 AM
To: Chris Breece
Cc: ccielab_at_groupstudy.com
Subject: Re: Design reasons for LACP active versus on

Chris, are you a CCIE proctor? :D

Like whoever comes up with these weird scenarios? nice one though ;-)

On Fri, May 22, 2009 at 1:18 PM, Chris Breece <cbreece1_at_gmail.com> wrote:

> Hey Geert, I just tried it using this code :
> c3750-ipbasek9-mz.122-46.SE.bin
>
> It worked. Must have been the code were using at the time.
>
> Chris
>
> On Fri, May 22, 2009 at 3:52 AM, Geert Nijs <Geert.Nijs_at_simac.be> wrote:
>
> > Chris,
> >
> > Cross-Stack LACP should work. Cross-Stack Pagp will not work:
> >
> > "PAgP cannot be enabled on cross-stack EtherChannels while LACP is
> > supported on cross-stack EtherChannels from Cisco IOS Software
> > Release 12.2(25)SEC and later."
> >
> > See:
> >
> >
> http://www.cisco.com/en/US/products/hw/switches/ps5023/products_config
> uration_example09186a00806cb982.shtml
> >
> > regards,
> > Geert
> > CCIE#13768
> >
> > -----Original Message-----
> > From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf
> > Of Chris Breece
> > Sent: woensdag 13 mei 2009 3:34
> > To: ccielab_at_groupstudy.com
> > Subject: Fwd: Design reasons for LACP active versus on
> >
> > Also,
> >
> > One scenario where we had to use "on" versus pagp or lacp was if we
> > used 3750's w/ stackwise. For instance, if one physical interface
> > was on
> switch
> > 1
> > in the stack and one physical interface was on switch 2, IOS
> > wouldn't
> allow
> > us to use PAGP or LACP to port channel them. "On" works fine in this
> case,
> > just make sure your wiring guys know where to plug in the cables :)
> >
> > Chris
> >
> >
> >
> >
> > ---------- Forwarded message ----------
> > From: Chris Breece <cbreece1_at_gmail.com>
> > Date: Tue, May 12, 2009 at 9:24 PM
> > Subject: Re: Design reasons for LACP active versus on
> > To: Cisco certification <ccielab_at_groupstudy.com>
> >
> >
> > I've created spanning tree loops using "on". LACP has some sanity
> checking
> > built in to prevent this.
> >
> > For instance, a typical access layer switch plugged into two
> > distribution switches all connected via layer 2. Configure the
> > following
> >
> > access layer switch:
> >
> > *int po1*
> > *switchport trunk encap dot1q*
> > *switchport mode trunk*
> > **
> > *int gi1/1*
> > *switchport trunk encap dot1q*
> > *switchport mode trunk*
> > *channel-group 1 mode on*
> > **
> > *int gi1/2
> > *
> > *switchport trunk encap dot1q*
> > *switchport mode trunk*
> > *channel-group 1 mode on*
> >
> >
> > Now plug gi1/1 into distro switch 1, and gi1/2 in distro switch 2.
> >
> > Watch the network explode :P
> >
> > LACP would err-disable the ports in this scenario.
> >
> >
> >
> > Chris
> >
> >
> >
> > On Tue, May 12, 2009 at 6:48 AM, Thameem Maranveetil Parambath <
> > tparamba_at_thecontactcentre.ae> wrote:
> >
> > > If you configure statically (on), the negotiation time can be
> > > saved. So
> I
> > > would go for (on) rather than active or desirable.
> > >
> > >
> > >
> > >
> > > Marc La Porte <marc.a.laporte_at_gmail.com> Sent by:
> > > nobody_at_groupstudy.com
> > > 12/05/2009 02:46 PM
> > > Please respond to
> > > Marc La Porte <marc.a.laporte_at_gmail.com>
> > >
> > >
> > > To
> > > Cisco certification <ccielab_at_groupstudy.com> cc
> > >
> > > Subject
> > > Design reasons for LACP active versus on
> > >
> > >
> > >
> > >
> > >
> > >
> > > Hi,
> > >
> > > From a design viewpoint, configuring LACP (L2 Etherchannel) from
> > > an
> > access
> > > switch (6500) to a third-party server (IBM, HP, etc) would it be
> > > better
> > to
> > > configure our side as "active" or as "on"?
> > >
> > > Thanks
> > > Marc
> > >
> > >
> > > Blogs and organic groups at http://www.ccie.net
> > >
> > > __________________________________________________________________
> > > _____ Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > The content of this email together with any attachments,
> > > statements and opinions expressed herein contains information that
> > > is private and confidential and intended for the named
> > > addressee(s) only. If you are not the addressee of this email you
> > > may not copy, forward, disclose or otherwise use it or any part of
> > > it in any form whatsoever. If you have received this message in
> > > error please notify postmaster_at_etisalat.ae by email immediately
> > > and delete the message without making and copies.
> > >
> > >
> > > 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
> >
> >
> >
> >
> >
> >
> >
> > disclaimer : http://apps.simac.be/disclaimer.htm
>
>
> Blogs and organic groups at http://www.ccie.net
>
> ______________________________________________________________________
> _ Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>

--
CCIE #19963
Blogs and organic groups at http://www.ccie.net