Hello,

I agree with Reza. This seems to be a problem with the EtherChannel, not with the STP. Using the mode on on EtherChannel groups is a risky business and should be avoided whenever possible because of risks of creating either Layer2 loops or tripping mechanisms such as EtherChannel Misconfig Guard which seems to also be the case here. If possible, both the Nexus and the Catalyst shall be configured (and verified to use) the mode active (the LACP). Until LACP does not negotiate the EtherChannel between both parties successfully, none of them should treat the bundle of the links as already aggregated and they should simply behave as redundant interconnections with no other ill effects.

It seems that the ports are not bundled in an EtherChannel on both sides of the bundle, and while one switch already treats them as a single EtherChannel, the other switch does not, and sends BPDUs over all these links (which is incorrect - only a single BPDU per VLAN should be transmitted through an EtherChannel, not a BPDU per VLAN per link). A nice article explaining the rationale behind the EtherChannel inconsistency detection can be found here:

http://www.cisco.com/en/US/tech/tk389/tk213/technologies_tech_note09186a008009448d.shtml

Best regards,

Peter

  To do this it is a necessity to shutdown both ports on both sides and configure them exactly the same on on both port channel SVI's and the 4 ports . when this is done bring the ports up at the same time using a no shut on the port channel SVI .  Trying to bring the ports themselves up one at a time won't work most of the time and will put the port channel into a err-disable state .

Glen,

You are right about having the physical ports shut down before reconfiguring the Port Channel interfaces, thanks for adding your comments. I would personally shutdown even the physical ports directly on their configuration, not just through their Port-Channel interface (I have a feeling that I have seen some configuration not to be propagated down to the member physical ports so I like to be foolproof here).

Actually, it is a best practice to shutdown the member ports before bundling them into the EtherChannel on both devices, and subsequently bring them back up only after they have been configured for EtherChannel operation on both devices.

Thanks again for pointing out this important issue!

Best regards,

Peter

Thank you for your responses everyone. I did however mention that I did use LACP and had the same problem. I went as far as to shutdown the  ports as well as disconnect them but no matter what I did as soon as the link came up the Catalyst 3012 disabled the physical ports only, the port channel was never put in errdisable state.

I never tried shutting down the portchannel interfaces so I guess that is worth a try. Is it also necessary to remove loop guard from the ports? Would using passive on the 3012 and active on the nexus make the creation of the portchannel more graceful? Thanks for all the help so far, I will be giving this another go in about four hours or so.

You should configure the necessary command for the Portchannel and the physical interface.  Once everything is up and running, you can always add more commands to the config.  Also, for your LACP use active/active and test again.

HTH

Reza

Well I tried it again and got it working. We double checked the vlans between the switches and noticed one vlan was missing from the 3012 but since that vlan was no longer needed we removed it from the nexus, we shut down the ports applied lacp config and brought them back up but still no luck. We then verified the port-channel interface and everything was fine, tried it again and still nothing. After a while we decided to remove the port-channel interface and try it again and then it worked lacp and mode on. Wish we had done that earlier, it was such an obvious step.

I am assuming it had something to do with that one vlan being missing on the 3012 but I'm not sure that was just an idea we had, but as far as I can tell vlans should only become an issue for a port channel when you are using allowed vlans across the trunks. Am I right?

In any case it is finally working thanks for all your input.