Spanning-tree inconsistent ports

Ran into this at work the other day and it took me a second to remember what was going on.  Inconsistent ports are somewhat of an oddity.  Let’s take a quick look at an example…

So we have the possibility for a layer 2 loop here.  STP is going to kick in and figure out which one of these ports to block.  Let’s take a look and see what happens…

Not that interface Fa1/0/2 shows a status of ‘BKN’ and a type of ‘P2p *TYPE_Inc’.  If we take a look at the inconsistent ports in spanning-tree, we’ll see the port there as well…

Looking at the configuration of the Fa1/0/2 interfaces on both switches we can see that I have one end configured as a trunk, and the other end configured as a access port…

An unusual configuration I agree, but why wouldn’t this work?  The trunk has it’s native VLAN set to 10 and the other end is an access port in vlan 10.  The trunk port should send untagged frames on vlan 10 and when they end up on switch1 they should be put in vlan 10.  

Moreover, I could see this being an issue if one end had a spanning-tree type of ‘edge’ configured with portfast since we truly shouldn’t be seeing spanning-tree BPDUs on an access port, but in this case, the port types are both P2P.

So, I did some packet captures.  It looked like spanning-tree was sending 802.1Q tagged BPDUs on VLAN 1 as well as VLAN 10…

That would give merit to the error message I’m seeing on the switch about the port being ‘inconsistent’…

So this is sort of odd right?  Recall that the trunk had been configured with the native VLAN set to 10.  So why was it sending out spanning-tree messages with a DOT1Q header of VLAN 10?

I could understand seeing the VLAN 1 BPDUs in a dot1q header, but why were the VLAN 10 BPDU’s showing up tagged?  I ran into some Cisco documentation that further confused me as I was trying to figure this out…

A quick post to networking-forum.com and mellowd was able to clear up the confusion for me.  He had ran into this during some of his testing and summed it up like this…

PVST BPDUs are always tagged, regardless of the native vlan.
The only untagged bpdus are 802.1d and MST bpdus, again regardless of native vlan

This makes sense.  If I change my spanning-tree mode to MST then the port inconsistency resolves itself. 

This introduces and important point about PVST. On trunk ports, PVST sends communication for each VLAN out bundled in a 802.1Q header with the appropriate VLAN header REGARDLESS of the native VLAN. If it did send the PVST info for the native VLAN untagged, then this configuration would (in my opinion) worked as I had initially expected. Please keep in mind that this wasn’t a real scenario, there was more gear and more complicated configuration in play for the problem that spawned this post. In the real world, two ends of a port should be configured identically in scenarios like this one.