802.1Q Native VLAN on Cisco IOS Switch

Dear ReneMolenaar, how did you capture the Traffic over wireshark as I am little unaware to how to use wireshark but as i am trying to capture traffic over switch interface but it doesnt showing me anything, please help.

Hello Waseem

When using wireshark on a switch, it is most often used with the SPAN or RSPAN feature of a switch. Take a look at this lesson, which explains this feature.

I hope this has been helpful!

Laz

Hello,

This article said that the native vlan carries some control plane traffic. I’ve read elsawhere that the DEFAULT vlan (always VLAN 1) carries the control plane traffic (CDP, STP, etc.). Can you clarify? There seems to be some contradiction here.

Under which circumstances would you want to tag the native VLAN?

Hello Andy

You are correct, in most cases it is indeed the default VLAN that carries the control traffic. CDP, VTP, DTP all use VLAN1. Some types of STP however (MSTP for example) use untagged frames, meaning they automatically use the native VLAN, as do LACP and LLPD. To some extent, it is IOS and platform dependent as well. So some control traffic does use the native VLAN, some uses the default VLAN, but which uses which can vary from platform to platform, and configuration to configuration.

Why would you want to tag the native VLAN? This is done for security purposes to mitigate against techniques such as double tagging to gain access to other VLANs. More about this can be seen in the following lesson:

I hope this has been helpful!

Laz

Hi,
if we use ‘switchport trunk encapsulation isl’ for trunking on both SWs, why should we still use ‘vlan dot1q tag native’? Why can not we use ‘vlan isl tag native’?
Can TAGging native vlan be done only with 802.1q?

Hello Murat

ISL has no concept of VLAN tagging and as a result, it has no concept of the native VLAN either. This is because ISL works on a completely different principle than 802.1Q.

ISL will take an Ethernet frame and it will encapsulate it into an ISL frame. This frame places an additional header of 26 bytes to the Ethernet frame along with an ISL CRC trailer. The information about the VLAN to which the frame belongs is contained within the ISL header.

802.1Q doesn’t add a whole header, but adds a field to the existing frame header where the tag is placed.

I hope this has been helpful!

Laz

Hi Rene,

On a previous post you mentioned the host never adds a tag on the ethernet frame but when the switch receives the frame it adds the tag. Also I know that all access interfaces have to belong to a vlan.
Now when it comes to the native vlan, what do you mean when you saying “when the switch receive an untagged frame”? as if it is a host attached to the port, it will always receive untagged frames and then will add the necessary tag. So if the interface belongs to the native vlan membership will add the native vlan tag. is it correct?

Hello Charalambos

When rene says “when the switch receives an untagged frame?” he means “on a trunk port”. Of course you are correct that all frames received on an access port will be untagged, but the native VLAN has meaning only when an untagged frame is received on a trunk port. Only then will that frame be placed on the configured native VLAN of that trunk port, otherwise, the switch doesn’t know which VLAN to place it on.

You might say “how can an untagged frame find itself on a trunk?” and you would be correct in asking that question. When a network is configured correctly, this shouldn’t happen. For more info on examples where this may occur, take a look at this post:

Having said that, there is a special case where untagged frames are received by trunk ports, and that is when you connect an IP phone to a switch, and a PC to the IP phone. The configuration doesn’t specifically use the term “trunk” although that is essentially what is created. You can find out more about that at this post:

I hope this answers your question, and although I have gone a bit overboard in providing additional information ( :stuck_out_tongue: ), I hope that you find it useful.

Laz

Hello Rene/Laz,
I am going to use the below topology as a reference for my questions.

Question-1:
==========
Can a switch have multiple native vlans on its different interfaces? For example, on SW-2, native vlan on the link between SW-1 and SW-2 is 100 and native vlan on the link between SW-2 and SW-4 is 200.

Question-2:
==========
Assuming that a switch can have multiple native vlans on its different interfaces. When SW-2 receives a broadcast message from SW-1 without any tag, it will think the broadcast message belongs to vlan 100 and it will send the broadcast message to SW-3 and SW-4, but it will not send the broadcast message to SW-5. Before SW-2 sends the broadcast message to SW-3, it will strip off the vlan tag. On the other hand, SW-2 will tag the frame with vlan 100 before it sends it to SW4. Is this statement correct?

Question-3:
===========
Will the computers that are connected to SW-4 and SW-1 and belong to vlan 200 be able to communicate to each other?

Thanks a lot.

Best Regards,
Azm Uddin

Hello Azm

Question 1:

Yes, you can configure different trunks on the same switch with different native VLANs.

Question 2:

First of all, if your network is configured correctly, SW2 should never receive an untagged frame on it’s port connected to SW1 (beyond control frames such as CDP and VTP etc). Let’s say however, that there is a hub connected on the link between SW1 and SW2 and there is a device connected to that hub that sends a broadcast. (Bad network design, but there you go…) If this does happen, an untagged broadcast frame will reach SW2 and will be placed on VLAN 100 since that is the native VLAN on that particular trunk port. From there on your statement is correct except for:

The broadcast will enter SW2 without a tag, but will be placed on VLAN 100 (native VLAN). Since the link between SW2 and SW3 is an access link, no tag will ever appear on this frame on its way to SW3. Remember that tags on frames only exist on the trunk links themselves and not within the switching fabric of the switch.

