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

Unanswered Question
Aug 11th, 2009
User Badges:

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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
jim_berlow Tue, 08/11/2009 - 13:37
User Badges:
  • Bronze, 100 points or more

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 Tue, 08/11/2009 - 14:55
User Badges:

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 Tue, 08/11/2009 - 16:37
User Badges:

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 Wed, 08/12/2009 - 03:14
User Badges:

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

Actions

This Discussion