Monday, January 31, 2011

Revisiting the VLAN 1 Myth - Again!

Over on the ipexpert blog, Marko recently busted the myth that "VLAN 1 is always allowed on switch trunks."

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.
Control frames don’t really belong to any VLAN per-se – they belong to the switch, regardless of the VLAN they are received on.
I can only mostly agree with Marko here.  Consider the following topology:

What should the CDP frames look like?  Cisco Press (swiped from a comment on Marko's post) says:
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).
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:

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.


  1. Very nice write-up. Updating article now :-)

    Marko Milivojevic - CCIE #18427 (SP R&S)
    Senior Technical Instructor - IPexpert

    1. This comment has been removed by a blog administrator.

  2. Thanks, Marko!

    For 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.

  3. So if i miss understood both yours' and Marko artical.
    I'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 ??

  4. @ June 5 anon,
    Yes, 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.

  5. This comment has been removed by a blog administrator.

  6. Thanks, Marko!

    how control traffic will be sent ??

  7. 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.