Question 3.

Yes. A PC on VLAN 200 on SW1 sends a packet to a PC on VLAN 200 on SW4. The frame will exit SW1 and reach SW2 via the trunk as a tagged frame. The frame will then exit the port that connects to SW4 as an untagged frame. It will enter SW4 on VLAN 200 and reach the appropriate PC.

I hope this has been helpful!

Laz

Was I supposed to see a tagged ethernet frame on the trunk after applying the
SW2(config)#vlan dot1q tag native
on both switches?

I still did not see my native traffic getting a vlan 10 tag:

As you could tell, used SPAN to capture the traffic from my fa0/10.
thanks in advance for your help!
G

Hello Martha

Control traffic such as CDP, VTP etc don’t use the native VLAN. When sent over trunk ports, these protocols use VLAN1 as the VLAN of communication between devices, even if VLAN 1 is disallowed from a particular trunk port and even if the native VLAN is configured to be tagged. And they are sent without a tag. So devices that receive CDP or other control frames on a trunk will automatically place them on VLAN1. This is a special case and applies only to these particular control frames.

If you were to experiment with sending traffic from one PC to another PC over the native VLAN of a trunk that has been configured to tag the native VLAN, you should see that traffic as tagged.

I hope this has been helpful!

Laz

I have a question on how switches handles traffic for vlans internally when 802.1q \tagging is not involved.

Example. A switch has 20 ports. 10 ports are configured for vlan 100 as access ports. 10 ports are configured as vlan 200 as access ports.

When a switch receives a packet on one of these access ports (broadcast for example). What logic does it do to look up what other ports are in this vlan to forward it to ?

Is there some sort of table\database the switches check internally to be able to pass\map traffic to other internal ports?

Thanks

1 Like

Hello Josh

There are various places where VLAN information is kept that pertains to the VLAN of each interface. VLAN information is contained within the configuration file, in the config of each interface. (interfaces without a VLAN config are by default on VLAN 1), so the switch “knows” to which VLAN each interface is assigned.

Also, if you look at the MAC Address Table you will see that it includes VLAN information for each MAC address and each port. This means that internally, the switch maintains a list of which ports belong to which VLAN.

2960-1#show mac address-table
          Mac Address Table
-------------------------------------------
Vlan    Mac Address       Type        Ports
----    -----------       --------    -----
   1    00ld.70ab.5d60    DYNAMIC     Fa0/2
   1    00le.f724.al60    DYNAMIC     Fa0/3
Total Mac Addresses for this criterion: 2
2960-1#

In the same way that the MAC address table is used to decide out of which port a particular frame must be sent, it is also used to decide out of which ports a broadcast must be sent.

I hope this has been helpful!

Laz

Thanks Laz,

My thoughts were along the same lines and i’m glad you confirmed it. I was just wondering if there’s any official process\logic that actually occurs.

Or is it just… the switch “JUST KNOWS” what port is associated to what becuase of mac\vlan mappings.

I guess i’m just trying to see if there’s some sort of internal lookup that actually occurs.

Hello Josh

There really isn’t any other mechanism that allows a switch to associate a port with a VLAN beyond the config and the MAC address table. Actually, the config corresponds the port with the VLAN while the MAC address table corresponds the MAC address with the port and the VLAN. So there are several correspondences (if I can say that?) that are taking place and are being used by the switch to perform this function.

Glad to hear that this has been helpful!

Laz

1 Like

Hello,

Maybe it’s the phrasing throwing me off, but I’m not clear what’s being said in the first
paragraph:

“The IEEE 802.1Q trunking protocol describes something called the “native VLAN”. All traffic sent and received on an interface that is configured for 802.1Q won’t have a tag on its Ethernet frame. When you look at it in Wireshark, it will look the same just like any normal Ethernet frame.”

Specifically, this part:

“All traffic sent and received on an interface that is configured for 802.1Q won’t have a tag on its Ethernet frame.”

The way it’s worded, it appears to say that NO traffic going across a trunk port will be tagged. We all know that’s not the case (and I know that wasn’t the intent of that sentence). Trunks are designed to carry tagged traffic. That’s why they exist. Can you explain in a different way what was meant by that statement?

1 Like

Hello Andy

Yes, you are correct, the wording does sound misleading. The meaning should be something like this:

“All traffic that belongs to the native VLAN that is sent and received on an interface that is configured for 802.1Q won’t have a tag on its Ethernet frame.”

I’ll ask @ReneMolenaar to reword it and clarify.

Thanks for pointing that out!

Laz

1 Like

Hi Andy,

I totally agree, just rewrote some of the sentences to make it clear. This one had some wordy sentences…

Rene

1 Like

Hello everyone, I started my network journey about a month ago. I am now taking the CCNA course on this website. When following along with the tutorials using Cisco Packet Tracer, I often get the error '% Invalid input detected at ‘^’ marker.
Sometimes this is because of a typo, but mostly I do what’s outlined and am using the right configuration context. For example:
Switch1# show interfaces fastEthernet 0/24 trunk in this lesson. Does anyone know why this keeps happening? Thanks in advance