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/
Thanks for this, I needed it!
This is was really useful for me, thank you!
This was very helpful, but I wonder about how VLT fits into this on the Force10 side which requires RSTP and won’t work with PVST, does that mean I have to do the VLAN 1 trick, or is there possibly a better option?
Apologies for the delay in my reply, i have been away/travelling for some time.
regarding your question, i am infact in the middle of a deployment where i have force10 S4810 Cores running VLT, with VRRP and RSTP. As par Force10’s own documentation, if interaction with Cisco based bridges were needed, then VLAN 1 would be the only choice in such a setup. open and allowed on both ends over the trunk.
the result should be simple enough to validate. the show span at either end should show the root being learnt over the relevant port, with the right MAC address as the root.
thanks for your comment, all the best!!
It had been long enough that I found the Force10 interop guide and went ahead and tried it. Everything is working well. Thanks for the article and reply. It is nice to have some real Force10 implementation guides and postings out there.
Very concise and informative document.