PVST+ BPDU on access interface and native vlan and VLAN tag in BPDU TLV

[fly]

does pvst+ BPDU inculde VLAN tag(IN TLV)  on access interface or native vlan

thank you!

[fsebera]

Hey Fly

:

Depends on which trunking protocol you are using.

:

ISL or 802.1Q

:

ISL attaches a VLAN ID header on all frames

802.1q inserts a VLAN ID inside all non-native frames

:

HTH

Frank

[fly]

Hi Frank,

    Thank you for quick answer.

    but my question is not only about 802.1q tag on trunk interface.

   I mean vlan tag inside BPDU frame.

   I know for PVST+,  non native vlan. cisco will inject a vlan tag inside BPDU TLV. when BPDU passthrough 802.1Q trunk interface. this BPDU will be encapsulated with a vlan tag.   if  Received switch find 802.1Q trunk vlan tag is not same as vlan tag in BPDU TLV,  receive swtich will report inconsistent  status and block related VLAN.

  my questions are:

  switchA(native vlan10)---(native vlan 10)SwitchB,

If BPDU create on native vlan 10 on switchB, does PVST+ inject VLAN tag in BPDU TLV filed?

  switchA(native vlan 1)------(native vlan20)SwtichB----802.1Qtrunk-----switchC(vlan20),

IF vlan 20 BPDU create on switchC, switchC PVST+ will inject vlan tag20 in BPDU TLV,  when this BPDU passthrough switchB, go out switchB to switchA, switchA config native vlan 20 on port to switchA, does switchB remove BPDU vlan tag from TLV field.   if doesn't switchA receive this BPDU, will orignal a inconsistent warning .because native vlan on switchA port is VLAN 1.

    i don't have time to test this.  SwitchB may be a third vendor switch.

Am I right?

  thank you!

Fly

[krahmani323]

Hi Fly,

About you first question and from the information in

http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a00801d11a0.shtml#topic1

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.

And regarding the second one, from the same link

http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a00801d11a0.shtml#topic2

If native vlans are not the same on each end of the trunks, a PVID-inconsistent state will be created.

Note that third party switches do not understand the Cisco PVST+ mac address (0100.0ccc.cccd) as spanning-tree realted, thus forwarding them just like normal multicast traffic 

Regards.

Karim

[Peter Paluch]

Hello Fly,

To answer your original question, on access ports, only standard STP or RSTP BPDUs are sent. There is no PVST+ or RPVST+ running on access ports, and therefore, the BPDUs do not contain the originating VLAN TLV. This TLV is placed only into PVST+ or RPVST+ BPDUs sent and received across trunk ports.

Best regards,

Peter

[Alexey Stytsenko]

Hello, Peter.

Maybe you (or smb else) can aswell clarify for me - which vlan MSTP uses to send its BPDU? Have no free switches to make lab and check

But as i suppose:

• Inside single region it sends BPDU to IEEE STP MAC address utagged (despite is vlan 1 native or not)
• On boundary ports connected to IEEE switch same way - untagged
• On boundaty port connected to PVST+/RPVST+ switch untagged on native vlan and replice to all other vlan with respective tags assigned

And if regarding third paragraph i am rather sure - this behaviour well known and described in many articles, but for first two i have doubts, cos i think it may be that MSTP use vlan 1 and send untagged frames if vlan 1 native and tagged with vlan 1 if other vlan choosed as native.

Both theory have rights to life (at least its seems to me so) but i want to know exactly

[Peter Paluch]

Hello Alexey,

You are correct all three accounts. MSTP BPDUs are sent untagged, regardless of the native VLAN, on internal ports and on boundary ports towards other regions or towards pure IEEE switches.

On boundary ports towards a (R)PVST+ region, the switch takes the VLAN1 BPDU and replicates it into (R)PVST+ BPDUs for each existing VLAN, tagged with the appropriate VLAN tag except the VLAN that is defined as native on that boundary port - that (R)PVST+ BPDU is sent untagged.

Best regards,

Peter

[Alexey Stytsenko]

Tnx for answer Peter!  I highly appreciate your responces

Maybe you can help me with few following assumptions too (confirm or make corrections):

1)  When MSTP Region1 conected with CST to MSTP Region2 them exchaneges  IEEE BPDU (version = 3) with no MSTI information attached - only IST  information included.

2) When MSTP Region1 conected with CST  to PVST+ switch them exchaneges IEEE (version = 0) BPDU replicated on  each vlan  with no MSTI information  and no IST information - whole  region presented as 1 switch

3) When MSTP Region1 conected  with CST to RPVST+ switch them exchaneges  IEEE BPDU (version = 2)  replicated on each vlan  with no MSTI information  and no IST  information - whole region presented as 1 switch

And  I must confess that Im not sure about BPDU types used by STP, MSTP,  PVST+  - it seems to me logical that all of them use same BPDU  format  (PVST+ use also SSTP BPDU but here i dont take it in to consideration)  but with different version numbers and differently treat flags fields,  but from other point -  MSTP bpdu have so much additional fields that it  seems to be other BPDU format. I tried to read http://www.ieee802.org/1/files/public/docs2009/aq-seaman-merged-bpdu-encoding-0509.pdf quote from there:

The format of MST BPDUs is compatible with that specified
for RST BPDUs, with the addition of fields to convey 
information for the IST and each MSTI

From  here i can make assumption that in 1st my question - MSTP BPDU used not  IEEE, and in 3rd question MSTP BPDU (version=3) and maybe even contain  IST information included.

So things a bit messed up in my head

Few  switches will help me a lot in finding answers, but i will get them  from warehouse only in two - three weeks, so this post will at least  serve as mention

[Peter Paluch]

Hello Alexey,

1)  When MSTP Region1 conected with CST to MSTP Region2 them exchaneges   IEEE BPDU (version = 3) with no MSTI information attached - only IST   information included.

I am not 100% sure here, but if I remember correctly, the switches will still send fully populated MST BPDUs including MSTI records to each other, however, only the CST information will be processed from these BPDUs, and the data in the MSTI records will be ignored.

2) When MSTP Region1 conected with CST  to PVST+ switch them exchaneges  IEEE (version = 0) BPDU replicated on  each vlan  with no MSTI  information  and no IST information - whole  region presented as 1  switch

Basically correct, although I would not say that the MSTP Region1 is connected to PVST+ switch with CST, rather, it is running PVST+ on the boundary port. The MSTP switch takes the IST ( = MSTI0 ) data and replicates it into PVST+ BPDUs sent out for each existent VLAN allowed on that trunk. This way, the entire MST region behaves as a single PVST+ switch identically configured for all VLANs. Certainly, PVST+ BPDUs have no MSTI records.

3) When MSTP Region1 conected  with CST to RPVST+ switch them  exchaneges  IEEE BPDU (version = 2)  replicated on each vlan  with no  MSTI information  and no IST  information - whole region presented as 1  switch

The situation here is absolutely identical to the previous point. In addition, it has been my observation that in case of interconnecting the MST and RPVST+ region using trunk links, the MST reverts to PVST+ and not to RPVST+ operation. I was once told that Cisco engineers at the time allegedly considered running RPVST+ Simulation to be too complex (because of the added state related to Proposal/Agreement to keep on per-VLAN basis) and not worthy of implementation. So while in this case the MST region should correctly revert to RPVST+ on its boundary port, in reality, it reverts to PVST+.

And  I must confess that Im not sure about BPDU types used by STP,  MSTP,  PVST+  - it seems to me logical that all of them use same BPDU   format  (PVST+ use also SSTP BPDU but here i dont take it in to  consideration)  but with different version numbers and differently treat  flags fields

STP and PVST+ use exactly the same BPDU format, with these exceptions:

• STP BPDUs are encapsulated into 802.2 LLC frames, and are always untagged. PVST+ BPDUs are encapsulated in 802 SNAP frames and are tagged according to their VLANs
• PVST+ BPDUs contain a special TLV record at their very end that describes the VLAN where the BPDU was originated. If, thanks to a native VLAN mismatch on a trunk, a PVST+ BPDU leaks from one VLAN to another, this TLV will still hold the original VLAN where the BPDU was originated. This allows for PVID inconsistency checks

RSTP and RPVST+ BPDUs differ in exactly the same ways, i.e. their format is absolutely identical, just the encapsulation is different and the RPVST+ BPDU contains the originating VLAN TLV.

MST BPDUs are different because their format is an extension of the RSTP BPDU format - it has the RSTP-compatible part describing the CST data, and MST extension part containing info about MSTIs. However, ordinary RSTP switches should be able to process the CST part from the MST BPDU and ignore the MSTI record.

Does this help a little?

Best regards,

Peter