Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Tagged native VLAN & 802.1D BPDU's

On a stacked 3750, I configured a trunk link (802.1Q) with a native VLAN 3:

switch(config-if)# switchport trunk encapsulation dot1q

switch(config-if)# switchport trunk native vlan 3

switch(config-if)# switchport mode trunk

Now I would expect to see plain (untagged) 802.1D BPDU's (not PVST+) to be sent to vlan 3 on this interface.

However, the PVST+ BPDU tagged for vlan 1 contains the same spanning tree payload

as the (untagged) 802.1D BPDU itself, indicating that they are intended for vlan 1.

Also shown by the root identifier 32769, which is 32768 + 1 (MAC address

reduction feature).

(see native_untagged.cap packets 17,18)

When tagging is configured for all vlans including the native VLAN:

switch(config)# vlan dot1q tag native

the same 802.1D BPDU is now tagged for vlan 3.

To me it seems that it is tagged for the correct VLAN (3), but it

contains spanning-tree payload for the wrong VLAN (1).

(see native_tagged.cap packets 12,13)

Any comment on this ?

version info available in version.txt

Thanks, Ferdinand

New Member

Re: Tagged native VLAN & 802.1D BPDU's


Here is a good explnation of how PVST+ interoperates with 802.1D:

What you are seeing does match what is documented for the scenario:

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.


The idea of PVST+ is to interoperate with a flat network (that's what the "+" represents). It is not really meant to change native VLANs on both sides of a link, in that case you may have issues with setting root of VLAN 1 and the native VLAN. The idea is to merge the native VLAN from STP into your PVST environment. Sending IEEE BPDU's helps us talk to these 802.1D hosts where they ONLY have 1 VLAN so it wouldn't matter.

I do see your concern here though if you were to put the same config on the other side of this link. This is not optimal but I will agree this warrants a bit of investigation, I'll let you know what else I can find.

It is interesting how we don't mention sending the native VLAN BPDU with a distinct priority, it's documented as the VLAN 1 BPDU.