Shutting Down VLAN1 for Security & switchport trunk native

[travis_bonfigli]

Hello All!

I have been reading the posts both current and old regarding the shutting down of VLAN1 and the use of the switchport trunk native command.  We have been asked to harden a number of switches in our enviornment and shutting down VLAN1 was the first thing we noticed we need to address.  I think I understand the the majority of the information/reasons for shutting down VLAN1, but there were still a few things that were not making any sense so I am coming to the experts for some clarification and help.

1.  From what I read, when you "shutdown" the SVI for VLAN1 on a switch with the shutdown command, you are actually only shutting down the Layer 3 interface for VLAN1, but that VLAN1 will still pass traffic for CDP, PAgP, and other Layer 2 features.  My question is can you actually completely shutdown VLAN1 from both a Layer 3 and Layer 2 perspective?  The reason I ask is because all my reading indicates that you should shut down VLAN1 as a security precaution, but if the above question is correct is the security benefit only from a Layer 3 perspective (which could make sense since VLAN1 is the default and on all switches so you wouldn't want to have that VLAN span all along your network if there are Layer 3 interfaces involved).

2.  Also from what I have seen in the forums, the native VLAN is always VLAN1 initially, but that you can change the native VLAN.  My question here is how exactly do you change the native VLAN?  It looks like the switchport trunk native command is what does that for trunk ports, but is that actually the case?  If this is the case I also read that you should use a VLAN that is not used for anything else - so for example, I could use VLAN 888 (assuming that I am not using it for anything else) as my new native VLAN by simply setting that with the switchport trunk native command on each trunk link?  And by changing the native vlan to something like VLAN888 is all I am really saying is that now all Layer 2 features like CDP, PAgP, etc (assuming they are enabled) are going to flow over VLAN888 instead of VLAN1?

3.  I also saw that you can prune (or should prune?) VLAN1 from all the trunk links.  Is this done by using the switchport trunk allowed vlan command to only allow only the vlans you want/are using (so in effect you are denying all others)?  Or does VLAN1 always have access to the trunk links?

4.  Finally, if the switchport trunk native command is the way to change the native VLAN, can you have more than one native VLAN on the same switch?  I am thinking that if I set up multiple trunk connections to multiple switches off of one switch, you could set the switchport trunk native statement to a different VLAN as long as it matches the remote end - if you can do this is there any reason to do that or should you look to use just the same native vlan for all trunk ports.

Okay, thank you so much in advance for any assistance!!!

Cheers,

Travis

[Jerry Ye · Accepted solution]

1) Shutting down VLAN1 SVI will only shut down the L3 interface, there is not way to shutdown/delete VLAN1 at L2.

2) Like you said in your post, you can change native VLAN with switchport trunk native command for trunk port or switchport access vlan for access port. But control traffic like CDP, DTP, PAgP, and VTP will still use VLAN1.

http://www.cisco.com/en/US/docs/switches/lan/catalyst4000/7.1/configuration/guide/e_trunk.html#wp1021602

3) You can prune VLAN1 off the trunk link but control traffic will still use VLAN1.

4) No, you can only have one (1) native VLAN on a trunk. Using different native VLAN on different trunk is not a bad idea, as long as you remember to match them up. I will not use the same native VLAN on all the switch through out your switching domain, if this is the case, it makes no different with VLAN1.

The reason not to use VLAN1 is really saying not to use VLAN1 for any user data traffic. VLAN1 is created by default on all Cisco switches, and VLAN1 cannot be removed from the VLAN database. Since VLAN1 is created by default, you can create a spanning tree loop if you use VLAN1 to carry user data traffic, like native VLAN mis-match on a trunk. For example, two switch is connected via a trunk and one side's native VLAN is VLAN1 and the other side's native VLAN is VLANx. Both VLAN's will merge and create a spanning loop through out the network, if VLAN1 is used as the native VLAN. The following link give some examples why not to use VLAN1

http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a008013159f.shtml#wp39009

Regards,

jerry

[travis_bonfigli]

Jerry:

Thank you so much for the assistance!  The link was very helpful as well.  So it looks like VLAN1 is there in a Layer 2 capacity even though it is shutdown from a Layer 3 point of view.  So, even if I prune VLAN1 by not including it with the "switchport trunk allowed vlan" command, the trunk will still pass CDP, PAgP, etc. across the trunk via VLAN1 or is the fact that I am using a "switchport trunk native vlan" command dictate that all the CDP, etc. traffic will be using the vlan I define?  Or, does VLAN1 simply find a way across the trunk no matter what I declare as the native vlan?  Thank you again for the help!

Cheers,

Travis

[Jerry Ye]

