Many people have seen the message logged to their switch about a mismatched native VLAN on a trunk, but how is it detected? There are two methods of detecting mismatched native VLAN on a trunk link:
- CDP.
- STP when using a Per-VLAN flavor such as PVST+ or RPVST+.
To demonstrate how this happens, I will setup a very simple topology in CML with two switches connected by a trunk link as seen below:
At this point only the following has been configured on the trunk link:
interface GigabitEthernet0/0 switchport trunk encapsulation dot1q switchport mode trunk negotiation auto
Now, let’s take a look at the PDUs being generated, CDP and STP. For CDP we can see the following in Wireshark:
Frame 31: 354 bytes on wire (2832 bits), 354 bytes captured (2832 bits) IEEE 802.3 Ethernet Logical-Link Control Cisco Discovery Protocol Version: 2 TTL: 180 seconds Checksum: 0x474d [correct] [Checksum Status: Good] Device ID: SW2 Software Version Platform: Cisco Addresses Port ID: GigabitEthernet0/0 Capabilities VTP Management Domain: Native VLAN: 1 Type: Native VLAN (0x000a) Length: 6 Native VLAN: 1 Duplex: Full Trust Bitmap: 0x00 Untrusted port CoS: 0x00 Management Addresses
Notice that the native VLAN is signaled and that it is currently set to 1.
For PVST+, there are two BPDUs being generated:
- IEEE BPDU to destination MAC of 0180.c200.0000.
- PVST+ BPDU to destination MAC of 0100.0ccc.cccd.
Note that the IEEE BPDU has no information on the originating VLAN:
Frame 2: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) IEEE 802.3 Ethernet Logical-Link Control Spanning Tree Protocol Protocol Identifier: Spanning Tree Protocol (0x0000) Protocol Version Identifier: Spanning Tree (0) BPDU Type: Configuration (0x00) BPDU flags: 0x00 Root Identifier: 32768 / 1 / 52:54:00:04:2a:87 Root Path Cost: 0 Bridge Identifier: 32768 / 1 / 52:54:00:04:2a:87 Port identifier: 0x8001 Message Age: 0 Max Age: 20 Hello Time: 2 Forward Delay: 15
The PVST+ BPDU does have this information:
Frame 3: 64 bytes on wire (512 bits), 64 bytes captured (512 bits) IEEE 802.3 Ethernet Logical-Link Control Spanning Tree Protocol Protocol Identifier: Spanning Tree Protocol (0x0000) Protocol Version Identifier: Spanning Tree (0) BPDU Type: Configuration (0x00) BPDU flags: 0x00 Root Identifier: 32768 / 1 / 52:54:00:04:2a:87 Root Path Cost: 0 Bridge Identifier: 32768 / 1 / 52:54:00:04:2a:87 Port identifier: 0x8001 Message Age: 0 Max Age: 20 Hello Time: 2 Forward Delay: 15 Originating VLAN (PVID): 1 Type: Originating VLAN (0x0000) Length: 2 Originating VLAN: 1
Now, let’s change the native VLAN on SW2 and see what happens:
SW2(config)#int gi0/0 SW2(config-if)#switchport trunk native vlan 2
CDP is now reporting that there is a native VLAN mismatch:
%CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on GigabitEthernet0/0 (2), with SW1 GigabitEthernet0/0 (1)
SW2 is detecting this by comparing the native VLAN in this PDU to what it has locally configured:
Frame 92: 354 bytes on wire (2832 bits), 354 bytes captured (2832 bits) IEEE 802.3 Ethernet Logical-Link Control Cisco Discovery Protocol Version: 2 TTL: 180 seconds Checksum: 0x484d [correct] [Checksum Status: Good] Device ID: SW1 Software Version Platform: Cisco Addresses Port ID: GigabitEthernet0/0 Capabilities VTP Management Domain: Native VLAN: 1 Duplex: Full Trust Bitmap: 0x00 Untrusted port CoS: 0x00 Management Addresses
Note that CDP is only reporting about the error. It doesn’t have the ability to block anything or take any corrective action.
STP is also detecting that there is a mismatch:
%SPANTREE-2-RECV_PVID_ERR: Received BPDU with inconsistent peer vlan id 1 on GigabitEthernet0/0 VLAN2. %SPANTREE-2-BLOCK_PVID_PEER: Blocking GigabitEthernet0/0 on VLAN0001. Inconsistent peer vlan. %SPANTREE-2-BLOCK_PVID_LOCAL: Blocking GigabitEthernet0/0 on VLAN0002. Inconsistent local vlan.
This is detected by checking the originating VLAN in PVST+ BPDU and comparing it to on what VLAN it was received:
Frame 94: 64 bytes on wire (512 bits), 64 bytes captured (512 bits) IEEE 802.3 Ethernet Logical-Link Control Spanning Tree Protocol Protocol Identifier: Spanning Tree Protocol (0x0000) Protocol Version Identifier: Spanning Tree (0) BPDU Type: Configuration (0x00) BPDU flags: 0x01, Topology Change Root Identifier: 32768 / 1 / 52:54:00:0b:45:06 Root Path Cost: 0 Bridge Identifier: 32768 / 1 / 52:54:00:0b:45:06 Port identifier: 0x8001 Message Age: 0 Max Age: 20 Hello Time: 2 Forward Delay: 15 Originating VLAN (PVID): 1 Type: Originating VLAN (0x0000) Length: 2 Originating VLAN: 1
There is a native VLAN (PVID) mismatch which is reported as PVID_Inc. STP goes into a broken state (BKN) and is blocking both of the offending VLANs:
SW2#show span vlan 1 VLAN0001 Spanning tree enabled protocol ieee Root ID Priority 32769 Address 5254.0004.2a87 This bridge is the root Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Bridge ID Priority 32769 (priority 32768 sys-id-ext 1) Address 5254.0004.2a87 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 300 sec Interface Role Sts Cost Prio.Nbr Type ------------------- ---- --- --------- -------- -------------------------------- Gi0/0 Desg BKN*4 128.1 P2p *PVID_Inc SW2#show span vlan 2 VLAN0002 Spanning tree enabled protocol ieee Root ID Priority 32770 Address 5254.0004.2a87 This bridge is the root Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Bridge ID Priority 32770 (priority 32768 sys-id-ext 2) Address 5254.0004.2a87 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 300 sec Interface Role Sts Cost Prio.Nbr Type ------------------- ---- --- --------- -------- -------------------------------- Gi0/0 Desg BKN*4 128.1 P2p *PVID_Inc
If STP didn’t block the VLANs, there would be bridging between two different VLANs, VLAN 1 and 2 in this scenario. By using PVST+, this misconfiguration didn’t lead to any “leaking” of traffic between different VLANs.
Just to show you what would happen without PVST+, let’s disable STP completely on SW2:
SW2(config)#no span vlan 1 SW2(config)#no span vlan 2
As SW2 is no longer generating BPDUs, SW1 therefore not receiving them, SW1 can change the state to forwarding on Gi0/0:
SW1#show span vlan 1 VLAN0001 Spanning tree enabled protocol ieee Root ID Priority 32769 Address 5254.000b.4506 This bridge is the root Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Bridge ID Priority 32769 (priority 32768 sys-id-ext 1) Address 5254.000b.4506 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 300 sec Interface Role Sts Cost Prio.Nbr Type ------------------- ---- --- --------- -------- -------------------------------- Gi0/0 Desg FWD 4 128.1 P2p
Then, let’s configure SVI in VLAN 1 on SW1 and VLAN 2 on SW2:
SW1#sh run int vlan 1 Building configuration... Current configuration : 60 bytes ! interface Vlan1 ip address 10.0.0.1 255.255.255.252 end SW2#sh run int vlan 2 Building configuration... Current configuration : 60 bytes ! interface Vlan2 ip address 10.0.0.2 255.255.255.252 end
Then let’s try a ping:
SW2#ping 10.0.0.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds: .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 4/4/5 ms
It works! By disabling STP on SW2, there is now bridging between VLAN 2 and VLAN 1. Let’s verify the ARP cache and then the MAC address table:
SW2#show ip arp Protocol Address Age (min) Hardware Addr Type Interface Internet 10.0.0.1 0 5254.000b.8001 ARPA Vlan2 Internet 10.0.0.2 - 5254.0004.8002 ARPA Vlan2 SW2#show mac address-table vlan 2 Mac Address Table ------------------------------------------- Vlan Mac Address Type Ports ---- ----------- -------- ----- 2 5254.000b.4506 DYNAMIC Gi0/0 2 5254.000b.8001 DYNAMIC Gi0/0 Total Mac Addresses for this criterion: 2 SW1#show ip arp Protocol Address Age (min) Hardware Addr Type Interface Internet 10.0.0.1 - 5254.000b.8001 ARPA Vlan1 Internet 10.0.0.2 1 5254.0004.8002 ARPA Vlan1 SW1#show mac address-table vlan 1 Mac Address Table ------------------------------------------- Vlan Mac Address Type Ports ---- ----------- -------- ----- 1 5254.0004.2a87 DYNAMIC Gi0/0 1 5254.0004.8002 DYNAMIC Gi0/0 Total Mac Addresses for this criterion: 2
Notice how SW2 knows MAC of SW1 (5254.000b.8001) via VLAN 2 although it originated in VLAN 1 on SW1. SW1 knows MAC of SW2 (5254.0004.8002) via VLAN 1 although it originated in VLAN 2.
In this post we learned that there are two mechanisms to detect a mismatch of native VLAN on a trunk link, CDP, and STP. CDP will only report the error, but has no mechanism of blocking (as expected) or correcting the misconfiguration. The PVST+ BPDUs that are generated contain information on the originating VLAN and compare this on the VLAN that the BPDU was received. If there is a mismatch, both the offending VLANs will be blocked. This prevents bridging frames between two different VLANs.
Daniel,
Wow, amazingly useful content these last few years! I always enjoy seeing your LinkedIn posts and then reading here.
Small alternative term: I’ve seen IOS docs describe the STP state as “Broken” instead of “Blocking” for the STP state used in this case. I’ve had recent reasons to look at Root Guard and Loop Guard, and they use the Broken (BKN) state as well. Those features also list the specific reason under the Type heading in *show spanning-tree*, as shown here with the PVID_Inc text.
Trivia and trivial, but wanted to add the note in case it’s helpful.
Great stuff!
Great to see you here, my friend! Thank you, I’m honored that you are reading them.
Technically correct is the best correct, as they say and you are absolutely correct! I went back and checked and the port is indeed in a broken state:
Port 1 (GigabitEthernet0/0) of VLAN0001 is broken (Port VLAN ID Mismatch)
Port path cost 4, Port priority 128, Port Identifier 128.1.
Designated root has priority 32769, address 5254.000b.4506
Designated bridge has priority 32769, address 5254.000b.4506
Designated port id is 128.1, designated path cost 0
Timers: message age 0, forward delay 13, hold 0
Number of transitions to forwarding state: 5
Link type is point-to-point by default
BPDU: sent 17447, received 1382
I’ll update the post to reflect this! Thank you!
Interesting Scenario , thanks Daniel for the useful content as usual!!
Incredible. This actually helped me to solve an issue with PVID_inc state on our switches. Now I also understand how it happened. Amazing content.
Thanks!