STP PVID and Type Inconsistency question

[Craddockc]

Community,

I am reading about the Native VLAN in 802.1q and came across this particular spanning tree issue but am having trouble understanding exactly how it works. When a native vlan mismatch exists on both ends of a trunk link, CDPv2 will gripe and say there is a native vlan mismatch. I understand that CDPv2 has a TLV that holds the native vlan value so CDP knows internally what the native vlan is on both sides of the link. However, I am struggling to understand how Spanning Tree knows what the native vlan is on the other side of the link. I dont see anywhere in the BPDU where this information is held. Does STP know this information by doing a BPDU comparison? Here is my understanding:

The switch will send a separate BPDU for each vlan on the trunk, 802.1q will tag each BPDU with its corresponding vlan ID, except for the native vlan which does not get tagged. If the far end switch sees a BPDU with a vlan tag of that of the native vlan on its interface it will wake up and say "Hey! That BPDU has a dot1q tag with that of my native vlan and I dont like that!." and it will subsequently block the port in a *BKN* PVID Inconsistent state. Is this right? 

Thanks!

[Peter Paluch · Accepted solution]

Hi,
You have a very keen thinking - and you are spot-on!

On trunks, PVST+ and Rapid-PVST+ BPDUs are not only 802.1Q-tagged, but also at their very end, there is also a special PVID TLV appended that carries the VLAN in which this BPDU was originated.

Check out the following two sample captures:
http://packetlife.net/captures/rpvstp-trunk-native-vid1.pcap.cap
http://packetlife.net/captures/rpvstp-trunk-native-vid5.pcap.cap

Dig deep into the BPDU contents - at the very end of the BPDU contents, Wireshark will show you the "Originating VLAN (PVID)" TLV and that TLV contains the VLAN in which the BPDU was generated.

In case of a VLAN mismatch, the VLAN in which a BPDU is received will be different from the VLAN indicated in the PVID TLV.

This detection does not work on access ports, obviously - on access ports, Cisco sends entirely standard BPDUs without any 802.1Q tags and without any PVID TLVs.

If the far end switch sees a BPDU with a vlan tag of that of the native vlan on its interface it will wake up and say "Hey! That BPDU has a dot1q tag with that of my native vlan and I dont like that!." and it will subsequently block the port in a *BKN* PVID Inconsistent state. Is this right? 

Not entirely. Consider this: The VLAN tag also contains the 802.1p Class of Service priority bits. If the sending switch needed to indicate a non-default CoS value for the outgoing frame that happens to belong to the native VLAN, it would still need to tag it, because without a VLAN tag, there is no field in the Ethernet header where the CoS value could be inscribed. So technically, receiving a tagged frame on the native VLAN is not an indication of a misconfiguration per se.

Feel welcome to ask further!

Best regards,
Peter

[TrivialPants]

HI @Peter Paluch ,

I am experiencing this same behavior with an l2vpn circuit that I have recently swapped from IOS XE to IOS XR. 

It is almost as though the swap from XE to XR is not translating the untagged or VLAN 1 to the new tagged service and thus causing the inconsistency for my specific instance. 

Here is my community post on the subject. https://community.cisco.com/t5/mpls/ios-xr-rewrite-not-working-migration-from-xe-issues/m-p/4777725#M24381

[Sebastian Schrader]

---

@Peter Paluch wrote:

on access ports, Cisco sends entirely standard BPDUs without any 802.1Q tags and without any PVID TLVs.

---

Hi Peter,

curiously I can only observe untagged PVST+ BPDUs sent to the PVST+ Destination Multicast MAC 01:00:0c:cc:cc:cd containing the Originating VLAN TLV and no standard IEEE BPDUs on the access ports of our Catalyst switches. There must be something platform/version/configuration depended going on.

Best regards,
Sebastian

[Peter Paluch]

Hello Sebastian,

This is very interesting : )

You definitely observed something different than what I did. I still suspect, however, that your configuration must contain something different - something that makes the port act as a trunk port. The logic is simple: It makes no sense to send (R)PVST+ BPDUs on access ports because, first, there is only a single (R)STP instance to be advertised so the multi-instance capability of (R)PVST+ would be wasted there; second, no classic switch connected to such an access port would understand these BPDUs because their destination MAC address and their encapsulation differs from the IEEE standard. The would be flooded but not processed by non-Cisco switches. That is why I also believe that this cannot be a platform-specific thing - it would break interoperability completely.

