cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5112
Views
5
Helpful
6
Replies

Native VLAN Question

snowmizer
Level 1
Level 1

I am working on a core switch replacement and am working on setting up the trunk ports. I've read various documents, posts, etc... about native vlans and am in information overload. I'm hoping that someone here can either clear up things or confirm what I'm thinking.

1. I've got trunk ports configured for connections between switches, connections for our VNX data mover LACP port channel, and connections for the port channel used for our UCS fabric interconnects. I understand that the native vlan on a port needs to match on both ends of the connection or a mismatch error will result. However, I'm not sure I can specify the native vlan on the VNX or UCS so I'm thinking that I don't want to specify the native vlan on these ports. Is this correct or do I need to specify the native vlan on all trunk ports?

2. I've read that I should create a native vlan that isn't used anywhere else on the network and then specify that vlan as the native vlan on my trunk ports. If I'm thinking correctly I should only need to create the vlan in the vlan database using the "vlan xx" command and then "switchport trunk native vlan xx" on my port. I don't believe I need any type of interface vlan set up with an IP address, etc.... Is this correct or do I need an "interface vlan" with no ip address and the no shutdown command specified?

3. I've also read that the native vlan needs to be part of my "switchport trunk allowed vlan..." list on the trunk port because it passes things like BPDUs, CDP, DTP, etc...traffic on the native vlan. But I've also seen that the native vlan shouldn't be part of the allowed vlan list. Which is correct?

4. Is there any type of switch control type traffic that needs to be allowed from vlan 1? Can this vlan be shutdown?

 

Thanks.

6 Replies 6

jj27
Spotlight
Spotlight

 

1. I've got trunk ports configured for connections between switches, connections for our VNX data mover LACP port channel, and connections for the port channel used for our UCS fabric interconnects. I understand that the native vlan on a port needs to match on both ends of the connection or a mismatch error will result. However, I'm not sure I can specify the native vlan on the VNX or UCS so I'm thinking that I don't want to specify the native vlan on these ports. Is this correct or do I need to specify the native vlan on all trunk ports?

 

It is recommended to apply the native VLAN to all trunk ports on interswitch links; however, you are correct that you cannot supply a native VLAN on the Fabric Interconnect uplinks and I would assume the same for VNX, but I do not know that storage product.  Keep in mind that within UCS and your VNX there should not be any traffic leaving those environments that are not already tagged in one way or another.  Those are controlled environments.  UCS will automatically configure the Ethernet uplinks with a VLAN allowed list based on the VLANs configured in the system.

 

2. I've read that I should create a native vlan that isn't used anywhere else on the network and then specify that vlan as the native vlan on my trunk ports. If I'm thinking correctly I should only need to create the vlan in the vlan database using the "vlan xx" command and then "switchport trunk native vlan xx" on my port. I don't believe I need any type of interface vlan set up with an IP address, etc.... Is this correct or do I need an "interface vlan" with no ip address and the no shutdown command specified?

 

You are correct that the VLAN has to exist in the VLAN database in each switch, but you do not need an interface created for it.  The native VLAN in this case is sometimes referred to as a blackhole VLAN and it is usually shutdown. Usually all unused switchports are configured for the blackhole VLAN and administratively down, but it depends on the security requirements of your network.

 

3. I've also read that the native vlan needs to be part of my "switchport trunk allowed vlan..." list on the trunk port because it passes things like BPDUs, CDP, DTP, etc...traffic on the native vlan. But I've also seen that the native vlan shouldn't be part of the allowed vlan list. Which is correct?

 

The native VLAN does not need to be allowed on the trunk unless you specifically need to allow devices on that VLAN to communicate, but that defeats the purpose of having an UNUSED VLAN for the native VLAN.

 

4. Is there any type of switch control type traffic that needs to be allowed from vlan 1? Can this vlan be shutdown?

 

Yes, you can shutdown VLAN 1 with no worries.  Control traffic such as CDP, LACP, etc. are still sent across the link regardless.  I believe on the Nexus platform you cannot even shut down VLAN 1, but I'm not 100% sure. 

Thanks for the explanations. It's helpful to have someone confirm what I was thinking. One final question....

