cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
802
Views
0
Helpful
2
Replies

RSTP second VLAN convergence

KenArcher
Level 1
Level 1

We have two SG550XG switches configured with RSTP connected to our core switch and convergence time on the native VLAN 1 is within the expected duration. However, a second VLAN 21 on the switch is behaving odd. When the connection to the root is removed we lose one ping, as expected, but when that connection is restored we lose 5-6 ping responses. If the port is set back to native VLAN 1 we lose one ping on the disconnect and one on the reconnect. The issue with VLAN 21 occurs regardless of whether the interface is trunk or access. From what I can tell the packets are dropping during the Listening/Learning phase during re-convergence as opposed to forwarding on the alternate path. Once te1/0/21 (primary uplink) returns to a forwarding state VLAN 21 begins to communicate again. Configuration of the uplink ports below.

2 Replies 2

KenArcher
Level 1
Level 1

MDF-SG550-102#sh span te1/0/21

Port te1/0/21 enabled
State: forwarding Role: root
Port id: 128.21 Port cost: 2000
Type: P2P (configured:Auto ) RSTP Port Fast: No (configured:Auto)
Designated bridge Priority : 8193 Address: b4:14:89:61:b2:80
Designated port id: 128.272 Designated path cost: 0
Guard root: Disabled BPDU guard: Disabled
Number of transitions to forwarding state: 1
BPDU: sent 38, received 4701
MDF-SG550-102#sh span te1/0/22

Port te1/0/22 enabled
State: forwarding Role: designated
Port id: 128.22 Port cost: 2000
Type: P2P (configured:Auto ) RSTP Port Fast: No (configured:Auto)
Designated bridge Priority : 36864 Address: 00:8e:73:ca:41:db
Designated port id: 128.22 Designated path cost: 2000
Guard root: Disabled BPDU guard: Disabled
Number of transitions to forwarding state: 7
BPDU: sent 4712, received 75
MDF-SG550-102#sh run int te1/0/21
interface TengigabitEthernet1/0/21
switchport mode trunk
!
MDF-SG550-102#sh run int te1/0/22
interface TengigabitEthernet1/0/22
switchport mode trunk
!

After some more research I discovered the 6509 is limited to MST and RAPID-PVST, with it being configured for RAPID-PVST. So I believe this may be an interoperability issue when connecting RSTP with RAPID-PVST. My understanding is for PVST normal STP BPDU are sent for VLAN1 and all other VLANs receive PVST BPDU. As a result VLAN1 converges as expected, within 2 seconds, while the other VLANs go thru the listening/learning phases, for a total of 30 seconds. I'm wondering if anyone has found a solution for this issue or would it be better to move to MST, which all our switches support. If we have to move to MST is it possible to migrate from RAPID-PVST to MST within incurring a system outage.