Editing Spanning Tree Protocol (section)

== Standards for VLANs ==
STP and RSTP do not segregate switch ports by VLAN.<ref name="Solomon">{{Cite book|title= Fundamentals of Communications and Networking|author =Michael G. Solomon, David Kim & Jeffrey L. Carrell |publisher= Jones & Bartlett Publishers|year=2014 |isbn= 9781284060157|pages=204}}</ref> However, in [[Ethernet]] switched environments where multiple [[VLAN]]s exist, it is often desirable to create multiple spanning trees so that traffic on different VLANs uses different links.

=== Proprietary standards ===
Before the IEEE published a Spanning Tree Protocol standard for VLANs, a number of vendors who sold VLAN-capable switches developed their own Spanning Tree Protocol versions that were VLAN capable. [[Cisco]] developed, implemented and published the {{anchor|PVST}}'''Per-VLAN Spanning Tree''' ('''PVST''') [[proprietary protocol]] using its own proprietary [[Cisco Inter-Switch Link|Inter-Switch Link]] (ISL) for VLAN [[Encapsulation (networking)|encapsulation]], and PVST+ which uses [[802.1Q]] VLAN encapsulation. Both standards implement a separate spanning tree for every VLAN. Cisco switches now commonly implement PVST+ and can only implement Spanning Trees for VLANs if the other switches in the LAN implement the same VLAN STP protocol. HP provides PVST and PVST+ compatibility in some of its network switches.<ref name="Solomon"/> Some devices from [[Force10 Networks]], [[Alcatel-Lucent]], [[Extreme Networks]], [[Avaya]], [[Brocade Communications Systems]] and [[BLADE Network Technologies]] support PVST+.<ref>{{cite web
|url=https://www.force10networks.com/CSPortal20/TechTips/0050B_HowDoIConfigureSpanningTree.aspx|title=Technical Documentation |publisher=[[Force10]]|access-date=2011-01-25}}</ref><ref>{{cite web |url=http://www.extremenetworks.com/libraries/products/DSExtXOS_1030.pdf |archive-url=https://web.archive.org/web/20061126120914/http://www.extremenetworks.com/libraries/products/DSExtXOS_1030.pdf |archive-date=2006-11-26 |url-status=live|title=ExtremeXOS Operating System, Version 12.5|publisher=[[Extreme Networks]] | year=2010| access-date=2011-01-25}}</ref><ref>{{cite web |url=http://www.bladenetwork.net/userfiles/file/PDFs/WP_PVST_SpanningTree_Cisco.pdf |archive-url=https://web.archive.org/web/20100612021303/http://bladenetwork.net/userfiles/file/PDFs/WP_PVST_SpanningTree_Cisco.pdf |archive-date=2010-06-12 |url-status=live |title=BLADE PVST+ Interoperability with Cisco |year=2006 |access-date=2011-01-25}}</ref> Extreme Networks does so with two limitations: Lack of support on ports where the VLAN is untagged/native, and also on the VLAN with ID 1. PVST+ can tunnel across an MSTP Region.<ref>{{cite web|url=http://www.cisco.com/en/US/docs/ios/12_1t/12_1t3/feature/guide/dtbridge.html#wp1020686 |title=Bridging Between IEEE 802.1Q VLANs |publisher=Cisco Systems|access-date=2011-01-25}}</ref>

The switch vendor [[Juniper Networks]] in turn developed and implemented its VLAN Spanning Tree Protocol (VSTP) to provide compatibility with Cisco's PVST, so that the switches from both vendors can be included in one LAN.<ref name="Solomon"/> The VSTP protocol is only supported by the EX and MX Series from Juniper Networks. There are two restrictions to the compatibility of VSTP:
#VSTP supports only 253 different spanning-tree topologies. If there are more than 253 VLANs, it is recommended to configure RSTP in addition to VSTP, and VLANs beyond 253 will be handled by RSTP.
#[[MVRP]] does not support VSTP. If this protocol is in use, VLAN membership for trunk interfaces must be statically configured.<ref>{{cite web |url=http://www.juniper.net/techpubs/en_US/junos10.0/topics/concept/bridging-mvrp-ex-series.html |title=Juniper Networks :: Technical Documentation :: Understanding Multiple VLAN Registration Protocol (MVRP) on EX Series Switches |website=www.juniper.net |url-status=dead |archive-url=https://web.archive.org/web/20120407024355/http://www.juniper.net/techpubs/en_US/junos10.0/topics/concept/bridging-mvrp-ex-series.html |archive-date=2012-04-07}}</ref>

By default, VSTP uses the RSTP protocol as its core spanning-tree protocol, but usage of STP can be forced if the network includes old bridges.<ref>{{Cite web|url=https://www.juniper.net/techpubs/en_US/junos9.4/topics/concept/spanning-trees-ex-series-vstp-understanding.html|title=Juniper Networks :: Technical Documentation :: Understanding VSTP for EX-series Switches}}</ref> More information about configuring VSTP on Juniper Networks switches was published in the official documentation.<ref>[https://www.juniper.net/techpubs/en_US/junos14.1/topics/concept/spanning-trees-ex-series-vstp-understanding.html Understanding VSTP]</ref>

Cisco also published a proprietary version of Rapid Spanning Tree Protocol. It creates a spanning tree for each VLAN, just like PVST. Cisco refers to this as {{anchor|RPVST}}'''Rapid Per-VLAN Spanning Tree''' ('''RPVST''').

=== Multiple Spanning Tree Protocol ===
{{Main|Multiple Spanning Tree Protocol}}

The Multiple Spanning Tree Protocol (MSTP), originally defined in [[IEEE 802.1s]]-2002 and later merged into [[IEEE 802.1Q]]-2005, defines an extension to RSTP to further develop the usefulness of VLANs.

In the standard, a spanning tree that maps one or more VLANs is called a ''multiple spanning tree'' (MST). Under MSTP, a spanning tree can be defined for individual VLANs or for groups of VLANs. Furthermore, the administrator can define alternate paths within a spanning tree. Switches are first assigned to an MST region, then VLANs are mapped against or assigned to this MST. A ''common spanning tree'' (CST) is an MST to which several VLANs are mapped, this group of VLANs is called ''MST instance'' (MSTI). CSTs are backward compatible with the STP and RSTP standard. A MST that has only one VLAN assigned to it is an ''internal spanning tree'' (IST).<ref name="Solomon"/>

Unlike some proprietary per-VLAN spanning tree implementations,<ref>{{cite web|url = https://www.cisco.com/en/US/prod/collateral/netmgtsw/ps6504/ps6528/ps2425/white_paper_c07-552114.html#wp9003215 |title = CiscoWorks LAN Management Solution 3.2 Deployment Guide |access-date = 2010-01-25 |date = August 2009}}</ref> MSTP includes all of its spanning tree information in a single BPDU format. Not only does this reduce the number of BPDUs required to communicate spanning tree information for each VLAN, but it also ensures backward compatibility with RSTP and, in effect, classic STP too. MSTP does this by encoding an additional region of information after the standard RSTP BPDU as well as a number of MSTI messages (from 0 to 64 instances, although in practice many bridges support fewer). Each of these MSTI configuration messages conveys the spanning tree information for each instance. Each instance can be assigned a number of configured VLANs and frames assigned to these VLANs operate in this spanning tree instance whenever they are inside the MST region. In order to avoid conveying their entire VLAN to spanning tree mapping in each BPDU, bridges encode an MD5 digest of their VLAN to instance table in the MSTP BPDU. This digest is then used by other MSTP bridges, along with other administratively configured values, to determine if the neighboring bridge is in the same MST region as itself.

MSTP is fully compatible with RSTP bridges in that an MSTP BPDU can be interpreted by an RSTP bridge as an RSTP BPDU. This not only allows compatibility with RSTP bridges without configuration changes but also causes any RSTP bridges outside of an MSTP region to see the region as a single RSTP bridge regardless of the number of MSTP bridges inside the region itself. In order to further facilitate this view of an MSTP region as a single RSTP bridge, the MSTP protocol uses a variable known as remaining hops as a time to live counter instead of the message age timer used by RSTP. The message age time is only incremented once when spanning-tree information enters an MST region, and therefore RSTP bridges will see a region as only one ''hop'' in the spanning tree. Ports at the edge of an MSTP region connected to either an RSTP or STP bridge or an endpoint are known as boundary ports. As in RSTP, these ports can be configured as edge ports to facilitate rapid changes to the forwarding state when connected to endpoints.