Currently we have two 4506 switches acting as our core switches. We have glbp set up on these switches and have all vlans duplicated across these switches. In our new environment I am replacing the 4506s with two 4500-X switches and three 2960-X switches. The 4500-X switches are in a VSS pair so I only have to configure the vlans once and the config gets replicated. Now I'm going to have all of the access ports that were previously on blades in the 4506s on the 2960-X switches. Do I need to create all vlans on each stack across the board (on the 4500-X VSS pair and on the 2960-X stacked switches)? I'm thinking I need to at least add them to the vlan database. What I'm also wondering is if I need to create an "interface vlan xx" with an IP address on each stack for each vlan since it's possible that traffic could pass between switches on each vlan?

Thanks.

It's not entirely clear what you are going to use the 2960s for.

If they are just going to be used as access switches for the clients ie. L2 only then you do not need SVIs for each vlan on them ie. all the inter vlan routing would be done on the 4500s.

You would need the vlans in the vlan database on all switches and for management you should use a dedicated vlan and you would need an SVI on the 2960s for this.

The 4500s would also have the management vlan and the default gateway on the 2960s would point to the IP address assigned to the management vlan SVI on the 4500s.

If you are talking about routing on the access switches then the above does not apply.

Jon

Something on CDP: "All CDP packets include a VLAN ID. If you configure CDP on a Layer 2 access port, the CDP packets sent from that access port include the access port VLAN ID. If you configure CDP on a Layer 2 trunk port, the CDP packets sent from that trunk port include the lowest configured VLAN ID allowed on that trunk port. The trunk port can receive CDP packets that include any VLAN ID in the allowed VLAN list for that trunk port." from Cisco's webpage: http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/5_x/nx-os/system_management/configuration/guide/sm_nx_os_cg/sm_4cdp.html

Dharamjeet Brar
Level 1
Level 1

1. No. Native VLAN mismatch error is triggered by CDP protocol that exchanges information between devices. If you are not willing to exchange data betweek adjacent ports using the native vlans (VLAN 1 by default) on either side, feel free not include the native vlan in "switchport trunk allowed vlan x,y,blah.." list. If native VLANs on both ends of the link are different, CDP will trigger the error. It is annoying, that is why people bother changing the native VLAN to fix this error. Essentially CDP is the culprit here, not the port. Another way around is to turn off CDP, not recommended, as CDP helps in troubleshooting sometimes. Use "show interfaces trunk" to verify what VLAN is native VLAN for an interface.

 

2. Purpose of not using native VLAN for transport is usually security. By default the native VLAN on a port is "VLAN 1", you only specify "switchport trunk native vlan blah..." command if you want to change that. No, you do not need to create a layer three interface for a VLAN you do not intend to use. Go read this artivle on NetworkWorld by Scott Hogg: "http://www.networkworld.com/community/node/38732", he explains it very well.

 

3. Again, if you are not going to use the VLAN 1 (by default native for the interface) or any native VLAN for that port to data transfer, do not add it to the allowed vlan list. About BPDUs: only allowed VLANs exchange BPDUs on a port. If a VLAN is not allowed on a port, it just means this link is not the part of logical topology for that VLAN, it kinda breaks the switching loop in a sense.

 

4. No need to allow anything for a VLAN if you do not intend to use it.

 

The way native VLAN works is, if you send traffic from a port with that VLAN ID (provided that the VLAN is allowed on the port), it is sent untagged by default. You can force tags on native VLAN by specifying "switchport trunk native vlan tag" on an interface level or completely remove VLAN from the interface allowed list "switchport mode trunk allow vlan remove blah..." or you can comnfigure a global command to tag all native VLAN traffic "vlan dot1q tag native" on the switch. If you change the native VLAN on a port using "switchport trunk native vlan blah...", it specifies that do not tag this VLAN for any traffic you are sending using this VLAN tag (unless you did anything specified in the last line).

 

---------------------------------------------------------------------------------

Feel free to disagree and let me know where you feel I am going wrong.

Hi guiarista, regarding what you said about tagging packets from the native vlan with "vlan dot1q tag native", you should mention that if you do so, you need to add the Vlan ID of the native vlan to the trunk allowed list. Otherwise, the frames will be dropped.

Am I right? I've tested this in a lab and I always need to allow the native vlan in the trunk if I have configured "vlan dot1q tag native" to prevent vlan hopping. If I'm doing this wrong, please someone correct me.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: