Cisco switches run different types of STP protocol, depending on whether the connected port is access, ISL trunk or 802.1q trunk. Natively, Cisco switch runs a separate STP instance for each configured and active VLAN (this is called Per-VLAN Spanning Tree or PVST) and standard IEEE compliant switches run just one instance of STP shared by all VLANs. Due to that reason, a group of switches running IEEE compatible STP protocol is called MST (Mono Spanning Tree) region, not to be confused with MSTP (multiple spanning tree).

​

Access Ports. Cisco switches run the IEEE version of STP protocol on the access ports. The IEEE STP BPDUs are sent to IEEE reserved multicast MAC address “0180.C200.0000” using IEEE 802.2 LLC SAP encapsulation with both SSAP and DSAP fields equal to “0×42”. (By the way, for the purpose of Layer2 filtering, IEEE BPDUs could be matched using a MAC ACL with LSAP value of ”0×4242”). Note that you can plug any standard IEEE compliant switch into a Cisco switch access port and they will inter-operate perfectly, joining the respective access VLAN’s STP instance with the IEEE STP instance (MST).

​

ISL Trunks. Cisco switches run PVST (Per-VLAN Spanning Tree) on ISL trunk links. The same IEEE STP BPDUs are sent for each VLAN, encapsulated with additional ISL header, which also carries the VLAN number. The magic part is that ISL header has special flag to distinguish frames carrying STP BPDUs and this is how PVST can re-use the regular IEEE BPDUs to simulate multiple spanning trees. Since PVST BPDUs have the same format as IEEE BPDUs (that is IEEE 802.2 LLC SAP) they can be matched using the same SSAP/DSAP values of “0×42” for the purpose of Layer 2 filtering.The group of Cisco switches connected using ISL trunks only is called PVST region.

​

802.1q Trunks. Cisco switches run PVST+ (Per VLAN Spanning Tree Plus) on 802.1q trunks. This is where things are getting a bit complicated. The goal of PVST+ is to interoperate with standard IEEE STP (MST) and allow transparent tunneling of PVST BPDUs across MST region to connect to other Cisco switches across the IEEE region. For further consideration, we’ll call a group of Cisco switches connected using 802.1q trunks as PVST+ region. Note that PVST+ region may connect to a PVST region using an ISL trunk and connect to MST region using a 802.1q trunk. The STP instances in PVST and PVST+ regions maps directly to each other, so no special interoperability solution is required. However, on IEEE side only one STP instance exists, contrary to multiple STP instances of PVST+ region. The first question is: if we want to interoperate with IEEE single tree, which PVST VLAN’s STP instance should be joined with MST? Cisco has chosen VLAN 1 for this purpose. Joined together, instances of Cisco VLAN 1 STP and MST are called “Common Spanning Tree” or CST (naturally, CST spans PVST, PVST+ and MST regions). As for the detailed PVST+ operations on 802.1q port, consider two following cases:

​

Case 1: Cisco switch connects to an IEEE switch using a 802.1q trunk with default native VLAN (VLAN 1)

IEEE side sends IEEE STP BPDUs to the IEEE multicast MAC address. These BPDUs are consumed and processed by VLAN 1 STP instance on Cisco switch (PVST+ region). The Cisco switch simply recognizes untagged IEEE BPDUs as belonging to VLAN 1 STP instance.

​

The PVST+ side (Cisco switch) sends IEEE STP BPDUs corresponding to local VLAN 1 STP to IEEE MAC address as untagged frames across the link. At the same time, special new SSTP (shared spanning tree, synonym to PVST+) BPDUs are being sent to SSTP multicast MAC address “0100.0ccc.cccd” also untagged. These SSTP BPDUs are encapsulated using IEEE 802.2 LLC SNAP header (SSAP=DSAP=”0xAA” and SNAP PID=”0x010B”). These BPDUs carry the same information as the parallel IEEE STP BPDUs for VLAN 1, but have additional fields, notably a special TLV with the source VLAN number. Note that IEEE switches do not interpret the SSTP BPDUs, but simply flood them through the respective VLAN topology. This facilitates BPDU tunneling in case there are other Cisco switches connected to IEEE cloud.

​

As for non-native VLANs (VLANs 2-4095) Cisco switch sends only SSTP BPDUs, tagged with respective VLAN number and destined to the SSTP MAC address. (Please remember that all SSTP BPDUs carry a VLAN number they belong to). The respective VLAN STP instances are “transparently expanded” across the MST region, considering it as a “virtual hub”. (Note that this may have some traffic engineering implications, since to non-CST VLANs the cost of traversing MSTP region equals to the cost of the link used to connect to the first MSTP switch).

​

Now the question is, why would Cisco switch send the same VLAN1 BPDU twice – destined to IEEE and SSTP multicast MAC addresses? Isn’t it supposed for the Cisco switch to join its VLAN 1 STP instance with the MST? The reason for sending additional SSTP BPDUs across VLAN 1 is purely informational, to perform consistency checking. The idea is to inform all other potential Cisco switches attached to MST cloud about our native VLAN. The receiving switch will only use IEEE BPDUs for VLAN 1 (CST) computations and will ignore SSTP BPDUs sent on VLAN 1.

​

For the purpose of layer 2 filtering, remember that you can match SSTP BPDUs using an ethertype value “0x010B”.This works with multilayer switches even though SSTP BPDUs are SNAP encapsulated, and the actual field is not “ethertype” but rather a SNAP Protocol ID.

​

Case 2: Cisco switch connects to IEEE switch using 802.1q trunk with non-default native VLAN (e.g VLAN 100).

IEEE switch sends IEEE STP BPDUs to IEEE multicast MAC address and those BPDUs are processed by VLAN 1 (CST) STP instance in the Cisco switch.

​

PVST+ side (Cisco switch) sends untagged IEEE STP BPDUs corresponding to VLAN 1 (CST) STP to IEEE MAC address across the link. This is done for the purpose of joining the local VLAN 1 instance and the IEEE instance into CST. At the same time, VLAN 1 BPDUs are replicated to SSTP multicast address, tagged with VLAN 1 number (to inform other Cisco switches that VLAN 1 is non-native on our switch). Finally, BPDUs of the native VLAN instance (VLAN 100 in our case) are sent untagged using SSTP encapsulation and destination address. Of course, native VLAN100 BPDUs, (even though they are untagged) carry VLAN number inside a special TLV SSTP header.

​

As in Case 1 for the remaining non-native VLANs (VLANs 2-4095) Cisco switch sends SSTP BPDU only, tagged with respective VLAN tag and destined to the SSTP MAC address. The other Cisco switches connected to the MSTP cloud receive the SSTP BPDUs and process the using the respective VLAN STP instances.

​

Consider the diagram below. SW1 and SW2 are Cisco switches, running STP instances for VLANs 1,2 and 3. Router R3 is converted into bridge (CRB mode and the same bridge-group on E0/0 and E0/1 interfaces, using IEEE STP protocol) to simulate an IEEE compatible switch. VLAN 1 STP instances of SW1 and SW2 are joined with STP instance running in R3. VLANs 2 and 3 consider path across R3 as another segment linking SW1 and SW2 and their SSTP information is passed transparently across R3.