vSphere Standard vSwitch VLAN and Trunk Port Groups

Most vSphere networking incidents are port-group mistakes rather than switch mistakes: a VLAN ID left at 0, a nested lab that needs guest tagging but is given a normal port group, or a host uplink that is not a trunk while the vSwitch expects tags to pass. This guide explains the three tagging models - virtual switch tagging, external switch tagging and virtual guest tagging - how the VLAN ID field on a port group changes host behaviour in each case, and the esxcli commands to build port groups and VMkernel adapters without the client. It closes with the verification steps that prove a guest is actually on the VLAN you think it is.

Three tagging models, one VLAN ID field

• Virtual Switch Tagging (VST) - the default in almost every environment. The physical switch port is an 802.1Q trunk, the port group has a VLAN ID between 1 and 4094, and the vSwitch strips the tag before the frame reaches the guest. The guest sees untagged traffic on the correct VLAN.
• External Switch Tagging (EST) - the physical port is an access port in a single VLAN and the port group VLAN ID is 0. Only one VLAN can traverse the uplink. Correct only where one VLAN per host uplink is genuinely acceptable.
• Virtual Guest Tagging (VGT) - the port group VLAN ID is 4095, which tells the standard switch to pass 802.1Q tags through to the guest. The guest OS, virtual firewall or nested hypervisor handles tagging itself. 4095 is not a VLAN on the wire, and a standard switch cannot restrict which VLANs the guest may use - that is a distributed switch trunk policy feature.

Build port groups with esxcli

esxcli network vswitch standard portgroup add --portgroup-name="VM-Network" --vswitch-name=vSwitch0
esxcli network vswitch standard portgroup set --portgroup-name="VM-Network" --vlan-id=30

esxcli network vswitch standard portgroup add --portgroup-name="Guest-Trunk" --vswitch-name=vSwitch1
esxcli network vswitch standard portgroup set --portgroup-name="Guest-Trunk" --vlan-id=4095

Keep management, vMotion, vSAN and IP storage traffic on their own port groups with their own VLAN IDs, and never convert a management port group into a 4095 trunk as part of another change. On a standard switch the configuration is local to each host - vCenter does not replicate it - so on a cluster you must apply identical settings everywhere, ideally through host profiles.

VMkernel adapters and traffic types

esxcli network ip interface add --interface-name=vmk1 --portgroup-name="vMotion-VMkernel"
esxcli network ip interface ipv4 set --interface-name=vmk1 --type=static --ip=192.168.20.10 --netmask=255.255.255.0
esxcli network ip interface tag add --interface-name=vmk1 --tagname=VMotion
esxcli network ip interface list

Each traffic type gets its own VMkernel interface for a reason: teaming policy, VLAN and MTU can then be tuned independently, and a misconfiguration in one cannot blackhole another. Tagging vMotion and then forgetting the corresponding VMkernel tag is a classic silent failure - vMotion traffic will attempt to use a VMkernel not enabled for it and fail only under load.

Verify end to end

esxcli network vswitch standard list
esxcli network vswitch standard portgroup list
esxcli network vswitch standard uplink list
esxcli network nic list
vmkping -I vmk1 -s 8972 192.168.20.1

Confirm three things: the port group carries the intended VLAN ID, the physical switch ports connected to active uplinks are trunks allowing those VLANs, and the guest actually received an address from the expected subnet. If a guest cannot reach anything after a port-group change, check the switch side first - an untagged/native VLAN mismatch on the uplink usually looks like a routing problem from inside the VM.

Teaming notes

The default standard-switch policy routes by originating virtual port ID; it spreads VMs across uplinks but never aggregates bandwidth for one VM. IP hash can spread flows but requires a static EtherChannel or static port channel on the physical switch, not LACP - LACP on the host side is a distributed switch feature. Compare this host-side model with the equivalent on Hyper-V in Hyper-V virtual switch VLAN and trunk configuration, and with a Linux host-side equivalent in Proxmox VE VLAN-aware bridge and LACP bonding.

原文链接：https://vmwaremadesimple.com/articles/home-lab-networking-vmware-vlans-vswitches-physical-setup.html