802.1Q Native VLAN on Cisco IOS Switch

u.forte · November 26, 2022, 11:35am

Hi, i want information please

I have see example from my customer there are some swtich with native vlan different form Vlan1 example switchport trunk native vlan 250
Why this command ?

thanks

lagapidis · November 28, 2022, 6:21am

Hello Ugo

By default, when you create a trunk, the native VLAN is set to VLAN 1. However, it is best practice to change the default native VLAN to something other than VLAN1. This should be done to mitigate security threats such as VLAN hopping.

More info on the threat of VLAN hopping can be found at this lesson:

I hope this has been helpful!

Laz

paminett · January 8, 2023, 7:18am

Question: Defaults for cisco are ports set to the default VLAN 1 and native VLAN to be on 1.

If we change the native VLAN to 99, does that make all ports still on VLAN 1 now tagged? ie when a frame goes to the port it gets tagged with vlan 1.
If I wish to keep using VLAN 1, would I need a subinterface on the router? Since now, frames are being tagged with VLAN 1?

Thanks

lagapidis · January 11, 2023, 10:59am

Hello Patrick

Yes, that is correct. Just a clarification, though, keep in mind that the native VLAN is set to 1 on any trunk ports that may be configured. The native VLAN only has meaning when we’re talking about trunk ports. If a switch has no trunk ports, then the native VLAN is non-existent.

If we change the native VLAN on a specific trunk port to 99, this does not affect any other port on the switch. The only thing it does is, if an untagged frame is received on that trunk port, that frame will be placed on VLAN 99. Remember that access ports that may be assigned to VLAN 1 will never “see” any tags at all regardless of what the native VLAN is on any trunk port.

If you have changed the native VLAN on a particular trunk port, then frames on VLAN 1 will only be tagged when sent over that trunk port. As for subinterfaces on a router, this is only done when you are configuring router on a stick. For more info on that, take a look at this lesson:

I hope this has been helpful!

Laz

marcel.schmid2 · August 22, 2023, 12:36pm

Hi @lagapidis,

I’ve just scrolled down through the posts and got a question to your statement:

I tested this with the following topology in EVE-NG and observed a different behaviour than you described.

Interface “e0/0” on S1 & S2:

switchport mode trunk
switchport trunk encapsulation dot1q
switchport trunk native vlan 999

Interface “e0/1” on S1 & S2:

switchport mode access
switchport access vlan 999

Now, when PC1 is trying to ping PC2, the Ethernet frame isn’t getting tagged on the trunk according to Wireshark capture.

As for my understanding, based on this topology the Ethernet frame gets tagged in three scenarios. When…
a) changing the VLAN on the access ports (to other than the native VLAN)
b) changing the native VLAN on the trunk ports (to different than the access VLAN)
c) activating native VLAN tagging globally

However, the Ethernet frame doesn’t get tagged, if the access VLAN is identical to the native VLAN.

Can you confirm this, or am I misunderstanding something?

Many thanks in advance. Your replies are awesome!

lagapidis · August 28, 2023, 4:57am

Hello Marcel

Concerning the answer you quoted from my previous post, I was responding to a question about Native VLAN tagging. The first question stated by the poster was, "What would happen if native VLAN tagging were enabled? " If that is the case, then frames belonging to the native VLAN sent over the trunk will be tagged.

In the scenario you tested, there is no native VLAN tagging enabled, so the behavior you see is expected.

All things being equal in your topology, if you make these changes, then the frame traversing the trunk will indeed be tagged.

For more info, take a look at this NetworkLessons note on the topic of Native VLANs and untagged frames.

I hope this has been helpful!

Laz

jayashree.seeni · January 20, 2024, 10:48am

Please explain more about Native VLAN, its purposes and share use cases.

lagapidis · January 22, 2024, 11:20am

Hello Jayashree

First of all, take a look at this lesson that talks about the Native VLAN:

You can also get some more information in th NetworkLessons Notes site at these particular notes:

If you have any other specific questionsa about the native VLAN, please let us know!

I hope this has been helpful!

Laz

premswan · May 16, 2024, 7:01am

Hi @lagapidis ,
Is the below scenario valid?, if yes, PC 2 will ping PC 3?

lagapidis · May 18, 2024, 5:36am

Hello Premkumar

If your fundamental question is “will this work” then the answer is yes, it will. PC2 will be able to ping PC 3 assuming their IP addressing is on the same subnet. This is because SW1 and SW2 are connected to each other over access ports. When a frame exits SW1 on that port, no tag information is included, so when SW2 receives that frame on the access port, it will place it on the VLAN configured on the access port.

Now is this scenario valid? It’s definitely NOT recommended. As the topology is, it will function, however, if you expand your network, create trunk links to other switches, and include the various VLANs in those trunks, things will get mismatched. It’s a good idea to keep your VLANs consistent across the whole topology.

I hope this has been helpful!

Laz

premswan · May 19, 2024, 8:42am

Great explanation! Of course we should use trunk ports between switches. I wanted to understand different access vlan ports behavior and can be used or not. Thanks for the clarification.

sathish84be · June 22, 2024, 12:47pm

I had somehow understood the concepts until now, but this statement confused me. Could you please be a little bit brief on this? I’m sorry for asking a dumb question.

davidilles · June 22, 2024, 3:40pm

Hello Sathish

Take a look at this

SW1(config)#vlan dot1q tag native
SW2(config)#vlan dot1q tag native

If you decide to tag the native VLAN on a trunk port, anything that is untagged and received on that trunk port will be dropped

