STP loop after adding new VLAN to the physical endpoint of an etherchannel

[rogelioalvez]

Hello guys:

Two core switches are linked by a port channel (built with two physical links).

Several access switches are in turn dual-linked to these core switches. STP is configured and operating on all vlans.

I added a vlan ("switchport trunk allowed vlan add xx") to one of the physical endpoints of the portchannel instead of doing this on the portchannel interface itself.

As soon as I executed the command, a storm of duplicated mac addresses started to be logged and the CPU of both core switches skyrocketed close to 100%. Many MAC addresses seemed to be coming into each core switch from different links at the same time, so a STP loop was generated as the result of my action.

I was explained that I should have added the new vlan to the portchannel, because this command would have been automatically propagated to the physical links that are part of the channel.

My question is: ¿is there a relationship between the command I entered and the (supposedly STP) loop I observed on these switches?

Any help will be greatly appreciated.

Rogelio

[jim_berlow]

Sorry to hear about your experience - I'm sure that you won't make this mistake again! As you mentioned, you should always make these kinds of changes on the port channel interface. I hope that Cisco will change the IOS in the future to prevent others from making this mistake (there has to be a way of locking the physical interfaces when channeled).

I don't have specific evidence for you to look at to correlate the events, but I assure you that created a misconfiguration of your trunks leading to the "death" of the switches.

One word of advice (in case you didn't do this). Whenever working with port channels, I never save the config until I know it worked and I can test everything afterward. That way if an emergency comes up, you can just reboot the switch and your back in business in 10 minutes.

HTH,

Jim

[rogelioalvez]

Hi Jim:

In fact, the CPU was so bussy that I spent a lot of time trying to telnet this switch back in order to undo this command :o)

Whenever I feel a command could generate a potential problem, I previously enter a "reload in 5" in order to be sure that if something wrong happens, worst case I will get access again after the reboot.

In this case, I was not aware how harmful the command could be. I will generate the problem in a lab environment and let you know.

regards, Rogelio

[chinkevi_2]

a lot of datacentre breaks because people add vlan to physical interface that is member of port channel.

I think this is due to the fact that if you add vlan to a physical interface that is a member of port channel, you break the etherchannel as you cause difference in vlan membership.

[rogelioalvez]

This was even worse. The channel did not break, because otherwise I wouldn't have had such a loop. No ERRDISABLE message was logged as I would have expected from such a mismatch in the endpoints of the channels or its members.

regards, Rogelio