02-09-2007 04:44 AM - edited 03-05-2019 02:15 PM
Hi,
I'm running RSTP on a stack consisting of 2 WS-C3750G-24TS-1U switches.
Recently I discovered spanning tree running on one of the stackwise ports of the stack:
------------------------------------------------
VLAN0001 is executing the rstp compatible Spanning Tree protocol
Bridge Identifier has priority 24576, sysid 1, address 001a.xxxx.xxxx
Configured hello time 2, max age 20, forward delay 15, transmit hold-count 6
We are the root of the spanning tree
Topology change flag not set, detected flag not set
Number of topology changes 46 last change occurred 2d21h ago
from GigabitEthernet2/0/24
Times: hold 1, topology change 35, notification 2
hello 2, max age 20, forward delay 15
Timers: hello 0, topology change 0, notification 0, aging 300
<...omitted...>
Port 1001 (StackPort2) of VLAN0001 is backup blocking
Port path cost 100, Port priority 128, Port Identifier 128.1001.
Designated root has priority 24577, address 001a.xxxx.xxxx
Designated bridge has priority 24577, address 001a.xxxx.xxxx
Designated port id is 128.1000, designated path cost 0
Timers: message age 15, forward delay 0, hold 0
Number of transitions to forwarding state: 2
Link type is point-to-point
BPDU: sent 0, received 137308
--------------------------------
As far as I understand, spanning tree is not supposed to be running on stackwise ports.
Is this normal or some sort of failure?
Solved! Go to Solution.
02-15-2007 09:26 AM
The spanning tree cannot be run independently on each stack member. There has to be some kind of internal messaging between the members so that the stack looks like a single bridge. This inter-member communication could have been implemented in several ways. In the current stacking architecture, members are communicating by sending BPDUs on the stack ports, which are virtual ports representing the connection to a kind of shared segment (a ring in fact) linking all the members together. As a result of this implementation choice, the stack ports are seen by STP (but STP is not really running on them). Note that the stack ports only appear in your show span output because you must have "debug spanning-tree events" configured on your switch. It would be hidden otherwise. The information displayed for the stack ports is to be considered as internal. For instance, stack ports are never blocking, even if in your example STP can show them as "backup blocking". Basically, forget about the output of this command for stack port, they don't have much meaning for the user.
All that you see is perfectly healthy and normal.
Regards,
Francois
02-15-2007 06:33 AM
Each switch has tables for storing its own local MAC addresses as well as tables for the other MAC addresses in the stack. The master switch keeps tables of all the MAC addresses reported to the stack. The master also creates a map of all the MAC addresses in the entire stack and distributes it to all the subordinates. Each switch becomes aware of every port in the stack. This eliminates repetitive learning processes and creates a much faster and more efficient switching infrastructure for the system. Subordinate switches keep their own spanning trees for each VLAN that they support. The StackWise ring ports will never be put into a Spanning Tree Protocol blocking state. The master switch keeps a copy of all spanning tree tables for each VLAN in the stack. When a new VLAN is added or removed, all the existing switches will receive a notification of this event and update their tables accordingly.
Subordinate switches wait to receive copies of the running configurations from the master and begin to start transmitting data upon receipt of the most current information. This helps ensure that all the switches will use only the most current information and that there is only one network topology used for forwarding decisions.
This URL should help you:
http://www.cisco.com/en/US/products/hw/switches/ps5023/products_white_paper09186a00801b096a.shtml
02-15-2007 09:26 AM
The spanning tree cannot be run independently on each stack member. There has to be some kind of internal messaging between the members so that the stack looks like a single bridge. This inter-member communication could have been implemented in several ways. In the current stacking architecture, members are communicating by sending BPDUs on the stack ports, which are virtual ports representing the connection to a kind of shared segment (a ring in fact) linking all the members together. As a result of this implementation choice, the stack ports are seen by STP (but STP is not really running on them). Note that the stack ports only appear in your show span output because you must have "debug spanning-tree events" configured on your switch. It would be hidden otherwise. The information displayed for the stack ports is to be considered as internal. For instance, stack ports are never blocking, even if in your example STP can show them as "backup blocking". Basically, forget about the output of this command for stack port, they don't have much meaning for the user.
All that you see is perfectly healthy and normal.
Regards,
Francois
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide