cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
37733
Views
72
Helpful
12
Replies

How BPDU is transmitted with Native VLAN for PVST and MSTP

szhongling
Level 1
Level 1

If native VLAN is VLAN 1, How BPDU is transmitted when using Cisco proprietary protocol PVST+ or IEEE protocol MSTP?

If native VLAN is changed to VLAN 999 , how is it then?

If native VLAN is changed to VLAN 999 and vlan 1 is not allowed on the trunk, how is it then?

And how other traffic will separately be affected with native vlan 1 and native vlan 999?

Thank you for any input!

1 Accepted Solution

Accepted Solutions

Peter Paluch
Cisco Employee
Cisco Employee

Hello Shi,

Regarding the MSTP, it is easy: the MSTP sends all its BPDUs untagged, regardless of the native VLAN on the trunk. Information about individual instances is contained as so-called Mrecords inside the single MSTP BPDU, and the entire BPDU is sent untagged.

The PVST+ is more complicated. I invite you to read the following two documents:

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

http://www.cisco.com/en/US/docs/ios/lanswitch/configuration/guide/lsw_rtng_vlan_ovw_ps6350_TSD_Products_Configuration_Guide_Chapter.html#wp1006501

In short, if the native VLAN is VLAN1 then:

  • VLAN1 standard STP BPDU is sent untagged
  • VLAN1 PVST+ BPDU is sent untagged
  • Other VLAN's PVST+ BPDUs are sent tagged with their appropriate VLAN

If the native VLAN is different from VLAN1 then:

  • VLAN1 standard STP BPDU is sent untagged
  • VLAN1 PVST+ BPDU is sent tagged with VLAN1
  • Other VLAN's PVST+ BPDUs are sent tagged accordingly (the one for the native VLAN will be untagged)

In short, the standard STP BPDU is always derived from VLAN1 and is always sent untagged. The PVST+ BPDUs are derived from their appropriate VLANs and are tagged according to the native VLAN on the trunk.

Best regards,

Peter

View solution in original post

12 Replies 12

Peter Paluch
Cisco Employee
Cisco Employee

Hello Shi,

Regarding the MSTP, it is easy: the MSTP sends all its BPDUs untagged, regardless of the native VLAN on the trunk. Information about individual instances is contained as so-called Mrecords inside the single MSTP BPDU, and the entire BPDU is sent untagged.

The PVST+ is more complicated. I invite you to read the following two documents:

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

http://www.cisco.com/en/US/docs/ios/lanswitch/configuration/guide/lsw_rtng_vlan_ovw_ps6350_TSD_Products_Configuration_Guide_Chapter.html#wp1006501

In short, if the native VLAN is VLAN1 then:

  • VLAN1 standard STP BPDU is sent untagged
  • VLAN1 PVST+ BPDU is sent untagged
  • Other VLAN's PVST+ BPDUs are sent tagged with their appropriate VLAN

If the native VLAN is different from VLAN1 then:

  • VLAN1 standard STP BPDU is sent untagged
  • VLAN1 PVST+ BPDU is sent tagged with VLAN1
  • Other VLAN's PVST+ BPDUs are sent tagged accordingly (the one for the native VLAN will be untagged)

In short, the standard STP BPDU is always derived from VLAN1 and is always sent untagged. The PVST+ BPDUs are derived from their appropriate VLANs and are tagged according to the native VLAN on the trunk.

Best regards,

Peter

Hello @Peter Paluch 

The concept makes much more sense about tagging, but if I capture packet

I couldn't see any Dot1Q tagging in BPDU

I have attached packet capture for your reference, please help me to understand.

Native vlan: 1

Stp mode: PVST+

vlan : 1 & 200

In my test IEEE bpdu (vl 1) & PVST+ bpdu (vl 1) should be untagged and, PVST+ bpdu (vl 200 ) should be tagged. but I don't see any difference between PVST+ bpdus for vlan 1 and vlan 200.bpdu tag test.PNG

 

Thanks 

Siva

Hello Siva,

if you are using a SPAN session to capture traffic you may need additional commands to avoid to have 802.1Q tags stripped something encapsulation replicate on monitor destination command.

 

Or you should look at hexadecimal and see if you see ethertype 0x8100 just after the end of source MAC address. It can be just a display issue.

 

Hope to help

Giuseppe

 

Hi Giuseppe, hi Siva,

Giuseppe is correct. Let me add two important points.

First, if you are capturing using SPAN, then - exactly as Giuseppe mentioned - you need to add extra configuration to the SPAN configuration so that the incoming and outgoing frames are SPANned with their tag. This is usually done by adding the encapsulation replicate keywords at the end of the monitor session ... destination interface command.

Second, I see you are capturing packets on Windows. Windows drivers almost always strip off any VLAN tags and pass the frames to Wireshark untagged. Some drivers can be configured (usually through Registry settings) to keep the VLAN tags in frames so that the Wireshark can see them, but it is not supported universally. You would get better results if you could use a PC that runs native Linux - under Linux, you always see the tags. Perhaps if you could tell me the exact type of your Ethernet NIC in the PC you are running, I could try googling a little to see if your NIC drivers support the option to keep the VLAN tags.

Best regards,
Peter

Hi @Peter Paluch  @Giuseppe Larosa 

Thanks for the help

 

@Peter Paluch 

I have enabled "Encapsulation replicate" on my Local SPAN.

also, I tried to capture the packet via HUB.

