A municipal top-of-rack switch delivers many VM port-group VLANs to the cluster on one physical uplink. Which vSphere and physical attachment model is that?
Select an answer to reveal the explanation.
Short Explanation
One driveway carrying many painted lanes is a trunk. The ToR sends several port-group VLANs down that uplink, and vSphere still depends on that physical VLAN model. Overlay can reduce tenant VLAN sprawl later, but it does not redefine this attachment as promiscuous mode or a guest-side transport zone.
Full Explanation
When a municipal top-of-rack switch delivers many VM port-group VLANs to the cluster on one physical uplink, the model is VLAN trunking of multiple 802.1Q VLANs from the physical switch onto the host uplinks. One driveway carries many painted lanes: the ToR trunks several VLANs, and vSphere port groups select which tag each VM network uses. Geneve overlay that removes every VLAN from the physical underlay overstates overlay’s role—overlay can reduce tenant VLAN sprawl, but it does not mean the underlay never uses VLANs for management, TEPs, or VLAN-backed segments, and it is not the model described for delivering many port-group VLANs on one uplink. An NSX transport zone that stamps VLANs inside the guest operating system misstates both transport zones and where tagging occurs. Promiscuous mode on a port group lets a VM see extra frames on that port group; it does not replace a trunk for carrying multiple VLANs to the host. Exam caveat: even in NSX designs, underlay trunks and VLAN hygiene remain operationally important for management, storage, and TEP networks. Associate questions test recognition of trunking versus access links and versus overlay. Operational check: confirm the ToR interface to each host is a trunk allowing the required VM and service VLANs; match VDS or VSS port-group VLAN IDs to allowed VLANs; and verify a VM on VLAN A cannot be expected to ride an access port that only permits VLAN B.