802.1Q Native VLAN on Cisco IOS Switch

lagapidis · January 29, 2020, 6:50am

Hello Ewout

Packet tracer is known as an network device simulator. This means that it is not actually running the real Cisco IOS software, but a program that imitates it. As such, its developers have only included a subset of all the real capabilities of IOS software. This means that not all commands are supported, and you will often find that you get the error you described.

Now for the specific command you mention, you will simply have to use the show interface trunk command. This will show you all of the trunk information for all trunks of the switch, rather than simply showing the specific interface, as the command you attempted intended.

If you want to ensure that all commands are made available to you, you should use a network device emulator such as GNS3, which actually runs the real IOS software, and thus supports all of the features and commands of real devices.

I hope this has been helpful!

Laz

joshspam83 · February 2, 2020, 1:41am

HI @lagapidis, @andrew @ReneMolenaar & EVERY ONE ELSE

I want change my native vlan on current switches to something that is used by nothing else in the network.

My mgmt vlan will be something completely different.

My main question is on control data.

With the new new vlan , that won’t be in use by anything else beside being native between switch. Do i need to allow it on the trunk ?

Eg. switch one native vlan 999 , switch 2 native vlan 999. Does this vlan need to be included in the allowed Trunk List for these two ports?

I understand some control data will allways use Vlan 1( even when not allowed on trunk links).

I would also like to know if this has any impact to designing a REP ring with a REP administrative vlan.

If i wanted my Native vlan 999 to be also used for REP admin vlan , does this need to be allowed on the trunks.

lagapidis · February 3, 2020, 8:02am

Hello Josh

The answer to this is “it depends”. It really depends on what you want to accomplish. Having said that, there are some best practices to keep in mind.

By default when you configure a trunk, the native VLAN is VLAN 1 and it is also included in the allowed VLANs, as all VLANs are allowed initially. By including the native VLAN in the allowed VLANs, it just states that any frame with a tag that equals that of the native VLAN will simply be treated as any other tagged frame, and placed on the appropriate VLAN. This will take place regardless of what the native VLAN configuration is, so the native VLAN configuration actually has no affect on this operation.

For security purposes, it is best practice to choose a native VLAN that is unused by other networks, as you very correctly are suggesting. This means that any frames that are placed on that trunk without a tag, will go to a VLAN that has no hosts/networks associated with it. Such a frame is suspicious, and any malicious intent would be mitigated with this strategy. If however you choose to have a native VLAN that actually has subnets/hosts associated with it, then you must allow it so that such networks can communicate over that trunk. Although not best practice, it is functionally sound.

Whether you allow the native VLAN or not, it will not affect control data. Such data is usually exchanged between the two directly connected devices, and will take place either over VLAN 1 as you say, or over the native VLAN, but all of this is unaffected by the allowing or disallowing of the native VLAN. It is possible however to force a switch to tag the native VLAN as well, as shown in the lesson.

Finally, concerning REP, after doing a bit of research, I can tell you that the native VLAN is used by REP only for sending the Link Status Layer (LSL) PDUs. These are REP’s counterpart to BPDUs, generally speaking. These are exchanged as untagged frames and use the native VLAN, whatever it may be. There is no special provisioning for including the native VLAN in trunks for this to function, so the native VLAN doesn’t need to be allowed on the trunks. You must however configure an administrative VLAN for all of the other types of communication necessary to make REP function, but this is independent of any native VLAN configuration.

I hope this has been helpful!

Laz

joshspam83 · February 3, 2020, 8:32am

Hi Laz,

Firstly thanks for your response. I really appreciate all the effort and time you put into these queries on the forum. I honestly believe that i have gained equal knowledge from reading your replies to users, to the lesson plans themselves.

In regards to the above. I always thought that a native vlan = untagged. Is this not correct ?
In your reply you state any frame that has a TAG of the native vlan will get switched to the appropriate Vlan. Could you please clarify this bit for me.

Having a read through this doc.

