Portchannel errdisable issue

Unanswered Question
Sep 17th, 2010


I have a problem that I can't seem to figure out. I have two 1gig copper uplinks between a catalyst 3012 and a nexus 7010. Both ports on each switch are configured as trunk ports and when they are connected, as expected one port is in the blocked state and the other is forwarding. When I configure ether channel on both sides the catalyst 3012 keeps errdisabling the ports and no errors are generated on the nexus.

If I use lacp or configure them to etherchannel statically I have the same problem. The nexus does not support the desireable state so I am not able to use that. Please see error and port configs below, any suggestions would be greatly appreciated.

interface range gigabitethernet 0/15 - 16
description Connection to Nexus-7000
switchport mode trunk
spanning-tree guard loop
channel-group 1 mode on

interface ethernet 1/37-38
description Connection to Catalyst 3012
switchport mode trunk
spanning-tree guard loop

channel-group 4 mode on

%PM-4-ERR_DISABLE: channel-misconfig (STP) error detected on Gi0/15, putting Gi0/15 in err-disable state
%PM-4-ERR_DISABLE: channel-misconfig (STP) error detected on Gi0/16, putting Gi0/16 in err-disable state

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Reza Sharifi Fri, 09/17/2010 - 19:58


Can you try using LACP for both sides using active mode?   Also, it is good idea to shut down the ports and the Etherchannel and once it is all configured do a "no sh" and bring them all up at the same time.  Also don't use spanning-tree guard loop and see if the portchannel comes up first



polofalltrades Fri, 09/17/2010 - 23:59

Hi there, the config seems to be fine. Since the error shows some misconfigs on the STP/Spanning-Tree Part, maybe you could try to check on any STP configurations discrepancies per port on the Cat3012, and compare it with the STP port configs on the nexus. I'm not very familiar with that model. However, you could try to check anyways.

Peter Paluch Sat, 09/18/2010 - 02:46


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:


Best regards,


glen.grant Sat, 09/18/2010 - 02:53

  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 .

Peter Paluch Sat, 09/18/2010 - 02:59


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,


KWillacey_2 Sat, 09/18/2010 - 05:50

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.

Reza Sharifi Sat, 09/18/2010 - 14:30

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.



KWillacey_2 Sun, 09/19/2010 - 10:49

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.


This Discussion