Can I ask you to share the exact type of the switch you're doing this experiment with, the exact IOS/IOS-XE version, and the full configuration of the switchport you're capturing this on?

Many thanks!

Best regards,
Peter

[Sebastian Schrader]

Hi Peter,

after playing a bit around with the interface configuration, we found the reason: It is the voice VLAN. As soon as we remove the

switchport voice vlan 2010

stanza, we can observe IEEE-compatible BPDUs for the access VLAN on the port:

switch(config-if)#interface GigabitEthernet1/0/1
switch(config-if)#no switchport voice vlan

Seeing PVST+ BPDUs on access ports with an additional voice VLAN configured is understandable, since such ports can carry multiple VLANs simultaneously (i.e. trunk semantics). In general such ports are a weird hybrid with both of access and trunk semantics depending on perspective/protocol from which they are viewed at. What I find a bit concerning though is that IEEE STP compatibility is lost on voice VLAN enabled access ports of (RP)PVST+ switches. The only way I could get the switch to transmit IEEE-compatible BPDUs on such ports was to use VLAN 1 as either voice or access VLAN. This is not a feasible solution for us, as we have multiple distinct voice and access VLANs per switching domain. Also, using VLAN 1 for user traffic is advised against.

For completeness you can find our full access switch port interface configuration below, although the behavior can be observed with a more minimal example. It is somewhat extensive as we employ a wide range of features (802.1X, RADIUS, MAC Authentication Bypass/MAB, Network Edge Authentication Topology/NEAT (w/o interface templates yet), VTPv3):

Spoiler

switch#show run int Gi1/0/1
Building configuration...

Current configuration : 856 bytes
!
interface GigabitEthernet1/0/1
 description redacted
 switchport access vlan 880
 switchport mode access
 switchport voice vlan 2010
 authentication control-direction in
 authentication event fail action authorize vlan 1001
 authentication event server dead action authorize vlan 178
 authentication event no-response action authorize vlan 178
 authentication event server alive action reinitialize
 authentication host-mode multi-domain
 authentication order mab dot1x
 authentication priority dot1x mab
 authentication port-control auto
 authentication periodic
 authentication timer reauthenticate server
 authentication violation protect
 mab
 dot1x pae authenticator
 dot1x timeout tx-period 4
 dot1x timeout supp-timeout 4
 mac access-group lltd in
 spanning-tree portfast edge
 ip dhcp snooping limit rate 20
end

switch#show int Gi1/0/1 switchport
Name: Gi1/0/1
Switchport: Enabled
Administrative Mode: static access
Operational Mode: static access
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: native
Negotiation of Trunking: Off
Access Mode VLAN: 139 (access-redacted)
Trunking Native Mode VLAN: 1 (default)
Administrative Native VLAN tagging: enabled
Voice VLAN: 2010 (voip-redacted)
Administrative private-vlan host-association: none
Administrative private-vlan mapping: none
Administrative private-vlan trunk native VLAN: none
Administrative private-vlan trunk Native VLAN tagging: enabled
Administrative private-vlan trunk encapsulation: dot1q
Administrative private-vlan trunk normal VLANs: none
Administrative private-vlan trunk associations: none
Administrative private-vlan trunk mappings: none
Operational private-vlan: none
Trunking VLANs Enabled: ALL
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled
Capture VLANs Allowed: ALL

Protected: false
Unknown unicast blocked: disabled
Unknown multicast blocked: disabled
Appliance trust: none

Best regards
Sebastian

[Peter Paluch]

Hello Sebastian,

You have presented a wonderfully formulated and investigated case. My respect to you!

I in fact did suspect that you might have had a voice VLAN configured but didn't want to jump to conclusions : ) I waited for you.

So let's summarize what you observed: You have an access port with access VLAN set to X and voice VLAN set to Y, and you observed this:

• If both VLANs X and Y are different from VLAN1, you only see (R)PVST+ BPDUs sent out, but neither of them is 802.1Q-tagged. There is no IEEE-formatted BPDU sent out at all.
• If any of VLANs X and Y is VLAN1, you see both IEEE and (R)PVST+ BPDUs sent out - IEEE BPDU is sent out for VLAN1, and (R)PVST+ BPDUs are sent out for both VLAN1 and the other VLAN (if any), but again, none of these BPDUs is 802.1Q-tagged.

This behavior would perfectly match the configuration of a trunk port with the following configuration:

interface ...
  switchport trunk encapsulation dot1q
  switchport mode trunk
  switchport trunk allowed vlan X,Y
  switchport trunk native vlan X