https://literature.rockwellautomation.com/idc/groups/literature/documents/td/enet-td005_-en-p.pdf

If the administrative VLAN is not allowed across the entire REP ring, both within and outside the
segment, the HFL frames will be dropped and network convergence will be dependent on the
slower LSL mechanism. While Link Status Layer (LSL) frames are considered control traffic and are
therefore relayed across the trunk regardless of pruning, HFL frames are considered data traffic and
must be explicitly allowed across the trunk.
• Since the administrative VLAN has similar constraints to the native VLAN, it makes sense to
assign the two as the same VLAN. In addition, most Cell/Area Zones will be separated by Layer
3 (distribution switch) domains, so constraining the HFL flooding does not need to be a
significant consideration.

So going on the above. If i have a native vlan that i DONT wan’t to allow across trunks. I should specify a separate REP administrative vlan that i DO permit across trunks?

Thank you
Josh

lagapidis · February 3, 2020, 11:26am

Hello Josh

I appreciate your encouragement! It’s responses like these that really make all of this worth it. We’re here to help and we’re doing our best, and thanks so much for your kind words!

Actually, what the native VLAN command does is it states that “if an untagged frame is received on a trunk port, in which VLAN should it be placed?” This does not mean that any traffic on the native VLAN will be sent over the trunk port without a tag. Take a look at the following topology:

Here we have a trunk that carries VLANs 5 6 and 10 and has a native VLAN of 99. Hosts A and B will be able to communicate, but hosts C and D will not. This is because only traffic on VLANs 5 6 and 10 will be sent out of the corresponding trunk ports and not VLAN 99 traffic. The native VLAN traffic will never be sent out of a trunk port. It only tells the trunk port what to do with incoming untagged frames.

In order for C and D to communicate, you must allow VLAN 99 on the trunk, and if you do so, their communication will take place using untagged frames.

The above description has to do with data plane traffic. Control plane traffic on the other hand will use the native VLAN across trunks by sending untagged frames from trunk ports. But this is limited only to control plane traffic. (I actually labbed this up to confirm).

Now applying this to REP, note that LSL frames are dealt with as control traffic, and those frames do indeed operate over the native VLAN. HFL frames on the other hand, that travel over the administrative VLAN, are considered data traffic and are dealt with in the same way as any traffic that goes from host to host.

Now the document states that it makes sense to assign the administrative VLAN as the native VLAN as well. This is perfectly fine, since any LSL traffic will be sent as untagged traffic across the trunks, and HFL traffic will be sent as tagged frames across the trunk. The tagged frames will be placed on the Administrative VLAN, while the untagged frames will be placed on the native VLAN. And in such a case case, both of these VLANs are the same.

So to answer your question:

…yes that is correct.

I hope this has been helpful!

Laz

msu135 · February 16, 2020, 2:57pm

@lagapidis. Thanks a Lot for your replies on the queries. they are very informative. I have few questions regarding the Native Vlan.

Q.1) for Example my Native Vlan is Vlan 2 on both ends of the Trunk and it has subnets/hosts associated with it(on both Switches) .Considering the Native Vlan tagging is enabled on Trunk, what will happen if i try to Ping from PC1 (Switch A) to PC2 (Switch B), will the Frames be tagged with Native Vlan ID for this Data Plane Traffic ? and what will happen to Control Traffic like (CDP,VTP,DTP,STP) will those frames also be tagged with Native Vlan Tag? or the control traffic from Switch A will be received without Native Vlan Tag on Switch B?

Q.2) In the Above example, if Native Vlan Tagging is not Enabled, will the frames from PC1 received on Trunk link on Switch B will not be tagged ?

lagapidis · February 17, 2020, 9:28am

Hello Mohammed

Let’s use the following topology to answer your questions:

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 if native VLAN tagging is enabled.

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 native VLAN tagging, then any untagged frames that arrive on the trunk interface will be dropped.

Control traffic such as CDP, VTP, PAgP and DTP don’t actually use the native VLAN. They use VLAN1. Interestingly, even if you disallow VLAN1 on a trunk interface, and change the native VLAN to something other than VLAN1, these control protocols will still use it, and switches see this as an exception to the allowed VLANs.

