Thanks for the responses.

Hi

1 ) Why do we need to connect a pc to a trunk port ? (dumb question:))

2 ) Why PC Network adapters support vlan tags ? .

   Vlan tagging is happens  only when   frame going through the  trunk  and the switch strip the vlan tag  before sending to the port where pc is connected . So my question is   even if the nic support  vlan tag the pc will  receive and send  untagged frame .   

( for example  If the  pc  connected to an access port  with vlan 10  , when the frame passes through the trunk it will be tagged by vlan 10 and when it leaves the trunk  vlan id will stripped )

Correct me if i am wrong :)

Thank you 

Hi,

The second question - why PC Network adapters support VLAN tags - is actually easier to answer :)

First of all, with regards to VLANs and frame tagging, there is actually nothing special to support on a network adapter! The VLAN tag itself is in fact stored in the payload of a tagged frame. Even to the most dumb network adapter, a tagged frame looks like any other - Destination MAC, Source MAC, EtherType (set to 0x8100), Payload (holding the rest of the VLAN tag, the original EtherType and the original Payload), and the FCS. Supporting VLANs and frame tags is possible on a purely software level. The fact that network adapters often do have hardware support for VLANs is related to performance reasons: With hardware VLAN support, the tagging, de-tagging, filtering and/or sorting frames based on the VLAN tag value is faster and it allows offloading these operations from the computer's CPU to the network card. However, even if the network adapter did not have any kind of VLAN support, the VLANs could still be implemented purely in the card's software driver.

Ordinarily, you would not see a common PC send and receive tagged frames. However, there are situations in which even a PC would send or receive a tagged frame. One of reasons is the presence of the Class-of-Service (CoS) bits in a VLAN tag. You surely know that basic Ethernet frame format does not include any kind of priority marking. There is no field in an Ethernet header that would allow you to indicate that this or that frame requires a preferential treatment. VLAN tags, on the other hand, have a 3-bit CoS field that allows you to indicate the priority of the tagged frame. Should a  PC need to send a frame that needs to be explicitly marked as more important than others, it can be done by inserting a VLAN tag into this frame and setting the CoS field to a non-zero value (with 3 bits, the maximum CoS value is 7).

Another reason for a computer to send and receive tagged frames would be when the computer itself would be intentionally placed into multiple VLANs. For example, the router-on-a-stick performing inter-VLAN routing is not a concept just for dedicated hardware routers. For example, any computer running Linux can be used in place of a Cisco router to perform inter-VLAN routing. Just like on a Cisco router, you would configure the Linux with subinterfaces for each VLAN it should be able to route from and to, assign IP addresses, and voila - you have a cheap and powerful inter-VLAN router. Yet another reason for receiving and sending tagged frames on a computer would be virtualization: You could have a server that runs multiple virtual operating systems in VirtualBox, VMWare, Xen or some other virtualization solution, and you want each of these virtual PCs to have a "separate" network card so that they can not talk to each other when they communicate with the outside world. You would do this again by creating subinterfaces on the physical machine, and bridging the individual virtual PCs with unique subinterfaces so that each virtual PC gets its own subinterface onto which it is bridged. As a result, the communication of individual virtual PCs would be tagged on the physical link depending on what virtual machine was speaking.

So, while not exactly a typical situation for an ordinary office PC, it is nonetheless quite normal to see a computer being connected to a trunk port. This, however, is always done with the prior knowledge that the computer will indeed need to talk to several VLANs simultaneously and directly. Otherwise there's no need for that.