If you prune VLAN1 by not including VLAN1 in the switchport trunk allow vlan command, it will affect your user data traffic running on VLAN1. For any switch control traffic, like CDP, DTP, VTP, and PAgP, it will still use VLAN1.

HTH,

jerry

[Jon Marshall]

travis_bonfigli wrote:
Jerry:
Thank you so much for the assistance!  The link was very helpful as well.  So it looks like VLAN1 is there in a Layer 2 capacity even though it is shutdown from a Layer 3 point of view.  So, even if I prune VLAN1 by not including it with the "switchport trunk allowed vlan" command, the trunk will still pass CDP, PAgP, etc. across the trunk via VLAN1 or is the fact that I am using a "switchport trunk native vlan" command dictate that all the CDP, etc. traffic will be using the vlan I define?  Or, does VLAN1 simply find a way across the trunk no matter what I declare as the native vlan?  Thank you again for the help!
Cheers,
Travis

Travis

DTP is slightly different from the other control protocols such as CDP/PAgP etc. DTP uses the native vlan to sends it's control frames. As jerry said the control protocols will always be allowed on the trunk even if you prune vlan 1 from it.

And if you change the native vlan from vlan 1 CDP/PAgP will still use vlan 1 to transmit frames. DTP will use the new native vlan. If you prune the native vlan off the trunk DTP will still use the native vlan to send frames.

Jon

[travis_bonfigli]

Jon/Jerry:

     Thank you so much for the help!  This has really cleared up a number of confusing things regarding VLAN1 and what shutting it down/changing the native vlan/pruning it will actually do - especially when it comes to trunking.  Again, thank you so much for taking the time to help me out, it is very appreciated!!!

Cheers,

Travis

[Jerry Ye]

Jon, thanks for clarifying DTP.

Regards,

jerry

[Ethen NY]

Hi Guys,

I came across this post when I was searching for the best practice to disable  Vlan 1 in our Core Network.

Almost all things are self explanatory here however i have some doubts and need some suggestions from experts on this forum.

following things I have noticed from this post

1) We can shut down Vlan 1 SVI

2) L2 Vlan 1 can not be deleted form the vlan database and hence we need to restrict all trunks in order not to use Vlan 1

2) Since we are pruning Vlan 1 on trunks, we have to allow Native Vlan (any newly created native vlan) on  the trunks to allow control traffic like CDP, STP and PaGP etc. and that this has to match on both the sides on the trunk otherwise we might end up with a STP loop due to Native Vlan mismatch.

I am planning to remove the Vlan 1 from my Data Centre Switches and hence wanted to be double sure on following things.

1) Once the Vlan 1 is restricted on trunk, will the Native Vlan carry CDP, STP and PagP etc traffic ?

2) Are there servers/any OS sending untagged traffic which needs access to Native Vlan ?

3) Is the purpose of creating Native Vlan is to carry the control traffic like cdp, stp etc when Vlan 1 is not allowed on the trunk ?

I am going to create a Native Vlan and  another SVI  and vlan x that will be assigned Vlan 1 IP.

Then I will restrict all the trunks not to carry Vlan 1.

Please help with the answers to my questions 1) and 2) above and let me know if my understanding is correct.

[Peter Paluch]

Hi Manishkumar,

The real danger does not lie in VLAN 1 being allowed on trunks but rather in allowing users to access VLAN 1 and carry their traffic over it. My personal recommendation is therefore a bit different from what has been proposed in this thread earlier:

1. You can keep VLAN 1 allowed on all trunks, or you can decide to manually prune it from trunks. Both will do. However, in any case, make sure that you do not use the VLAN 1 to carry any user traffic: Do not place access ports into VLAN 1, avoid using VLAN 1 on trunks connected to devices such as routers, servers with virtual machines, etc.
2. Configure the native VLAN on all trunks to be a different VLAN than VLAN 1, and just as with VLAN 1, do not use it for any other purpose - do not place any access ports into this native VLAN, do not use it on trunks for attached devices.

As an example, you could leave VLAN 1 allowed on all trunks and redefined the native VLAN on all trunks to 1001. From that moment on, you would avoid using VLANs 1 and 1001 for any attached device in your network - you would simply forget about them and not use them for any other purpose than to simply exist.

2) Since we are pruning Vlan 1 on trunks, we have to allow Native Vlan (any newly created native vlan) on  the trunks to allow control traffic like CDP, STP and PaGP etc. and that this has to match on both the sides on the trunk otherwise we might end up with a STP loop due to Native Vlan mismatch.

This is not entirely correct. Even if you manually prune VLAN 1 from trunks, the switch still allows all the control plane protocols that exist in VLAN 1, such as CDP or VTP, to be carried over such trunks. You therefore do not need to concern yourself too much about the fate of these protocols as they will continue to work just fine.

