Management and Native VLAN Best Practices

[rtmiles24]

Currently our network has a Native VLAN of X set on the trunk links.

We have a management VLAN of Y for all our management traffic.

I have read 2 separate recommendations regarding how to handle these VLAN's.

The first recommends using the Native VLAN as the Management VLAN.

The second recommends keeping these VLAN's separate as I currently have it designed.

Both recommendations came from reputable sources.

What is the best practice, and just as importantly, why is it better than the other option?

Thanks in advance.

[Joel]

The management and native VLAN is 1 by default. It’s good practise to separate management and user data traffic. Best practise changing the native VLAN to an unused VLAN. I would recommend if possible locking down the VTY sessions and if possible firewall the management VLAN so only relevant users can establish a connection to the kit.

SANS has an old publication on VLAN implementations. There’s a section on VLAN hoping and native VLAN.

http://www.sans.org/security-resources/idfaq/vlan.php

[rtmiles24]

Joel, Thanks for your time. I have already implemented the best practices you mentioned in your reply. I read the documentation you linked to as well. However, I am still looking for a clear reason to combine or keep separate the Native and Management VLAN's. Previously I have found differing opinions from CCIE level resources and want a definitive final answer with justification.

[Masoud Pourshabanian]

Hello,

The only reason to consider native vlan the same as manamnet vlan is having some devices which do not support vlan tagging. Those devices need to receive frames with no tag.

If all your devices support vlan tagging, assign an unused VLAN to the native VLAN, and put all unactive interfaces into that VLAN.

Hope it helps,

Masoud

[rtmiles24]

Thanks for the info! We are a pure Cisco shop so we are good to go in the VLAN tagging area.

[Gilbert Wong]

Why put all unactive interfaces into native VLAN? Can you explain more?

[weylin.piegorsch]

You might do something like to prevent accidental use of the interfaces.  The idea is that if something does connect to it when it's not supposed to, then it won't receive service since the Native VLAN should (normally, and in theory) not carry user traffic.

I'm of the opinion that you don't put inactive interfaces on the native VLAN, but rather define a VLAN ID (something other than VLAN 1 because you should avoid VLAN 1 for everything) as a VLAN for "these ports are not supposed to be in-use".  Then put inactive ports into "mode access" and apply that VLAN.

But, that's just my opinion.  Masoud showcased an environment when using the native VLAN as the "port is inactive" VLAN.  If you're in that environment then it's a perfectly valid approach.

[Jon Marshall]

What were the reasons given in the sources you mention ?

The recommendation I have always followed was to keep the native vlan separate from any other vlan so you would have a switch management vlan and a different native vlan neither of which was vlan 1.

The reason was because there used to be a possibility of vlan hopping when you used the native vlan although to be honest I don't know whether that still applies to recent switches.

I also like the native vlan to have no SVI.

There are some devices though, as far as I am aware, like APs that use the native vlan for management and you can't change it which would mean having to use a SVI for it if you wanted to connect remotely.

At least I assume it would as I don't really have any experience with wireless.

Perhaps that is what some of your resources were referring to ?

Apart from that though I can't see any benefit to combining the two.

Jon

[rtmiles24]

Unfortunately I don't remember the reasons given for combining the two. I do remember it was in a CCNP training video and it was mentioned as a best practice. So I wrote it down on my to do list and moved ahead with the project at hand.

I got back around to it this week and searched for the reasoning behind the recommendation and found info from a CCIE that recommended keeping the VLAN's separate.

Based on that and feedback from you and other nice people here, I will keep them separate and not create a SVI for the Native VLAN. 

Thanks again and take care.

[Peter Paluch]

Hi,

I may be coming in quite late as Jon and others have posted very insightful answers. Hopefully, my couple of words will still be of some help.

It has always been my personal recommendation to

• Avoid using VLAN1 and whatever native VLAN you have on your trunks to carry user traffic
• Change the native VLAN on trunks from 1 to a different unused VLAN
• Have the management VLAN to be again standalone and separate from both VLAN1 and any native VLAN you're using (this is really just a direct consequence of the previous two points)

The reasons behind avoiding the use of VLAN1 and the native VLAN for whatever user purpose are multifold. Very importantly, some of the inter-switch protocols on trunks operate explicitly in VLAN1 (such as CDP or VTP, STP being a specific case of a protocol operating across all VLANs including VLAN1) while others (such as LOOP, DTP or MSTP) operate in whatever native VLAN the trunk has. Clearly, having either VLAN1 or the native VLAN carry user traffic alongside these crucial inter-switch protocols does not feel like a good idea - just think of what an exceedingly large traffic carried over any of these VLANs could lead to if it resulted into frame drops during congestion. Even worse is the fact that a user placed either into VLAN1 or the native VLAN could maliciously inject rogue frames of these protocols into the network and wreak havoc with your equipment. Another reason is the VLAN hopping attack mentioned by Jon that allows anyone who happens to be placed into a VLAN that is used as a native VLAN on some trunk to send frames to different VLANs. (Jon, you might be interested to know that on Catalyst 2960/3560, tagged frames on access ports are accepted only if these ports are configured with a voice VLAN, otherwise they are dropped). Because VLAN1 is also by default used as the native VLAN on trunks, it is an early guess of any attacker seeking to do a VLAN hopping attack. Last but not least, you certainly don't want any device that happens to be connected to a trunk for whatever reason and not using frame tags to land in a VLAN that is used for whatever purpose. Devices incapable of operating with 802.1Q tagging are not to be connected to trunks, and if they are, it's better to prevent them from communicating rather than ending up in a VLAN into which they don't belong.

Would this make any sense?

Best regards,
Peter

[rtmiles24]

Peter,

Thank you for the detailed answer! I was doing some follow-up on this/CCNP studying and found the following best practices for VLANs & Trunking in the CCNP Switch FLG.

 -Avoid using VLAN 1 as the balck hole for all unused ports. Use any other VLAN except 1 to assign all the unused ports to it.

 - Try to always have separate voice VLANs, data VLANs, Management VLANs, Native VLANs, black hole VLAN's, & default VLANs (VLAN 1)

 - Prevent all data traffic from VLAN 1; only permit control protocols to run on VLAN 1 (DTP,VTP,STP BPDU's, PAgP, LACP, CDP, and such)

You and the other respondents were spot on and the feedback is greatly appreciated!

Rich

[Peter Paluch]

Hi Rich,

You're welcome!

I would add one rule to the set of best practices:

• Place all unused ports into a standalone VLAN, and make that VLAN to be a suspended VLAN (using the state suspend command in the VLAN configuration mode). This will cause all ports in that VLAN to become blackholed - all received frames will be dropped right away.

Best regards,
Peter

[lauriusndipwashimwe]

What is really the advantages of these best Vlan practices?

1.do not place any device or port in the native vlan

2. Do not place any ordinary user ports in the Management VLAN 

3 .Do not place anything in VLAN 1

[edsge teenstra]

Thanks for this extensive explanation, this was what i was searching for ..

Cheers 

[krunal.dave]

Hi Peter,

Question in regards to:

• Avoid using VLAN1 and whatever native VLAN you have on your trunks to carry user traffic
• Change the native VLAN on trunks from 1 to a different unused VLAN
• Have the management VLAN to be again standalone and separate from both VLAN1 and any native VLAN you're using

What do you do when your trunk link goes to a cisco access point and you are using vlan mapping? what would the native vlan be there? i believe the access point needs a native vlan for managemenet?