White Paper Issue: October 2006 Integration of BX600 SB9 Switches in Cisco Networks Page 14 / 47
Figure 6 : Combining RAPID-PVST and 802.1w after failure of Po1
Figure 6 shows this scenario. When server 1 now wants to send data to server 2, switch B will send it to switch A via Po3 (as
indicated by the MAC address table), which has no connection to the SB9 and will drop the packet. This will not change until
either the MAC address table entry times out (after ~300 seconds) or the server SB9 sends a packet that has been seen by
switch B, whichever happens first.
This scenario shows that RSTP and RAPID-PVST are not compatible in this respect. A worst-case failover time of 300 sec will
not be acceptable.
Running RAPID-PVST on VLAN Trunks while disabling STP at the SB9
When RAPID-PVST is running at the Cisco switches and STP is disabled at the SB9 we have almost the same scenario as
above, where the Cisco switches were running STP and STP was disabled at the SB9. Figure 7 shows this scenario.
SB9
STP disabled
Cisco A
priority 0 for all vlans
Po1
Po1
Po2
Po2
Po3 Po3
On all trunks:
VLAN 1 native
VLAN 10 tagged
VLAN 20 tagged
Cisco B
priority 4096 for all vlans
Alternate
discarding
Root port
forwarding
Designated port
forwarding
Designated port
forwarding
Figure 7 : RAPID-PVST while STP is disabled at SB9
When the Po1 link fails, the Po2 of switch B will stop receiving BPDUs. After three times the “hello” interval, the switch will
change the state of port Po2 to “learning” and will then follow the normal state machine so that the convergence time is the
same as with 802.1D.
Since the RSTP cannot operate with the proposal/agreement mechanism on this link, root changes will also be relatively slow
within all the VLANs that are running on the trunks to the SB9.