Cisco and Force10 – STP Spanning Tree Interoperability

.

Cisco Implements a proprietary flavor of spanning tree protocol, which is Per-VLAN in nature. This gives rise to certain considerations in a multi-vendor environment. Any third party switches that implement STP based on the IEEE standard, have a spanning tree implementation that has a single instance span the entire switch, regardless of the number of VLANs in place. Connecting such switches to a Cisco environment may result in broken STP topologies with multiple root bridges, if inter-operability is not ensured before hand. However, some vendors (Extreme Networks, Force10, Brocade and Juniper’s VSTP) do have switches/implementations that interact with Cisco STP MC Address to ensure inter-operability.

On Force10 switches, the following options can assist with ensuring inter-operability.

• Force10 switches are Per-VLAN spanning tree capable, which is compatible with the Cisco PVST method. The current STP method implemented on Cisco Switches is PVST+, which has an equal in the PVST+ method available on force10. Thus, the command

Config)# protocol spanning-tree pvst

Config-protocol PVST)# no disable

will ensure compatibility between the F10 & Cisco switch fabrics. However, the following should be taken into account.

Force10’s PVST implementation is based on IEEE’s STP (802.1D), and the costs used are that of IEEE .1s (MST). If you have a hybrid port on the other end participating in PVST+, it may transmit two kinds of BPDUs: an 802.1D BPDU and an untagged PVST+ BPDU. The PVST+ BPDU is sent to perform consistency checking and to inform the other Cisco switches about the native VLAN configuration.

F10 switches do not expect PVST+ BPDU (tagged or untagged) on an untagged port. If this happens, FTOS places the port in error-disable state. To prevent this behavior, use the command “no spanning-tree pvst err-disable cause invalid-pvst-bpdu“. After you configure this command, if the port receives a PVST+ BPDU, the BPDU is dropped, and the port remains operational.

• The other option available in multi-vendor environments including Cisco switches is to make use of VLAN 1 to bridge the two environments.

Cisco implementation of spanning tree is such that while on all non-default VLANs (other than VLAN 1), Cisco switches multicast STP frames only on Cisco STP MC MAC Address; on VLAN 1, the switches address the frames to the IEEE MC MAC address. In order to interoperate with a IEEE compliant bridge, a Cisco switch running its proprietary PVST+ protocol must interact with the mono/Common Spanning Tree instance of the IEEE compliant STP bridge. Whereas PVST+ executes an STP instance for each VLAN, including VLAN 1, CST assumes only one spanning-tree instance for the entire bridged network, regardless of the number of VLANs configured. The CST instance can be imagined as the logical topology that results from STP convergence of VLAN 1.

Ergo, for a Cisco bridge running PVST+ to be able to converge with a third party bridge running 802.1w RSTP, VLAN 1 must be allowed on all 802.1Q trunks that interconnect them.

But consider now for a moment, what would happen if the native VLAN is changed from VLAN 1 to some other number on the dot1q interface of the Cisco switch. On a Cisco IOS switch, it is ONLY VLAN 1 that is sympathetic to the requirements of the IEEE standard. No other VLAN, including a renumbered native VLAN, will transmit BPDUs on the open standard MAC address.

Thus, it is only on VLAN 1 that a Cisco switch will transmit STP BPDUs on the IEEE MAC (0180.c200.0000) to create that CST, and consequently, It is only on VLAN 1 that an IEEE STP bridge can converge with PVST+ on a Cisco Catalyst switch. Therefore, do not block VLAN 1 on a dot1q interface that is connected to an IEEE bridge. If the native VLAN ID is changed from 1 to another number, ensure that VLAN 1 is allowed on the trunk to allow the IEEE bridge to converge with a Cisco PVST+ bridge on the CST.

Regardless of the existence of other VLANs, from an STP perspective, the IEEE compliant bridge interacts only with VLAN 1, and therefore only one logical STP topology exists. This workaround ensures an STP topology that spans the network, but it does not accommodate the per VLAN mapping of STP, as only on VLAN 1 is the STP topology built and shared between the rival switches. The downside to this approach is that it explicitly requires VLAN 1 to be enabled. This can be a serious issue in itself. The primary reasons are:

a)       In default VLAN 1, the switch behaves as a generic IP host, responding to all broadcasts and multicasts. Thus, in case of a loop/storm/issue, the switch CPU takes a direct hit, software based layer 3 lookups increase exponentially, and switch management becomes inaccessible. It is never good practice to utilize this VLAN in very large networks.

b)      Default VLAN 1 has also been observed to experience issues with generous MTU sizes.

Since Force10 switches allow STP interoperability via PVST mode, this is definitely the recommended choice. For configuring the STP and VLAN related parameters on Force10 switches, you can refer to the following post: https://hasanmansur.com/2012/10/29/force10-layer-2-parameters-configuration-vlans-stp/

.