Basic Trunking and Native Vlan understanding

[smk391]

Hi, I'm trying to understanding the following, it is a basic topic but I need to be crystal clear on my understanding. 

We have a VM connected to a trunk port, the VM was unable to contact its default gateway which was located on a firewall further up north in the DC. 

The VM was sending frames untagged to the trunk interface on the switch 

Once I had added a native VLAN config to the trunk ( native 765 ) the VM was able to reach the gateway. 

Why is this?

my understanding that the frames were getting dropped because they were not being tagged?  the switch was receiving the frame, no VLAN tagging ( & no native VLAN ) and therefore dropped the frame ?  is this correct?

When I added the native VLAN, is it the switch which adding the VLAN 765 header into the frame?

many thanks 

[luis_cordova]

Hi @smk391 ,

In simple words, the function of the Native Vlan is tag all the packets that arrive without tag.
When you configure the Native Vlan in your trunk port, you are giving a VLAN number to the untagged packets.

Once the packet already has a tag, it can be switched and routed.

Regards

[Jaderson Pessoa]

@smk391 as @luis_cordova said. To add a bit on this, there is other option on VM Networking to set native vlan on that if you dont like to apply it on switch interface.

[Jaderson Pessoa]

@smk391 as Luis said. To add a bit on this, there is other option on VM Networking to set native vlan on that if you dont like to apply it on switch interface.

[joseph.h.nguyen]

Why you say? Switching is coded that way.  You have to understand that by default networking endpoint does not insert (tag) its frame with 802.1Q overhead.  Switch in general receives untagged frames and associated them to a VLAN based on its current configuration in order to build its CAM table, or content addressable memory table.  By default, received frames are processed and their source MAC address becomes associated to VLAN 1 unless otherwise configured to a specific VLAN ID.  Simultaneously, the process reads and learns the destination MAC address within the frame header and then determines its handling based on MAC address bits whether it is a unicast, multicast or a broadcast type.  Unicast action performs a MAC address lookup based on its CAM table and based on that lookup, it either forwards the frame and queued it the outgoing switch port or it floods the unicast frame to all switch ports in the same VLAN except the originating port.  By default, frames leaving the switch are not tagged, specifically switch mode access ports, unless frames are leaving from a switch port trunk.  Outgoing trunking interface processes the queued outbound source mac address within the frame header by inserting a 802.1Q overhead based on the CAM table.  

To answer your questions, your switch trunk port processed untagged frames and associated them to the switch configured native VLAN ID to build its CAM table.  Prior to changing your native VLAN ID to 765, your VM's frames were flooding every switch ports in your switch's native VLAN but not to the ones in VLAN 765.  Switch trunking port expects to see 802.1q or the absence of it.  Switch access port only expects an absence of 802.1Q (untagged frame).  Generally, switch does not drop frames unless it is configured otherwise.

You should be aware that typical VM environment has the capability to tag VM's frames by creating virtual switch or port group.

[Jon Marshall]

Just to clarify as you asked for it to be crystal clear. 

You are spot on as to the reason it was not working but be aware there is always a native vlan on the switch, it just didn't match the one you were using on your ESXi host. 

Once you changed the native vlan to match your host then it worked but the switch does not then add a tag to the frame, it does not need to, because it knows what vlan the frame is in already and it still would not need to add a tag if it was forwarding it on to another switch providing the same native vlan has been used on all trunk links. 

However, as you can if you want, use a different native vlan per trunk, if the switch did need to forward it on to another switch and the native vlan was not the same then it would now need to add a tag to that frame before sending it. 

Probably goes without saying but just to be clear I am not suggesting having a different native vlan per trunk is a good idea :) 

Jon

[smk391]

Thank you very much for quick and useful replies, much appreciated everyone.  

From what I can understand, the vm was unable to contact the gateway because there was no native clan configured. Well there is ( vlan 1 ) but it was different to the vlan of the gateway.  The switch doesn't add in the vlan tag for the native vlan.  

So the frame came onto the switch with no tagging, the switch flooded to find out the gateway's Mac address out of all ports on vlan 1.  It didn't get a reply so the VMware was unable to contact it's gateway. 

Workaround, 

Either get the VMware team to tag the frame or use tagging on the switch by either using a native vlan or by adding the port to a vlan using the switch port mode access command?? 

With the switch port mode access and then switchport access vlan X , the switch would then insert the vlan header wouldn't it ? 

Thanks 

[Jon Marshall · Accepted solution]

Your workarounds are correct but just to note if you change native vlan or use an access port you are not tagging on the switch because the switch does not need to tag as explained previously. 

Jon