Recommendations for tagging Native VLANs on 802.1q trunks

Anyone have any thoughts or negative issues with tagging Native VLANs on 802.1q trunks?  We have a number of Cisco IOS and NX-OS switches going into deployment with trunks between each other as well as trunks to numerous servers (for VMware implementations) and we're trying to decide whether or not to allow native VLANs on trunks, and if so, whether to tag them or not.  Just looking for insight.
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Ken BooneNetwork ConsultantCommented:
Okay so here is the deal.  In terms of an 802.1q trunk there is always a "native" vlan which is always untagged.  Then all other vlans going across the trunk are tagged.  Now this "native" vlan can be different for every trunk, but for the two ports that make up the trunk they need to match.  Also, the tags only exists while the packets are going through the 8021.q trunk.   On Cisco switches, the default native vlan is 1 and so if you do not see the commend switchport trunk native vlan x then you can assume that 1 is the native vlan which will be untagged.

Cisco pretty much doesn't recommend using vlan 1 for anything, however, I have a ton of customers that do.  If you have a large enterprise I would stay away form using 1.   Here is a blurb from a cisco doc discussing vlan 1:

3.9 Isolate VLAN 1 from User Traffic
Historically the Catalyst 6500 has used VLAN 1 as a special management VLAN. This VLAN can also be used as native (that is, untagged) VLAN on 802.1Q trunks and serves as the default VLAN for access ports. It is used by various protocols like STP, Cisco Discovery Protocol, VTP, and PAGP. One issue is that because of its nature VLAN 1 can end up spanning the entire network. This can lead to the network becoming somewhat unstable if STP loops are formed. Of more concern is that, as an untagged VLAN, VLAN 1 has the potential of being misused to initiate a VLAN hopping attack. With this attack, the user can use VLAN 1 to hop into another VLAN bypassing the Layer 3 device that normally polices the movement of traffic between VLANs.
For this reason, the recommendation is to avoid using VLAN 1 for any user traffic and as default VLAN of any port. Moreover it is recommended to use another numbered VLAN to carry the network management traffic (telnet, SSH, SNMP, and so on).
A generic recommendation is to remove VLAN 1 from all ports and trunks that do not need it. Reducing the spread of VLAN 1 will minimize the opportunity of it being compromised.

Hope that helps.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
I think the above answer is pretty complete. The only thing I would clarify is that Native VLANs and tagged VLANs are mtually exclusive- the native vlan is by definition the one that is not tagged, which by default is Vlan 1. My recommendation is to leave it that way.

From a security perspective, vlan 1 is evil and should never be assigned to a port or trunk period, including as a native vlan. VLAN 1 should be removed from all trunks and a new native vlan created, say vlan 899. In addition, VLAN 1 is used for many Cisco L2 services, CDP, PAgP, and VTP, and as mentioned above can grow very large left unattended to. The default services provided under vlan 1 and it's potential scope make it a lightning rod for exploitation.

Utilize a park vlan so you can un-assign vlan 1 default port assignments and reassign ports to the new park vlan, say 999. Also create a unique management vlan.

The segmentation of the above mentioned functions greatly enhances the overall security posture of your infrastructure.

harbor235 ;}
OWASP: Threats Fundamentals

Learn the top ten threats that are present in modern web-application development and how to protect your business from them.

Actually you can leave the native vlan as vlan1, but simply don't pass it on the trunk. I do that all the time. I only allow the vlans I actually need across the trunk, but if you want all of them then only allow 2-4094.
cdaly26Author Commented:
Thanks everyone for your feedback.  A followup question:
If I disallow the native VLAN on the trunks (ie. not include it in the allow list), what effect, if any, does this have on services like CDP, VTP, etc...  I ask because I've seen articles that say it has no effect, and others that indicate it will break them.  Thoughts?
I don't use VTP (I set all switches to transparent) so I don't know what it does to that. CDP works fine.
By the way, Cisco also recommends NOT using VTP because although it was created to make administration easier, it actually makes things much more confusing and potentially unstable.

The layer 2 services continue work fine, remember VLAN 1 is not disabled, you are just not trunking it because of the security concerns. No layer 2 service that uses VLAN 1 stops functioning. Again, do not disable VLAN 1, just do not assign it to a port nor trunk it anywhere.

 Mike, I am not sure where you read Cisco does not recommend VTP, I'd like to read that if you have a link available. From my experience VTP is a valuable tool when used properly. There were some early bugs but they were worked out some time ago. Perhaps you to not use VTP in default mode, VTP needs to be secured and must be configured so the default VTP settings do not overwrite the VLAN database of an operational VTP domain. I have worked in environments with huge layer 2 networks and VTP was never the problem, misconfiguration was always the issue. Layer 2 will not scale effectively without VTP enabled.

Also, VLAN 1 left as the native VLAN is not recommended, I would follow the steps I outlined above concerning vlans and trunking. Changing the native vlan to something other than
vlan 1 does nothing to CDP/PAgP/VTP, they still use vlan 1, however, the frames are not tagged and will not be forwarded past the layer 2 peer. Leaving vlan 1 as the native vlan will allow the CDP/PAgP/VTP information to be forwarded everywhere in the switch mesh just waiting to be collected by someone that should not be. Why would you be broadcasting details about your network?