Regarding the native VLAN on trunks - well, this is a neverending debate. I wish the native VLAN was never invented but well, it's here so we have to fight with it. Often, it is explained as "the VLAN that will save you if you happen to connect a normal PC to a trunk", and you have asked quite correctly - why on Earth would I want to connect a normal PC to a trunk, if not for reasons stated above? And you would be perfectly right - you wouldn't. The reason for native VLANs is different. If you try to study the IEEE 802.1Q standard you will learn that it does not recognize the terms access port and trunk port. It has no distinction for these port types. Instead, 802.1Q considers each port to be possibly associated with multiple VLANs at once. One of these VLANs is called the Primary VLAN, its number (ID) is called the Primary VLAN ID (PVID), and this VLAN is considered to be the one that is always associated with the port and thus does not need to use tags. Any other VLAN that is in addition associated with the port obviously has to use tags to be distinguishable. From this viewpoint, a port that is associated just with its PVID would be what Cisco calls an access port, and a port that is associated with VLAN IDs other than just its PVID would be what Cisco calls a trunk port, with the PVID being the trunk's native VLAN ID.

So in the way IEEE defines VLANs and their usage, PVID (= native VLAN ID) is a property of each port, so any implementation that claims compatibility with 802.1Q has to implement the PVID. Cisco decided to have a twist on the understanding of VLANs, and came up with access ports (i.e. ports associated just with their PVID and no other VLAN ID) and trunk ports  (i.e. ports associated with many VLAN IDs including PVID), and so each trunk port must have its PVID - and that is what we call native VLAN and why we need to at least support it - although we do not need to make use of the native VLAN on trunks.

Quite convoluted.

Best regards,
Peter

Hi Peter 

getting more clear 

Thanks 

Hi!

There are some material and explanation of voice vlan and native vlan as a cisco's implementation of TAGGED, UNTAGGED traffic, PVID and trunk ports.

To check this theory I made a little lab:

Here is some illustration and result:

Hi,

I believe that the problem lies in the configuration of your SWITCH_1 and SWITCH_3. According to the exhibit, you have configured their trunks as follows:

switchport trunk native vlan 12
switchport trunk allowed vlan 14

In effect, the only VLAN that is ever allowed to pass over this trunk is VLAN 14. The fact that VLAN 12 is untagged is completely irrelevant to this fact - VLAN 12 is not in the list of allowed VLANs so all communication in VLAN 12 on this trunk is prohibited, tagged or native.

Try replacing the second command with

switchport trunk allowed vlan 12,14

and see what happens then.

Best regards,
Peter

You absolutely right, Peter! It was my misunderstanding of the switchport logic. After adding vlan 12 to the trunk everything work as well! I will made some traffic capture and lab to dig deeper.

Best regards,

Dmitriy.

I will buy Peter Paluch a bottle of suds anytime he wants me to.  Truly well explained and well understood.  There are people that understand things and yet there are people that understand things but cannot explain.  Peter falls into a unique category of individuals that know what they are talking about and can explain succinctly.  Well done.

p

Hi,

I will buy Peter Paluch a bottle of suds anytime he wants me to.

LOL, you know what they say: Be careful what you wish, for you may get it :)

Seriously, though, thank you very much. Your kind words are very much appreciated.

Best regards,
Peter

I know this was posted a while ago but I just want to say thanks for this explanation. I was looking for some more information about native VLAN IDs and your post absolutely nailed it. Many thanks.

Very well explained by Peter.

But may i ask one other question than:

From the explanation from Peter, i understand that the PVID is sort of a "backup" vlan: i receive lots of tagged frames and if -intentionally or by accident- receive an untagged frame, i put it in vlan PVID. Fine.

What happens (or should happen) if a trunked port receives a TAGGED frame with PVID tag ? Like in this case:

 switchport trunk native vlan 352

 switchport trunk allowed vlans 352,355

If it receives an untagged frame, it is put in vlan 352.

1) What happens if this port received a tagged 352 packet ?

- is it forwarded or is it dropped ?

- and is this behavior consistent across all Cisco platforms ?

2) What happens if this packet is forwarded to a second server with the same config.

Because this packet is defined as native vlan, all tags are removed and the packet is forwarded untagged. Doesn't this generate communication problems as the server is expecting tagged packets ? Or does the server also need to have a native vlan concept ?

