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.
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.
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.
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,
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.
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.
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
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?
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!
I would add one rule to the set of best practices:
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
Question in regards to:
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?
Sorry for interrupt :-)
But I have a simmilar question.
Have backbone/trunk with VLAN 10(Management) 20(IP phones) 30(Internet access) 990(Native).
Connecting to Standalone AP1242AG AccessPoint SSID1 is member of VLAN20, SSID2 is member of VLAN30.
I want to use VLAN10 as management on the AP.
So what should I do regarding BVI1 interface on the AP ???
Is it possible to assign ip addresses beloging to VLAN10 to BVI1, and do management that way ?? And what about native VLAN ??
Or is it just to put VLAN10 on AP an mark it as native ???
Yep. This is an unfortunate case where Cisco's best practice recommendation should not be followed. You MUST use the native VLAN for LWAP management.
RLANs need to be trunked, the VLAN that carries LWAPP/CAPWAP and carries LWAP management must be untagged. This is fine if there's no RLANs, just make it an access port, but otherwise you need to use the native VLAN to carry WLANs over LWAPP/CAPWAP and to carry LWAP management data.