except one thing: The (R)PVST+ BPDUs are sent untagged.

And that is a wrong behavior.

Let me rephrase: It is okay, and in fact, necessary to send out (R)PVST+ BPDUs out from an access port with a voice VLAN. The reason is that we run two VLANs on such a port, and that suddenly implies all the possible issues that could occur if such a port would be connected by mistake to another switchport - the need to run multiple STP instances, the need to detect and as much as possible avoid native VLAN mismatches, etc. The situation is equivalent to a trunk with two arbitrary VLANs allowed, one of them in addition being the native VLAN. That is exactly what (R)PVST+ has been created to handle.

The issue of losing IEEE (R)STP compatibility is not really relevant here. You see, an access port with a voice VLAN is intended - by any supported design - to be connected directly to a computer and/or an IP phone but not to another switch. Access ports with a voice VLAN are not supposed to be "fanned out" by another switch. Hence, the question of IEEE (R)STP interoperability in this situation is immaterial; if such a port is connected back to the network, we don't care about interoperability but merely about disaster prevention. There, (R)PVST+ does the job quite nicely. That is also the reason we cannot blindly send out IEEE BPDUs for the access VLAN on such a port - we'd possibly cause a native VLAN mismatch with a real trunk somewhere else with VLAN1 allowed, or with CST on non-Cisco switches. We simply have to keep the trunk (R)PVST+ semantics on such a port, even if it doesn't feel natural - because we're forced by the circumstances of it being a port with multiple VLANs allowed. From this point of view, an access port with a voice VLAN is necessarily undistinguishable from a trunk port with two allowed VLANs as discussed earlier.

However, what is very wrong is that we send those (R)PVST+ BPDUs untagged. This causes even the voice VLAN BPDU to be potentially processed against the access VLAN (R)PVST+ instance if it was ever received on another such port or a trunk. It would of course trigger Primary VLAN Inconsistency because the originating VLAN TLV would not match the receiving VLAN... but it's not how this is supposed to work.

In fact, there was a similar defect seen on Nexus switches running NX-OS (CSCvn67454), and that one got fixed. We clearly need to get this fixed in IOS/IOS-XE, too.

I hope this clarifies the state of matters somewhat, but please feel more that welcome to ask further!

Best regards,
Peter

[Sebastian Schrader]

Hi Peter,

thank you for your elaborate answer. I almost always learn something, when reading your posts or attending your sessions.

I assume you tested the defective behavior you describe in your own lab, since the screenshot of the packet capture I shared only shows untagged (R)PVST+ BPDUs for VLAN 139 (the switchport access VLAN). The capture was performed on a directly connected host, that does not advertise itself as phone via CDP/LLDP, so the switch hasn't enabled the voice VLAN on the port.

When I do a SPAN session on an interface with a proper VoIP phone attached, I observe the following:

1. Only a phone connected: Tagged (R)PVST+ BPDUs for the voice VLAN and Untagged (R)PVST+ BPDUs for the configured access VLAN.
2. Phone and RADIUS-VLAN-Assigned 802.1X Host: Tagged (R)PVST+ BPDU for the voice VLAN and Untagged (R)PVST+ BPDU for the RADIUS-assigned access VLAN.

This is the behavior I've expected and not the defective behavior you described. Access port VLAN (R)PVST+ BPDUs are sent untagged, but the voice VLAN (R)PVST+ BPDUs are sent tagged. The switch I tested this on is a C3560CX running IOS 15.2(7)E2.

---

@Peter Paluch wrote:

The issue of losing IEEE (R)STP compatibility is not really relevant here. You see, an access port with a voice VLAN is intended - by any supported design - to be connected directly to a computer and/or an IP phone but not to another switch. Access ports with a voice VLAN are not supposed to be "fanned out" by another switch. Hence, the question of IEEE (R)STP interoperability in this situation is immaterial; if such a port is connected back to the network, we don't care about interoperability but merely about disaster prevention.

Not to disagree, but to put into context: In a large and constantly changing campus network such as ours, we can not afford maintaining individual/specific switch port configurations for specific devices (phones, desktop switches, access points, regular hosts) statically configured on specific ports, which is why we need to have a generic interface configuration that allows every type of device to connect and intelligent dynamic protocols (802.1X/MAB, RADIUS-assigned VLANS, NEAT/CISP, LLDP/CDP) which change the interface configuration dynamically.

Best regards
Sebastian