Moreover, you are somewhat confusing the native VLAN and VLAN 1. These two are entirely independent, and it just happens that by default, the native VLAN is VLAN 1. Even if you changed the native VLAN to a different VLAN, some protocols are tied by their design to VLAN 1. This is true at least for CDP and VTP. Even if you change the native VLAN, they will continue to operate in VLAN 1, meaning their frames will become tagged with VLAN 1 and that's it. Some other control plane protocols, however, are always carried in the native VLAN regardless of which VLAN that is. There protocols include MSTP, DTP, LOOP. These would continue being sent untagged under all circumstances.

From a principial point of view, it is necessary to allow both VLAN 1 and native VLAN on a trunk to make sure both classes of control plane protocols (those tied to VLAN 1 and those tied to native VLAN) can still be carried over that trunk. Now, entering the switchport trunk allowed vlan except 1 will prevent user data traffic in VLAN 1 from passing that trunk, however, the control plane protocols in VLAN 1 will still be allowed to pass, because such exception is built into that command by design. Regarding the native VLAN, I have seen some bugs on Catalyst switches where suspending a native VLAN (different from VLAN 1) or pruning it off from a trunk caused some of these protocols to stop working properly.

So my recommendation is: Prune VLAN 1 off the trunks if you want to. However, use a different native VLAN than VLAN 1 on all trunks, and keep all user traffic off the VLAN 1 and the native VLAN.

For whatever needs in your data center, use different VLANs than 1 and the native VLAN. Also keep in mind that the management VLAN (that is, the VLAN in which a SVI exists and which allows a switch to be remotely managed as it provides IP connectivity to that switch) has to be different from both VLAN 1 and native VLAN for the same security purposes.

Feel welcome to ask further!

Best regards,
Peter

[Ethen NY]

Thanks for the valuable Information Peter.

Ultimatly what I have understood is as follows:

1) The SVI Vlan 1 needs to be configured with another vlan say ''Vlan X (SVI and L2 also)''

2) VLAN 1 (L2) still has to be there to carry the control trafic on trunks or we can configure '' switchport trunk allowed vlan except 1'' command

3) VLAN 1(L2) must be removed from Access Ports (Server connectivity in my Case)

4) Native Vlan  may not be requiqred as vlan 1 is by default vlan 1 and is the native vlan and we will configure the command ''switchport trunk allowed vlan except 1''  which will still allow the control traffic.

Also, I have heard that there are some servers liek IBM ESX which needs to send untagged frames so, I have to also consider them as well and allow native vlan on those trunks connecting to such servers.

Appreciate your quick response.

Thanks & Regards

Manishkumar navar

[Peter Paluch]

Hi,

1) The SVI Vlan 1 needs to be configured with another vlan say ''Vlan X (SVI and L2 also)''

Better said, the SVI for VLAN 1 shall be shutdown, and another VLAN and corresponding SVI shall be created for the purpose of assigning an IP address and managing the switch remotely.

2) VLAN 1 (L2) still has to be there to carry the control trafic on trunks or we can configure '' switchport trunk allowed vlan except 1'' command

Yes. VLAN1 cannot be removed from the switch VLAN database by any means but if you feel more secure, you can disallow VLAN1 on all trunks by excluding it from the list of allowed VLANs on that trunk.

3) VLAN 1(L2) must be removed from Access Ports (Server connectivity in my Case)

Yes. In other words, every port configured with switchport mode access or lacking the switchport mode command altogether must also have the switchport access vlan vlan-id present, with vlan-id being different from 1.

4) Native Vlan  may not be requiqred as vlan 1 is by default vlan 1 and is the native vlan and we will configure the command ''switchport trunk allowed vlan except 1''  which will still allow the control traffic.

You suggest keeping the native VLAN on trunks set to VLAN1, just disallow it on trunks. I am okay with this setup as long as you do not use MSTP. I have seen some buggy behavior with MSTP and disabled native VLAN on trunks.

Also, I have heard that there are some servers liek IBM ESX which needs to send untagged frames so, I have to also consider them as well and allow native vlan on those trunks connecting to such servers.

If you intend to run trunk ports to servers, and servers need to send/receive some untagged traffic, change the native VLAN on those trunks to another VLAN. This will be the VLAN to catch the untagged traffic from/to servers. Do not make the change on trunks that interconnect your switches (on these inter-switch links, VLAN 1 will remain as the native VLAN as per your decision in Step 4), just on the trunks toward servers.

Best regards,
Peter

[polyacanthus]

Good information here. Am I correct in thinking then my trunk between an edge router and a core switch should describe at least 4 vlans for basic best practice:

vlan 1 not allowed

vlan x native but no layer 3

vlan y user traffic

vlan z management