802.1Q Native VLAN on Cisco IOS Switch

[u.forte (ugo f)]

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 (Lazarus Agapidis)]

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:

VLAN Hopping

I hope this has been helpful!

Laz

[paminett (Patrick Minett)]

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

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.

2. 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 (Lazarus Agapidis)]

Hello Patrick

@paminett

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

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.

@paminett

• 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 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.

@paminett

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?

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:

How to configure Router on a Stick

I hope this has been helpful!

Laz

[marcel.schmid2 (Marcel Schmid)]

Hi @lagapidis,

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

@lagapidis

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.

As far as data plane traffic goes, traffic on the native VLAN will never be sent out of a trunk port untagged. The native VLAN configuration tells the trunk port on which VLAN incoming untagged frames should be placed. If you configure VLAN tagging, then any untagged frames that arrive on the trunk interface will be dropped.

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 (Lazarus Agapidis)]

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.

@marcel.schmid2

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

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]

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

[lagapidis (Lazarus Agapidis)]

Hello Jayashree

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

802.1Q Native VLAN on Cisco IOS Switch

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

• https://notes.networklessons.com/native-vlans-and-untagged-frames
• https://notes.networklessons.com/switchport-trunk
• https://notes.networklessons.com/vlans-when-a-tagged-frame-arrives-on-an-access-port
• https://notes.networklessons.com/vlan-control-frames

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

I hope this has been helpful!

Laz

[premswan (Premkumar S)]

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

[lagapidis (Lazarus Agapidis)]

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 (Premkumar S)]

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 (Sathish Murugesan)]

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]

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 (Sathish Murugesan)]

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

[lagapidis (Lazarus Agapidis)]

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 (Sathish Murugesan)]

Great, appreciate it @lagapidis