VMware vSphere Networking deep dive

vSphere Networking
vSphere 6.0
VEPSUN TECHNOLOGIES

Introduction to vSphere Standard Switches
Types of Virtual Switch Connections
A virtual switch provides two connection types to hosts and virtual machines:
 Connecting virtual machines to the physical network.
 Connecting VMkernel services to the physical network. VMkernel services include access to IP storage,
such as NFS or iSCSI, VMware vSphere, vMotion migrations, and access to the management network.
The VMware ESXi management network port is used to connect to network or remote services, including
VMware vSphere Web Client. Each ESXi management network port and each VMkernel port must be configured
with its own IP address, netmask, and gateway.
To help configure virtual switches, you can create port groups. A port group is a template that stores
configuration information to create virtual switch ports on a virtual switch. Virtual machine port groups are
used to connect virtual machines to one another with common networking properties.
Virtual machine port groups and VMkernel ports connect to the outside world through the physical Ethernet
adapters that are connected to the virtual switch uplink ports.
Virtual Switch Connection Examples
When you are designing your networking environment, VMware vSphere enables you to place all your networks
on a single virtual switch. Or you can opt for multiple virtual switches, each with a separate network. The
decision partly depends on the layout of your physical networks. For example, you might not have enough
network adapters to create a a seperate virtual switch for each network. Instead, you might team your network
adapters in a single virtual switch and isolate the networks by using VLANs.

Because physical NICs are assigned at the virtual switch level, all ports and port groups that are defined for a
particular switch share the same hardware.
Types of Virtual Switches
 A standard switch is a virtual switch configuration at the host level.
 A distributed switch has similar components as those of a standard switch. A distributed switch
functions as a single virtual switch across all associated hosts. A distributed switch is configured in
VMware vCenter Server at the data center level.
Standard Switch Components

The image shows five standard switches, each devoted to a different purpose. From left to right, the switches
are in numerical order:
1. A standard switch with a single outbound adapter. this switch is used only by VM1.
2. An internal-only standard switch, which enables virtual machines in a single ESXi host to communicate
directly with other virtual machines connected to the same standard switch. VM2 and VM3 can use this
Switch communicate with each other.
3. A standard switch with teamed NICs. A NIC team provides automatic distribution of packets and failover.
4. A standard switch that is used by the VMkernel for accessing iSCSI-or NAS-based storage.
5. A standard switch that is used by the VMkernel to enable remote management capabilities.
Viewing the Standard Switch Configuration
The image shows the standard switch vSwitch1 on an ESXi host. By default, the ESXi installation creates a virtual
machine port group named VM Network and a VMkernel port named management Network.
A good practice is to remote the VM Network virtual machine port group and keep virtual machine networks
and management networks separated for performance and security reasons.
To remove a standard switch, Click the Red X next to the switch to be deleted. To display virtual switch
properties, Click the pencil icon above the virtual switch.
Port group properties for a port or port group can be displayed. If applicable, Cisco Discovery Protocol (CDP)
information can be shown for a physical adapter.
CDP enables ESXi administrators to determine which Cisco switch port is connected to a given virtual switch.
When CDP is enabled for a particular virtual switch, you can view properties of the cisco switch from the
vSphere Web Client. Properties include device type, Port ID, hardware capabilities, and so on.

About VLANs
VLANs provide for logical groupings of switch ports, enabling communications as if all virtual machines or ports
in a VLAN were on the same physical LAN segment. A VLAN is a software-configured broadcast domain. Using a
VLAN has the following benefits:
 Creation of logical networks that are not based on the physical topology
 Improved performance by confining broadcast traffic to a subset of ports on a switch
 Cost saving by partioning the network without overhead of deploying new routers
VLANs can be configured at the port group level. The ESXi host provides VLAN support through virtual switch
tagging, which is provided by giving a port group a VLAN ID. By default, a VLAN ID is optional. The VMkernel then
takes care of all tagging and untagging as the packets pass through the virtual switch.
The Port on a physical switch to which an ESXi host is connected must be defined as a static trunk port. A trunk
port is a port on a physical Ethernet switch that is configured to send and receive packets tagging with a VLAN
ID. No VLAN configuration is required in the virtual machine. In fact, the virtual machine does not know that it is
connected to a VLAN.
Network Adapter Properties
You can change the connection speed and duplex of a physical adapter to transfer data in compliance with the
traffic rate.
If the physical adapter supports SR-IOV, you can enable it and configure the number of virtual functions to use
for virtual machine networking.

Network Switch and Port Policies
Network security policy provides protection against MAC address impersonation and unwanted port scanning.
Traffic shaping is useful when you want to limit the amount of traffic to a virtual machine or a group of virtual
machines. You do traffic shaping to either protect a virtual machine or traffic in an oversubscribed network.
Use the teaming and failover policy to determine how the network traffic of virtual machines and VMkernel
adapters that are connected to the switch is distribute between physical adapters, and how the traffic should be
rerouted if an adapter fails.
These policies are defined for the entire standard switch and can be defined for a VMkernel port or a virtual
machine port group. When a policy is defined for an individual port group, the policy at this level overrides the
default policies defined for the standard switch.
Configuring Security Policies

For a vSphere standard switch, you can configure security policy to reject MAC address ad promiscuous mode
changes in the guest operating system of a virtual machine.
The network security policy contains the following exceptions:
 Promiscuous mode: Promiscuous mode allows a virtual switch or port group to forward all traffic
regardless of their destinations. Default is Reject.
 MAC address changes: When set to Reject, if the guest attempts to change MAC address assigned to the
virtual NIC, it stops receiving Frames. Default is Accept
 Forged Transmits: A frame's source address field may be altered by the guest, and contain a MAC
address other than the assigned virtual NIC MAC address. you can set the forged transmits parameter to
accept or reject such frames. Default is Accept.
In general, these policies give you the option of disallowing certain behaviors that might compromise security.
For example, a hacker might use a promiscuous mode device to capture network traffic for unscrupulous
activities. Or someone might impersonate a node and gain unauthorized access by spoofing its MAC address.
Set Promiscuous mode to Accept to use an application in a virtual machine that analyzes or sniffs packets, such
as a network-based intrusion detection system.
Set MAC address changes and Forged transmits to reject to help protect against certain attacks launched by a
rogue guest operating system.
Leave MAC address changes and Forged transmits at their default values (Accept) if your applications change
the mapped MAC address, as do some operating system-based firewall.
Traffic-Shaping Policy

A virtual machine's network bandwidth can be controlled by enabling the network traffic shaper. The network
traffic shaper, when used on a standard switch, shapes only outbound network traffic. To control inbound
traffic, use a load-balancing system, or turn on rate-limiting features on your physical router.
Configuring Traffic Shaping
The ESXi host shapes only outbound traffic by establishing parameters for the following traffic characteristics:
 Average bandwidth (Kbps): Establishes the number of kilobits per second to allow across a port, average
over time. The average bandwidth is the allowed average load.
 Peak Bandwidth (Kbps): The maximum number of kilobits per second to allow across a port when it is
sending a burst of traffic. this number tops the bandwidth that is used by a port whenever the port is
using its burst bonus.
 Burst size (KB): The maximum number of kilobytes to allow in a burst. if this parameter is set, a port
might gain a burst bonus if it does not use all its allocated bandwidth. Whenever the port needs more
bandwidth than specified in Average bandwidth, the port might have allowed to temporarily transmit
data at a higher speed if a burst bonus is available. This parameter tops the number of kilobytes that
have accumulated in the burst bonus and thus transfers at a higher speed.
Network traffic shaping is off by default.
To configure traffic shaping in vSphere Web Client
1. Navigate to the host.
2. On the Manage tab, Click Networking, and Select Virtual switches.
3. Navigate to the traffic shaping policy on the standard switch or port group, and configure the traffic
shaping policy by setting the average bandwidth, peak bandwidth, and burst size values.

Although you can establish a traffic-shaping policy at either the virtual switch level or the port group level,
settings at the port group level override settings at the virtual switch level.
NIC Teaming and Failover Policies
NIC teaming and Failover Policies enable you to determine how the network traffic is distributed between
adapters and how to reroute traffic in the event of an adapter failure. NIC teaming policies include load-
balancing and failover settings. Default NIC teaming and Failover policies are set for the entire standard switch.
these default settings can be overridden at the port group level. The policies show what is inherited from the
settings at the switch level.
To edit teaming and failover settings in the vSphere Web Client
1. Navigate to the host
2. On the Manage tab, Click Networking, and select Virtual Switches.
3. Select a switch from the list.
4. In the topology diagram of the switch, click the port group name.
5. Click Edit under the topology diagram title and select Teaming and failover.
6. Configure settings in this section.

Load-Balancing Method: Originating Virtual Port ID
With this method, a virtual machine's outbound traffic is mapped to a specific physical NIC. the NIC is
determined by the ID of the Virtual port to which this virtual machine is connected. This method is simple and
fast and does not require the VMkernel to examine the frame foe necessary information.
When the load is distributed in the NIC team using the Port-based method, no single-NIC virtual machine gets
more bandwidth than can be provided by a single physical adapter.
Load-Balancing Method: Source MAC Hash

In this Load-balancing method, each virtual machine's outbound traffic is mapped to a specific physical NIC that
is based on the virtual NIC's MAC address.
This method has low overhead and is compatible with all switches, but it might not spread traffic evenly across
all the physical NIC's.
When the load is distributed in the NIC team using the MAC-based method, no single-NIC virtual machine gets
more bandwidth than can be provided by a single physical adapter.
You can also balance your traffic based on the current traffic loads of the physical NIC's. The NIC with less load is
more likely to be chosen.
Load-Balancing Method: Source and Destination IP Hash
In This Load-balancing method, a NIC for each outbound packet is selected based on its source and destination
IP addresses.
The IP-based method requires 802.3ad link aggregation support or Etherchannel on the switch. the Link
Aggregation Control protocol is a method to control the bundling of several physical ports to form a single
logical channel. LACP is part of the IEEE 802.3ad specification.
Etherchannel is a port trunking technology that is used primarily on Cisco switches. This technology enables
grouping several physical Ethernet links to create one logical Ethernet link for providing fault tolerance and high-
speed links between switches, routers, and servers.
When the load is distributed in the NIC team using the IP-based method, a single NIC virtual machine might use
the Bandwidth of multiple physical adapters.

