Switch is causing network outage
We have two Meraki MS320's as our core and 6 tertiary switches that are meshed to the core switches (two trunk cables - one cable goes to each core switch). The tertiary switches are SGE2010's and SG500X's.
One of the tertiary switches (SGE2010) can only have a single cable plugged into the core. If I plug in the redundant trunk cable, the entire network goes down. It seems that the Cisco switch thinks it is the root bridge and therefore has no Root or Alternate STP port. The Bridge ID and Root Bridge ID are the same. The ports are all either disabled or forwarding. The trunk ports are configured just like the rest of the tertiary switches. What I find odd is that the core switch has a lower MAC address number than the Cisco switch. If two switches fight for Root Bridge, doesn't the lower number win? ... and why isn't my Cisco SGE2010 accepting Root Bridge declaration from the Meraki?
A reboot of the switch didn't fix the problem.
You can refer to this question that led to the issue. It didn't appear to take place before the STP changes. (or may be it did happen but root guard is making it become more evident)
https://www.experts-exchange.com/questions/28667364/Port-STP-Change-on-Meraki-MS320-Locking-Up-Entire-Network.html
Thank you for any help.
One of the tertiary switches (SGE2010) can only have a single cable plugged into the core. If I plug in the redundant trunk cable, the entire network goes down. It seems that the Cisco switch thinks it is the root bridge and therefore has no Root or Alternate STP port. The Bridge ID and Root Bridge ID are the same. The ports are all either disabled or forwarding. The trunk ports are configured just like the rest of the tertiary switches. What I find odd is that the core switch has a lower MAC address number than the Cisco switch. If two switches fight for Root Bridge, doesn't the lower number win? ... and why isn't my Cisco SGE2010 accepting Root Bridge declaration from the Meraki?
A reboot of the switch didn't fix the problem.
You can refer to this question that led to the issue. It didn't appear to take place before the STP changes. (or may be it did happen but root guard is making it become more evident)
https://www.experts-exchange.com/questions/28667364/Port-STP-Change-on-Meraki-MS320-Locking-Up-Entire-Network.html
Thank you for any help.
ASKER
They are all running RSTP, and by all, I mean core and tertiary.
If you have two switches that are connected and they both think they're the root then either A) they're not communicating at all or B) they are not speaking the same language (in this case, spanning-tree).
Now as far as option A, it could be a unidirectional link.
That said, when only one of the uplinks is connected from the offending switch, does everything work fine? If so, then there's no unidirectional link.
And if everything is working fine with the single uplink in place, what does the STP information show? Does the SGE2010 recognize the Meraki as the root?
Now as far as option A, it could be a unidirectional link.
That said, when only one of the uplinks is connected from the offending switch, does everything work fine? If so, then there's no unidirectional link.
And if everything is working fine with the single uplink in place, what does the STP information show? Does the SGE2010 recognize the Meraki as the root?
ASKER
Yes, the tertiary switch works fine when only one cable is plugged in. I verified that it isn't the port by plugging only one cable in to both trunk ports. The problem only happens with both cables plugged in.
No, the SGE2010 still thinks it is the Root Bridge even though it is connected to the Meraki.
No, the SGE2010 still thinks it is the Root Bridge even though it is connected to the Meraki.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I've tried different ports on the Cisco and different ports on the Meraki. RSTP is running on all of them.
When this switch is connected to the Meraki switch, what is the port state? I'm guessing Designated.
Can you connect this switch to one of the other Cisco's?
Can you connect this switch to one of the other Cisco's?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
The connected port is Designated
I will try connecting it to another Cisco tonight since I don't want to do it during working hours.
Config attached
BPDU guard is enabled for the access ports but not the trunk/uplink ports.
Here are some screenshots:
1- Port 24 of the "bad" Cisco is naming its own port 24 as the designated port ID... that's the port connected to the Meraki which should be telling it that the Meraki is the root bridge. This port's settings are identical to those of the other Cisco trunk ports with the exception of the bad one being Designated and the proper ones being Root/Alternate.
2- Here is the "bad" STP property screenshot
3- Here is a working switch with STP properties
I will try connecting it to another Cisco tonight since I don't want to do it during working hours.
Config attached
BPDU guard is enabled for the access ports but not the trunk/uplink ports.
Here are some screenshots:
1- Port 24 of the "bad" Cisco is naming its own port 24 as the designated port ID... that's the port connected to the Meraki which should be telling it that the Meraki is the root bridge. This port's settings are identical to those of the other Cisco trunk ports with the exception of the bad one being Designated and the proper ones being Root/Alternate.
2- Here is the "bad" STP property screenshot
3- Here is a working switch with STP properties
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Great to hear, look forward to the update!
ASKER
I stumbled upon the solution myself but the suggestions you had here helped me narrow down the possibilities.
But since you've got other Cisco switches of the same model, just look at one of the switches that is behaving and see what version of STP it's running then configure this misbehaving switch to run the same version.