hope this helps,

harbor235 :}
Ken BooneNetwork ConsultantCommented:
Cisco's best practices have recommended not using VTP, however on a large scale network with good config management and good engineers it is an effective tool.  Problems caused by VTP are almost ALWAYs caused by an engineer who doesn't understand it and misconfigures something.  In the small to medium market its best to shut down VTP and avoid the risk.  In fact on most of the switches that run the smartport macros, the global cisco macro sets the vtp mode to transparent.  These were created to help guys who didn't know much about switch setup set up switches easier according to best practices.  So harbor I agree on a large scale network its great, but only if you have guys that know what they are doing.  On the small to medium side of the house I would recommend turning it off.

As far as when to use VTP I agree, obviously you do not need VTP if you have a static environment or not have many vlans to worry about it.  It's a function of your spanning tree topology and the number of vlans you are trunking. At some point it becomes more work to trunk the appropriate vlans where needed as well as creating the same vlans on every switch, Sooner or later it becomes a ton of work. I hope you are not advocating trunking all vlans by default?

I still would like to see where Cisco best practices recommends not using VTP?  Again, I assume you are reading that its best to avoid VTP with its default settings.

This is a good conversation,

harbor235 ;}
Ken BooneNetwork ConsultantCommented:
Here is a document that presents the idea for turning it off.

This doc is dated but it has a ton of good information in general on it.

In every doc that talks about smartports it mentions this is best practice as well:

you need to look at the "macro global apply cisco-global"

I have noticed that on 1 series of switch it sets it to server, but on most of the switches now, the current cisco-global smartport sets vtp to transparent.  I can't remember which switch it is.  It might be an older 2950 but I can't remember

But again it all comes down to the size of the network and the risks associated.  I have one customer that has a large network of about 300 switches, with probably about 500 vlans.  At one point they had a lightening hit that took down one of their 6500s.  When it came back up, something happened without any user intervention and for some reason multiple vlans were gone and immediately removed from switches across the network.  Half the vlans were gone.  With VTP transparent this never would have happened.  They are now VTP transparent everywhere.  

So yes there is overhead when setting up a new vlan, however, the vlans are only configured on the switches and trunks where it needs to be and no where else, so yea we might have to hit 5 or 6 or 8 switches when a new vlan is added, but there is no risk of the network crashing due to vtp.  For them it was a good trade-off.  For smaller networks, many times you don't have engineers that fully understand all the ramifications nor have any type of change management controls and they say hey this is great turn it on and let it run in server mode, and then don't pay any attention to it at all and the lack of understanding brings a large risk to those smaller company's networks.

So the 300 switch network could benefit from VTP with pruning, but with different engineers coming in and out from different integrators, and IT staff that is not real experienced its best if they leave it off.  They can't take the downtime as public safety is a concern on this particular network.

I think if you reread my first statement concerning VTP you will agree, I never said it was good in all situations, I did not agree that VTP is a bad thing and I also did not agree that Cisco recommends against using it.  My original discussion about VTP detailed the problems with VTP (misconfigurations and securing it against the default settings).

The docs you referenced do not state that Cisco recommends against using it, and thats my point.  Are there situations where it may not be the correct technology given requirements, sure.

As for the effects of a lightning strike to VTP, I guess we should turn off BGP, OSPF, ........... as well and go to static routing?  

harbor235 ;}
Ken BooneNetwork ConsultantCommented:
Yes there have been cisco docs that showed it as best practice  - i have seen them on several occasions.  But unfortunately I am trapped in a hotel room that has the crummiest wireless network and I keep losing signal so its a little hard to  surf...  but anyway I know there were specific smartport documents that discussed each command of each smartport macro.  Every command that was put in the built in macros where put there based on best practices.   There used to be some docs that specifically broke down each macro and went through and detailed why it was best practice.  I know I have seen vtp transparent discussed in those docs as being the best practice.  

I agree that you are non-commital on whether it is or whether it isn't a bad thing and that you were merely pointing out the issues of msiconfiguration and the problems thereof ;)  

But I definitely have seen cisco docs showing vtp transparent as the best practice.  Now having said that I don't know how old those docs are..  I have been doing this a long time... too long in fact.

From personal experience over the years I have seen many side affects from customers running vtp.  The power outage was one thing.  I have had customers inadvertantly delete vlans throughout the whole network (lack of understanding and experience).  I have seen odd results when a non cisco switch received a vtp packet and decided to throw the network into a loop.  These were avaya cajun core switches that were introduced into a cisco network.  VTP is cisco proprietary, and the cajuns totally freaked out - all 3 of them and even though stp was setup properly the cajuns immediately threw themselves into a loop and took down the network.  I have seen oddities pop up on several occassions with other vendors switches as well.  

So from my personal experiences over the years it is my opinion that in the majority of cases there is more potential for harm than good.