The IP-based load-balancing method only affects outbound traffic. for example, a virtual machine might choose
a particular NIC to communicate with a particular destination virtual machine. The return traffic might not arrive
on the same NIC as the outbound traffic. the return traffic might arrive on another NIC in the same NIC team.
Detecting and Handling Network Failure
Monitoring the link status provided by the network adapter detects failures like cable pulls and physical switch
power failures. this monitoring does not detect configuration errors, such as a physical switch port being
blocked by the spanning tree protocol or misconfigures VLAN membership. This method cannot detect
upstream, no directly connected physical switch or cable failures.
Beaconing introduces a load of a 62-byte packet approximately every 1 second per physical NIC. When
beaconing is activated, the VMkernel sends out and listens for probe packets on all NICs in the team. This
technique can detect failure that link-status monitoring alone cannot. consult your switch manufacturer to
confirm the support of beaconing in your environment.
A physical switch can be notified by the VMkernel Whenever a virtual NIC is connected to a virtual switch. A
physical switch can also be notified whenever a failover event causes a virtual NIC's traffic to be routed over a
different physical NIC. the notification is sent out over the network to update the lookup tables on physical
switches. in most cases, this notification process is desirable because otherwise virtual machines would
experience greater latency after failovers and vSphere vMotion operation. But do not set this option when the
virtual machines connected to the portgroup are running unicast-mode Microsoft Network Load Balancing
(NLB). NLB in multicast mode is unaffected.
When using explicit failover order, always use the highest order uplink from the list of active adapters that pass
failover-detection criteria.

The Failback option determines how a physical adapter is returned to active duty after recovering from a failure.
If Failback is set to Yes, the failed adapter is returned to active duty immediately upon recovery, displacing the
standby adapter that took its place at the time of failure.
If Failback is set to No, a failed adapter is left inactive even after recovery, until another currently active adapter
fails, requiring its replacement.

Introduction to vSphere Distributed Switches
Benefits of vSphere Distributed Switches
Standard switch and distributed switch features comparison
VMware vCenter Server owns the configuration of the distributed switch. the configuration is consistent across
all hosts that use the distributed switch.

Distributed switch architecture
A distributed switch components move network management to the data center level.
A distributed switch is managed entirely configured in vCenter server. the distributed switch abstracts a set of
standard switches that are configured on each associated host. vCenter Server manages the configuration of
distributed switches and all configuration is consistent across all hosts. Consider a distributed switch as template
for the network configuration on each ESXi host.
Each distributed switch includes distributed ports. you can connect any networking entity, such as a virtual
machine or a VMkernel interface, to a distributed port.
vCenter server stores the state of distributed ports in the vCenter server database. Networking statistics and
policies migrate with virtual machines when the virtual machines are moved from host to host.
A distributed port group enables you to logically group distributed ports to simplify configuration. A distributed
port group specifies port configuration options for each member port on distributed switch. Distributed port
groups define how a connection is made through a distributed switch to a network. ports can also exist without
port group.
An uplick is an abstraction to associate vmnics on multiple hosts to a single distributed switch. an uplink in a
distributed switch performs a similar function as that of vmnic standard switch. Two Virtual machines on
different hosts can communicate with each other only if both virtual machines have uplinks in the same
broadcast domain.
The distributed switch architecture consists of two planes: the control plane and the I/O plane.
the control plane resides in vCenter server. the control plane is responsible for configuring distributed switches,
distributed port groups, distributed ports, uplinks, NIC teaming, and so on. the control plane also coordinates

the migration of the ports and is responsible for the switch configuration. For Example, if a conflict arises in the
assignment of a distributed port, the control plane acts as the deciding authority to resolve the conflict.
The I/O plane is implemented as hidden virtual switch in the VMkernel of each ESXi host. The I/O plane manages
the I/O hardware on the host and is responsible for forwarding packets.
Distributed Switch Example
Viewing Distributed Switch

Consider the following points when you configure distributed switch settings:
 Uplink ports connect the distributed switch to physical NICs on associated hosts. The number of uplink
ports is the maximum number of allowed physical connections to the distributed switch per host.
 By using VMware vSphere Network I/O Control, you can prioritize the access to network resources for
certain types of infrastructure and workload traffic according to the requirements of your department.
Network I/O Control continuously monitors the I/O load over the network and dynamically allocates
available resources.
 After you add the distributed switch, if your system has custom port group requirements, create
distributed port groups that meet those requirements.
Creating a Distributed Switch
Editing General and Advanced Distributed Switch Properties
vSphere Distributed Switch supports basic and snooping models for filtering of multicast packets that are related
to individual multicast groups. Choose a model according to the number of multicast groups to which the VMs
on the switch subscribe.

The distributed switch supports the default basic mode for filtering multicast traffic. The distributed switch also
supports multicast snooping that forwards multicast traffic in a more precise way based on the Internet Group
Management Protocol (IGMP) and Multicast Listener Discovery (MLD) messages from VMs.
Basic Multicast Filtering
In basic multicast filtering mode, a VM sends out IGMP join requests through the network, indicating the VM’s
intention of joining a particular multicast group. A standard switch or a distributed switch forwards multicast
traffic for VMs according to the destination MAC address of the multicast group. The switch saves the mapping
between the port and the destination multicast MAC address in a local forwarding table.
The switch does not interpret the IGMP messages that a VM sends. The switch forwards them to the local
multicast router. The router interest the IGMP messages, and joins the VM to a multicast group, or removes it
from a multicast group.
The basic mode has the following restrictions:
 A Virtual machine might receive packets from groups that it is not subscribed for because the switch
forwards packets according to the destination MAC address of a multicast group, which can be mapped
upto 32 IP multicast groups.
 A virtual machine that is subscribed for traffic from more than 32 multicast MAC addresses receives
packets that it is not subscribed for because of a limitation in the forwarding model.
 The switch does not filter packets according to source address as defined in IGMP version 3.

Multicast Snooping
In multicast snooping mode, a distributed switch provides IGMP and MLD snooping according to RFC 4541. The
switch dispatches multicast traffic more precisely by using IP addresses. This mode supports IGMPv1, IGMPv2,
and IGMPv3 for IPv4 multicast group addresses, and MLDv1 and MLDv2 for IPv6 multicast group addresses.
The switch dynamically detects the membership of a Virtual Machine. When a Virtual Machine sends a packet
that contains IGMP or MLD membership information through a switch port, the switch snoops the packet and
creates a mapping entry. This entry records the destination IP address of the multicast group, and for IGMPv3,
the source IP address from which the VM prefers to receive multicast traffic. If a VM does not renew its
multicast group membership within a certain period of time, the switch removes the previously recorded entry
from its mapping records.
In the multicast snooping mode of a distributed switch, a virtual machine can receive multicast traffic on a single
switch port from up to 256 groups and 10 sources.
Migrating Network Adapters to a Distributed Switch
You can migrate physical NICs, VMKernel adapters and Virtual machine network adapters at the same time.
If you want to migrate Virtual Machine network adapters or VMkernel adapters, ensure that the destination
distributed port groups have at least one active uplink and that the uplink is connected to a physical NIC on this
host. Alternatively, migrate physical NICs, virtual network adapters and VMkernel adapter at once.
If you want to migrate physical NICS, ensure that the source port groups on the standard switch have at least
one physical NIC to handle their traffic. For example, if you migrate a physical NIC that is assigned to a port
group for virtual machine networking, ensure that the port group is connected to at least one physical NIC.
Otherwise, the virtual machines on the VLAN on the standard switch will have connectivity between each other
but not to the external network.

Assigning a physical NIC of a host to a distributed switch
You can assign physical NICs of a host that is associated with a distributed switch to an uplink port on the host
proxy switch.
Connecting Virtual Machines to a Distributed Switch
Connect Virtual Machines to a distributed switch either by configuring an individual Virtual Machine NIC or by
migrating groups of Virtual machines from the distributed switch.

Connect virtual machines to distributed switches by connecting their associated virtual network adapters to
distributed port groups. For an individual virtual machine, you must modify the virtual machine’s network
adapter configuration. For a group of virtual machines, you must migrate virtual machines from a virtual
network to a vSphere distributed switch.
Editing Distributed Port Group General Properties
A distributed port group specifies port configuration options for each member port on a distributed switch. You
can edit the distributed port group settings to define how a connection is made to a network.
Port binding options include static, dynamic and ephemeral.

Editing Distributed Port Group Advanced Properties
You can also enable the rest of any configuration that is set per port when a distributed port disconnects form a
Virtual machine.

About the VMkernel Networking Level
Consider the following key points about TCP/IP stacks at the VMkernel level
 Default TCP/IP stack: Provides networking support for the management traffic between vCenter Server
and Esxi hosts and for system traffic such as vSphere vMotion, IP storage and vSphere FT.
 vMotion TCP/IP stack: Supports the traffic for live migration of virtual machines. Use the vMotion TCP/IP
stack to provide better isolation for the vSphere vMotion traffic. After you create a VMkernel adapter in
the vMotion TCP/IP stack, you can use only this stack for vSphere vMotion migration of this host. The
VMkernel adapters on the default TCP/IP stack are disabled for the vSphere vMotion Service. If a live
migration uses the default TCP/IP stack while you configure VMkernel adapters with the vMotion TCP/IP
stack, the migration completes successfully. However, the involved VMkernel adapters on the TCP/IP
stack are disabled for future vSphere vMotion sessions.
 Provisioning TCP/IP stack: Supports the traffic for virtual machine cold migration, cloning, and snapshot
creation. You can use the provisioning TCP/IP stack to handle NFC traffic during long-distance vSphere
vMotion migration. VMkernel adapters configured with the provisioning TCP/IP stack handle the traffic
form cloning operations on a separate gateway. After you configure a VMkernel adapter with the
provisioning TCP/IP stack, all adapters on the default TCP/IP stack are disabled for the provisioning
traffic.
 Custom TCP/IP stacks: You can add custom TCP/IP stacks at the VMkernel level to handle networking
traffic of custom applications.

Creating a VMkernel Adapter on a Host Associated with a Distributed Switch
Consider the following important points when creating a VMkernel adapter on a host that is associated with a
distributed switch:
 You should dedicate a single distributed port group per VMkernel adapter
 For better isolation, you should configure one VMkernel adapter with one traffic type.

MAC Address Management
MAC addresses are used in the Layer 2 (Data Link Layer) of the network protocol stack to transmit frames to a
recipient. In vSphere, vCenter Server generates MAC addresses for virtual machine adapters and VMkernel adapters, or
you can assign addresses manually.
Each network adapter manufacturer is assigned a unique three-byte prefix called an Organizationally
Unique Identifier (OUI), which it can use to generate unique MAC addresses.
VMware supports several address allocation mechanisms, each of them with a separate OUI:
 Generated MAC addresses
