Hello everybody,
I am having an issue with MST in a very, very simple setup, shown in this picture:
sw1 is a stack of 2 3750 running 12.2(53)SE1, sw2 is a 2960 running 12.2(53)SE1 as well. spanning tree is mstp with one instance, and sw1 is the root. The ports are dot1q trunks, with only one vlan allowed.
On gi0/48 of sw2 we configured an higher stp path-cost, and in fact it is in "Altn BLK" state. When I shut gi1/0/1 on sw1, gi0/48 becomes root port and traffic goes on the other link without any problem and no noticeable delay.
The problem is that when I "no shut" gi1/0/1 on sw1, I can no more ping sw2 (i am using a PC attached to sw1 of course).
When, after restoring gi1/0/1, there is no connectivity to sw2, if I search the MAC address of sw2 in sw1, it still shows it on gi2/0/1. Since at this time the first link is up and gi0/48 of sw2 is again "Altn BLK" packets go nowhere. Doing a "clear mac address-table dynamic address <mac of sw2>" immediately restores connectivity. After 5 minutes the MAC timeouts from the fdb and connectivity is restored anyway.
It is my understanding that the topology change (TC) mechanism should cure this problem automatically, with the "fast aging" of the FDB, but sw1 sees no TC when the primary link is restored, "sh span det" shows that:
- when i "shut" gi1/0/1, both switches see a TC (counter increment), sw1 "from Gi2/0/1" with "Topology change flag set, detected flag not set", and sw2 "from Gi0/48" (whatever this "from" means, is it the transitioned port or the port where the TC BPDU was received?) with "Topology change flag set, detected flag not set"
- when I "no shut" gi1/0/1, sw1 sees no TC, sw2 sees a TC "from Gi0/47", with "Topology change flag set, detected flag not set"
It seems to me that sw1 is not generating a TC when it should, and/or it is not seeing the TC generated by sw2. I am not exactly sure about what should happen in this situation, but I bet sw1 should somehow fast age.
Configuration is straightforward mst with only one instance, same configuration name and revision on both switches, ports are not boundary. I think the upper two switches are not related to what's happening. Here are some details of sw1 and sw2, for those of you with great patience:
sw1# sh conf | b spanning-tree
spanning-tree mode mst
spanning-tree etherchannel guard misconfig
spanning-tree extend system-id
!
spanning-tree mst configuration
name singola
!
spanning-tree mst hello-time 1
spanning-tree mst max-hops 30
spanning-tree mst 0 priority 4096
!
...
sw1# sh span det
MST0 is executing the mstp compatible Spanning Tree protocol
Bridge Identifier has priority 4096, sysid 0, address (sw1).d000
Configured hello time 1, 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 25 last change occurred 00:35:12 ago
from GigabitEthernet2/0/1
Times: hold 1, topology change 35, notification 1
hello 1, max age 20, forward delay 15
Timers: hello 0, topology change 0, notification 0
Port 55 (GigabitEthernet2/0/1) of MST0 is designated forwarding
Port path cost 20000, Port priority 128, Port Identifier 128.55.
Designated root has priority 4096, address (sw1).d000
Designated bridge has priority 4096, address (sw1).d000
Designated port id is 128.55, designated path cost 0
Timers: message age 0, forward delay 0, hold 0
Number of transitions to forwarding state: 1
Link type is point-to-point by default, Internal
BPDU: sent 76629, received 38
Port 1 (GigabitEthernet1/0/1) of MST0 is designated forwarding
Port path cost 20000, Port priority 128, Port Identifier 128.1.
Designated root has priority 4096, address (sw1).d000
Designated bridge has priority 4096, address (sw1).d000
Designated port id is 128.1, designated path cost 0
Timers: message age 0, forward delay 0, hold 0
Number of transitions to forwarding state: 1
Link type is point-to-point by default, Internal
BPDU: sent 1396, received 4
sw1# sh switch
Switch/Stack Mac Address : (switch 2 of sw1).d000
H/W Current
Switch# Role Mac Address Priority Version State
----------------------------------------------------------
1 Member (switch 1 of sw1).7680 1 0 Ready
*2 Master (switch 2 of sw1).d000 1 0 Ready
sw2# sh conf | b spanning
spanning-tree mode mst
spanning-tree etherchannel guard misconfig
spanning-tree extend system-id
!
spanning-tree mst configuration
name singola
sw2# sh span det
MST0 is executing the mstp compatible Spanning Tree protocol
Bridge Identifier has priority 32768, sysid 0, address (sw2).4700
Configured hello time 2, max age 20, forward delay 15, transmit hold-count 6
Current root has priority 4096, address (sw1).d000
Root port is 47 (GigabitEthernet0/47), cost of root path is 0
Topology change flag not set, detected flag not set
Number of topology changes 24 last change occurred 00:25:19 ago
from GigabitEthernet0/47
Times: hold 1, topology change 35, notification 1
hello 1, max age 20, forward delay 15
Timers: hello 0, topology change 0, notification 0
Port 47 (GigabitEthernet0/47) of MST0 is root forwarding
Port path cost 20000, Port priority 128, Port Identifier 128.47.
Designated root has priority 4096, address (sw1).d000
Designated bridge has priority 4096, address (sw1).d000
Designated port id is 128.1, designated path cost 0
Timers: message age 2, forward delay 0, hold 0
Number of transitions to forwarding state: 1
Link type is point-to-point, Internal
BPDU: sent 5, received 1511
Port 48 (GigabitEthernet0/48) of MST0 is alternate blocking
Port path cost 100000, Port priority 128, Port Identifier 128.48.
Designated root has priority 4096, address (sw1).d000
Designated bridge has priority 4096, address (sw1).d000
Designated port id is 128.55, designated path cost 0
Timers: message age 2, forward delay 0, hold 0
Number of transitions to forwarding state: 10
Link type is point-to-point, Internal
BPDU: sent 32, received 63824
The problem is there also when switch 1 of sw1 is the master of the stack. A workaround is to enable logging from sw2 to something attached to sw1, so sw1 immediately learns the correct FDB entry for sw2, but I'm worried that I could have problems with servers attached to sw2.
During this troubleshooting I discovered something funny: if you set "deb spanning-tree events", then "sh span det" shows also stackport2. These ports are not usually shown, and you cannot show them by name, but they often appear as "from" of the TCs. A cisco doc on stacking says that these ports are never blocking, but I see:
Port 873 (StackPort2) of MST0 is backup blocking
Port path cost 20000, Port priority 128, Port Identifier 128.873.
Designated root has priority 4096, address (omissis).d000
Designated bridge has priority 4096, address (omissis).d000
Designated port id is 128.872, designated path cost 0
Timers: message age 2, forward delay 0, hold 0
Number of transitions to forwarding state: 0
Link type is point-to-point, Internal
BPDU: sent 34, received 80525
I googled and searched the bug toolkit but found nothing. Lots of people have problems with too many TCs, I appear to be the only one needing more TCs. Your help will be very much appreciated.
Regards,
Bergonz