PC3#ping 192.168.10.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.1, timeout is 2 seconds:
!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/5/7 ms

Everything is working so far. Now, let’s configure SW2 to not tag the native VLAN, so it will send anything from PC3 in VLAN 10 untagged. Let’s see what SW1 will think about this.

SW2(config)#no vlan dot1q tag native

PC3#ping 192.168.10.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.1, timeout is 2 seconds:
.....

As you can see, SW1 dropped this traffic. The reason for this is that the moment you configure native VLAN tagging, the switch will drop any traffic that simply isn’t tagged. Since I’ve left native VLAN tagging configured on SW1, it dropped the traffic.

If you’re still confused, please let me know. And don’t apologize for asking questions, how else are you supposed to learn something? We’re glad to help.

David

sathish84be · June 23, 2024, 11:49am

Hello @davidilles
Really appreciate you taking the time to address my doubts. I am now confident

lagapidis · June 25, 2024, 3:56pm

Hello Sathish

As usual, @davidilles did a great job in answering your question. I believe that my statement you highlighted may have been a bit confusing, so I updated it in my post.

Laz

sathish84be · June 26, 2024, 10:29am

Great, appreciate it @lagapidis

psf1575 · November 3, 2024, 5:26am

Hello Laz,

Given the topology shown in the question above, you state that once VLAN 99 is allowed on the trunks of both switches, that “VLAN 99 traffic will be tagged just like all other traffic”. My understanding is that given the configuration shown in the topology, traffic from VLAN 99 would only be tagged if we configure both switches to tag traffic originating from the native VLAN. Therefore, in the absence of the vlan dot1q tag native command on both switches, frames originating in VLAN 99 would traverse the trunk ports untagged, since VLAN 99 is the native VLAN configured on our trunks. Theres no mention of native VLAN tagging being configured on both of these switches, therefore any frames that hosts C and D send each other would traverse the trunk link untagged. Correct?

Similarly, in the following post 802.1Q Native VLAN on Cisco IOS Switch - #109 by lagapidis you mention that “Hosts C and D are on VLAN 99 which is configured as the native VLAN on the trunk. If C pings D, the frame will be tagged when it egresses Fa0/1 on SW1. Such frames will be tagged regardless of whether or not native VLAN tagging is configured. So to answer your second question as well, these frames will always be tagged” which is confusing to me, because the only way that frames between hosts C and D would be tagged across the trunk in the shown topology/configuration is if native VLAN tagging is configured, but you mention traffic between them would be tagged even if native VLAN tagging was not configured, which I dont believe is true. Also the diagram in this post doesnt show VLAN 99 as being allowed across the trunk.

I did have a question. Assume that in the topology from the first post above, we add VLAN 99 to the list of allowed VLANs on just one side of the trunk link, but we dont add VLAN 99 to the list of allowed VLANs on the other side of the trunk link. VLAN 99 is still configured as the native VLAN on both ends of the link. In this scenario, when the switch allowing traffic from VLAN 99 transmits a frame from a host on VLAN 99 untagged out of its trunk port, and this frame reaches the trunk port on the other side, does this mean that the untagged frame being received on this switch would be dropped, since the native VLAN to which untagged frames should be associated with is not allowed on this trunk port? I understand if we were to receive a tagged frame on a trunk port, and the 802.1Q tag on that frame includes a VLAN ID thats not allowed on the trunk, then the switch would drop the frame. But im curious how it would work if an untagged frame is received, and the native VLAN configured on the port is not allowed.

Thank You Laz

lagapidis · November 5, 2024, 7:14am

Hello Paul

You’re absolutely correct for both of those posts. I will go in and make the appropriate changes to correct the content. Thanks for pointing that out!

Now as for your final question, the quick answer is that any untagged frame that arrives on a trunk interface will be placed on the native VLAN. This is the case even if you have the configuration you suggest. However, I did lab this up and found that such a configuration does not work as expected. The reason doesn’t have to do with the receiving switch not accepting the frame, but with the sending switch. With such a configuration, the sending switch will never send out a frame. I found that there are no frames captured on the link between the two switches when you attempt to make this work. I don’t know if this is an issue with CML or if the inconsistent configuration across the trunk is causing the sending switch not to send out those frames at all!

In any case, this is not a configuration that you would want on your production network, but it is an interesting situation to examine further. If you have some physical hardware to try this out on it may be enlightening.

I hope this has been helpful!

Laz

xastraea02x · December 13, 2024, 2:54am

Hi Rene,

Let’s say I have a switch with three ports. I want two ports to trunk the native vlan and one port to let the native vlan be untagged. I input the command vlan dot1q tag native - this tags all the native VLANs. How can I configure the one port not to tag the native vlan?

lagapidis · December 16, 2024, 5:59am

Hello Xastraea02x

It all depends on the platform and IOS version you are using. For the 2900, 3600, and 3700 series switches, you can only apply native VLAN tagging globally for all trunks on the device as shown within the. This is also the case for the CML vIOS_L2 image I used to test this command out.

For more advanced platforms such as the 6500/6800 and others, you can apply this on a per-interface basis but only for IOS versions 12.2(33)SXH and later. In any case, check the specs of your particular device to determine if it is supported.

For those platform and IOS version combinations that support this feature, you can issue the following interface command:

Switch(config-if)#switchport trunk native vlan tag

On those platforms that support per-interface native VLAN tagging, you must keep in mind that in order for this interface command to work, you must first enable the feature globally using the vlan dot1q tag native command.

Details concerning how this command behaves in various setups can be found at this Cisco command reference:

I hope this has been helpful!

Laz