o Assigned by vCenter Server
o Assigned by the ESXi host
 Manually set MAC addresses
 Generated for legacy virtual machines, but no longer used with ESXi
If you reconfigure the network adapter of a powered off virtual machine, for example by changing the automatic MAC
address allocation type, or setting a static MAC address, vCenter Server resolves any MAC address conflict before the
adapter reconfiguration takes effect.
MAC Address Assignment from vCenter Server
vSphere 5.1 and later provides several schemes for automatic allocation of MAC addresses in
vCenter Server. You can select the scheme that best suits your requirements for MAC address duplication,
OUI requirements for locally administered or universally administered addresses, and so on.
The following schemes of MAC address generation are available in vCenter Server:
 VMware OUI allocation, default allocation
 Prefix-based allocation
 Range-based allocation
After the MAC address is generated, it does not change unless the virtual machine's MAC address conflicts with that of
another registered virtual machine. The MAC address is saved in the configuration file of the virtual machine.
Preventing MAC Address Conflicts
The MAC address of a powered off virtual machine is not checked against the addresses of running or suspended
virtual machines.
When a virtual machine is powered on again, it might acquire a different MAC address. The change might
be caused by an address conflict with another virtual machine. While this virtual machine has been powered
off, its MAC address has been assigned to another virtual machine that has been powered on.

If you reconfigure the network adapter of a powered off virtual machine, for example, by changing the automatic MAC
address allocation type or setting a static MAC address, vCenter Server resolves MAC address conflicts before the
adapter reconfiguration takes effect.
VMware OUI Allocation
VMware Organizationally Unique Identifier (OUI) allocation assigns MAC addresses based on the default
VMware OUI 00:50:56 and the vCenter Server ID.
VMware OUI allocation is the default MAC address assignment model for virtual machines. The allocation works with
up to 64 vCenter Server instances, and each vCenter Server can assign up to 64000 unique MAC addresses. The
VMware OUI allocation scheme is suitable for small scale deployments.
MAC Address Format
According to the VMware OUI allocation scheme, a MAC address has the format 00:50:56:XX:YY:ZZ where
00:50:56 represents the VMware OUI, XX is calculated as (80 + vCenter Server ID), and YY and ZZ are
random two-digit hexadecimal numbers.
The addresses created through the VMware OUI allocation are in the range 00:50:56:80:YY:ZZ -
00:50:56:BF:YY:ZZ.
Prefix-Based MAC Address Allocation
On ESXi hosts 5.1 and later, you can use prefix-based allocation to specify an OUI other than the default one
00:50:56 by VMware, or to introduce Locally Administered MAC Addresses (LAA) for a larger address
space.
Prefix-based MAC address allocation overcomes the limits of the default VMware allocation to provide unique
addresses in larger scale deployments. Introducing an LAA prefix leads to a very large MAC address space (2 to the
power of 46) instead of an universally unique address OUI which can give only 16 million MAC addresses.
Verify that the prefixes that you provide for different vCenter Server instances in the same network are unique.
vCenter Server relies on the prefixes to avoid MAC address duplication issues.
Range-Based MAC Address Allocation
On ESXi hosts 5.1 and later you can use range-based allocation to include or exclude ranges of Locally
Administered Addresses (LAA).
You specify one or more ranges using a starting and ending MAC addresses, for example, (02:50:68:00:00:02,
02:50:68:00:00:FF). MAC addresses are generated only from within the specified range.

You can specify multiple ranges of LAA, and vCenter Server tracks the number of used addresses for each range.
vCenter Server allocates MAC addresses from the first range that still has addresses available. vCenter Server checks for
MAC address conflicts within its ranges.
When using range-based allocation, you must provide different instances of vCenter Server with ranges that do not
overlap. vCenter Server does not detect ranges that might be in conflict with other vCenter Server instances. See the
vSphere Troubleshooting documentation for more information about resolving issues with duplicate MAC addresses.
Assigning a MAC Address
Use the vSphere Web Client to enable prefix-based or range-based MAC address allocation and to adjust the allocation
parameters.
If you are changing from one type of allocation to another, for example changing from the VMware OUI allocation to a
range-based allocation, use the vSphere Web Client. However, when a schema is prefix-based or range-based and you
want to change to a different allocation schema, you must edit the vpxd.cfd file manually and restart vCenter Server.
Change to or Adjust Range- or Prefixed-Based Allocations in the vSphere Web Client
By switching from the default VMware OUI to range- or prefixed-based MAC address allocation through the vSphere
Web Client, you can avoid and resolve MAC address duplication conflicts in vSphere deployments.
Change the allocation scheme from the default VMware OUI to range- or to prefixed-based allocation by using the
Advanced Settings available for the vCenter Server instance in the vSphere Web Client.
To switch from range- or prefixed-based allocation back to VMware OUI allocation, or between range- and prefixed-
based allocation, edit the vpxd.cfg file manually.
Set or Change Allocation Type
If you are changing from range- or prefixed-based allocation to the VMware OUI allocation, you must set the allocation
type in the vpxd.cfd file and restart the vCenter Server.
Procedure
1 On the host machine of vCenter Server, navigate to the directory that contains the configuration file:
 On a Windows Server operating system, the location of the directory is vCenter Server home
directoryApplication DataVMwareVMware VirtualCenter.
 On the vCenter Server Appliance, the location of the directory is /etc/vmware-vpx.
2 Open the vpxd.cfg file
3 Decide on an allocation type to use and enter the corresponding XML code in the file to configure the
allocation type.

The following are examples of XML code to use.
 VMware OUI allocation
<vpxd>
<macAllocScheme>
<VMwareOUI>true</VMwareOUI>
</macAllocScheme>
</vpxd>
 Prefix-based allocation
<vpxd>
<macAllocScheme>
<prefixScheme>
<prefix>005026</prefix>
<prefixLength>23</prefixLength>
</prefixScheme>
</macAllocScheme>
</vpxd>
 Range-based allocation
<vpxd>
<macAllocScheme>
<rangeScheme>
<range id="0">
<begin>005067000001</begin>
<end>005067000001</end>
</range>
</rangeScheme>
</macAllocScheme>
</vpxd>
4 Save the vpxd.cfg.
5 Restart the vCenter Server host.
MAC Address Generation on ESXi Hosts
An ESXi host generates the MAC address for a virtual machine adapter when the host is not connected to
vCenter Server. Such addresses have a separate VMware OUI to avoid conflicts.
The ESXi host generates the MAC address for a virtual machine adapter in one of the following cases:
 The host is not connected to vCenter Server.
 The virtual machine configuration file does not contain the MAC address and information about the
MAC address allocation type.

MAC Address Format
The host generates MAC addresses that consists of the VMware OUI 00:0C:29 and the last three octets in hexadecimal
format of the virtual machine UUID. The virtual machine UUID is based on a hash calculated by using the UUID of the
ESXi physical machine and the path to the configuration file (.vmx) of the virtual machine.
Preventing MAC Address Conflicts
All MAC addresses that have been assigned to network adapters of running and suspended virtual machines on a given
physical machine are tracked for conflicts.
If you import a virtual machine with a host-generated MAC address from one vCenter Server to another, select the I
Copied It option when you power on the virtual machine to regenerate the address and avoid potential conflicts in the
target vCenter Server or between the vCenter Server systems.
Setting a Static MAC Address to a Virtual Machine
In most network deployments, generated MAC addresses are a good approach. However, you might need to set a static
MAC address for a virtual machine adapter with unique value.
The following cases show when you might set a static MAC address:
1 Virtual machine adapters on different physical hosts share the same subnet and are assigned the same
MAC address, causing a conflict.
2 Ensure that a virtual machine adapter always has the same MAC address.
By default, VMware uses the Organizationally Unique Identifier (OUI) 00:50:56 for manually generated addresses, but
all unique manually generated addresses are supported.
Assign a Static MAC Address with the vSphere Web Client
You can assign static MAC addresses to the virtual NIC of a powered off virtual machine by using the vSphere Web
Client.
Procedure
1 Locate the virtual machine in the vSphere Web Client.
a. Select a datacenter, folder, cluster, resource pool, or host and click the Related Objects tab.
b. Click Virtual Machines and select the virtual machine from the list.
2 Power off the virtual machine.
3 On the Manage tab of the virtual machine, select Settings > VM Hardware.
4 Click Edit and select the Virtual Hardware tab.
5 In the Virtual Hardware tab, expand the network adapter section.
6 Under MAC Address, select Manual from the drop-down menu.
7 Type the static MAC address, and click OK.
8 Power on the virtual machine.

Assign a Static MAC Address in the Virtual Machine Configuration File
To set a static MAC address for a virtual machine, you can edit the configuration file of the virtual machine by using the
vSphere Web Client.
Procedure
1 Locate the virtual machine in the vSphere Web Client.
a. Select a datacenter, folder, cluster, resource pool, or host and click the Related Objects tab.
b. Click Virtual Machines and select the virtual machine from the list.
2 Power off the virtual machine.
3 On the Manage tab of the virtual machine, select Settings.
4 On the VM Options tab, expand Advanced.
5 Click Edit Configuration.
6 To assign a static MAC address, add or edit parameters as required.
ethernetX.addressType static
ethernetX.address MAC_address_of_the_virtual_NIC
X next to ethernet stands for the sequence number of the virtual NIC in the virtual machine.
For example, 0 in ethernet0 represents the settings of the first virtual NIC device added to the virtual
machine.
7 Click OK.
8 Power on the virtual machine.

