http://www.alliedtelesis.com/userfiles/file/howto_aw-_config_pvst_interop_cisco_REVB.pdf
https://cciethebeginning.wordpress.com/2008/10/15/differences-between-pvst-and-pvst/
debug spanning-tree bpduHuawei S Series Switches, Interoperation with Cisco PVST+
http://www.asipartner.com/LinkClick.aspx?fileticket=8SZnL6L9PYc%3D&tabid=1341
On a trunk port, PVST+ sends standard:
- STP BPDUs with the destination MAC address of 01-80-C2-00-00-00 only in VLAN 1,
- and sends Cisco proprietary BPDUs with the destination MAC address of 01-00-0C-CC-CC-CD in other VLANs allowed by the trunk port.
Huawei switches transparently transmit Cisco proprietary BPDUs as common multicast frames.
From the STP point of view, IEEE 802.1D is not VLAN-aware and IEEE 802.1Q is VLAN-aware, but it uses a single STP instance for all VLANs. That is, if the port is blocking then it is blocking for all VLANs on that port. The same is true for forwarding.
This list shows how PVST+ interoperates with IEEE 802.1Q or IEEE 802.1D, if the Native VLAN on an IEEE 802.1Q trunk is VLAN 1:
VLAN 1 STP BPDUs are sent to the IEEE STP MAC address (0180.c200.0000), untagged.
VLAN 1 STP BPDUs are also sent to the PVST+ MAC address, untagged.
Non-VLAN 1 STP BPDUs are sent to the PVST+ MAC address (also called the Shared Spanning Tree Protocol [SSTP] MAC address, 0100.0ccc.cccd), tagged with a corresponding IEEE 802.1Q VLAN tag.
If the Native VLAN on an IEEE 802.1Q trunk is not VLAN 1:
VLAN 1 STP BPDUs are sent to the PVST+ MAC address, tagged with a corresponding IEEE 802.1Q VLAN tag.
VLAN 1 STP BPDUs are also sent to the IEEE STP MAC address on the Native VLAN of the IEEE 802.1Q trunk, untagged.
Non-VLAN 1 STP BPDUs are sent to the PVST+ MAC address, tagged with a corresponding IEEE 802.1Q VLAN tag.
Note: Native VLAN STP BPDUs are sent untagged.
PVST+ Explained
http://blog.ine.com/2008/07/17/pvst-explained/
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 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.
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.
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.
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.
Theory Behind PVID- and Type-Inconsistencies
http://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/24063-pvid-inconsistency-24063.html
Differences between PVST and PVST+
from: https://cciethebeginning.wordpress.com/2008/10/15/differences-between-pvst-and-pvst/
Behind the simple “plus” in PVST+ lurk quite subtle details that can make the difference between the two concepts very fuzzy, so the goal of this post is to give you a very brief explanation and I hope enough simple to grasp about PVST and PVST+ and their relationship with the standard IEEE 802.1q:
- Make sure the native VLAN in PVST+ regions, communicating together through IEEE 802.1q, is the same.
- Whatever the complexity of the IEEE 802.1q network, only costs at the borders with PVST+ regions counts for PVST+-IEEE 802.1q native VLAN (VLAN 1 by default) cooperate with PVST, PVST+ and MSTI (802.1s).
- PVST (ISL) instances are mapped one-to-one with PVST+ (802.1q) instances.
IEEE 802.1q standard
BPDU transported over native VLAN untagged (cannot differentiate between different VLANs), therefore support natively only one single instance of STP for all VLAN, MST (Mono Spanning Tree).
(-) Not interoperable and less flexible approach.
PVST (Per VLAN Spanning Tree) Cisco proprietary
(+) Improve the limitation of 802.1d STP (created before VLAN) by supporting one separate instance for each VLAN, using ISL trunk only.
(-) Still not interoperable with IEEE 802.1q that supports only one STP instance.
PVST+ Cisco proprietary
(+) Modification of PVST: allow PVST over standard IEEE 802.1q:
1) PVST+ native VLAN BPDUs are transported (merged) in IEEE native VLAN (CST) untagged using IEEE STP MAC 0180.0CCC.CCCD 01-80-C2-00-00-00
2) In addition to that, PVST+ native VLAN is send a second time tunneled over IEEE 802.1q using special multicast MAC 0100.0CCC.CCCD (Shared spanning Tree, SSTP):
--- Untagged, if PVST+ native VLAN=VLAN 1. (figure1)
--- Tagged (coded with TLV, containing VLAN ID), if native VLAN other than VLAN 1. (figure2)
This is used exclusively for consistency check. Besides, the error “PVID-inconsistency” is generated if PVST+ BPDU is received on a VLAN different from the one it was generated from.
3) Non-native VLAN BPDUs always tunneled over IEEE 802.1q using special multicast MAC 0100.0CCC.CCCD (Shared spanning Tree, SSTP), tagged (coded with TLV, containing VLAN ID)
STP "tunnels"
 |
| PVST+ native VLAN is VLAN 1 |
 |
| PVST+ native VLAN is different from VLAN 1 |
Here is what to retain :
802.1q (standard) supports only one single instance of STP
- native VLAN (Common Spanning Tree) – (let’s say channel 1)
- one STP instance – (let’s say channel 2)
- Support one STP instance per each VLAN
- uses ISL trunk only.
- Doesn’t support 802.1q
- native VLAN over “Common Spanning Tree” (over channel 1)
- Each per-VLAN STP is encapsulated using a special Multicast MAC and transported (over channel 2)
“For a long time, IEEE believed there should be one common spanning tree (CST) and obviously Cisco had come out with ISL trunking and PVST allowing for multiple instances.https://learningnetwork.cisco.com/thread/26558
When the 802.1Q standard was derived, they mandated a single spanning tree, which if you followed the spec would **** the operation of PVST. So Cisco “improvised” by merely changing the destination address to a different L2 multicast address.
The good thing about that is that in case you had a mixed environment, now any non-Cisco switch receiving a PVST+ BPDU would simply flood it out all available ports for that vlan instead of killing it if it were using the original IEEE multicast address and not in the native vlan.
Sometimes the history of “why” makes it easier to remember the details of “how”. So PVST doesn’t “not support” 802.1Q, it’s the 802.1Q won’t support PVST.”
Scott