Link to home
Start Free TrialLog in
Avatar of jamieroth
jamieroth

asked on

Which VLAN should be used for the Native VLAN on a 802.1q Trunk

I will be setting up a 802.1q trunk between a c5500 and a c2924. Right now the link between the two switches is not trunked. All ports on the c2924 are on VLAN 1. The port on the 5500 is on vlan 134. I need to setup a trunk so that I can add two VLANS to the c2924. Most of the ports will be on VLAN 134. Should I make VLAN 134 the native vlan for the trunk since that traffic won't be tagged, or should I place both sides of the trunk on VLAN 1? If I make VLAN 134 the native VLAN what needs to be done to make it the management VLAN?
ASKER CERTIFIED SOLUTION
Avatar of harbor235
harbor235
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Cisco reccommends that you use Vlan1 as the native vlan for those ports, but prune it from the trunk. They also say to use a different vlan for switch management (NOT the default vlan 1) and 3rd one for user data.

They also suggest not putting any ports on vlan1 that don't specifically need it, including unused and shut down ports.
Avatar of j3ggs
j3ggs

I would personally make the one that is the management VLAN. This way, if the trunk fails you can manage the box still. This should therefore be done both sides.
Avatar of jamieroth

ASKER

The reason I was thinking that VLAN 134 should be the native VLAN is because most of the workstations on the 2924 will be on VLAN 134. All of those frames wouldn't need to be tagged if 134 was the native VLAN on the trunk. Does this make sense? Would it even make that big of a difference? I believe the 802.1q tag is 4 bytes for every frame that isn't on the native VLAN.
1 is the one you should use even if you are not going to send any traffic over it. I myself when I have a choice on larger networks prefer to use 1 as a management VLAN for the switches with it’s own subnet. It’s easer to secure them that way with access lists, also it adds a level of obscurity to the underlying network, which doesn’t hurt either.  
At my last employer, which was a huge bank, we used VLAN 1 for the management vlan. But at my current employer, and in a Cisco document on Vlan security best practices I read (doesn't seem to be available on the public part of their web site- a Cisco SE sent it to me), they suggest what I stated earlier.

It will work no matter which way you go. The main reason Cisco says to use VLAN 1 for native but then prune it from the trunks, is that in a larger network VLAN1 spanning tree can get to be very messy and unstable. If you're using it for switch management, it makes switch management unstable in turn. At the bank, we were very careful about switching design so that spanning tree wasn't much of an issue.
You do not want to remove vlan 1 from any trunk, as stated earlier Cisco runs key services from this vlan, things will break, What you want to do, in the case of a large network is use another vlan for management and not trunl vlan 1 anywhere, I would love to see that document that says you should remove vlan 1 from trunk ports.

harbor235
I remove it from trunk ports on a regular basis. I do this on trunks that are running Etherchannel too, without consequence. CDP runs on VLAN 1 by default. If VLAN 1 is not there it will automatically run on another VLAN. I always use VTP transparent mode for safety and stability, so I don't know offhand if it would affect VTP VLAN propagation- it might.

Unfortunately the document I was sent by my Cisco SE is a pdf or I'd post the URL here. But I quote: "VLAN 1 may sometimes end up upwisely spanning the entire network if not appropriately pruned and, if its diameter is large enought, the risk of instability can increase significantly. Besides, the practice of using a potentially omnipresent VLAN for management purposes puts trusted devices to higher risk of security attacks from untrusted devices that my misconfiguration or pure accident gain access to VLAN 1 and try to exploit this  unexpected security hole." and later on the same page: "Prune VLAN 1 from all trunks and from all the access ports that don't require it (including not connected and shutdown ports)."