Etherchannel misconfig causing loops

Unanswered Question
Jan 21st, 2010
User Badges:

I've read several places where it's been said that configuring the individual ports in an etherchannel as opposed to the port-channel interface has the potential to cause loops. I've also recently seen this happen due to an engineer making that same mistake. Can anyone give me an explanation as to why that happens? My assumption was that as soon as the ports in the etherchannel were not logically the same that the etherchannel would shut down?...meaning no traffic would go across it? How does the loop form if the channel is down?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Jon Marshall Thu, 01/21/2010 - 13:20
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

rsamuel37 wrote:


I've read several places where it's been said that configuring the individual ports in an etherchannel as opposed to the port-channel interface has the potential to cause loops. I've also recently seen this happen due to an engineer making that same mistake. Can anyone give me an explanation as to why that happens? My assumption was that as soon as the ports in the etherchannel were not logically the same that the etherchannel would shut down?...meaning no traffic would go across it? How does the loop form if the channel is down?


The problem is that if one of the individual ports in the etherchannel is configured so that it does not match with the other ports it can drop out of the etherchannel bundle. The problem you now have is with STP because as long as all the ports are in the etherchannel bundle then STP will treat it as one link. If one of the ports falls out of the bundle it will still be forwarding so now you have a L2 loop because the rest of the etherchannel bundle is still forwarding traffic as well.


Jon

rsamuel37 Thu, 01/21/2010 - 14:00
User Badges:

That's interesting...I thought the default behavior of an etherchannel was to shut the entire channel down if there was a difference in the ports in the channel. That doesn't seem to be the case...

rsamuel37 Thu, 01/21/2010 - 14:04
User Badges:

....and to add to my last post...even if the etherchannel doesn't get shut down, the switch actually reported that the port that was changed it's state to down:



Jan 13 14:05:14.081: %EC-5-CANNOT_BUNDLE2: Gi1/0/25 is not compatible with Gi1/0/27 and will be suspended (vlan mask is different)

Jan 13 14:05:15.079: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/25, changed state to down


so I'm still wondering how the loop would form?

Giuseppe Larosa Thu, 01/21/2010 - 13:26
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Rsamuel37,

we have seen the same thing happens even between C6500.


A possible interpretation is that by adding a new vlan to a member link of an already established etherchannel an asimmetry is introduced and there is the potential to create a bridging loop that can isolate a campus network (it happened two times in our case).


When the vlan is added on the port-channel the switch is able to add the vlan to all member links in a coordinate manner.


Some colleague have reported to have used the command

spanning-tree etherchannel guard misconfig


but I'm not sure it can protect from human errors.


configuration of member links has to be identical before the bundle is setup. After the bundle is up any change has to be done on the port-channel for the reasons reported above.


Hope to help

Giuseppe

glen.grant Thu, 01/21/2010 - 15:13
User Badges:
  • Purple, 4500 points or more

    Think the problem is with etherchannels  that are misconfigured when they are forced on as opposed to using a negotiated channel such as pagp or lacp . PAGP and lacp have protections which will not bundle the channels if they are misconfigured whereas if you force the channel on you don't have that protection as it is being unconditionally forced on even if the config is incorrect.   I prefer to use  negotiated channels , have never had an issue with a negotiated channel.  Always bring all the ports in a channel up at the same time .  If you have to add a link to an existing channel schedule downtime , shut the port channel down add the new link and then bring all the ports up at once by doing a no shut on the port channel SVI.

Actions

This Discussion