It’s quite common to want to present multiple VLANs to your vSphere host, as typically the guests being virtualized belong to a multitude of different VLANs. Perhaps the VLANs are being used to separate the DMZ from LAN, or development from production. Whatever the decision may be, the functional requirement is there.
In some cases, I see what I call a “porcupine” host. One that is covered with NICs to satisfy VLAN requirements, as each uplink (or pair of uplinks) have been connected to access ports on the next hop switch. Yikes!
While there are some use cases for doing this (such as for an air gap security requirement) it’s not necessarily the best way to get the job done. Instead, the use of trunk ports may be appropriate and reduce both cost and complexity.
The infamous “Porcupine Host”!
A Brief Introduction to Trunking
Trunking is the concept of passing multiple VLANs over the same port using tags. The most common tagging is 802.1Q, which is an IEEE standard that nearly all switches support. The tag is there to identify which VLAN the layer 2 frame belongs to. vSphere can both understand these tags (receive them) as well as add them to outbound traffic (send them).
Here are a few good ideas when setting up trunk ports to a vSphere host:
- Only present the VLANs that are necessary for the virtual machine guests on the vSphere host to the trunk port. This is the “Trunking VLANs Enabled” section of a switchport. It helps keep unnecessary broadcast traffic to a minimum.
- I typically use both PortFast and BPDU guard on a trunk port destined for a vSphere host. PortFast enables the port to immediately begin forwarding traffic, without the need for spanning tree to ensure that another switch is not connected to the port. BPDU guard listens for BPDUs on the port, which are sent by other switches, to ensure that other switches are not accidentally connected to the port. vSphere standard and distributed switches are an exception to this, as they are unable to form a loop and thus spanning tree will be satisfied.
Configuring a Trunk on a Cisco Switch
From your Cisco switch, identify which port(s) the vSphere host will be connected to. This assumes you have some level of knowledge of how to work with Cisco IOS.
Here are sample commands on my Cisco Catalyst 3550 in the home lab:
User Access Verification
Enter configuration commands, one per line. End with CNTL/Z.
Lab3550(config)#interface fastEthernet 0/8
Lab3550(config-if)#switchport trunk encapsulation dot1q
Lab3550(config-if)#switchport mode trunk
Lab3550(config-if)#spanning-tree bpduguard enable
%Warning: portfast should only be enabled on ports connected to a single
host. Connecting hubs, concentrators, switches, bridges, etc... to this
interface when portfast is enabled, can cause temporary bridging loops.
Use with CAUTION
There, I have now have a trunk port.
If I wanted to limit the VLANs allowed on this trunk, the command below can be issued once you enter the (config-if) mode for the interface:
Lab3550(config-if)#switchport trunk allowed vlan [WORD | add | all | except | none| remove]
Setting VLANs on vSphere Portgroups
Now that the switch is configured to pass multiple VLANs over the trunk port, the final step is to create portgroups on the vSphere host. In this scenario, we’re creating portgroups in VST (virtual switch tagging) mode. This means that the virtual switch will read (remove tags) and send (add tags) to traffic, while the guest will be completely unaware of the tags.
The process is simple. From within the settings of a portgroup, navigate to the VLAN section. Change the VLAN type to VLAN, and enter the VLAN ID the portgroup should be receiving. Below is my home lab portgroup that is listening for tags on VLAN 10.
I also find it helpful to name the portgroup something that reflects the VLAN. In my example above, my portgroup is named “VLAN10 – 192.168.10.X” to easily denote both the VLAN and subnet being used.
This one is pretty straight forward, so I will leave you with a dancing bear.