cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
860
Views
0
Helpful
6
Replies

The native is restless ...

fibrefletch
Level 1
Level 1

A regular, data vlan can have an administered id to distinguish it from vlan 1, and that is good practice, lets change it to vlan 101

When frames from vlan 101 go over a trunk, they are tagged with their id of 101 (fine so far)

Now consider the native vlan, which as we all know is, wait for it, UNTAGGED, and being so defines it as the native vlan when it traverses a trunk link.

We can change the native vlan id, from its default id value of 1, so for our purposes, let’s make it an id value of 999

Dilemma 1 - How is the new native vlan 999, recognized on the trunk unless it is actually TAGGED? (it needs tagging with 999 surely.)

Dilemma 2 - vlan 999 (the new native vlan from dilemma 1) can be removed from the trunk link so its not allowed to send frames, yet the native vlan still operates ? (tested OK) (also vlan 1 can be removed from the trunk ?)

Dilemma 3 - according to ‘some sources’, if the native vlan id is changed from the default id 1, control traffic frames (CDP, VTP, PAgP, DTP, etc.) change to use vlan 1 and they are tagged!

Dilemma 4 – according to ‘some sources’ it is good policy (for security reasons, keeping it brief) to tag all vlan’s, including the native vlan, and there is a global command to tag the native vlan - "vlan dot1q tag native" which will tag all vlans on all trunk links on a switch.
Also, for security, each trunk can be changed individually on the interface with "switchport trunk native vlan id" It is recommended to change to an unused vlan id, and then remove that vlan id from the link

Dilemma 5 – according to ‘some sources’ a native vlan does not need to be configured and recommended that it is not. Traffic that is local to the link (CDP, VTP, PAgP, DTP, etc.) will still be sent and received untagged, and it will work correctly. This traffic will never be sent beyond the link, even with a native vlan configured. Configuring a native vlan can present a security risk, as can the use of Vlan 1. (It may be that some devices do not understand tags, so then a native vlan would be needed.)

My conclusion - the native vlan id remains somewhere in the switch even through the id has been removed from visibility to the user.

Are there any experts that can sort this out, especially the most obvious  Dilemma 1?

1 Accepted Solution

Accepted Solutions

Philip D'Ath
VIP Alumni
VIP Alumni

We can probably clear up a lot of things in one go with this pearl of wisdom - the native vlan is not tagged.  If all VLANs are tagged then there is effectively no native vlan.

"vlan dot1q tag native" enforces this by making every vlan on every trunk is tagged.  No frame is sent without a tag.  Hence there is no native vlan.  The concept is gone.

View solution in original post

6 Replies 6

Philip D'Ath
VIP Alumni
VIP Alumni

We can probably clear up a lot of things in one go with this pearl of wisdom - the native vlan is not tagged.  If all VLANs are tagged then there is effectively no native vlan.

"vlan dot1q tag native" enforces this by making every vlan on every trunk is tagged.  No frame is sent without a tag.  Hence there is no native vlan.  The concept is gone.

Thanks Phil,

Its probably me that has got a wire crossed here, and cant get passed it.

My hypothesis:

If we change the id of the native vlan, this changes some 'label' (lets not call it an id)  within the switch (which the user does not see), when the frame from the native vlan gets on a trunk, it is not given a tag (like other data frames would be on differing data vlans) because the frame is from the native vlan, and so the frame is considered as from the native vlan on that link

You don't happen to know what "value" or id the command vlan dot1q tag native uses do you (this does tag all native vlans on all trunks on the switch ???)

Referring back to my first post, I have read all those details in respected / prominent texts

Well, they say the only way to know is to experiment, so I am going to do a simple lab in GNS3 today and try see what is happening with wireshark and will report back ...

As Philip D'Ath says, switches tag all incoming frames. The tag value depends on the incoming frame. If it has a tag, then the switch uses that. If it does not, then the switch must assign one. That value is the native VLAN id on a trunk port. (Access mode ports do this implicitly.) Once assigned, the formerly untagged frame is treated in the same way as all of the other tagged frames.

I agree with albosch  .

Let me word it differently.  The "tag" is the 802.1q part of the layer 2 header that (if present), says what vlan the packet is to go on.

Internally, every frame the switch processes has the vlan associated with it.  I'm not going to use the term "tag" here, as this is part of the internal state that the switch keeps about every packet, and not necessarily anything to do with the layer 2 header.

Now when a frame arrives, if there is a layer 2 tag, the switch notes this vlan id internally.  If there is no layer 2 tag, then the switch records internally what the native vlan number is.  Note that no matter which case - it records a vlan id internally.

When the switch transmits a packet, and it is a trunk port, and the internal valid ID of the packet matches the configured native vlan then the packet is sent with no layer 2 tag.  If the packet does not match the configured native vlan than a layer 2 tag is added to the frame.

As you can see, the impact of a layer 2 vlan tag only has meaning at point in time when the packet is received on the wire or sent on the wire, but not when it is "inside" of the switch.

All sounds good, you have described it much better than I was starting to guess at. Thank you Phil for taking time explaining the issue.

We now have a great record for this particular question and an understanding of something which is not immediately obvious, especially for beginners

Thanks too Albosch as well for the valid contribution :-)

I hope you like my additional info in my response to my own question above to your first response (under D2) about the native keyword used on a router sub interface (for a ROaS), do you both concur ?

FF.

I have to give the answer to Phil, he is not wrong!

And to answer my own question after some testing in in GNS3 (as far as I am able) and sniffing packets

D1 - a record of the native vlan id is obviously held on the switch outside of putting a tag on for its recognition on trunks, so if it has no tag on the trunk it does not matter, when it reaches the other end of the link, it is once again recognised as the native vlan value (value at both ends should be the same.). No tagging is made to native vlan frames as they traverse the trunk.

D2 - The native vlan can be removed from the allowed list, I guess this prevents against misuse by regular data frames. Any control protocols (such as CDP) are still able to use the native vlan on the trunk (However, remember if the native vlan is used / needed by any devices, or by mistake some device is not assigned a vlan id other than the default, it should obviously not be removed.
In relation to this, another thing that was bugging me answered - the command on a router sub interface encap dot1q 1 (id) native is used so that vlan is recognised for Vlan 1 traffic, (and potentially unassigned traffic on Vlan 1) and IT ALSO IS the native vlan (because of native keyword.) So any traffic not belonging to a Vlan (unassigned vlan traffic) gets picked up on the sub interface, although of course good practise is that it should be on an administered Vlan (given an id other than 1)

D3 – I dismiss dilemma 3, an aberration

D4 – I can’t prove or disprove as I do not have equipment that uses this command, so I am happy with Phills answer. The native vlan is not used at all with the vlan dot1q tag native command. All Vlans, including the native, are tagged, (so effectively, there is no native vlan) This would only present a problem if you had devices using the native vlan. You can remove the vlan id from the trunk link and this does not affect operations, I could not remove Vlan 1 outside of Packet Tracer

D5 – I guess in normal circumstances procedure would be to assign another id to the native vlan (other than 1) and then remove that from the trunk link (there are security issues here also which I am not getting into)

I have never spent so much time struggling with such a simple concept due to general poor and ambiguous explanations in books and training material

Keep the good info coming!

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco