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:

IEEE 802.1q standard

PVST (Per VLAN Spanning Tree) Cisco proprietary

PVST+ Cisco proprietary

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.

(+) 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.

(+) 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):

  1. Untagged, if PVST+ native VLAN=VLAN 1. (figure1)
  2. 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)

– 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.

Figure 1: PVST+ native VLAN is VLAN 1

Figure 2: 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)

PVST (Cisco proprietary)

  • Support one STP instance per each VLAN
  • uses ISL trunk only.
  • Doesn’t support 802.1q

PVST+ (Cisco proprietary) Enhance PVST capabilities by allowing to transport PVST over 802.q :

  • 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)

… and little of history from Scott Morris :

“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.

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

About ajnouri
Se vi deziras sekure komuniki eksterbloge, jen mia publika (GPG) ŝlosilo: My public key for secure communication: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x41CCDE1511DF0EB8

14 Responses to Differences between PVST and PVST+

  1. Josh Rogers says:

    Excellent article, thanks.

  2. Pavel Devecka says:

    Extract from article:
    PVST+ native VLAN BPDUs are transported (merged) in IEEE native VLAN (CST) untagged using IEEE STP MAC 0180.0CCC.CCCD.

    My comment:
    Shouldn’t there be 0180.C200.0000 instead?

    • cciethebeginning says:

      You are absolutely right Pavel,

      The BPDUs on the native VLAN of the trunk are sent 1st time to the reserved IEEE 802.1D spanning tree multicast MAC address (01-80-C2-00-00-00) and a second time to the reserved SSTP multicast MAC address (01-00-0c-cc-cc-cd).

      I fixed it in the post, thank you for the correction.

  3. Pavel Devecka says:

    Again some comments from me. 🙂

    From article:
    1. Untagged, if PVST+ native VLAN=VLAN 1. (figure1)
    2. Tagged (coded with TLV, containing VLAN ID), if native VLAN other than VLAN 1. (figure2)

    My comment:
    According to my research in books and on the Internet, native VLAN should be always untagged in this case, which is also logical. According to point 2, if native VLAN wouldn’t be VLAN 1, then VLAN ID would be carried in 802.1q and also in TLV for all VLANs. That would mean, that receiving switch wouldn’t have any way how to figure out which VLAN is the native one on the other side of trunk. But if native VLAN would be always untagged, then receiving switch would be able to check what is the VLAN ID in TLV field of frame received without 802.1q tag and it would know, which VLAN is the native one.

    From article:
    1) – PVST+ native VLAN BPDUs are transported (merged) in IEEE native VLAN (CST)

    My comment:
    I could spot information, that it’s always VLAN 1, which is mapped to the CST.

  4. Tom Kacprzynski says:

    Really good article…thanks for writing it.

  5. Pingback: Spanning Tree Protocol | Route Reflector

  6. UmA says:

    will pvst support bpdu TCN notification ?

  7. Pingback: Switching – Spanning-Tree | Från CCNA till certifierad CCIE

  8. Gang MA says:

    figures are great!

  9. PIYUSH says:

    little confusion on Tagged and Untagged frame.If vlan 1 received untagged information and it send to other switch so that time it’s tagged and forward to next switch.So how you can say that frame was untagged.

  10. Ney A. Mendez says:

    it was great.

  11. Euris says:

    Thanks for the explanation, I´m wondering how could vlan dot1q tag native influence the BPDUs being transfered in both scenarios (native VLAN = 1 and native VLAN being another number)… : )

Leave a reply to junaid Cancel reply