The primary purpose of tagging the native VLAN is to mitigate against VLAN hopping attack techniques. You can find out more about VLAN hopping at the following lesson.

I hope this has been helpful!

Laz

dsoroff · February 25, 2020, 1:02pm

Yes, this makes sense.

pradyumnayadavgla · April 26, 2020, 12:57pm

Hi Laz,

After configuring interface as a trunk port we see an output in which we can see few VLAN allowed in Management domain and few VLAN are in Spanning tree Port-Fast state not pruned so my question is here that can we use VLAN among them to our Purpose ?

lagapidis · April 27, 2020, 6:30am

Hello Pradyumna

I’m not sure I understand the question. Are you referring to a specific lab topology, and if so which one? Can you please clarify?

Thanks!

Laz

pradyumnayadavgla · April 27, 2020, 12:20pm

Hi Laz,

I am discussing about the same topology we are using in How to change Native VLAN topic in and the output of command show int f0/24 trunk you can find Management and Spanning-Tree forward state related stuff ?

SW2#show interfaces fastEthernet 0/24 trunk

Port        Mode             Encapsulation  Status        Native vlan
Fa0/24      on               802.1q         trunking      1

Port        Vlans allowed on trunk
Fa0/24      1-4094

Port        Vlans allowed and active in management domain
Fa0/24      1,10,12-13,20,23-24,30

Port        Vlans in spanning tree forwarding state and not pruned
Fa0/24      1,10,12-13,20,23-24,30

lagapidis · April 27, 2020, 1:43pm

A post was merged into an existing topic: Private VLAN (PVLAN) on Cisco Catalyst Switch

lagapidis · April 27, 2020, 1:43pm

Hello Pradyumna

The specific output simply shows which VLANs are allowed on the configured trunk. All of the VLANs can be used for whatever purpose you want. The designation here simply states that the VLANs listed in “the management domain” are those that are shared and managed in the specific VTP domain. Pruning simply indicates which of those VLANs have been “blocked” from traversing the trunk, simply because there are no hosts on the other side of the link that are on that VLAN. You can find out more about pruning at the following lesson:

I hope this has been helpful!

Laz

brice.angoua · May 5, 2020, 9:26pm

Hi Rene,
I am Learning CCNP RS. i try to understand Something but i can’t.
i know that , good practice recommends to configure the same native vlan on two switches connected throw a trunk Link. but i Don’t know why if native VLAN a re different on both switches , thes switch will not work properly.

lagapidis · May 7, 2020, 5:43am

Hello Angoua

Actually, it is possible to connect two switches via a trunk with a different Native VLAN on either end. The connection will work, however, there are a few problems with it. First of all, you will be getting Native VLAN mismatch syslog messages on both switches informing you of the problem. Secondly, and more importantly, a native VLAN mismatch can be a security issue. If your native VLANs are not the same, users can gain access to a VLAN that they are not allowed to access. If an untagged frame crosses the link, it will end up in the wrong VLAN on the other end.

Now why would an untagged frame cross the link? Take a look at this post.

For this reason, it best practice (and essential) to ensure that the native VLAN is the same on both ends.

I hope this has been helpful!

Laz

louis1 · October 18, 2020, 7:13am

If the Native VLAN is changed from VLAN1 to something else, will CDP etc still use VLAN 1 to communicate, or will they use the new Native VLAN to communicate? Because I saw on a NetworkLessons.com practice exam that CDP will use VLAN 1 to communicate no matter what.

Thanks!

lagapidis · October 19, 2020, 6:26am

Hello Louis

When we talk about “what VLAN CDP will use” this only has to do with trunk ports. Any access ports used to interconnect two switches will still exchange CDP packets regardless of what VLAN those ports are assigned to. In those cases, CDP packets will be exchanged without VLAN tags, just like all traffic in and out of an access port.