My NIC name is "Intel(R) Ethernet Connection 1218-LM",
driver version: 12.12.218.0.

 

Thanks 

Siva

Hi Siva,

The following page describes the registry changes you need to perform so that your Intel NIC passes the VLAN tags to the driver and thus to the Wireshark:

https://www.intel.com/content/www/us/en/support/articles/000005498/network-and-i-o/ethernet-products.html

Depending on the type of your driver, you will need to add either the MonitorModeEnabled or the MonitorMode dword value to your registry, set to 1. It should be in fact okay to add them both and have them both set to 1; the exact instructions are in the document above.

As usual, when manually modifying your Windows registry, be very careful - you know how sensitive it is.

Best regards,
Peter

Thanks for your valuable time @Peter Paluch

Hello @Peter Paluch  @Giuseppe Larosa 

Sorry for asking an answered question again and again,

I still have confusion with my Lab test, please help me on it.

 

SW: 3550

STP mode: RSTP

Native VLAN: 3

Allowed VLAN: 1-3

Trunk type: Dot1Q

Pc OS: Linux 

"Vlan dot1q tag native" command applied.

 

from your statement:

" If the native VLAN is different from VLAN1 then:

 

  • VLAN1 standard STP BPDU is sent untagged "

My lab test:

VLAN 1 IEEE BPDU sent on native VLAN with Tag 3 (because I enabled native VLAN tagging) <--- Agree with you.NV31-min.jpg

 

from your statement: 

"If the native VLAN is different from VLAN1 then:

  • Other VLAN's PVST+ BPDUs are sent tagged accordingly (the one for the native VLAN will be untagged)"

 

My Lab test:

VLAN 2 sstp bpdu sent with Tag 2

VLAN 3 sstp bpdu alslo sent with Tag 3 (because I enabled native VLAN tagging) <--- Agree with youNV32-min.jpg

NV33-min.jpg

 

Next

From your statement:

"If the native VLAN is different from VLAN1 then:

  • VLAN1 PVST+ BPDU is sent tagged with VLAN1"

 

My Lab Test:

VLAN 1 sstp bpdu sent without any tag!  <-----I have a confusion here with your statement.

 NV34-min.jpg

 

Also, I changed native VLAN back to 1

now

  • IEEE VLAN 1 BPDU  is not tagged (but I still enabled "vlan dot1q tag native" command) 
  • Other VLAN SSTP BPDUs were tagged correctly.
  • And VLAN 1 SSTP BPDU was not tagged! (in the previous test  Native vlan 3 tagged but it didn't happen for VLAN 1)NV11-min.jpg

    NV12-min.jpg

    NV13-min.jpg

     

what should I conclude?!!

Cisco documents says as per your explanation but I couldn't get that result in real-time, please help me to understand.

 

+I studied control packets like VTP, CDP  always uses VLAN 1, but I couldn't find any tag on these packets while native vlan 3.


Thanks 

Siva 

Hello Siva,

you have performed very interesting tests. Thanks for having shared your results.

 

As I have explained in the other thread the command vlan dot1q tag native  applies for sure to user traffic frames and to those protocol frames that can support tagging.

I have provided there an example taken from real world experience of an interoperability issue caused by mismatch on tagging / not tagging IEEE RSTP BPDUs.

 

Your tests show that Cisco implementation will honor the tagging for both IEEE STP BPDU and Cisco PVST BDPU if the native Vlan is not the default one and vlan dot1q tag native is enabled.

However, when you changed the native Vlan back to 1 you see the IEEE STP BPDUs untagged and also Cisco PVST BPDUs untagged. This behaviour is in line with what I have seen on switches of other vendors when the native Vlan is the default one the IEEE STP BPDU are sent untagged for backward compatibility (or because so it is stated on IEEE standard).

 

Hope to help

Giuseppe

 

@Giuseppe Larosa 

 

Thank you very much for your continuous help.

 

Shall I conclude the below statements for cisco devices?

 

When "VLAN dot1q tag native" is enabled and native VLAN is non-default:

 

  • IEEE standard BPDU ---over native VLAN---tagged
  • SSTP VLAN 1 BPDU---over VLAN 1---untagged
  • SSTP other BPDU---over their VLAN---tagged

 

When "VLAN dot1q tag native" is enabled and native VLAN is default VLAN 1:

 

  • IEEE standard BPDU ---over native VLAN---untagged
  • SSTP VLAN 1 BPDU---over VLAN 1---untagged
  • SSTP other BPDU---over their VLAN---tagged

 

when Native vlan tagging is disabled and native VLAN is default VLAN 1:

 

  • IEEE standard BPDU ---over native VLAN---untagged
  • SSTP VLAN 1 BPDU---over VLAN 1---untagged
  • SSTP other BPDU---over their VLAN---tagged

 

when Native vlan tagging is disabled and native VLAN is non-default:

 

  • IEEE standard BPDU ---over native VLAN---untagged
  • SSTP VLAN 1 BPDU---over VLAN 1---untagged
  • SSTP native VLAN BPDU---over native VLAN---untagged
  • SSTP other BPDU---over their VLAN---tagged

I'm preparing for CCNP please help me to conclude the behavior.


Thank you

siva  

szhongling
Level 1
Level 1

Dear Peter,

Thank you for your answering and papaers.

Junwei Li
Level 1
Level 1

Thank you guys for the discussion and the information ,will reproduce on my lab env

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card