User guide

Open Problem Reports and Feature Exceptions
OmniSwitch 6600/7000/8800—Release 5.1.6.R02 page 63
PR 72119
On an OS7000 series switch, when redundant links are present between two MSTP bridges, the resultant
topology will choose a blocking port regardless of the VLAN port mapping on the links. Therefore, if a
VLAN is configured on one redundant link, but not the other, the bridge may block the port that the
VLAN is configured on.
Workaround: This is a known issue with MSTP and the older flat spanning tree. To send specific VLAN
traffic between switches with redundant links, all the redundant links need to be 802.1q tagged members
of the VLAN. So, one will always be forwarding. See the Users Guide / CLI Guide for more information.
PR 74365
If a port on an OS7000 or OS6600 series switch is connected to another port that is Blocked/Alternate,
then this port might not receive any BPDUs from the Blocked port in order to figure out the 'Next Best
Root' port. So, the show spantree x command for this switch will not show the 'Next Best Root' port.
(Note: This information is provided to be compatible with the XOS products and is not needed to compute
spanning tree topology).
Workaround: Try disconnecting/reconnecting the link so BPDUs may be exchanged through these ports.
PR 76951
The Show Spantree command still displays some values in the 'Path Cost', 'Op Cnx', and 'Designated
Bridge ID' columns for a port when it is down.
Workaround: If the port's 'Operating Status' Column shows DIS (for disabled), just ignore the values for
the rest of the other columns. These values are being displayed to show the past connection history of the
path cost, connection type and Bridge ID etc.
PR 77228
When running scripts using automation tools to configure an OS7000 series switch from the 802.1D proto-
col to 802.1W, the spanning tree seems to be stuck in a blocking state for a certain VLAN in the 802.1W
protocol.
Workaround: Executing commands manually or from the boot.cfg file to switch protocols works OK. In
case this problem occurs, try switching STP modes: bridge mode flat and then bridge mode 1x1 to see if
this problem goes away.
PR 77262
When running scripts using automation tools to configure spanning tree on a stand-alone OS6600 stack,
it's observed that the CPU Utilization could go up to 100% after changing the bridge protocol from 802.1D
to 802.1W. The spanning tree task seems to be stuck in a loop forever causing the CPU utilization to go
up.
Workaround: Manually typing in the commands to switch protocols and configure spanning tree works
OK. In addition, executing the same commands in the boot.cfg file also works OK.