Traffic Stops on new trunk connection

[sphbecker1]

I have an odd issue that I can't understand. It isn't exactly a huge issue, but I would like like help understanding what is happening here, because I don't get it.

2 floor office with a Cat9300 stack on each floor. We don't have a huge number of devices, so made the decision to have VLANs span floors. So our final setup will be...

Firewall===(2x1gb copper etherchannel trunk)===SwitchStack1===(2x10gb fiber etherchannel trunk)===SwitchStack2

SwitchStack1 has been in production for a few weeks now and everything is working fine. Getting ready to deploy SwitchStack2 to the new floor and caused an unexpected network outage. As a basic connectivity test before I racked the new switches, I used a copper port in my office to connect sw1 to sw2 to each other using TenGig ports on each. The only command on each port was switchport mode trunk. The moment I connected them, sw1 stopped passing traffic to the firewall. Traffic resumed about 15 seconds later. After hours I performed the test a few times, as soon as the switches connect to each other, all traffic on an unrelated trunk stops for 15 seconds.

sw2 basically has no config (other than setting that one port to trunk), no vlans setup yet, no IP addresses assigned, no other connections of any kind. I am very confused...how can simply connecting a vanilla unconfigured switch cause an upstream outage? I looked at sw1's logs, nothing shown other than that interface coming up and back down.

I am guessing this has something to do with STP...but I don't understand why there would be an interaction like to, especially with a trunk port going to the firewall, which doesn't even run STP.

[Reza Sharifi · Accepted solution]

Appears to be an STP issue. Can you make stack-1 switch the primary STP root for all vlans and keep stack-2 as default?

Also, make sure VTP is in transparent mode or turned off.

spanning-tree vlan x root primary

HTH

[sphbecker1]

EDIT: I can confirm that setting the switch directly connected to the firewall as the STP root corrected the issue.

You are likely correct and I will give your suggestion a try. However, I am still struggling to understand the interaction. Why would connecting a new port cause a change in the STP state of an existing port? Surely STP isn't so aggressive that it will move an existing port into Blocking state while a new port is still in the Listening state.

This question is more about me wanting to learn what happened for my own understanding and less about finding a resolution to the specific issue.

[Reza Sharifi]

Why would connecting a new port cause a change in the STP state of an existing port?

It is most likely because the new stack-2 that you are connecting to the existing stack has an equal or lower priority than the existing stack and that is causing the STP for all VLANs to recalculate. If you configure the new stack with a higher priority before plugging it into the existing stack, you should not see this behavior. That is also one of the reasons for making one set of switches (usually the core) the root by lowering its priority and leaving access switches as default.

HTH