On a dot1q trunk, all frames are tagged except those on the native VLAN, right? What about PVST BPDUs? Until today, I thought they obeyed the same rule, but now I doubt it.
I did an experiment. Take two switches, a distribution switch and an access switch, and join then with a trunk that passes all VLANs. Make the native VLAN of this trunk, say, 12 - at both ends of course. Make the distribution switch the root of every VLAN. The access switch knows that the distribution switch is the root.
Now clear VLAN 12 from the trunk at the access switch end. As expected, the Spanning Tree for VLAN 12 shuts down beceuse there are no longer any ports supporting it. Most of the VLANs carry on as before. But something interesting happens to VLAN 1 : it is no longer able to receive or process BPDUs on the trunk. Normal VLAN 1 traffic passes fine, but the BPDUs are no longer processed. As a result, the access switch believes it is the root of VLAN 1.
If you have two uplinks into the distribution layer everything falls to pieces. Clear VLAN 12 from both trunks, and the access switch no longer receives VLAN 1 BPDUs from the trunk, so both uplinks go into forwarding. Normal traffic passes OK, so the result is meltdown.
Has anyone else observed this?
So, on a dot1q trunk with a native VLAN not 1, are VLAN 1 BPDUs tagged or not. Are the native VLAN BPDUs tagged or not?
"On a dot1q trunk with a native VLAN not 1, are VLAN 1 BPDUs tagged or not"
If the Native VLAN on an IEEE 802.1Q trunk is not VLAN 1:
1) VLAN 1 STP BPDUs are sent to the PVST+ MAC address, tagged with a corresponding IEEE 802.1Q VLAN tag.
2) VLAN 1 STP BPDUs are also sent to the IEEE STP MAC address on the Native VLAN of the IEEE 802.1Q trunk, untagged. [IMP POINT]
3) 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.
Now from point 2 VLAN 1 STP BPDUs are also sent to the IEEE STP MAC address on the Native VLAN and because in your case NATIVE vlan is 12 and you have removed vlan 12 from trunk VLAN 1 STP will also not pass on the trunk as it is sent to NATIVE VLAN and NATIVE vlan is not allowed on thr trunk it will behave the same way it is behaving in your case.
Let me get this clear in my mind. I understand your point 2, that VLAN STP BPDUs are also sent on the native VLAN, i.e. untagged, and that therefore those will be blocked if I remove VLAN 12 from the trunk. OK.
But your point 1 says that the VLAN 1 BPDUs are also sent with the corresponding VLAN tag, i.e. tagged 1. So are you saying that VLAN 1 BPDUs are sent twice over, once tagged 1, and once untagged? In that case clearing the native VLAN should not break the VLAN 1 Spanning Tree, 'cos VLAN 1 was still allowed on the trunk. But it does break VLAN 1.
Or am I missing something subtle in your wording ... to the PVST+ MAC address ... as distinct from ... to the IEEE STP MAC address ...? Please could you explain that further.
Vlan 1's BPDUs are indeed sent twice, to the IEEE and to the "PVST" address. The BPDU sent untagged to the IEEE address is mandatory for compliance to the standard (vlan 1 is always the CST in Cisco's PVST model). The duplicate BPDU sent to the PVST address is ignored by cisco switches: these BPDUs are only used to detect pvid inconsistencies, because PVST BPDUs include in their payload the id of the instance that generated them.
What you are seing would not happen with a cat6k running IOS at least. This problem might be platform dependent because each and every platform has a different way of disabling a vlan. On the cat6k (IOS at least;-)), when you disable the native vlan, the asics are still programmed to receive control packets. I don't know if this is possible in every platform but I would consider this a bug.
Thanks for the reply. I am going to raise it with the TAC. I think it does make sense for them to be sent twice. Do you have any document that I could refer to please?
What I do know is that clearing the (unused) native VLAN from my trunks broke the Spanning Tree for VLAN 1, and caused an embarassing meltdown on the LAN. So at the very least, clearing the native VLAN should give a health warning. After all, the repercussions are much greater than portfast, and that has a health warning.
I have seen this behaviour on Cat 4003 running CatOS 8.4(5)GLX, which is almost the latest version, and on Cat29xx running 12.1.
As I see it, there were two possibilities. After I cleared the native VLAN, either the distribution switches stopped sending the VLAN 1 BPDUs, or the access switch stopped receiving them. I tested that by allowing the native VLAN on the distribution-switch side, and clearing it on the access-switch side. VLAN 1 was still broken. Therefore, clearing the native VLAN prevents the VLAN 1 BPDUs from being reveived. Now I must do the converse experiment (in the lab!): clear the native on the distribution-switch side, but allow it on the access-switch side. That will tell me whether the distribution switch is still sending them.
To be honest with you, I don't have a document to support my opinion that we should still send untagged bpdus even when the native vlan is disabled, and I doubt there exist one (I'll check a little bit). That's probably going to be controversial, because vlan 1's BPDUs are sent on the native vlan (again, the duplicate BPDU sent to the PVST address is never considered by the receiving switch). However, this behavior is not obvious and, as you pointed, needs to at least be very clearly documented if not changed.
On the top of that, not all the cisco switches behave this way!
OK, so I tried the converse experiment. I cleared the native VLAN on the distribution-switch side of the link, but not on the access-switch side. This time the access switch could see the correct root BPDUs, and know correctly who the root was.
So the conclusion is that if you clear the native VLAN from a trunk port, it stops receiving and processing VLAN 1 BPDUs - both the tagged ones to the PVST and the untagged ones to the IEEE address. But it does continue to send them. I'm not sure which it continues to send: the tagged PVST ones or the untagged IEEE ones, or even both, but enough BPDUs get through for the other side to see the root BPDUs.
I think that looks more like a bug, but it is strange that I can reproduce it on both IOS and CatOS switches. I'll see what the TAC have to say.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...