One of my colleagues today asked me if it was possible to use VLAN ID 4095 for the “management” network of ESXi. This VLAN ID is however reserved for a very specific purpose.
This particular VLAN ID is only to be used for “Virtual Guest Tagging” (VGT). It basically means that the VLAN ID is stripped off at the Guest OS layer and not at the portgroup layer. In other words the VLAN trunk(multiple VLANs on a single wire) is extended to the virtual machine and the virtual machine will need to deal with it.
When will you use this? To be honest there aren’t many use cases any more. In the past it was used to increase the number of VLANs for a VM. The limit of 4 NICs for VI3 meant a maximum of 4 portgroups / VLANs per VM. However with vSphere the maximum amount of NICs went up to 10 and as such the amount of VLANs for a single VM also went up to 10.
Before people start to get excited about Virtual Guest Tagging, I personally prefer to stay away it. It heavily complicates the configuration of the VM and the vSwitch/dvSwitch and adds additional unneeded “stress” on your VMs vCPU.







Hi Duncan,
Thanks for sharing this! It was a question a few weeks ago from a costumer which i at the time couldn’t reply on.
With this explanation i most certainly can.
BTW. Do you have any indication of the “stress” factor of VGT?
One note (i think you’ve forgotten the word “from” in between away and it). Stay away from it. FYI.
Again thanks for the information!
Arjan Timmerman
That’s somewhat odd – hopefully he meant management “port” as on a physical switch (not the management network in ESXi). Either case, is there a better way to get a management port than using 4095 in combination with promiscuous mode for the port group?
It is also probably worth noting that the IEEE 802.1Q standard states that VLAN ID 4095 is reserved and should not be used for VLAN assignments. This is why VMware utilised ID 4095 to provide VGT.
@arjan, well that depends on the amount of network IO doesn’t it? But probably a couple %. It would not be a lot, but with 30 VMs running on a host it might result in something unexpected for something that is unneeded.
@virtual_jtw no ESXi management network. not sure what the reason was.
@KyleMcM good comment, should have mentioned that.
Hi Duncan,
actually, i have already used this Vlan ID in a special configuration (when virtualizing ESX4) so that the v(vSwitch) can unTag the vlans on its own vPortgroups, in that configuration i VMotioned a VM from a pESX to a vESX and also a vESX with running vVMs from one pESX to another.
Saad OUACHE.
Guys
Be aware that there are network-equipment vendors out there which use that vlan for certain internal management functions and will thus not transport this vlan. So better stay away from VLAN-ids >4090…
Cheers
Roman
There are some use cases for this. When you want to see whether a VLAN is working properly to the ESX host, you can set up a Linux VM with 4095 that has access to all VLANs to see if you can hit layer 3 on them. It’s more for a network checkup VM, not an everyday sort of thing.
Doesn’t AppSpeed use 4095 to grab traffic off the vSwitch for analysis?
@CarlSkow, definitely a good usecase for it.
We have two use cases for that in production :
the first one is for doing some traffic inspection with WireShark or other software.
the second one is an inter-VLANs router under Vyatta, we have dozens of VLANs routed through a few gigabit LAN interfaces with ‘trunking VM Network’
One use case for guest VLAN trunking when 10 vNICs are not enough:
We have >300 VMs in 65 landscapes (VLANs), we plan to double both numbers. So we have 65 portgroups in vDS on ESX cluster and each VLAN obviously has its own network segment.
I’m right now in the middle of VDI PoC which will utilize Citrix DDC/PVS to provision/deliver virtual desktops and ESX/VI as VD hosting infrastructure.
DDC/PVS needs to communicate to every VLAN/virtual desktop it is going to manage. So there are only two options left: setup inter-VLAN routing or have an option for DDC/PVS server have a leg (interface) in every VLAN where desktops are going to reside.
Because we have a requirement for fenced networks (devices in VLANs should not be able to communicate with devices in other VLANs) the second option is the only acceptable option for us. And Guest OS VLAN tagging in the only way to have it done in Vmware.
Coincidentally i have a business case for the use of 4095 which we will be implementing soon. I’d be interested to see if what i am going to do is incorrect!
I have 4 ESXi hosts in a cluster and each host has only one pNIC left (1Gb). I have assigned this vmnic to a vSwitch and created three port groups within this vSwitch; Zone1, Zone2, Zone3. All the port groups have been assigned VLAN ID 4095; displayed as ‘All’.
We will be hosting several VMs within these port groups with VMs being in Zone1 the closest to our corporate LAN and the VMs within Zone3 being the closest to the outside world. We will be using our corporate LAN and WAN hardware to VLAN the traffic between the zones in a type of serial (Zone 1 to Zone2 to Zone3) to ensure traffic stays within certain boundaries.
I can’t see this being a problem. Does anyone disagree?
Thanks
Simon