3) I can force a port to tag the native vlan to solve the problem in 2:

switchport trunk native vlan tag

The question then is: does this not alter behaviour (1), ie both tagged and untagged packets for the native vlan are still accepted ?

regards,

Geert

Hi Geert,

My apologies for getting back to you so late.

i understand that the PVID is sort of a "backup" vlan: i receive lots of tagged frames and if -intentionally or by accident- receive an untagged frame, i put it in vlan PVID. Fine.

This is one way of looking at it, and it's not a wrong one - that the native VLAN is a sort of a "fallback" VLAN for untagged frames. Then again, you might ask: If both devices are using the trunk the way they should - by properly tagging traffic with the corresponding VLAN tags - why should you be even worried about receiving untagged frames?

Cisco and IEEE 802.1Q seem to have been having different takes at the same thing. 802.1Q can be seen as an extension to existing 802.3 Ethernet standards. With an extension, you should keep what you already have, and add new features on top. This seems to be the case with the 802.1Q and the native VLAN: With basic Ethernet, we had no VLANs and no tagging. When 802.1Q came along, the basic Ethernet without VLANs remained in the form of the native VLAN, and VLANs were added on top of the existing functionality. 802.1Q standard does not divide switch ports into access ports and trunks; rather, it merely adds the possibility of each port to carry multiple tagged VLANs in addition to its existing functionality of carrying untagged traffic.

Cisco took a different approach: It decided to go with a notion of access ports that remain in a single VLAN and do not use tagging, and trunk ports that are by default a member of all VLANs and obviously need to use tagging. However, to claim compatibility with 802.1Q, it was necessary for trunk ports to also support the PVID which got the name of the "native VLAN" in Cisco parlance.

switchport trunk native vlan 352
switchport trunk allowed vlans 352,355

If it receives an untagged frame, it is put in vlan 352.

Correct.

1) What happens if this port received a tagged 352 packet ?

- is it forwarded or is it dropped ?

It is forwarded. Recall that the VLAN tag also carries CoS bits and the DEI (Discard Eligible Indicator) bit. If you need to send a frame in the native VLAN with a non-default CoS value across a trunk, the only way to indicate this CoS value is to tag the frame. Surely, dropping the frame in this case would be quite a mistake.

- and is this behavior consistent across all Cisco platforms ?

I cannot say with first-hand experience for all switching platforms made by Cisco, but it has been my experience with Catalyst platforms. If I have some time I can test that with Nexus switches as well. However, I believe that the logic of sending tagged frames on the native VLAN due to non-default or explicitly indicated CoS values is clear enough to warrant a similar behavior for all switching platforms.

2) What happens if this packet is forwarded to a second server with the same config.

Because this packet is defined as native vlan, all tags are removed and the packet is forwarded untagged. Doesn't this generate communication problems as the server is expecting tagged packets ? Or does the server also need to have a native vlan concept ?

Even though this might be a little nitpicking, the removal of the VLAN tag due to native VLAN affects only the top tag. If the frame carried multiple VLAN tags, as is common in Q-in-Q scenarios, only the top tag that matched the native VLAN of the egress trunk would be removed. Of course, with single-tagged frames, the frame would indeed be sent out untagged.

If the server is expecting tagged frames then obviously, this would cause communication problems.

Very simply put, if you want to use a native VLAN to carry traffic on a trunk then both endpoints of the trunk must support it. Otherwise, the untagged frames would be misprocessed by the device that expects them to be tagged.

I cannot speak for Windows-based servers as I do not have operational experience with those, but at least as far as Linux-based servers go, they support native VLAN naturally - the native VLAN is simply represented by the physical interface itself (e.g. eth0), while the subinterfaces such as eth0.11, eth0.12, etc. are dedicated to specific VLANs.

Please feel welcome to ask further!

Best regards,
Peter