802.1q tag

[ohassairi]

is there any technical reason why 802.1q does not tag frames in native vlan ?

[Peter Paluch]

Hello,

This issue is a little convoluted. The 802.1Q has no concept of a "native VLAN" (that is a Cisco term), neither it talks about access and trunk ports. In 802.1Q, the port is assigned its Primary VLAN ID, which is the main VLAN it resides in and which does not need tagging (this is precisely the "native VLAN" in Cisco parlance). A port may have additional VLANs associated with it, however, these VLANs must obviously be tagged so that the port can distinguish between frames belonging to different VLANs. Remember: 802.1Q does not divide port between access and trunk ports. All it does is specifying a set of VLANs associated with a port.

From this viewpoint, the Primary VLAN ID is a natural concept. However, for practical purposes, it is convenient to think about a port to either belong to a single VLAN only which is its Primary VLAN ID - hence the concept of an access port with its access VLAN - or to think about a port as belonging to all VLANs, i.e. the trunk port. However, to remain compliant with 802.1Q standard, even a trunk port must utilize the concept of a Primary VLAN ID - the native VLAN as we know it.

This being said, there is hardly a more confusing topic in basic VLAN operation than the native VLAN, and I wish so much that this concept was not invented at all. With an access port not using tags (save for priority tagging) and trunk port tagging each and every frame, the world would have been much simpler and no functionality would be lost...

Best regards,

Peter

[Syed Aman Hussain]

can u send sh vtp and sh vlan and sh run

[Peter Paluch]

Hello,

For what reason? This is a principial question, not an issue of a particular configuration.

Best regards,

Peter

[ohassairi]

thanks peter, but honestly i still can't understand why 802.1q does not tag vlan 1?

if you can explain it in  a simppler manner i will appreciate it.

may be i can ask the question in another way: what problem can be happen if 802.1q tag vlan 1?

[Alexander Maroukian]

Hi,

I would like to add some information to what Peter  have already said. You may need the native (for me it is native because  this is native form of the ethernet frame) vlan untagged because some  protocols like STP (IEEE BPDU frames) and DTP use untagged frames.

HTH,

Alex

*Please rate helpful posts.

[Peter Paluch · Accepted solution]

Hello,

Sure, let's try it from a different end

The native VLAN is something like a "VLAN of last resort" that processes all frames which do not have a tag. If an untagged frame arrives on a trunk port, we assign it to the native VLAN of this port. Also, frames belonging to this native VLAN are sent untagged so they can be assigned to the same VLAN at the other end of the trunk link, assuming the neighboring switch uses the same logic to assign untagged frames to the same native VLAN.

We do not technically need to have an untagged VLAN on a trunk port. All VLANs can be tagged without any problems. It is even perfectly fine and allowed to tag a frame that belongs to a native VLAN because you only explicitly state what the switch would otherwise infer implicitly (by the configuration of the native VLAN on a port). So, once again, there is no definitive technical need to have a concept of native VLAN that is untagged on a trunk. Some switches, for example 3560 Catalysts, can be even forced to tag all VLANs including the native VLAN using the vlan dot1q tag native command, in essence removing the concept of native VLAN altogether.

The only reason that there is a concept of a native VLAN is because the 802.1Q standard requires that a port is capable of accepting both tagged and untagged frames. Therefore, there must be a VLAN that consumes and emits untagged frames on this port - and this is exactly the native VLAN as we know it.

Alexander, it is true that some signalling protocols between switches like DTP are always sent untagged. However, it would not interfere with their operation even if they were sent as tagged. They do not depend on the existence of a native (i.e. untagged) VLAN in order to work.

Best regards,

Peter

[Alexander Maroukian]

Hello Peter,

I really am trying to understand your opinion and to dig deeper into this. You have said this in one of your previous posts :

"Nov 22, 2010 3:11 PM                             (in response to yoram12345)

Re: how to tagg STP BPDU frame

Yoram,

