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?