I'd like to present a rebuttal :-)
The origins of the myth seem to me to be threefold:
- On old platforms, you really couldn't remove VLAN 1 from tagging interfaces
- Cisco documentation indicates that control traffic always uses VLAN 1
- There's an unrelated VLAN traversal attack involving VLAN 1, which is just one more reason to avoid using it.
Marko clearly demonstrated that transit traffic on VLAN 1 can be pruned from a trunk, and concluded:
control traffic (VTP, CDP, STP) is sent untagged [...] All untagged traffic on trunks belongs to native VLAN… except for those control frames which don’t.I can only mostly agree with Marko here. Consider the following topology:
Control frames don’t really belong to any VLAN per-se – they belong to the switch, regardless of the VLAN they are received on.
What should the CDP frames look like? Cisco Press (swiped from a comment on Marko's post) says:
So, even though VLAN 1 is disallowed from the trunk, frames tagged with VLAN 1 should still appear there. Wireshark agrees. Cisco Press is vindicated:It is important to understand that even if the native VLAN of an 802.1Q trunk is not VLAN 1, all of the above protocols (with the exception of DTP as indicated in the previous note) are still sent on VLAN 1, with a tag attached indicating VLAN 1 is not the native VLAN (if the native VLAN is VLAN 1, then messages are sent without a tag).
While you can definitely remove VLAN 1 transit traffic from a trunk, control frames really do belong to VLAN 1, and you can't remove these frames from the trunk. VLAN 1 is magic afterall.
Myth somewhat un-busted.
Very nice write-up. Updating article now :-)
ReplyDelete--
Marko Milivojevic - CCIE #18427 (SP R&S)
Senior Technical Instructor - IPexpert
This comment has been removed by a blog administrator.
DeleteThanks, Marko!
ReplyDeleteFor the record, I presented *exactly* your argument a few months ago:
"it's not native traffic, nor is it VLAN 1. It doesn't belong to any VLAN!"
I didn't believe Cisco Press either when one of my pals (Hi George!) brought it to my attention. Not until I ran the test anyway.
The fact that this traffic gets tagged is surprising indeed. I think the roots of this design decision lie in interoperability between different STP technologies.
So if i miss understood both yours' and Marko artical.
ReplyDeleteI'm putting my question again here as, what if I changed the Native Vlan on Switches and disallow Vlan 1 in the Trunks ???
Will control traffic ( like VTP, STP, etc) will still be sent ??
@ June 5 anon,
ReplyDeleteYes, it will be sent. Look at the configuration snippets embedded in the diagram above. I have changed the native VLAN and disallowed VLAN 1, just like you propose.
The captures show that control traffic is still sent, and that it's tagged with VLAN 1, in spite of the prohibition by the allow list.
This document also helps a lot.
ReplyDeleteBest Practices for Catalyst 6500/6000 Series and Catalyst 4500/4000 Series Switches Running Cisco IOS Software
http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a00801b49a4.shtml
Especially the following part :
In summary, note this information about trunks:
CDP, VTP, and PAgP updates are always forwarded on trunks with a VLAN 1 tag. This is the case even if VLAN 1 has been
cleared from the trunks and is not the native VLAN. If you clear VLAN 1 for user data, the action has no impact on control
plane traffic that is still sent with the use of VLAN 1.
l
On an ISL trunk, DTP packets are sent on VLAN1. This is the case even if VLAN 1 has been cleared from the trunk and is no
longer the native VLAN. On an 802.1Q trunk, DTP packets are sent on the native VLAN. This is the case even if the native
VLAN has been cleared from the trunk.
l
In PVST+, the 802.1Q IEEE BPDUs are forwarded untagged on the common Spanning Tree VLAN 1 for interoperability with
other vendors, unless VLAN 1 has been cleared from the trunk. This is the case regardless of the native VLAN configuration.
Cisco PVST+ BPDUs are sent and tagged for all other VLANs. See the Spanning Tree Protocolsection for more details.
l
Cisco - Best Practices for Catalyst 6500/6000 Series and Catalyst 4500/4000 Series Switches Running Cisco IOS Software
http://kbase:8000/paws/servlet/ViewFile/24330/185.xml?convertPaths=1 (5 of 100) [8/24/2006 10:40:37 AM]
802.1s Multiple Spanning Tree (MST) BPDUs are always sent on VLAN 1 on both ISL and 802.1Q trunks. This applies even
when VLAN 1 has been cleared from the trunks.
l
Do not clear or disable VLAN 1 on trunks between MST bridges and PVST+ bridges. But, in the case that VLAN 1 is
disabled, the MST bridge must become root in order for all VLANs to avoid the MST bridge placement of its boundary ports
in the root-inconsistent state. Refer to Understanding Multiple Spanning Tree Protocol (802.1s)for details.
This comment has been removed by a blog administrator.
ReplyDeleteThanks, Marko!
ReplyDeletehow control traffic will be sent ??
First, thanks for the work on this. I'm sure you all spent several hours/days setting up labs and figuring it out, and I get to 'steal' the info in 15 minutes. I also found a little more to this puzzle that I found interesting. The setup is a 6504 with all layer 3 interfaces at the hub site, which connects to a asr 1002 at a remote site. The asr 1002 has two branch sites off of it that are 3825s. The asr and 3825s all have 1 interface that is configured to have sub-interfaces with non-native vlan1 configured (i.e. encapsulation dot1q x native) for the LAN segments. What is interesting is that it doesn't seem to just affect the vlan trunking interfaces, but the whole chassis. The 3825s see the asr b/c they have non-native vlan 1 sub-interfaces and can interpret the vlan 1 tagged frame, whereas the 6504 does not have any sub-interfaces, and cannot read the cdp frame. I haven't taken pcaps to verify, but it does seem that once you create a sub-interface with non-native vlan 1, all interfaces on the chassis start tagging vlan 1.
ReplyDelete