It is my personal opinion that if you use VTP you need to understand the risks thereof, and proceed with caution.  Once you have a network that is so big that manually creating vlans is that big of a problem, its probably time to start thinking about moving to L3 anyway and just avoid the whole stp thing as well!   I personally don't think it is worth the risk for most of my customers to run vtp.

So not arguing with you other than the fact I know I have seen cisco docs state that vtp transparent was best practice - not to say those docs may not be dated ;)    But anyway I think the author now has a good understanding of some of the issues and ramifications of using vtp as a result of this conversation.  Its all good.
Ken BooneNetwork ConsultantCommented:
I found one of the docs.  It is the SRND for camppus network high availability doc:

It says:

"The following are best practices to use when deploying multiple VLANs on a single switch-to-switch interconnection or trunk:

•Deploy VLANs on the interconnection between access and distribution layers.

•Use VLAN Trunking Protocol (VTP) in transparent mode to reduce the potential for operational error.

•Hard set the trunk mode to on and the encapsulation negotiate to off for optimal convergence.

•Assign the native VLAN to an unused ID or use the Tagged Native VLAN option to avoid VLAN hopping.

•Manually prune all VLANS except those needed.

•Disable Trunking/VLAN tagging on host ports with the following commands: "


" The benefits of dynamic propagation of VLAN information across the network are not worth the potential for unexpected behavior due to operational error. For this reason, VTP transparent mode is the recommended configuration option. "

Now having said that the doc of course really pushes the l3 core distribution access model which really eliminates the need for a lot of vlan trunking anyway.


Do you see my point though, saying VTP is not recommended and use VTP using best practices is a whole different thing. The same can be said about BGP, running BGP with default settings is not recommended, there are a whole slew of best practices to make it safe and scalable. However,
you never hear of anyone saying Cisco recommends not to use BGP, that's all I am saying, trying to give cdaly26 perspective on when and when not to use VTP.

I don't disagree with what you are saying.

harbor235 ;}
Regarding making the native vlan something other than vlan 1- I don't think it matters whether it is vlan 1 or something else. The native vlan is by definition the untagged one. There is nothing special about vlan 1 in and of itself that makes it more risky to use as the native vlan EXCEPT for the fact that by default it's on everywhere, which makes it easier to jump on to. I may be wrong about that, but I think the point is:
1. Don't use vlan 1 for user traffic
2. Don't use the native vlan for user traffic
3. On trunks, don't propagate or configure vlans that aren't needed.

To harbor235's credit, the security best practices document I have, which is a PDF I printed out a long time ago, actually says "Configure the VTP domains appropriately or turn off VTP altogether..."

I like the control that I have by doing it manually, and I've done it that way even in a very large organization like an unnamed enormously big bank. But I also don't believe in spreading VLANs everywhere- I use different vlans for different floors, buildings, etc. the one time that VTP was left on (server everywhere), someone deleted a VLAN from a switch and it deleted it from another switch where it killed an active network- never again! I think administrative control is far more important than the minor convenience of not having to configure vlans on a couple of switches.  And if you have a ton of switches sharing a vlan, my personal opinion is that you need to redesign your network.
Ken BooneNetwork ConsultantCommented:
Now having read all this and looking some stuff up, I learned that there is an option now where you can tag the native vlan on the trunk.  Apparently its been around for awhile.   Check out this link guys.  You might already know about this but thought I would pass this one.  Lot of good info in this post!

That's a great article, especially with the followup posts. I might have to try that, but I'm concerned about whether it would kill the link until both sides are configured- not a good thing to do on a production network during the day.

Although we leave Vlan1 as the native vlan, untagged, we NEVER use vlan 1 for traffic, we never allow it across a trunk, and we keep all unused ports disabled. The result is that anyone who wants to do this attack already has to have enable-level access to the switch- in which case they can do whatever they want anyway.

One reason to change the native vlan is that 802.1q trunks use the native vlan to establish communication between layer 2 peers. Segementing layer 2 services to multiple vlans can only enhance your security posture. Allowing all layer 2 services to use the same vlan (vlan 1) only increases the risk of exploitation, why not segement and make it harder? If you change the native vlan DTP/STP/UDLD will use the new native vlan. There are numerous tagging attacks out there, again, protecting trunks especially from a autoconfiguration standpoint by seperating that function to a seperate non user vlan stregthens your security posture.  There are also double encapsulated frame attacks, if you change your native vlan to something non standard this elimates an attack vector on trunks becuase they now do not know the native vlan for trunk links and the default vlan for all  layer 2 services.

So if we leave all layer 2 services in vlan 1 this allows for a predicatble attack vector on the layer 2 infrastructure, as I mentioned above, double encapsulated later 2 attacks can occur from a user port in any vlan. (Security best practices on users ports help eliminate this as well)

The other key componenet is to also segment the management function to a seperate vlan from the native and park vlans, normally vlan 1 is used for this function by default as well.

This has been a good discussion,

harbor235 ;}
I should add- we never use Vlan1 for the management vlan either- management goes on either the user vlan or a separate management vlan, depending on the circumstances.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Network Architecture

From novice to tech pro — start learning today.