Objective 2.1 – Implement and manage virtual standard switch (vSS) networks

Create and Manage vSS components

There are four major components of the Virtual Standard Switch (vSS)

Virtual Switch

A vSwitch is software that allows communication between virtual machines and the outside world. It’s embedded at hypervisor layer, so a switch within the host. By default, each ESXi host has a single virtual switch called vSwitch0. Each virtual port on a vSwitch can connect to a network adapter of a virtual machine, or an uplink adapter on the physical machine (vNIC or pNIC)

You can see all the virtual Switch of an ESXi host from “WebClient-> ESXi host -> Manage-> Networking-> Virtual Switch”



A Port Group is a group of ports on a vSwitch. Every port group has name which is unique to the current host (we’re talking about STANDARD vSwitches here).

Portgroups can be broadly classified into two types: Portgroups used for VM traffic and Portgroups used for VMKernel traffic.

Virtual Network adapter (vmnic)

The virtual network adapter is an object that is linked to the physical NIC and used to provide connectivity between the vSwitch and the physical switch via the physical NIC. So this is the link from the vSwitch to the Physical NIC on the host:


Physical Network Adapter (pNIC)

If youw ant the vSwitch to talk to the outside world, then we need to connect a pNIC to it… these will have a cable connecting them to a real physical switch.

How to create a Virtual Switch

vSwitches can be created from the GUI or from CLI. To create from the CLI do the following:

#esxcli network vswitch standard add -v vSwitch1


Create a new Portgroup “JC-Temp-PG” in vSwitch2

#esxcli network vswitch standard portgroup add -p “JC-Temp-PG” -v vSwitch2


Assign an uplink “vmnic4” to Virtual Swtich2

#esxcli network vswitch standard uplink add -u vmnic4 -v vSwitch2


Set the uplink “vmnic4” as active in vSwitch2

#esxcli network vswitch standard policy failover set -a vmnic4 -v vSwitch2


To remove PortGroups/vmnic’s and vSwitches from CLI:

Remove a PortGroup “JC-Temp-PG” from vSwitch2

#esxcli network vswitch standard portgroup remove -p “JC-Temp-PG” -v vSwitch2

Remove uplink “vmnic4” from vSwitch2

#esxcli network vswitch standard uplink remove -u vmnic4 -v vSwitch2

Remove virtual Switch “vSwitch2” from ESXi inventory.

#esxcli network vswitch standard remove -v vSwitch2

Create and Manage vmkernel ports on standard switches

VMkernel network interfaces are used primarily for management traffic, which can include vMotion, IP Storage, Virtual SAN and other management traffic on the ESXi system. You can also bind a newly created VMkernel network interface for use by software and hardware dependent iSCSI. By default there is one vKernel Portgroup “Management Network” available in the default vSwitch0 on each ESXi hosts.

Each VMkernel network interface has its own MAC address and one or more IP addresses, and responds to the standard Ethernet protocol as would a physical NIC. The VMkernel network interface is created with TCP Segmentation Offload (TSO) enabled.

Configure advanced vSS settings

There are several settings which you can change in the VSS:

MTU Size

You can change MTU Size by editing the VSS Setting -> Properties -> Set MTU Size (in bytes)


MTU Stands for Maximum transfer Unit. By default its set to 1500. Changing the MTU is required/recommended for NSX (or any SDN solution), VSAN, iSCSI etc. To enable Jumbo frames change the default MTU size into 9000.

NOTE: When you use Jumbo frame on ESXi. Make sure your physical switch and storage is also configured for Jumbo frame setting as well.

To change the default MTU Size into “9000” of “vSwitch2”

#esxcli network vswitch standard set -m 9000 -v vSwitch0 (Where –m = MTU and –v = virtual Switch)


Security Settings

You can change Security Setting by editing the vSS Setting -> Security -> Change “Accept/Reject” from the Dropdown.


Promiscuous Mode: by default it is “Reject”. You can set it to “Accept” if you want to use an application in a virtual machine that analyzes or sniffs packers, such as a network-based intrusion detection system. This is alsp required if you want to nest ESXi hosts in your lab ;p

MAC Address Changes: By default this policy is set to “Accept” in vSS. If you set it to “Reject” it will help protect against certain attacks launched by a rogue guest operating system if the VM attempts to change the MAC address assigned to a Virtual NIC. The host will stop sending traffic to the VM, in other words all inbound traffic to this VM has been stopped.

Forged Transmits: By default his policy is set to “Accept” in vSS. Forged transmits behavior is the opposite to the MAC Address change. If you set it to “Reject” it will check the source MAC address, if it has changed than it will drop all the outbound traffic from the VM. In other words Forged Transmit occurs when a network adapter starts sending out traffic whilst pretending to be a different MAC.

To change the default “Promiscuous” Security Policy into “Accept” of a Port group “JC-TEMP-PG”

#esxcli network vswitch standard portgroup policy security set -p “JC-TEMP-PG” -o true (Where –o = allow-promiscuous and –p = portgroup-name. Similarly you can use –f = forged transmit and –m = mac address change)


Traffic shaping

You can change Traffic shaping by editing the vSS Setting -> Traffic Shaping -> Change “Enabled/Disabled” from the Dropdown.

Traffic shaping on a vSS will only shape or limit outbound network traffic. By default this setting is disabled in a vSS however you can enable it and set the Network traffic limit in AVG/PEAK/BRUST.


To enable Traffic shaping on vSwitch2 and set the bandwidth AVG 700/Brust 1024/Peak 900:

#esxcli network vswitch standard policy shaping set -v vSwitch2 -e true -b 700 -t 1024 -k 900 (Where -b = avg bandwidth, -t = burst size, -e = enabled, -k = peak bandwidth and -v = vswitch name)


Teaming and Failover Policies

You can change NIC teaming by editing the VSS Setting -> Teaming and Failover -> Change you desired settings.


NIC team policies allow you to determine how network traffic is distributed between physical adapters and how to route traffic in the event of an adapter failure. NIC teaming policies include load-balancing and failover settings. Default NIC teaming policies are set for the entire standard switch however you can override these default settings at the port group level.

Load Balancing Polices

Routed Based on the Originating Virtual Port: The virtual switch selects uplinks based on the virtual machine port IDs on the vSphere Standard Switch or vSphere Distributed Switch.

Each virtual machine running on an ESXi host has an associated virtual port ID on the virtual switch. To calculate an uplink for a virtual machine, the virtual switch uses the virtual machine port ID and the number of uplinks in the NIC team. After the virtual switch selects an uplink for a virtual machine, it always forwards traffic through the same uplink for this virtual machine as long as the machine runs on the same port. The virtual switch calculates uplinks for virtual machines only once, unless uplinks are added or removed from the NIC team.

The port ID of a virtual machine is fixed while the virtual machine runs on the same host. If you migrate, power off, or delete the virtual machine, its port ID on the virtual switch becomes free. The virtual switch stops sending traffic to this port, which reduces the overall traffic for its associated uplink. If a virtual machine is powered on or migrated, it might appear on a different port and use the uplink, which is associated with the new port.

Route Based on IP Hash:The virtual switch selects uplinks for virtual machines based on the source and destination IP address of each packet.

To calculate an uplink for a virtual machine, the virtual switch takes the last octet of both source and destination IP addresses in the packet, puts them through a XOR operation, and then runs the result through another calculation based on the number of uplinks in the NIC team. The result is a number between 0 and the number of uplinks in the team minus one. For example if a NIC team has four uplinks, the result is a number between 0 and 3 as each number is associated with a NIC in the team. For non-IP packets, the virtual switch takes two 32-bit binary values from the frame or packet from where the IP address would be located.

Any virtual machine can use any uplink in the NIC team depending on the source and destination IP address. In this way, each virtual machine can use the bandwidth of any uplink in the team. If a virtual machine runs in an environment with a large number of independent virtual machines, the IP hash algorithm can provide an even spread of the traffic between the NICs in the team. When a virtual machine communicates with multiple destination IP addresses, the virtual switch can generate a different hash for each destination IP. In this way, packets can use different uplinks on the virtual switch that results in higher potential throughput.

However, if your environment has a small number of IP addresses, the virtual switch might consistently pass the traffic through one uplink in the team. For example, if you have a database server that is accessed by one application server, the virtual switch always calculates the same uplink, because only one source-destination pair exists.

Route Based on Source MAC Hash: The virtual switch selects an uplink for a virtual machine based on the virtual machine MAC address. To calculate an uplink for a virtual machine, the virtual switch uses the virtual machine MAC address and the number of uplinks in the NIC team.

Use explicit Failover Oder: No actual load balancing is available with this policy. The virtual switch always uses the uplink that stands first in the list of Active adapters from the failover order and that passes failover detection criteria. If no uplinks in the Active list are available, the virtual switch uses the uplinks from the Standby list.

The above descriptions lifted from VMware

Network Failure detection: Using this will detect the link state of the physical adapter. If the physical switch fails or someone unplugs the cable from the NIC or the physical switch, failure will be detected and failover initiated.

  • Link Status only: Relies solely on the link status that the network adapter provides. This option detects failures, such as cable pulls and physical switch power failures, but not configuration errors, such as a physical switch port being blocked by spanning tree or that is misconfigured to the wrong VLAN or cable pulls on the other side of a physical switch.
  • Bacon probing: Sends out and listens for beacon probes on all NICs in the team and uses this information, in addition to link status, to determine link failure. This detects many of the failures previously mentioned that are not detected by link status alone.

Notify Switch: If you select Yes, whenever a virtual NIC is connected to a vSS or whenever that virtual NIC’s traffic would be routed over a different physical NIC in the team because of a failover event, a notification is sent out over the network to update the lookup tables on physical switches. In almost all cases, this process is desirable for the lowest latency of failover occurrences and migrations with vMotion.      

Failback: This option determines how a physical adapter is returned to active duty after recovering from a failure.

These configurations can all be made from the CLI:

Example 1: Change the load balancing policy of vSwitch2 into IP based Hashing

#esxcli network vswitch standard policy failover set -v vSwitch2 -l iphash where -l = load balancing (portid, iphash, mac, explicit) and -v = vswitch name

Example 2: Change the Network failover detection method of vSwitch2 into beacon probing

#esxcli network vswitch standard policy failover set -v vSwitch2 -f beacon where -f = failure detection (link, beacon) and -v = vswitch name

Example 3: Set the Notify Switch option of a vSwitch2 to No

#esxcli network vswitch standard policy failover set -v vSwitch2 -n false where  -n = notify switch

Example 4: Set the failback of vSwitch2 to No

#esxcli network vswitch standard policy failover set -v vSwitch2 -b false where -b = failback


VLANs can be tagged at the portgroup level.

From GUI you can change/set VLAN Setting by selecting and editing the PortGroup on the vSwitch and in the PortGroup properties enter the VLAN ID.


From the CLI:

#esxcli network vswitch standard portgroup set -p “VM Network” -v 15