Below is how I got LACP LAGs working between a C5 and a Cisco 4507. I did not have to do anything different with spanning-tree on either device. Cisco is running rapid-pvst and Enterasys is running rstp. Nor did I need the "no spanning-tree etherchannel guard misconfig spanning-tree extend system-id" on the Cisco side. I've tested it trying to fail it in a dozen or so ways and it has worked fine throughout. Our Cisco 4507 is the new model with sup-7e if it makes a difference. On the Cisco side be aware of the below bug when configuring a port channel. I included the text of the bug below as well in case someone doesn't have a Cisco ID.
http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsq36972 ENTERASYS C5 ===================== #lacp Set lacp enable set lacp singleportlag enable ! #port set port lacp port ge.1.47 enable set port lacp port ge.1.48 enable CISCO 4507 ===================== interface Port-channel6 switchport switchport mode trunk flowcontrol receive on service-policy input INGRESS-MARKING-DST end interface GigabitEthernet1/7 switchport mode trunk channel-protocol lacp channel-group 6 mode active spanning-tree link-type point-to-point service-policy output EGRESS-QUEUING end interface GigabitEthernet2/7 switchport mode trunk channel-protocol lacp channel-group 6 mode active spanning-tree link-type point-to-point service-policy output EGRESS-QUEUING end CISCO BUG on Port Channel Config =========================== Portchannel does not form. Log messages indicate misconfig. Symptom: Log message indicates compatibility issue on portchannel due to misconfiguration, but mis config does not exist: %EC-5-CANNOT_BUNDLE2: Gi3/16 is not compatible with Po1and will be suspended (trunk mode of Gi3/16 is dynamic, Po1 is trunk) Conditions: The following configuration sequence will cause int g3/16 unable to join the bundle. int g3/16 shut switchport trunk enacp dot1q switchport mode trunk switchport nonegotiate channel-group 1 mode on int po1 switchport trunk enacp dot1q switchport mode trunk switchport nonegotiate int g3/16 no shut Workaround: -Do NOT configure the port-channel with the same configuration while all physical ports are still in shutdown mode. Instead, just unshut the physical ports and the configuration of first one unshutdown will be carried over to the port-channel.. or -Do not use 'switchport nonegotiate' Fyi, Brian -----Original Message----- From: Kellogg, Brian D. Sent: Monday, January 07, 2013 10:51 AM To: Enterasys Customer Mailing List Subject: RE: [enterasys] PVST and RSTP Problems? Thanks for all the help. The problem I was running into was a bug on the Cisco side detailed in the link below. Deleting and recreating the port-channel SVI on the Cisco side fixed the problem. http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsq36972 Thanks, Brian -----Original Message----- From: Tricia Thomas [mailto:[email protected]] Sent: Monday, January 07, 2013 9:54 AM To: Enterasys Customer Mailing List Subject: Re: [enterasys] PVST and RSTP Problems? Hi Brian, I will follow up with you off-list on this. Regards, Tricia Thomas On 01/04/2013 06:13 PM, Kellogg, Brian D. wrote: > Would anyone be willing to share the config on both an Enterasys C5 and a > Cisco switch that I can compare my non-working LAG config to? > > thanks, > Brian > > ________________________________ > From: Tricia Thomas [[email protected]] > Sent: Thursday, January 03, 2013 4:38 PM > To: Enterasys Customer Mailing List > Subject: Re: [enterasys] PVST and RSTP Problems? > > Hi & Happy New Year everyone, > > Sorry, I am late to this discussion. > > We have the same configuration as described by John Kaftan-- RST on the > enterasys side (S*Series and DFE) and "spanning-tree mode rapid-pvst" on the > cisco 6500s. > > We use multi-vlan trunked LAGs between the enterasys equipment at the edge > and the 6500s at the distribution, and have had good success with this for > many years. > > The LAGs on the cisco are configured for dot1q encapsulation and LACP. > > I have had some issues getting this to work with C5s, not sure why, but once > up, these too have been stable. > > > Regards, > > Tricia Thomas > > > -On 12/28/2012 12:30 PM, Baack, Adam wrote: > Thanks for all the help. I think we have a few things to look into now. > > Adam Baack > Sent from my iPhone > > On Dec 28, 2012, at 12:09 PM, "John Kaftan" > <[email protected]<mailto:[email protected]>> wrote: > We had the same problem going between our S4 and our 6509. We moved to RST > on the 6509 (spanning-tree mode rapid-pvst) It was painless and is probably > a good choice so the 6509 was doing RST PVST and the Enterasys stuff was just > doing RST. They seemed to be working well. I would log into the Enterasys > switches and they would recognize the 6509 as the root bridge etc. > > Do you have Netsight? There is a flex view that can help you determine if > you are getting lots of topology changes. Having lots of topology changes > when your network is stable otherwise is a bad thing. It takes up resources > and you will have performance problems. With the flex view you can see the > number of topology changes and when the last topology change took place. If > the number goes up rapidly and the time since the last change is always in > minutes or seconds you have a problem. GTAC should be able to help you with > that. > > As for the LAGs my first question is what is your long term plan? Are you > going with an Enterasys core as well. If so skip the LAGs if you can. We > tried for over a week and could not get a LAG stable between the 6509 and the > S4. We kept getting the same error that you are. We tried filtering BPDUs > on the Cisco because it seemed it was getting confused by the BPDUs coming > accross the LAG. That helped for awhile but then after a couple of days the > LAG went down again with err-disable on the Cisco side. > > Eventually we just bailed since the LAG was used for all traffic between our > users and the server farm we couldn't have it failing. We have been watching > the utilization and it is staying under 1 Gb so that will have to hold us > until we can get the 6509 out of there for good. > > > > > > > On Fri, Dec 28, 2012 at 10:00 AM, Baack, Adam > <[email protected]<mailto:[email protected]>> wrote: > Disclaimer: We are mostly server guys here and know enough switching to be > dangerous. We know very little about spanning tree, etc. > > We're implementing our phase 1 of our Enterasys replacement and have been > installing B5 stacks in all of our headquarter IDFs. They are connecting > back to a Cisco 6509 (Sup 2). > > We just started having problems where the 6509 would err-disable the LACP lag > between the 6509 and the IDFs. The lag is set for trunking. In the terminal > of the 6509 it shows channel mismatch error. We spoke with GTAC and they > said something about the B5 stacks not participating in spanning tree and the > 6509 doesn't know what to do so it disables it. > > Also, some of our IDFs have another Cisco switch farther down... example: > 6509 --> B5 Stack --> Cisco 3750. The 3750 is also trunking. These setups > seem to be the ones with problems. > > GTAC suggested possibly moving from PVST to RSTP so all of our spanning-tree > is the same. Unfortunately I'm not exactly sure how we would do that or if > that's the solution for us. > > Anyone have experience with this type of setup and did you have problems? > > Thanks. > > Adam Baack > Network Administrator > Lee County Sheriff's Office > > > ***IMPORTANT MESSAGE*** > This message is intended for the use of the person or entity to whom > it is addressed and may contain information that is privileged and > confidential, the disclosure of which is governed by applicable law. > If the reader of this email is not the intended recipient or the > employee or agent responsible to deliver it to the intended recipient, > you are hereby notified that any dissemination, distribution or > copying of this information is STRICTLY PROHIBITED. > If you have received this email by error, please notify us immediately > and destroy the related message. This footnote also confirms that this > email message has been swept for the presence of computer viruses, > worms, hostile scripts and other email-borne network threats. PLEASE > NOTE: Florida has a very broad public records law. Most written > communications to or from government officials are public records > available to the public and media upon request. Your email > communications may be subject to public disclosure per Sec. 119 F.S. > > --- > To unsubscribe from enterasys, send email to > [email protected]<mailto:[email protected]> with the body: unsubscribe > enterasys [email protected]<mailto:[email protected]> > > > > -- > John Kaftan > IT Infrastructure Manager > Utica College > > > * --To unsubscribe from enterasys, send email to > [email protected]<mailto:[email protected]> with the body: unsubscribe > enterasys [email protected]<mailto:[email protected]> > > * --To unsubscribe from enterasys, send email to > [email protected]<mailto:[email protected]> with the body: unsubscribe > enterasys [email protected]<mailto:[email protected]> > > > * --To unsubscribe from enterasys, send email to > [email protected]<mailto:[email protected]> with the body: unsubscribe > enterasys [email protected] > > --- > To unsubscribe from enterasys, send email to [email protected] with the > body: unsubscribe enterasys [email protected] --- To unsubscribe from enterasys, send email to [email protected] with the body: unsubscribe enterasys [email protected] --- To unsubscribe from enterasys, send email to [email protected] with the body: unsubscribe enterasys [email protected] --- To unsubscribe from enterasys, send email to [email protected] with the body: unsubscribe enterasys [email protected]