I  am afraid there is no such command that would force a switch to emit  its own 802.1D/802.1Q BPDUs as tagged. The format of BPDUs is strictly  given by the IEEE 802.1D (STP) and 802.1Q (MSTP) standards, and it is  not expected that STP/RSTP/MSTP BPDUs are tagged. Tagging these frames  would in effect violate the standard and possibly cause switches that  are standards-compliant to misrepresent or misunderstand these BPDUs.  Effects on a redundant switches network in such a case would be  deleterious.

There  is a remote possibility to use the Q-in-Q tunelling to encapsulate the  BPDUs of your devices into additional 802.1Q tag but that would most  probably necessitate another piece of 3560/3750 switch on each side of  the link and personally I do consider this to be a serious solution  (perhaps a dirty and expensive workaround).

Perhaps if you provide us with an exhibit of your network we could help you further.

Best regards,

Peter"

This is from the following discussion - https://supportforums.cisco.com/thread/2053780

I cannot understand how I can tag STP IEEE BPDU for example.

That is why (and for other reasons also) I do believe that you technicaly need the native (untagged) vlan. I believe that is also a reason to be in the standard.

I am always happy to read your posts which are deep technical and very clear. I hope that you will provide a good example and explanation of your position. Thank you.

Best regards,

Alex

[Peter Paluch]

Hello Alex,

I am honored. Thank you!

Wow, you have digged out quite an old post of mine. And now I seem like I am contradicting myself, am I not?

I cannot understand how I can tag STP IEEE BPDU for example.

There are two issues to this: a technical ability of tagging a STP IEEE BPDU with a VLAN tag, and the legality of doing that. Technically, it is always possible to insert a 802.1Q tag into a frame - I am sure we both agree on this. However, a different question is whether the receiving device is expecting that a particular datagram arrives in a tagged frame.

Surely, an end host does not usually send tagged frames and it would not understand if it received a tagged frame itself (after all, end hosts rarely, if at all, know anything about VLANs and their own VLAN they're placed in). On trunk links, however, tagging user traffic is always possible (and even necessary). The concept of native VLAN on a trunk link for user data traffic is practically useless: instead of assigning untagged frames into the native VLAN implicitly thanks to the native VLAN setting on the trunk port, you can always explicitly indicate into which VLAN do these frames belong by tagging them. After all, that's the very point of the vlan dot1q tag native command. From this viewpoint, therefore, once a pair of communicating devices understand 802.1Q-tagged frames for user data traffic, they can always tag all their communication.

The communication between switches themselves is a different issue. Inter-switch communication is always a difficult topic because the traffic is not just an ordinary user data traffic, rather, the communication is inteded for the switches themselves. Contrary to, say, Frame Relay LMI that uses selected DLCIs for DTE-DCE communication (DLCI 0 for ANSI and Q.933a, 1023 for Cisco), there is no concept of a signalling VLAN - a separate, distinct VLAN that contains all inter-switch communication. What VLAN, for example, does an IEEE STP BPDU belong into if it is intended exclusively for the neighboring switch? Does a switch, as a Layer2-addressable entity, reside in some particular VLAN?

These are issues that are not of a technical but more of a philosophical nature, and there is no simple answer. Not even Cisco has a definitive approach For example, VTP and CDP systematically belong to VLAN1 and if you change the native VLAN, these messages become tagged with VLAN1. On the other hand, LOOP and DTP messages are always sent untagged, regardless of the native VLAN setting.

It seems to be IEEE's favourite approach to not tag any inter-switch protocols like STP/RSTP/MSTP, LACP, LLDP etc. If an IEEE-compliant implementation received, say, a tagged STP BPDU, would it accept it - regardless of the value in the VLAN tag? It's not certain, and furthermore, it would be a violation of the standard. But from a purely technical point of view, is there a problem in tagging STP BPDUs? Surely not, after all, tagging BPDUs is what PVST+ and RPVST+ are built upon. It's just the matter of interpreting the tagged frame appropriately. A noteworthy fact is also that the IEEE could decide that a special VLAN is reserved for all these inter-switch signalling protocols, and even this traffic could become tagged.

So once again, there are two aspects to the issue of tagging traffic: whether it can technically be done by inserting an 802.1Q tag (and this is indisputable - every Ethernet frame can be tagged), and whether it will be understood by the receiving device.

Does this answer your question? Please feel welcome to ask further!

Best regards,

Peter