cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
59587
Views
48
Helpful
10
Replies

Native Vlan Tagging

zarnims
Level 1
Level 1

Hello,

I have an understanding that we can configure the tagging for native vlan to prevent from vlan hopping (double tagging) attack. The point is that what happened to untagged ones like traffic from low end devices such as soho switches which are connected at the other end and they don't understand the vlan at all. I'm having a confusion as I'm preparing for my ccnp exam. Any help would be really appreciated guys. Thanks in advance.

Regards,
Zerny

1 Accepted Solution

Accepted Solutions

Hello Zerny,

I just came back from a lab. I can confirm that if vlan dot1q tag native is configured, a trunk always performs tagging on the outgoing frames (i.e. the native VLAN setting is ignored and all frames are tagged with the corresponding tag value). Untagged frames arriving at a trunk port will be dropped without being forwarded further.

I've tested this on Catalyst 3560 (12.2(55)SE6) and 3560V2 (15.0(1)SE).

Best regards,

Peter

View solution in original post

10 Replies 10

Peter Paluch
Cisco Employee
Cisco Employee

Hello Zerny,

Keep in mind that the vlan dot1q tag native command applies only to tagging frames on trunk ports. It has no effect on access ports - these ports will continue operating in untagged mode.

what happened to untagged ones like traffic from low end devices such as  soho switches which are connected at the other end and they don't  understand the vlan at all.

I suppose you are asking what will happen to low end switches connected to trunk ports. To be honest, connecting low end switches to tagged ports is always a bad idea. Contrary to what is being said all the time, the native VLAN is not here to provide for backward compatibility with non-tagging devices, although it is capable of doing that. The native VLAN is a concept retaken from 802.1Q standard that states that each port has a Primary VLAN ID (the native VLAN in Cisco parlance), and may have additional VLAN IDs (tagged VLANs). In order to be compatible with 802.1Q, each device has to implement this concept, resulting into Cisco's native VLANs on trunks.

Tagged frames are still valid Ethernet frames with their source and destination MAC addresses exposed, and low end switches will switch them just like normal frames. They will just be unable to prevent isolation between VLANs because these switches do not process nor honor VLAN tags.

Configuring vlan dot1q tag native will cause all frames being sent out a trunk port to be tagged, ignoring the native VLAN. What I am not sure, though, is whether this command also causes a trunk port to drop received untagged frames. I was unable to find a hint on that in the documentation so I guess I will have to make an experiment in our lab to see. I hope I won't forget about it, and within a day, I will get back here once again with the results I have gather so far.

Please feel welcome to ask further!

Best regards,

Peter

Hello Peter,

Your answer is very informational and helps me a lot. Sorry that I forgot to mention I was talking about the 802.1q trunk port. I am very keen for the result after your lab testing. Really really appreciated. Thanks again. Bear with my English.

Regards,
Zerny

Sent from Cisco Technical Support iPhone App

Hello Zerny,

I just came back from a lab. I can confirm that if vlan dot1q tag native is configured, a trunk always performs tagging on the outgoing frames (i.e. the native VLAN setting is ignored and all frames are tagged with the corresponding tag value). Untagged frames arriving at a trunk port will be dropped without being forwarded further.

I've tested this on Catalyst 3560 (12.2(55)SE6) and 3560V2 (15.0(1)SE).

Best regards,

Peter

Hi Peter,

Thanks for your help on this. I, now, know and assured that the incoming untagged frames will be discarded after the vlan dot1q tag native command. I still have something came up to my thoughts after this, which is the control protocols like CDP, STP, VTP, PAgP, etc will still be able to make it through the link (are they independent?) or will they be discarded also?? Excuse my narrow knowledge.

Regards,

Zerny

HI Zerny,

To answer your other question, when you configure native VLAN to be  something other than VLAN 1, CDP and VTP will not be tagged, but STP in  VLAN 1 will be, if you are running PVST+. If you're running MST, then it  won't be.

Regards

Inayath

HI Inayath,

Thanks for the reply. I'm getting confused. I assume that in PVST, it will use tags for each vlan spanning tree instance but in MST, it uses instance mapping to vlans which doesn't rely on any particular vlan or vlan 1. I get that. For CDP and VTP frames you have mentioned in the comment, could you please explain further a bit? I couldn't find any documentation to refer. Would be really appreciated.

when you configure native VLAN to be  something other than VLAN 1, CDP and VTP will not be tagged,

Regards,

Zerny

So the switch with this command will tag the primary VLAN for outgoing traffic on the trunk, and reject all incoming untagged traffic, with the exception of control traffic. 

 

"Control traffic continues to be accepted as untagged on the native VLAN on a trunked port, even when the vlan dot1q tag native command is enabled."

 

Hi Peter, I have done a capture on a trunk port of a 3560 CG SW.  Even though the default vlan is 1 and the native vlan is set to 1 on the trunk port that carries other vlans, I see the SW tagging the native vlan with ID=1;  When I do a show on the native vlan tagging, this is what I see

<switch#sh vlan dot1q tag native
dot1q native vlan tagging is disabled>

Not sure why this is going on.  The SW software is:

Cisco IOS Software, C3560C Software (C3560c405ex-UNIVERSALK9-M), Version 15.2(2)E3, RELEASE SOFTWARE (fc3)

Hello,

I am not sure what's going on myself, but these are two things I would be looking into:

  1. Check whether the frames tagged with VLAN=1 carry a non-zero CoS value. Indicating a non-default priority of the frame can be only done by tagging it, so that would explain why the tag is there.
  2. How did you do the packet capture itself? Was it a SPAN session, or did you have a PC with Wireshark connected to a trunk port? Using a PC with a Wireshark is preferable - this will make sure that we really see what is being sent across the wire.

Best regards,
Peter

I'm a little confused about tagging a native vlan. Is this really necessary? From my understanding, nothing should be on the native Vlan. Let's say I use native vlan 99 on a network and any unmanaged switches are connected to switchport access ports to a specific vlan. So nothing would ever attach to a trunk port unless it was another Cisco switch with the proper trucking configuration. In this scenario, would there be any benefit to tagging a native vlan?

Review Cisco Networking for a $25 gift card