Choosing a network adapter for your virtual machine
Network adapter choices depend on the version number and the guest operating system running on the virtual
machine.
Vlance: This is an emulated version of the AMD 79C970 PCnet32- LANCE NIC, and it is an older 10 Mbps NIC with drivers
available in most 32-bit guest operating systems except Windows Vista and later. A virtual machine configured with this
network adapter can use its network immediately.
VMXNET: The VMXNET virtual network adapter has no physical counterpart. VMXNET is optimized for performance in a
virtual machine. Because operating system vendors do not provide built-in drivers for this card, you must install VMware
Tools to have a driver for the VMXNET network adapter available.
Flexible: The Flexible network adapter identifies itself as a Vlance adapter when a virtual machine boots, but initializes itself
and functions as either a Vlance or a VMXNET adapter, depending on which driver initializes it. With VMware Tools
installed, the VMXNET driver changes the Vlance adapter to the higher performance VMXNET adapter.
E1000: An emulated version of the Intel 82545EM Gigabit Ethernet NIC. A driver for this NIC is not included with all guest
operating systems. Typically Linux versions 2.4.19 and later, Windows XP Professional x64 Edition and later, and Windows
Server 2003 (32-bit) and later include the E1000 driver.
Note: E1000 does not support jumbo frames prior to ESXi/ESX 4.1.
E1000e: This feature emulates a newer model of Intel Gigabit NIC (number 82574) in the virtual hardware. This is known as
the "e1000e" vNIC. e1000e is available only on hardware version 8 (and newer) virtual machines in vSphere 5. It is the
default vNIC for Windows 8 and newer (Windows) guest operating systems. For Linux guests, e1000e is not available from
the UI (e1000, flexible vmxnet, enhanced vmxnet, and vmxnet3 are available for Linux).
VMXNET 2 (Enhanced): The VMXNET 2 adapter is based on the VMXNET adapter but provides some high-performance
features commonly used on modern networks, such as jumbo frames and hardware offloads. This virtual network adapter is
available only for some guest operating systems on ESXi/ESX 3.5 and later. Because operating system vendors do not
provide built-in drivers for this card, you must install VMware Tools to have a driver for the VMXNET 2 network adapter
available.
VMXNET 3: The VMXNET 3 adapter is the next generation of a para-virtualized NIC designed for performance, and is not
related to VMXNET or VMXNET 2. It offers all the features available in VMXNET 2, and adds several new features like
multiqueue support (also known as Receive Side Scaling in Windows), IPv6 offloads, and MSI/MSI-X interrupt delivery.
Because OS vendors do not provide built-in drivers for this card, you must install VMware Tools or open-vm-tools to have a
driver for the VMXNET 3 network adapter available.
Note: VMXNET 3 is supported only for virtual machines version 7 and later, with a limited set of guest operating systems.

vSphere CLI Commands to Troubleshoot ESXi Network Configurations
To troubleshoot networking configurations from the ESXi command line, ESXCLI is the tool to use or PUTTY can be
used.
There are a number of options available when running ‘esxcli’ in terms of network settings:
~ esxcli network
We’ll go through some of the options that these namespaces offer.
Listing vSwitch Configuration
You can list the vSwitches configured on a ESXi host by running:
~ esxcli network vswitch standard list
To list distributed vSwitches instead, swap ‘standard’ for ‘dvs’ in the command. Following on from the output above you
can also dig down to look at the Policy, Portgroup settings for the vSwitch:
~ esxcli network vswitch standard

For example, to display the failover settings for vSwitch0, the following command can be run:
~ esxcli network vswitch standard policy failover get -v vSwitch0
Listing VMKernel Interfaces
To list the VMkernel ports on a host you can run:
~ esxcli network ip interface list
The command will display the interface name, MAC address, and which vSwitch and Portgroup it belongs to. To list the IP
address configuration for the VMkernel ports:
~ esxcli network ip interface ipv4 get

Listing Connections and Neighbors
To list established connections on your host you can run:
~ esxcli network ip connection list
This is the equivalent of running ‘netstat’ on a Windows machine. To list the host’s ARP cache (or neighbors table) you can
run:
~ esxcli network ip neighbor list
This can be useful when troubleshooting connectivity, for example, when a host is failing to connect to another over the
vMotion network.
You can list the host’s routing table by running:
~ esxcli network ip route ipv4 list

Troubleshooting Network Connectivity Using Netcat
Netcat can be used to test connectivity to and from your ESXi host.
You can view the options available by running:
~ nc -h
The basic syntax is:
~ nc -z <DestinationIP> <Destination Port>
For example, to test connectivity on to port 80 you could run:
~ nc -z 192.168.1.15 80
You can also use netcat to test a range of ports on a remote host:
~ nc -w 1 -z 192.168.1.15 80-85
Netcat will report back with the ports it has found to be open within the specified range.

Troubleshooting network connectivity with ping and vmkping
You can test connectivity to remote ESXi host using the ping and vmkping utilities. Using vmkping to test connectivity via
vMotion interfaces is a common practice. For example:
~ vmkping 192.168.1.20
If you use vmkping with the ‘-D’ switch, you can test the host’s IP stack as the command will automatically test configured
IP addresses:
~ vmkping -D

Troubleshooting SSL port connectivity with openssl
You can use the open ssl client present on an ESXi host to test connectivity to an ssl port – for example to vCenter or to
another host. To do so:
~ openssl s_client -connect 192.168.1.100:443
The output will also contain details about the certificate, which can be useful when troubleshooting certificate problems.

Capturing Traffic with tcpdump-uw
To display packets on interface vmk0 you can run:
~ tcpdump-uw -i vmk0 | more
To output the traffic capture to a file you can run:
~ tcpdump-uw -i vmk0 -s 1514 -w /vmfs/volumes/datastore1/traffic.pcap
You can then open the resulting .pcap file in a tool such as Wireshark, for analysis:

Viewing Physical NIC Configuration
You can list the physical NICs installed in the host by using:
~ esxcli network nic list
Using the ‘esxcli network nic’ namespace you can also bring interfaces up and down (which is useful for testing), and you
can view interface statistics.
~ esxcli network nic <cmd> <cmd options>
An example of how to display interface statistics is shown here:
~ esxcli network nic stats get -n vmnic0

Configuring the speed and duplex of an ESXi or ESX host network adapter
ESXi/ESX recommended settings for Gigabit-Ethernet speed and duplex while connecting to a physical switch port:
 Auto Negotiate <-> Auto Negotiate (For 1 Gbps)
 Auto Negotiate <-> Auto Negotiate (For 10 Gbps, supported only by ESXi/ESX 3.5 Update 1 and above)
Note: Many drivers do not support forced 1000Mbps or 10000Mbps speeds, and require the auto-negotiation set for this to work correctly. Auto-
negotiation is considered as the normal and official way that both Gigabit and 10-Gigabit networking is designed to function. For more information, see the
IEEE 802.3ab, 802.3an, and 802.3ae standards. Many drivers do not allow forced 1000Mbps or 10000Mbps because it is not officially supported by the IEEE
standards.
When working with 10 GB Fiber Channel over Ethernet (FCoE) configurations, Auto Negotiatemay or may not be supported
or recommended. For more information, consult your networking equipment vendor or administrator.
 1000 MB / Full Duplex <-> 1000 MB / Full Duplex
 VMware does not recommend mixing a hard-coded setting with Auto-negotiate
 Fast Ethernet – 100 MB /Full Duplex <-> 100 MB /Full Duplex
Duplex Mismatch
 A common issue with speed/duplex is when the duplex settings are mismatched between two switches, between a
switch and a router or between the switch and a workstation or server.
 This can occur when manually hard coding the speed and duplex or from auto negotiation issues between the two
devices.
The advantages of utilizing auto negotiation on Gigabit-Ethernet Interfaces:
 Auto negotiation is highly recommended on ESXi/ESX Gigabit-Ethernet Interface cards and physical Gigabit switch
ports for these reasons:
o Although hard coding the speed and duplex will work and is in the documentation, in some cases there
are performance issues after an ESXi/ESX upgrade 3.5 – setting the configuration to Auto Negotiate seems
to resolve performance issues.
o It resolves issues with iSCSI, vMotion, network performance, and related network issues.
Duplex settings: While Cisco devices only support full duplex, the IEEE 802.3z standard does have support
for half duplex Gigabit-Ethernet. Because of this, duplex is negotiated between Gigabit-Ethernet devices.
o Flow Control: Because of the amount of traffic that can be generated by Gigabit-Ethernet, there is a
PAUSE functionality built into Gigabit-Ethernet.

Note: The PAUSE frame is a packet that tells the far-end device to stop the transmission of packets until the receiver is able to handle
all the traffic and clear its buffers. The PAUSE frame has a timer included, which tells the far-end device when to start to send packets
again. If that timer expires without getting another PAUSE frame, the far-end device can then send packets again. Flow Control is an
optional item and must be negotiated. Devices can be capable of sending or responding to a PAUSE frame, and it is possible they will
not agree to the flow-control request of the far-end.
 Fast Ethernet – 100 / Full <–> 100 / Full: VMware recommends forcing the network adapter on the ESX server host
and the physical switch port to which it connects to 100 / Full when using 100 MB links with an ESX server host.
Configuring the speed and duplex of the ESXi/ESX server network adapter using the vSphere Client
1. Log in to the ESXi/ESX host using the vSphere Client as the root user or a user with equivalent permissions.
2. Highlight the ESXi/ESX server host and click the Configuration tab.
3. Click the Networking link.
4. Click Properties next to the appropriate virtual switch.
5. Click the Network Adapters tab.
6. Highlight the desired network adapter, and click Edit.
7. Select appropriate speed and duplex from the dropdown.
About the esxcfg-nics command, which is used to configure Network Interface Cards
~ esxcfg-nics <options> [nic]
The esxcfg-nics command provides information about the physical NICs in use by the VMkernel.
This prints the VMkernel name for the NIC, its PCI ID, driver, link state, speed, duplex, and a short PCI description of the
card. It also allows users to set speed and duplex settings for a specific NIC.

The below Esxi has 2 nics with 1GBps speed.
We are forcing the vmnic0 to use fast Ethernet at half duplex speed
~ esxcfg-nics -s 100 -d half vmnic0
The changes will get reflected in the GUI.

Verifying the integrity of the physical network adapter on an ESX/ESXi host
If the Esxi doesn’t recognize the NIC card, As part of troubleshooting networking issues related to the physical network
adapter, it is necessary to attempt to rule out a hardware problem. The following steps assume that the network adapter is
not seen within the vSphere Client.
To rule out if the issue is caused by a hardware problem:
~ lspci -p
In this example, there are two physical Broadcom NICs and two Intel NIC recognized by the host. Under the Module column,
it shows the name of the driver that has been loaded for each card. Under the Name column, it specifies the vmnic that has
been assigned to each card. If there is no driver or vmnic designation associated with a network adapter, the host detects
the card in the slot, but does not recognize the brand/model.
If the lines do not exist at all for the card that has been added to the server, then steps need to be taken to rule out faulty
hardware.
To rule out faulty hardware:
 If it is an add-in network adapter, reseat it or move it to an alternate PCI slot on the server’s motherboard.
 Try an alternate network card.
 Update the BIOS of the server to the latest version recommended by the manufacturer.
 Run hardware diagnostics to identify any potential hardware issues.

Packet Tracing
The basic command to view the data flow is the esxtop
~ esxtop
The pktcap-uw tool is an enhanced packet capture and analysis tool that can be used in place of the legacy tcpdump-uw
tool. The pktcap-uw tool is included by default in ESXi 5.5.
Get help and Syntax information:
~ pktcap-uw -h |more

To View the live Capture of VMKernel Interface Traffic
~ pktcap-uw –vmk vmk0

To capture the output to a file, use -o option:
~ pktcap-uw --vmk vmk0 -o /tmp/vmk0capture.pcap
You can limit the data being captured using the ‘-c’ option, which allows you to specify the number of packets you wish to
capture
~ pktcap-uw --vmk vmk0 -c 1

Capture Traffic of a specific physical network card(vmnic) on ESXi Host:
~ pktcap-uw --uplink vmnic0
Capture traffic from a virtual switchport on a dvSwitch:
~ pktcap-uw --switchport <Switch-Portnumber>
Ex, pktcap-uw --switchport 33554433
To get the Switch port ID
~ esxtop -> Press n -> PORT-ID
To Capture packets for multiple points simultaneously, Capture Packets of both Switch port and physical adapter at same
time using the below command:
~ pktcap-uw --switchport 33554433 -o /tmp/33554433.pcap & pktcap-uw --uplink vmnic0 -o /tmp/vmnic0.pcap &

Stop pktcap-uw tracing with the kill command:
~ kill $(lsof |grep pktcap-uw |awk ‘{print $1}’| sort -u)
To check that all pktcap-uw traces are stopped:
~ lsof |grep pktcap-uw |awk ‘{print $1}’| sort -u
Captured packets can be viewed in Sniffer tools such as Wireshark.
First, transfer the packets using WinSCP.

Troubleshoot ESXi Host DNS and Routing Related Issues
It is important that name resolution is configured correctly on your ESXi hosts, as it is important for many vSphere
features. Your hosts and vCenter servers should be able to do lookups against their configured DNS servers, and there
should be both forward and reverse DNS records created for vCenter and each of the hosts. Using the vSphere client, the
DNS settings can be found under the host’s Configuration tab, in the DNS and Routing section:
You can also list the configured DNS servers using the CLI. Do to so, use the ‘esxcli network ip dns’ namespace. For example:
~ esxcli network ip dns server list
You can also add and remove name servers using commands under this namespace. To list, and modify, the host’s search
domains, you can use:
~ esxcli network ip dns search list
Of course, having these parameters set correctly will only be of use if you can communicate with the configured DNS
servers.

You can use Netcat to test connectivity:
~ nc -z 192.168.1.15 53
And you can use NSLOOKUP to confirm that you can perform queries against the DNS server:
~ nslookup <FQDN>
As an alternative to esxcli, you can also use the vicfg-dns command from the vMA or vSphere CLI. Running the command
without any parameters will display a host’s DNS configuration:
vi-admin@vma:~> vifptarget --set 192.168.88.134
vi-admin@vma:~[192.168.88.134]> vicfg-dns
DNS Configuration
Host Name esxi1
Domain Name vmlab.local
DHCP false
DNS Servers 10.0.0.1
You can use vicfg-dns to change a hosts DNS configuration. Running ‘vicfg-dns –help’ will display the available options. As an
example here, to change the DNS server(s) that a host will use you can run:
vi-admin@vma:~[192.168.88.134]> vicfg-dns -D 10.0.0.10,10.0.0.11
Updated Host DNS network configuration successfully.

Checking the configuration again, there are now two DNS servers configured:
vi-admin@vma:~[192.168.88.134]> vicfg-dns
DNS Configuration
Host Name esxi1
Domain Name vmlab.local
DHCP false
DNS Servers 10.0.0.10
10.0.0.11
Troubleshooting ESXi Routing Configuration
There are a number of ways to display and configure a host’s routing configuration. As I ended the last section talking about
vicfg-dns, I’ll start this one by looking at vicfg-route.
To display the host’s routing table, use:
vi-admin@vma:~[192.168.88.134]> vicfg-route -l
VMkernel Routes:
Network Netmask Gateway Interface
default 0.0.0.0 10.0.0.1 vmk3
10.0.0.0 255.255.255.0 Local Subnet vmk3
10.10.20.0 255.255.255.0 Local Subnet vmk1
192.168.88.0 255.255.255.0 Local Subnet vmk0
The vicfg-route command can be used to add and remove static routes. To set the default vmkernel gateway:
vi-admin@vma:~[192.168.88.134]> vicfg-route 10.0.0.2
vi-admin@vma:~[192.168.88.134]> vicfg-route -l
VMkernel Routes:
Network Netmask Gateway Interface
default 0.0.0.0 10.0.0.2 vmk3
10.0.0.0 255.255.255.0 Local Subnet vmk3
10.10.20.0 255.255.255.0 Local Subnet vmk1
192.168.88.0 255.255.255.0 Local Subnet vmk0

Troubleshoot VMKernel Related Network Configuration Issues
VMkernel interfaces are used for a number of functions, such as management traffic, vMotion, Fault Tolerance
logging, iSCSI and NFS. VMkernel interfaces are given the name ‘vmkx’, where X is the number (in order that it was created
on the host). You can see VMkernel interfaces clearly when looking at a host’s networking configuration:
Looking at the properties of the VMkernel portgroup you can see what type of traffic the vmk interface is being used for:
Testing the Management Network using the DCUI
You can test management network connectivity using the ‘Test Management Network’ option available in the DCUI.
This can be useful to test management connectivity following installing ESXi. Common issues that may cause these tests to
fail include setting an incorrect VLAN for the management network (or not setting one at all), specifying incorrect DNS or
default gateway IPs, and selecting the wrong physical adapter to be used for management traffic.

Troubleshooting VMkernel Issues using the CLI
There are a number of CLI commands available to help you in troubleshooting VMKernel issues. To list the VMKernel ports
on a ESXi host you can run:
~ esxcli network ip interface list
If you wanted to add a new VMKernel port you can do so using the following:
~ esxcli network ip interface add --interface-name=vmk6 –portgroup-name=”FT”
You can then assign it an IP address using:
~ esxcli network ip interface ipv4 set --ipv4=10.20.10.1 --netmask=255.255.255.0 --type=static --interface-
name=vmk6
To remove a VMK interface, you can use:
~ esxcli network ip interface remove --interface-name=vmk6
Testing VMKernel Interface Connectivity
For example, to test connectivity to another hosts management IP I could run:
~ esxcli network diag -H 192.168.1.10

Troubleshooting ESXi VLAN Configurations using Command Line Tools
There are a few ways to troubleshoot network/VLAN configuration from a command line, using tools such as
ESXCLI and vicfg/esxcfg either locally on the ESXi host or remotely using vCLI or the vMA. Here, I’ll aim to give examples
using esxcfg commands ran from a vMA, and ESXCLI commands executed locally on the ESXi host.
Listing Port Group Settings:
~ esxcli network vswitch standard portgroup list
Configuring VLAN Tags:
~ esxcli network vswitch standard portgroup set -p VMNetwork --vlan-id 10
Adding and Removing Port Groups:
~ esxcli network vswitch standard portgroup add -p testpg -v vSwitch0
~ esxcli network vswitch standard portgroup set -p testpg --vlan-id 7

If you check in GUI:
To delete a port group:
~ esxcli network vswitch standard portgroup remove -p testpg -v vSwitch0

Ghosted Adapters
After a P2V, some VMs may not get the Network connectivity because of the NIC driver mismatch. These network
adapters are called as Ghosted Adapters which needs to be removed from the VM. To do so,
On your VM go to Start > RUN > CMD > Enter > Type “
> set devmgr_show_nonpresent_devices=1
While still in the command prompt window type:
devmgmt.msc
and then open Device Manager and click on the Menu go to View > Show Hidden Devices(like on the pic).
Then you should see which devices are marked like ghosted devices. They are grayed out. Those devices you can safely
remove from the device manager.

LUN Masking
Alright – here we go – the push is on. 8 weeks to cover some random, sparingly used topics
off of the VCAP5-DCA blueprint. Today, let's tackle an item out of the very first objective on the
blueprint; LUN masking.
LUN masking is essentially a process that will mask away LUNs, or make those LUNs inaccessible
to certain ESXi hosts. You know when you go into your backend array and say which hosts can
have access to which LUNs – yeah, that's basically LUN masking. However, for the sake of this
exam, it's performed on the host itself through something called claimrules. That said, it's much
harder, but explained below…
So first off, we need to decide on a LUN that we want to mask. There are many ways to list all of
your LUNs/Datastores through the CLI and through the vSphere Client, so pick your beast. What
we need to get is the LUNs identifier – the long string of characters that ESXi uses to uniquely
identify the LUN. Since the claimrule is create within the CLI we might as well just find these
numbers inside of the CLI as well – since you may be pressed for time on the exam. So, let's first
list our LUNs, showing each identifier.
esxcli storage core device list | less
As you can see I piped the output to less. If we don't do this and there are a lot of LUNs attached to
your host then you may get a little overwhelmed with the output. "esxcfg-scsidevs -m" will also give
you some great information here, which may be a little more compact than the esxcli command.
Chose your weapon, so long as you can get the identifier. The LUN shown in the above image has
an identifier of "naa.6006048c6fc141bb051adb5eaa0c60a9" – this is the one I'm targeting.
So now we have our identifier it's time to do some masking. We have some decisions at this point
to make though. We can mask by path (removing individual path visibility), by vendor (this will mask
all LUNs to a specific vendor), or by storage transport (yeah, like all iSCSI or all FC). If we look at
the currently defined claimrules we can see most types are utilized. To do so, use the following
command
esxcli storage core claimrule list

For our sake here we will go ahead an perform our masking by path. I will note below though if you
were to choose vendor or transport where that would be setup.
So, in order to do it by path, we need to see all of the paths associated with our identifier. To do so,
we can use the following command along with grepping for our identifier.
esxcfg-mpath  -m | grep naa.6006048c6fc141bb051adb5eaa0c60a9
Alright, so you can see we have 2 paths. That means in order to completely mask away this LUN
we will need to do all of the following twice; once using the vmhba32:C1:T0:L0 path and once using
vmhba32:C0:T0:L0.
Now, time to begin constructing our claimrule! First off we will need an ID number. Certailny don't
use one that is already taken (remember "esxcli storage core claimrule list") or you can use the "-u"
to autoassign a number. I like to have control over this stuff so I'm picking 200. Also to note is the -
t option – this specifies the type of claimrule (remember when i said we could mask by vendor). Our
-t to do a path will be location, however this could be vendor or transport as well.** Running "esxcli
storage core claimrule add" with no arguments will output a bunch of examples ** So, in order to
mask by location we will specify -A, -C, -T, and -L parameters referencing our path and the -P states
we want to use the MASK_PATH plugin. The command should look like the one below.
esxcli storage core claimrule add -r 200 -t location -A vmhba32 -C 1 -T 0 -L 0 -P
MASK_PATH
and for our second path – don't forget to put a new rule ID
esxcli storage core claimrule add -r 201 -t location -A vmhba32 -C 0 -T 0 -L 0 -P
MASK_PATH
Running "esxcli storage core claimrule list" will now show our newly created rules, however they
haven't been applied yet. Basically they are running in "file" – we need them to be in "runtime" This
is as as easy as running
esxcli storage core claimrule load

Now we are all set to go – kinda. They are in runtime, but the rules will not be applied until that
device is reclaimed. So, a reboot would work here – or, a more ideal solution, we can run a reclaim
on our device. To do so we will need that device identifier again and the command to run is…
esxcli storage core claiming reclaim -d naa.6006048c6fc141bb051adb5eaa0c60a9
And done! And guess what – that LUN is gonzo!!! Congrats Master Masker!
HEY! Wait! I needed that LUN
Oh SNAP! This is my lab environment and I need that LUN back, well, here's how we can undo
everything we just did!
First off, let's get rid of those claimrules we just added
esxcli storage core claimrule remove -r 200
Listing them out will only show them in runtime now, they should no longer be in file. Let's get them
out runtime by loading our claimrule list again.
Now a couple of unclaim commands on our paths. This will allow them to be reclaimed by the
default plugin.
esxcli storage core claiming unclaim -t location -A vmhba32 -C 0 -T 0 -L 0
A rescan of your vmhba and voila! Your LUN should be back! Just as with Image Builder I feel like
this would be a good thing to know for the exam. Again, it's something that can easily be marked
and tracked and very specific! Happy studying!
iSCSI Port Binding
My plan is to go over all the skills in Objective 1.3 but before we get into PSA commands and what
not let's first configure iSCSI port bonding – this way we will have a datastore with multiple paths
that we can fiddle around with
First off iSCSI port binding basically takes two separate paths to an iSCSI target (the paths are
defined by vmkernel ports) and bonds them together. So, we need two vmkernel ports. They can
be on the same switch or separate switches, but the key is that you can only have one network
adapter assigned to it. Meaning the vSwitch can contain multiple nics, but you need to ensure that
the config is overridden on the vmkernel level to only have one NIC active. Let's have a look at this.
Below you will see the current setup of my vmkernel ports (IPStore1 and IPStore2).

As you can see, my configuration here is actually wrong and needs to be adjusted – remember, one
nic per vmkernel port. So, with a little click magic we can turn it into what you see below.
Basically, for IPStore1 I have overridden the default switch config on the vmkernel port, setting
vmnic0 as active and vmnic1 as unused. For IPStore2 we will do the same except the opposite
(hehe, nice, that makes no sense) – basically, override but this time set vmnic1 as active and
vmnic0 as unused. This way we are left with two vmkernel ports, each utilizing a different NIC.

Now that we have the requirements setup and configured we can go ahead and get started on
bonding the vmkernel ports together. This is not a hard thing to do! What we are going to want to
do is right-click on our software iSCSI initiator and select 'Properties'. From there we can browse to
the 'Network Configuration' tab and simply click 'Add'. We should now see something similar to
below.
As you can see above, our VMkernel adapters are listed. If they weren't, that would indicate that
they are not compatible to be bonded, meaning we haven't met the requirements outlined earlier.
By selecting IPStore1 and then going back in and selecting IPStore2 ( I know, you can't do it at the
same time ), then selecting OK, then performing the recommended rescan you will have completed
the task. We can now see that below inside of our 'Manage Paths' section for a datastore that has
been mounted with our iSCSI initiator we have some nifty multipath options. First, we have an
additional channel and path listed, as well, we are able to switch our PSP to thinks like Round
Robin!

Random Storage Scenarios (Section 1 – Part 1)
Scenario 1
Let's say we've been tasked with the following. We have an iSCSI datastore (iSCSI2) which
utlizes iSCSI port bonding to provide multiple paths to our array. We want to change the default PSP
for iSCSI2 from mru to fixed, and set the preferred path to travel down CO:T1:L0 – only one problem,
C0:T1:L0 doesn't seem to be available at the moment. Fix the issues with C0:T1:L0 and change the
PSP on iSCSI2 and set the preferred path.
Alright, so to start this one off let's have a look first why we can't see that second path to our
datastore. If browsing through the GUI you aren't even seeing the path at all, the first place I would
look at is claimrules (now how did I know that ) and make sure that the path isn't masked away –
remember the LUN Masking section. So ssh on into your host and run the following command.
esxcli storage core claimrule list

As you can see from my output lun masking is most certainly the cause of why we can't see the
path. Rule 5001 loads the MASK_PATH plugin on the exact path that is in question. So, do you
remember from the LUN Masking post how we get rid of it? If not, we are going to go ahead and do
it here again.
First step, we need to remove that rule. That's done using the following command.
Now that its gone we can load that current list into runtime with the following command
But we aren't done yet! Instead of waiting for the next reclaim to happen or the next reboot, let's go
ahead and unclaim that path from the MASK_PATH plugin. Again, we use esxcli to do so
And rescan that hba in question – why not just do it via command line since we are already there…
esxcfg-rescan vmhba33
And voila – flip back into your Manage Paths section of iSCSI2 and you should see both paths are
now available. Now we can move on to the next task, which is switching the PSP on iSCSI2 from
MRU to Fixed. Now we will be doing this a bit later via the command line, and if you went into the
GUI to check your path status, and since we are only doing it on one LUN we probably can get
away with simply changing this via the vSphere Client. Honestly, it's all about just selecting a
dropdown at this point – see
below.
I circled the 'Change' button on this screenshot because it's pretty easy to simply select from the
drop down and go and hit close. Nothing will happen until you actually press 'Change' so don't
forget that. Also, remember, PSP is done on a per-host basis. So if you have more than one host
and the VCAP didn't specify to do it on only one host, you will have to go and duplicate everything
you did on the other host. Oh, and setting the preferred path is as easy as right-clicking the desired
path and marking it as preferred. And, this scenario is completed!

Scenario 2
The storage team thanks you very much for doing that but requirements have changed and they now
wish for all of the iSCSI datastores, both current and any newly added datastores, to utilize the Round
Robin PSP. How real life is that, people changing their mind
No problem you might say! We can simply change the PSP on each and every iSCSI datastore –
not a big deal, there's only three of them. Well, you could do this, but the question specifically
mentions that we need to have the PSP set to Round Robin on all newly added iSCSI datastores as
well, so there's a bit of command line work we have to do. And, since we used the vSphere Client
to set the PSP in the last scenario, we'll do it via command line in this one.
First up, let's switch over our existing iSCSI datastores (iSCSI1, iSCSI2, iSCSI3). To do this we will
need their identifier which we can get from the GUI, however since we are doing the work inside the
CLI, why not utilize it to do the mappings. To have a look at identifiers and their corresponding
datastore names we can run the following
esxcfg-scsidevs -m
As you can see there are three datastores we will be targeting here. The identifier that we need will
be the first string field listed beginning with t10 and ending with :1 (although we don't need the :1).
Once you have the string identifier of the device we want to alter we can change its' PSP with the
following command.
esxcli storage nmp device set -d t10.FreeBSD_iSCSI_Disk______000c299f1aec010__________
VMW_PSP_RR
So, just do this three times, once for each datastore. Now, to handle any newly added datastores to
defaulr to round robin we need to first figure out what SATP the iSCSI datastores are utilizing, then
associate the VMW_PSP_RR PSP to it. We can use the following command to see which SATP is
associated with our devices.
esxcli storage nmp device list

As you can see, our iSCSI datastores are being claimed by the VMW_SATP_DEFAULT_AA SATP.
So, our next step would be to associate the VMW_PSP_RR PSP with this SATP – I know, crazy
acronyms! To do that we can use the following command.
esxcli storage nmp satp set -s VMW_SATP_DEFAULT_AA -P VMW_PSP_RR
This command will ensure that any newly added iSCSI datastores claimed by the default AA SATP
will get the round robin PSP.
At this point we are done this scenario but while I was doing this I realized there might be a quicker
way to to change those PSP's on our existing LUNs. If we set associate our SATP with our PSP
first then we can simply utilized the following command on each of our datastores to force them to
change their PSP back to default (which will be RR since we just changed it).
esxcli storage nmp device set -d
t10.FreeBSD_iSCSI_Disk______000c299f1aec010_________________ -E
Of course we have to run this on each datastore as well – oh, and on every host
Scenario 3
Big Joe, your coworker just finished reading a ton of vSphere related material because his poor little
SQL server on his iSCSI datastore just isn't cutting it in terms of performance. He read some best
practices which stated that the max IOPs for the Round Robin policy should be changed to 1. He
requested that you do so for his datastore (iSCSI1). The storage team has given you the go ahead but
said not to touch any of the other datastores or your fired.
Nice, so there is really only one thing to do in this scenario – change our default max IOPs setting
for the SCSI1 device. So, first off, let's get our identifier for SCSI1
esxcfg-scsidevs -m
Once we have our identifier we can take a look on the roundrobin settings for that device with the
following command
esxcli storage nmp psp roundrobin deviceconfig get -d
t10.FreeBSD_iSCSI_Disk______000c299f1aec000_________________

As
we can see, the IOOperation Limit is 1000, meaning it will send 1000 IOPs down each path before
switching to the next. The storage team is pretty adamant we switch this to 1, so let's go ahead and
do that with the following command.
esxcli storage nmp psp roundrobin deviceconfig set -d t10.FreeBSD_iSCSI_Disk______000c299f1
iops -I 1
Basically what we define with the above command is that we will change that 1000 to 1, and specify
that the type of switching we will use is iops (-t). This could also be set with a -t bytes and entering
the number of bytes to send before switching.
So, that's basically it for this post! Let me know if you like the scenario based posts over me just
rambling on about how to do a certain task! I've still got lots more to cover so I'd rather put it out
there in a format that you all prefer! Use the comments box below! Good Luck!
Storage Scenarios (Section 1 – Part 2)
Hopefully you all enjoyed the last scenario based post because you are about to get another
one Kind of a different take on covering the remaining skills from the storage section, section 1.
So, here we go!
Scenario 1
A coworker has come to you complaining that every time he performs storage related functions from
within the vSphere client, VMware kicks off these long running rescan operations. He's downright
sick of seeing them and wants them to stop, saying he will rescan when he feels the need to, rather
than having vSphere decide when to do it. Make it happen!
So, quite the guy your coworker, thinking he's smarter than the inner workings of vSphere but luckily
we have a way we can help him. And also the functions we are going to perform are also part of
the VCAP blueprint as well – coincidence? Either way, the answer to our coworkers prayers is
something called vCenter Server storage filters and there are 4 of them, explained below…
RDM Filter (config.vpxd.filter.rdmFilter) – filters out LUNs that are already mapped as an RDM
VMFS Filter (config.vpxd.filter.vmfsFilter) – filters out LUNs that are already used as a VMFS
datastore
Same Hosts and Transports Filter (config.vpxd.filter.sameHostsAndTransporstFilter) – Filters
out LUNS that cannot be used as a datastore extent

Host Rescan Filter (config.vpxd.filter.hostRescanFilter) – Automatically rescans storage
adapters after storage-related management functions are performed.
As you might of concluded it's the Host Rescan Filter that we will need to setup. Also, you may
have concluded that these are advanced vCenter Server settings, judging by the config.vpxd
prefixes. What is conclusive is that all of these settings are enabled by default – so if we need to
disable one, such as the Host Rescan Filter, we will need to set the corresponding key to false.
Another funny thing is that we won't see these setup by default. Basically they are silently enabled.
Anyways, let's get on to solving our coworkers issue.
Head into the advanced settings of vCenter Server (Home-vCenter Server Settings->Advanced
Options). From here, disabling the host rescan filter is as easy as adding the
config.vpxd.filter.hostRescanFilter and false values to the text boxes near the bottom of the screen
and clicking 'Add' – see below
And voila! That coworker of yours should no longer have to put up with those pesky storage
rescans after he's done performing his storage related functions.
Scenario 2
You work for the mayors office in the largest city in Canada. The mayor himself has told you that he
installed some SSD into a host last night and it is showing as mpx.vmhba1:C0:T0:L0 – but not being
picked up as SSD! You mention that you think that is simply SAS disks but he persists it isn't (what is
this guy on crack :)). Either way, you are asked if there is anything you can do to somehow 'trick'
vSphere into thinking that this is in fact an SSD.

Ok, so this one isn't that bad really, a whole lot of words for one task. Although most SSD devices
will be tagged as SSD by default there are times when they aren't. Obviously this datastore isn't an
SSD device, but the thing is we can tag it as SSD if we want to. To start, we need to find the
identifier of the device we wish to tag. This time I'm going to run esxcfg-scsidevs to do so (with -c to
show a compact display).
esxcfg-scsidevs -c
From there I'll grab the UUID of the device I wish to tag, in my case mpx.vmhba1:C0:T0:L0 – (crazy
Rob Ford). Now if I have a look at that device with the esxcli command I can see that it is most
certainly not ssd.
esxcli storage core device list -d mpx.vmhba1:C0:T0:L0
So, our first step is to
find out which SATP is claiming this device. The following command will let us do just that
esxcli storage nmp device list -d mpx.vmhba1:C0:T0:L0
Alright, so now that we know the SATP we can go ahead and define a SATP rule that states this is
SSD
esxcli storage nmp satp rule add -s VMW_SATP_LOCAL -d mpx.vmhba1:C0:T0:L0 -o
enable_ssd
And from here we need to reclaim the device
esxcli storage core claiming reclaim -d mpx.vmhba1:C0:T0:L0
And, another look at our listing out of the device should now show us that we are dealing with a
device that is SSD.

esxcli storage core device list -d mpx.vmhba1:C0:T0:L0
So there you go Mr. Ford, I mean Mr. Mayor – it's now SSD!!!!
Migrating to vSphere Distributed Switches
Before we get to involved in the details I'll go through a few key pieces of information. As you can
see below, there are a lost of port groups that I will need to migrate. These are in fact the port
groups that are setup by default with AutoLab. Also, I'm assuming you have redundant NICs setup
on all your vSwitches. This will allow us to migrate all of our VM networks and port groups without
incurring any downtime. As stated before, there are many blog posts around this subject and many
different ways to do the migration. This is just the way I've done it in the past and I'm sure you can
probably do this in a smaller amount of steps but this is just the process I've followed.

Step 1 – Create the shell
So the first step is to create our distributed switch. This is pretty simple! Just head into your
network view and select 'New vSphere Distributed Switch', Follow the wizard, it's not that hard.
Pay attention to the number of uplinks you allow as you need to be sure that you have as many
uplinks in your distributed switch as you have physical adapters assigned to your standard switches.
Also, I usually add my hosts into the distributed switch during this process, just not importing and
physical NICs. Basically we're left with a distributed switch containing our hosts with no uplinks
assigned. Once we have our switch we need to duplicate all of the por tgroups we wish to migrate
(Management, vMotion, FT, VM, etc.) If you are following along with the autolab you should end up
with something similar to the following (ignore my PVLAN port groups – that's another blog post).

One note about the uplinks that you can't see
in the image above. I've went into each of my port groups and setup the teaming/failover to mimic
that of the standard switches. So, for the port groups that were assigned to vSwitch0, i've set
dvUplink1 and 2 as active, and 3/4 as unused. For those in vSwitch1, 3/4 are active and 1/2 are
unused. This provides us with the same connectivity as the standard switches and allows us to
segregate the traffic the exact same way that the standard switches did. This can by editing the
settings of you port group and modifying the Teaming and Failover section. See below.
Step 2 – Split up your NICs
Alright! Now that we have a shell of a distributed switch configured we can begin the migration
process. This is the process I was mentioning at the beginning of the post that can be performed a
million and one ways! This is how I like to do it. From the hosts networking configuration page, be
sure you have switched to the vSphere Distributed Switch context. The first thing we will do is

assign a physical adapter from every vSwitch on each host to an uplink on our dvSwitch. Now, we
have redundant NICs on both vSwitches so we are able to do this without affecting our connectivity
(hopefully). To do this, select the 'Manage Physical Adapters' link in the top right hand corner of the
screen. This will display our uplinks with the ability to add NICs to each one.
Basically, we want to add vmnic0 to dvUplink1 and vmnic2 to dvUplink3. This is because we want
one NIC from each standard switch into each of the active/unused configurations that we have
setup previously. It's hard to explain, but once you start doing it you should understand. To do this,
just click the 'Click to Add NIC' links on dvUplink1 and 3 and assign the proper NICs. You will get a
warning letting you know that you are removing a NIC from one switch and adding it to another.
Be sure you repeat the NIC additions on each host you have, paying close attention to the uplinks
you are assigning them to.

Step 3 – Migrate our vmkernel port groups
Once we have a couple of NICs assigned to our dvSwitch we can now begin to migrate our
vmkernel interfaces. To do this task, switch to the networking inventory view, right click on our
dvSwitch and select 'Manage Hosts'. Select the hosts we want to migrate from (usually all of them
in the cluster). The NICs that we just added should already be selected the in 'Select Physical
Adapters' dialog. Leave this as default, we will come back and grab the other NICs once we have
successfully moved our vmkernel interfaces and virtual machine networking, it's the next screen, the
'Network Connectivity' dialog which we will perform most the work. This is where we say what
source port group should be migrated to what destination port group. An easy step, simply
adjusting all of the dropdowns beside each port group does the trick. See below. When your done,
skip the VM Networking for now and click 'Finish'.
After a little bit of time we should now have all of our vmkernel interfaces migrated to our distributed
switch. This can be confirmed by looking at our standard switches and ensuring we see no
vmkernel interfaces What you might still see though is VMs attached to Virtual Machine port groups
on the standard switches. This is what we will move next.
Step 4 – Move your virtual machine port groups
Again, this is done through the Networking Inventory and is very simple. Right-click your dvSwitch
and select 'Migrate Virtual Machine Networking'. Set the VM network you wish to migrate as your
source, and the one you created for it in your dvSwtich as your destination (see below). When you
click next you will be presented with a list of VMs on that network, and whether or not the
destination network is accessible or not. If we have done everything right up to this point it should
be. Select all your VMs and complete the migration wizard.

This process will have to be done for each and every virtual machine port group you wish to
migrate. In the case of autolab, Servers and Workstations. Once we are done this we have
successfully migrated all of our port groups to our distributed switch.
Step 5 – Pick up the trash!
The only thing left to do at this point would be to go back to the hosts' view of the distributed switch,
select 'Manage Physical Adapters' and assign the remaining two NICs from our standard switches
to the proper uplinks in our dvSwitch.
Netflow, SNMP, and Port Mirroring
Objective 2.1 covers off some other components in regards distributed switches so I thought I would
just group them all together in this post since there isn't a whole lot to getting the setup.
First up, SNMP
Remember a week or so ago when we went over how to manage hosts with the vSphere
Management Assistant? Well I hope you paid attention as we will need to have our hosts
connected to the vMA in order to configure SNMP (technically you could do it with any instance of
the vSphere CLI but the vMA is already there for you on the exam so you might as well use it). We

will need to use a command called vicfg-snmp in order to setup a trap target on our hosts. So to
start off, let's set a host target with the following command
vifptarget -s host1.lab.local
Once our host is set as the target host we can start to configure SNMP. First off, let's specify our
target server, port, and community name. For a target server of 192.168.199.5 on the default port of
162 and a community name of Public we can use the following command
vicfg-snmp -t 192.168.199.5@162/Public
Now, simply enable SNMP on the host with -E
vicfg-snmp -E
You know what, your done! Want to test it, use -T. Check your SNMP server to be sure you have
recieved the trap!
vicfg-snmp -T
I would definitely recommend exploring the rest of the options with vicfg-snmp. You can do so by
browsing the help of the command. Look at things like multiple communities (-c), how to reset the
settings to default (-r), and how to list out the current configuration (-s) etc…
vicfg-snmp --help
Also, don't forget you need to do this on all of your hosts! Keep in mind that vCenter also has
SNMP settings. These are configured in the vCenter Server Settings under the SNMP section.
There is a complete GUI around this so I'm not going to go over how to configure these.
NetFlow
Netflow is configured on the settings of your dvSwitch (Right-click dvSwitch->Edit Settings) on the
NetFlow tab. There are a number of items we can configure here. First off, our collector IP and port.
This is the IP and port of the actual NetFlow collector where we are sending the data too. To allow
all of your traffic to appear as coming from a single source, rather than multipleESX management
networks you can specify an IP address for the dvSwitch here as well. This doesn't actually live on
your network, just shows up in your NetFlow collector.

There are a few other settings here as well; Active Flow Export Timeout and Idle Flow Export
Timeout handle timeouts for the flows, whereas the sampling rate determins what portion of data to
collect. IE, a sampling rate of 2 will collect every other packet, 5, every fifth packet and so on. The
Process internal flows only will only collect data between VMs on the same host. That's really it for
netflow, not that hard to configure.
Port Mirroring
I supposed you may be asked to mirror a certain port to an uplink or VM on the exam so it's probably best to
go over this. First off if you were asked to mirror traffic from VMA to VMB thenyo1u need to determine what
ports these VMs are attached to. You can see this on the Ports tab of the dvSwitch. Just sort by the
'Connectee' column and find their corresponding Port IDs. For the sake of this example let's say VMA is on
port 150 and VMB is on 200.
To do the actual mirroring we need to be on the Port Mirroring tab of the dvSwitches settings. Here we can
click 'Add' to setup the mirror. As shown we give our session a name and description as well as there is a few
settings regarding encapsulating VLANs and the maximumlenght or packet to capture.

The next couple of steps simply setup our source and destination for our mirror. To follow our
example we can use 150 for the source, and port 200 for the destination. Unless we explicity check
the 'Enable' box when completing the setup, all port mirrors are disabled by default. They can be
enabled by going back into the session and explicitly enabling the session.
CDP and LLDP
Well, 8 weeks of VCAP has dwindled down into a serious 8 days of VCAP – and for now, how about
a little bit of random information from the Networking section of the blueprint.
First up, CDP and LLDP
These are relatively easy to configure, however there are a few different modes that they can be run
in, therefore I thought it would be best if I write them down in hopes that maybe I’ll remember them if
any scenarios require me to configure them.
Basically the functionality of the two protocols is identical – they both provide discovery of ports
connected to a virtual switch. CDP however supports just Cisco physical switches whereas LLDP
supports any switch supporting LLDP. Another note, CDP can be enabled on both vSphere
Standard Switches and vSphere Distributed Switches – LLDP – dvSwitch only!
So let’s have a look at the dvSwitch config first. Like I mentioned earlier it’s pretty simple. From the
properties tab of a vSphere Distributed Switch select ‘Advanced’. From here its as simple as setting
the status to Enabled, the type to either CDP or LLDP, and the Operation mode (explained below).
 Listen – ESXi detects and displays information from the associated physical switch port,
but all information in regards to the virtual switch is not available to the physical switch.
 Advertise – ESXi presents information in regards to the virtual switch available to the
physical switch, but doesn’t detect any information in regards to the physical switch port
 Both – Does both advertise and listen.

Now that we are enabled we can view what information we receive inside of the Networking section
of a hosts configuration tab. To do so, simply expand out your physical uplinks and click the
information icon (shown below).
And that’s all there is for that – with the distributed switch anyways. To get CDP working on a
standard switch we are once again back into the command line interface. Probably good to brush
up on these commands anyways since its also mentioned in the blueprint. So, Let’s say we wanted
to configure CDP on a vSphere Standard Switch called vSwitch0 to a value of Both. We could use
the following command

esxcli network vswitch standard set –v vSwitch0 –c both
And that’s all there is to that – valid options for –c would be both, listen, advertise or down. To view
we could use the same process as above.
Private VLANS
While we are on the topic of vSphere Distributed Switches why not just cover Private VLANs.
Private VLANs is something I've never used in production, thus the reason I'm covering it in this
series. Honestly, this lazy Sunday night is the first time I've even touched them and they are very
very easy to configure technically so long as you understand the concepts first.
What is a PVLAN?
A Private VLAN is essentially a VLAN within a VLAN! Can somebody say inception!! Basically they
allow us to take one VLAN and split it into three different private VLANs each containing restrictions
in regards to connectivity to each other. As far as use cases, the most common I can see is in a
DMZ type scenario where lots of restrictions and security is in place. The three types are
promiscuous, community, and isolated and are explained below.
Promiscuous PVLAN.
A Promiscuous VLAN has the same VLAN ID as your main VLAN. Meaning if you wanted to setup
some Private VLANs on VLAN 200, the promiscuous vlan would have an ID of 200. VMs attached
to the promiscuous VLAN can see all other VMs on other PVLANs, and all other VMs on the PVLAN
can see any VMs on the promiscuous VLAN. In the DMZ scenario, Firewalls and network devices
are normally placed on the promiscuous VLAN as all VMs normally need to to see them.
Community PVLAN
VMs that are a member of the Community PVLAN can see each other, as well as see VMs in the
promiscuous VLAN. They cannot see any VMs in the Isolated PVLAN. Again, in the DMZ scenario
a Community PVLAN could house VMs that need inter connectivity to each other, such as a web
and database server.
Isolated PVLAN
VMs in an isolated PVLAN are just that; isolated! The only other VMs they would be able to
communicate with are those in promiscuous VLAN. They cannot see any VMs that are in the
community VLAN, nor can they see any other VMs that might be in the Isolated VLAN. A good spot
to put a service that only needs connectivity to the firewall and nothing else.
PVLANs in vSphere

PVLANs can be implemented within vSphere only on a vSphere Distributed Switch. Before we can
assign a VM to a PVLAN there is a little leg work that needs to be done on the switch itself in terms
of configuring the PVLAN. To do so, right-click your dvSwitch and select 'Edit Settings'. On the
Private VLAN tab (shown below) is where you initially setup your PVLAN. As you can see, I've
setup my main private VLAN ID as 200, therefore my promiscuous PVLAN is also 200. Then, I
have an isolated and community PVLAN configured with and ID of 201 and 202 respectively.
Now our Private VLAN is setup to be consumed. The only thing left to do is create some port
groups that contain the Private VLAN. We need the port groups in order to assign VMs on the
respective network. Again, right-click your dvSwitch and select 'New Port Group'. Give your port
group a name, and set the VLAN type to Private VLAN. Once this happens you will see another box
appear where we can select either the Promiscuous, Isolated, or Community entry of our PVLAN.
Go ahead and make three port groups, each one being assigned to either 200, 201, or 202.

Now it is as simple as attaching your VMs network adapters to the desired port group. For my
testing I created 4 small Linux instances; a firewall, a web server, a database server and a video
streaming server. Trying to recreate a DMZ type scenario I assigned the web and database server
to the community PVLAN as they needed to communicate with each other. I assigned the video
streaming server to an isolated PVLAN as it has no need to communicate with either the web or db
server. And I assigned the firewall to the promiscuous PVLAN, as all VMs need to be able to
communicate with it in order to gain access to the outside world. After 'much a pinging' I found that
everything was working as expected. So try it out for yourself. Try reassigning VMs to different port
groups and watch how the ping responses stop. Like I said, these are very easy to setup
technically, just understand the implications of what happens when VMs do not belong to the proper
PVLAN. Good Luck!
The rest of Section 2 – Port Binding, CLI, and DPIO
Section 2 of the blueprint is a pretty big one, and some of the pieces warranted their own post –
however there are a lot of small little skills that don’t really require a complete tutorial so I thought I
would just slam them all in here!
Determine use cases for and apply Port Binding settings
vSphere offers three types of port binding in their vSwitch settings (Distributed Virtual Switch
only)– all of which are explained below

 Static – the port will be assigned immediately on connection to the vSwitch. The VM will
stay connected to this port even when it’s powered off. The only way to free up the port is to
explicitly remove the NIC from the VM. Static Ports are managed through vCenter Server
 Dynamic – Port is connected when the VM is powered on and then disconnected when
the VM is powered off. Dynamic ports are managed through vCenter Server. This method has
been depreciated in vSphere 5.x
 Ephemeral – Both static and dynamic port binding has a set number of ports, in
ephemeral, the ports are actually created and destroyed on the VM power on/power off event
therefore requiring a bit more overhead. That said, these are managed by the host, therefore,
networking can still be connected/disconnected in the event that vCenter Server is unavailable.
Choosing a port binding method is pretty easy – Right click on your port group, chose edit settings
and it should be front and centre in the General section.
As far as use-cases go, really ephemeral only needs to be used in recovery purposes since they are
a bit more demanding in terms of overhead. Also, ephemeral does not maintain port-level
permissions and controls when a VM is rebooted, since the port will be destroyed and recreated.
For the most part it’s best to use Static port binding – and since 5.0 offers an auto expand feature to
dynamically grow the number of ports by a specified interval, you shouldn’t have to worry about
running out of ports.

Command Line goodness
The networking section references the ability to use command line tools to manage both standard
and distributed virtual switches. Obviously I can’t go over every command and every switch. Just
be sure to know how to use esxcfg-vswitch, esxcfg-vmknic, esxcfg-route, the networking
namespaces in esxcli, as well as some of the PowerCLI cmdlets around networking (Get-
VirtualSwitch, Get-NetworkAdapter, Get-VMHostNetwork, etc).
Hint – for the PowerShell command line stuff you can quickly find the PowerCLI commands
associated with networking (or anything for the matter) by utilizing the Get-VICommand cmdlet and
passing a search string. IE, to return all cmdlets containing ‘net’ you can use the following
Get-VICommand –Name *Net*
Determine use cases for and applying VMware DirectPath I/O
I’ve never used DPIO – that said, there it is on the blueprint so I’d better figure it out. As for use
cases, honestly I haven’t seen many. For the most part utilizing the virtualized hardware seems to
perform well enough, but if you need the tiny bit performance improvement it claims to provide there
are a couple of steps to get it running.
First up we need to configure pass-through on the host itself. This is done on the Configuration tab
under ‘Advanced Settings’. Simply select ‘Configure Pass-through’ and select the device you want
to present to a VM.

Once you are done this you will need to restart the host in order to complete the next step, so go
ahead and do that.
As for presenting the pass-through device to the VM this is done just as you would do any other
piece of hardware (In ‘Edit Settings’ of a VM). Simply select PCI Device as your hardware and
follow the wizard. You should see your device that you had setup for pass-through earlier in the
dropdown box as shown
below.
From here you will need to ensure that your guest OS has the correct drivers in order to install this
hardware as it is presented directly to the VM. Aside from creating a memory reservation on your
VM there are also a ton of features that are unavailable when you utilize DPIO. Things such as
vMotion, HA, DRS, Snapshots, Hot add, Fault tolerance are all not supported – probably why there
is such low adoption.
And I think that should just about wrap up networking. There is some teaming information
mentioned, but honestly I find this to be VCP level knowledge and I’m just going to assume you
already know it Good Luck!
vSphere Network I/O Control
Alright – here we go, Network I/O Control – Objective 2.4 of the blueprint lists this as a skill you
must know. Honestly, I've never used this before writing this post…thankfully, it's a very very easy
thing to configure. Unless I'm missing something, in which case I'm in for some trouble come exam
time

VMware vSphere Networking deep dive

VMware vSphere Networking deep dive

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to VMware vSphere Networking deep dive

Similar to VMware vSphere Networking deep dive (20)

Recently uploaded

Recently uploaded (20)

VMware vSphere Networking deep dive