For trunk ports, CDP will always use VLAN1 on switches since VLAN1 can never be removed from the database. If the native VLAN remains VLAN1 on a trunk port, then CDP packets will be sent untagged. If the native VLAN has been changed on a trunk port, CDP packets will be sent tagged on VLAN1, even if this VLAN is not allowed on the trunk!

I hope this has been helpful!

Laz

TechnologyOperationT · November 11, 2020, 3:09am

Hi Laz,

To quote you “So, to answer your question, you must create vlan 10 in order for your native vlan configuration to work correctly.”, do you mean that we have to create the native vlan before the native vlan can work properly? I did a lab today and notice by me just issue “sw tru native vlan 10” without creating native vlan 10 in advance, the traffic can still pass.Would you please clarify?

Thank you very much,
Helen

lagapidis · November 13, 2020, 8:26am

Hello Helen

Yes, you are correct. Even if you configure a trunk with a native VLAN that does not exist, the traffic will successfully be transmitted, and the trunk will operate. However, other features that require native VLANs to function may fail. For example, STP can fail in such a case, as described in this post:

In any case, I labbed this up and attempted to recreate the scenario. Note below:

SW1#show run inter gig 0/1
Building configuration...

Current configuration : 203 bytes
!
interface GigabitEthernet0/1
 switchport trunk native vlan 10
 switchport mode trunk
end

I configured a trunk on GigabitEtherent 0/1 and configured VLAN 10 as the native VLAN. I then display the configured VLANs in the switch:

SW1#show vlan brief

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    Gi0/0
1002 fddi-default                     act/unsup 
1003 token-ring-default               act/unsup 
1004 fddinet-default                  act/unsup 
1005 trnet-default                    act/unsup

Note that there is no VLAN 10. However, the below command shows that the trunk on Gi0/1 is indeed using VLAN 10 as the native VLAN:

SW1#show inter trunk

Port        Mode             Encapsulation  Status        Native vlan
Gi0/1       on               802.1q         trunking      10

Port        Vlans allowed on trunk
Gi0/1       2-4094

Port        Vlans allowed and active in management domain
Gi0/1       none

Port        Vlans in spanning tree forwarding state and not pruned
Gi0/1       none
SW1#

This simply means that when STP, or any other feature that leverages the native VLAN sends an untagged frame to this interface, it will be dropped simply because VLAN 10 does not exist. Remember that the native VLAN configuration on an interface tells the switch onto which VLAN it should place any untagged frames it receives.

So, the trunk will function, but any feature that uses the native VLAN will fail.

I hope this has been helpful!

Laz

shane_corban · December 17, 2020, 4:05am

Hi

I’m posting a basic question but am confused by concept of native vlan and what I see with linux bridges connecting to Cisco nexus switches.

What I’m seeing is that even though switch is learning the Mac address of my vm connected through a linux bridge, and the uplink is configured as trunk for all clan’s pings are failing to active hosts on the same vlan.

When I added below native vlan config incrementally, it started working:

interface Ethernet1/38
  switchport mode trunk
  switchport trunk native vlan 120

arp was failing on the host, now its resolving for the server I was pinging 120.101 below.

[root@rhev8-1 network-scripts]# arp -a
_gateway (10.29.9.1) at 7c:21:0e:b3:06:fc [ether] on bridge0
? (10.29.120.101) at <incomplete> on bridge1
? (10.29.120.1) at <incomplete> on bridge1
? (10.29.9.10) at 00:50:56:8d:87:75 [ether] on bridge0
? (10.29.9.101) at 80:30:e0:41:30:80 [ether] on bridge0
? (10.29.9.50) at 00:50:56:91:14:44 [ether] on bridge0
? (10.29.120.105) at 52:54:00:30:43:f2 [ether] on bridge1
? (10.29.9.156) at 52:54:00:02:b8:92 [ether] on bridge0

I’m not tagging any vlans on the host nic, so I’m curious why this is the case and why the native vlan is required in the config for connectivity to work - sorry for the basic question.

Thanks
-Shane