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

First up, let's have a look at the requirements.
 Enterprise Plus licensing – since you need a distributed switch to use NIOC, in turn you
need Ent+ licenses.
OK, maybe I should of said requirement – not plural. I can't seem to find any other requirements for
using NIOC. Anyways, the first step in getting NIOC setup is to enable it, and this in itself is a
matter of checking a box. From within the Networking inventory view on the Resource Allocation
tab select ‘Properties’ and check the box
System Network Resource Pools
Easy enough right! Now on to our Network resource pools. As you can see, there are some default
system network resource pools already setup within NIOC.
 Fault Tolerance
 iSCSI
 Management Traffic
 Virtual Machine Traffic
 vMotion
 vSphere Replication
I’ll leave it to your imagination as to what traffic these represent. Basically these resource pools are
automatically applied to their corresponding traffic type when we enable NIOC. NIOC utilizes the
same type of sharing mechanism that resource pools utilize. Meaning each resource pool is
assigned a share value, one that will apply relatively to the other pools during network contention.
Thus, if going by the example in the Networking guide, if we assign FT and iSCSI a share value of
100, while all other resource pools having 50 shares, iSCSI and FT would each get 25% while the
remaining resource pools would receive 12.5% of the available bandwidth (during contention). The
table below should help with that formula
Resource Pool Shares Total Shares Percentage
iSCSI 100 400 25%
FT 100 400 25%
Management 50 400 12.5%

VM 50 400 12.5%
vMotion 50 400 12.5%
Replication 50 400 12.5%
What if I want to further segregate my VM traffic?
A valid question. To resolve this NIOC allows us to create our own User-defined network resource
pools. Again, this is a very easy process. Selecting ‘New Network Resource Pool’ will get the dialog
box open that we need. See Below..
As you can see, we can create our own resource pool, assign either a predefined (high, normal,
low) share value to it (or we can set a custom number) as well as a QoS priority tag if we need to
tag outbound QoS from our virtual switch. Just a note, we can change the values and QoS tags on
our system defined resource pools as well if need be.
Now that we have our resource pool created there’s only one final step in applying it. Using the
‘Manage Port Groups’ link we can assign our newly created resource pool to one of our
dvPortGroups. Below I’ve done just that by assigning ‘My Server Traffic’ to dvServers.

And that’s all there is to NIOC really. Again, not too hard, but something I’ve never touched before
now. Also, something that could of caught me off guard on the exam – the last thing i want to do is
spend time reading documentation! Good luck studying!
Network Scenario
Your company leverages the full Enterprise Plus licensing and has set up a Distributed
vSwitch. Recently, the number of ports needed on a particular portgroup exceeded the
number configured. You are tasked with creating a new Portgroup, called
DvS_ProductionNetwork which only connects the running VM’s and also functions when
vCenter is down.
Off we go again. So, let’s recall. There are 3 different options of port binding on a DvS.
Static binding – Which creates a port group with a manual set number of ports. A port is assigned
whenever a vNIC is added to a VM. You can connect a vNIC static binding only through vCenter.
Dynamic binding (Deprecated in vSphere 5.0!) – A port is assigned to a vNIC when the VM is
powered on, and it’s vNIC is in a connected state. You can connect this dynamic binding only
through vCenter.
Empheral binding – A port is assigned to a vNIC when the VM is powered on, and it’s vNIC is in a
connected state. This binding method allows the bypass of vCenter, allowing you to manage virtual
machine networking when vCenter is down.
So, that’s the one we need! Empheral binding! Luckily, it’s quite simple to configure. Hop over to the
networking inventory (Ctrl + Shift + N) and create the new port group. Give it a name and leave the
number of ports on the default of 128.

Now edit the settings of this port group, and select the Empheral binding under the port binding
dropdown. Also note, that the number of ports is greyed out now.
More Networking Scenarios
Your recent work on the new portgroup was top notch! Now, the network administrators
have some new requirements. You currently use one vNIC for the DvS. A second pNIC has
been connected to the network and you have been tasked with adding it to the DvS. Also
ensure that the DvS_StorageNetwork Port Group only uses the new pNIC and does VLAN
tagging on VLAN ID 20.
Another networking objective. Whoohoo! Allright, let us first check out the current network adapters
available on the host:
Allright, so vmnic2 is the one that we can add to the DvS_AMS01. Go over to the networking view
(Ctrl + Shift + N) and edit the settings of your DvS. We first need to check if the DvSallows for
2 uplinks, instead of just 1.

And check this out! It’s still set to 1. This is a good one to remember for the exam, on the DvS object
itself, you configure the maximum number of physical adapters (also called uplink ports) per host.
So set that one to 2 and let’s continue with adding vmnic2 to the DvS.
Since the host is already connected to the DvS, click the DvS and select Manage Hosts. You will
find your host, and you can add the second nic.
You could also do this from the hosts and clusters view, do whatever works for you.
Now that we have added that pNIC to the DvS, we need to create the DvS_StorageNetwork port
group. Remember that we need to do VLAN tagging on VLAN ID 20 here. Create the new port
group now, it’s settings should look like this:
Now, for the last part: As ESXi does load balancing by default (originating port ID based) we will
now have load balancing on the DvS_ProductionNetwork, which is great, but not what we need for
the Storage Network.
Open up the settings of that port group and go to the Teaming and Failover section.
Both uplink ports are now under Active Uplinks. Let’s review real quick what the options are:
Active Uplinks – actively being used for traffic flow
Standby Uplinks – will only become active until a failure occurs on one of the active uplinks
Unused Uplinks – this adapter will never be used for this port group
We need to ensure that it will never use this uplink, so move the dvUplink1 over to the
UnusedUplinks. It should then look like this:

Host Cache Scenario
You recently acquired some SSD drives for in your hosts. You’re not running vSphere 5.5 yet
so vFRC is not an option. You read something about swap to host cache, and you think it
might be wise to configure your SSD drive for usage as host cache.
Well, the process of configuring this isn’t that hard. The swap to host cache will be used as a last
resort and a replacement of swapping to “disk”. Remember that vSphere has 4 main memory
management techniques:
1) Transparent page sharing: Eliminates redundant copies of memory pages by removing them
from memory and creating a reference instead.
2) Memory ballooning: In times of contention, the balloon driver (comes with VMware Tools) will
ask the guest OS for unused memory and returns this back to vSphere
3) Memory compression: After ballooning runs out, try compressing the memory (basically
gzipping it).
4) Swap to disk / host cache: Swap memory to a disk of some sort.
So, the swapping itself comes last in a process of memory management. While it’s still not wanted,
swapping to an SSD is still better than to storage or slow local storage.
You configure this by offering up a (portion of a) n SSD tagged datastore as host cache. Go to
Configuration -> Host cache configuration

All devices that are being recognized as SSD drive will show up here. You can right click the
datastores and set the amount of disk space that you are willing to spend on host cache. If you
haven’t formatted a datastore yet, but do have an SSD in place, you can use the Add storage
wizard mentioned above.
Once you’ve configured this, you can browse the datastore which you have (partially) allocated to
Host cache. On your datastore, you will find a hashed folder, and in that folder a folder named
hostCache.
Something like this: 5241d252-0687-cf96-f89a-10ddb1eabcf5/hostCache
In this folder, you will find as much .vswp files as the total number of GB’s that you have allocated to
host cache.

HA
Although High Availability is something I’ve been configuring for many years now I thought it might
be a good idea to go over the whole process again. This became especially evident after watching
the HA section of Jason Nash’s TrainSignal/PluralSight course, as I quickly realized there are a lot
of HA advanced settings that I’ve never modified or tested – with that said, here’s the HA post.
First off I’m not going to go over the basic configuration of HA – honestly, it’s a checkbox right – I
think we can all handle that. I will give a brief description of a few of HA bullet points that are listed
within the blueprint and point everyone where we can manage them.
First up, Admission Control
When an HA event occurs in our cluster, we need to ensure that enough resources are available to
successfully failover our infrastructure – Admission control dictates just how many resources we will
set aside for this event. If our admission control policies are violated, no more VMs can be powered
on inside of our cluster – yikes! There are three types…
Specify Failover Host – Ugly! Basically you assign a host as the host that will be used in the event
of an HA event. The result of an HA event is the only time that this host will have VMs running on it
– all other times, it sits there wasting money
Host failures cluster tolerates – This is perhaps the most complicated policy. Essentially a
slot size is calculated for CPU and memory, the cluster then does some calculations in order to
determine how many slot sizes are available. It then reserves a certain number of failover slots in
your cluster to ensure that a certain number of hosts are able to failover. There will be much more
on slot size later on in this post so don’t worry if that doesn’t make too much sense.
Percentage of Cluster resources reserved – This is probably the one I use most often. Allows
you to reserve a certain percentage of both CPU and Memory for VM restarts.
So, back to slot size – a slot is made up of two components; memory and cpu. HA will take the
largest reservation of any powered on VM in your environment and use that as its memory slot size.
So even if you have 200 VMs that have only 2GB of RAM, if you place a reservation on just one VM

of say, oh, 8GB of RAM, your memory slot size will be 8GB. If you do not have any reservations
set, the slot size is deemed to be 0MB + memory overhead.
As for CPU, the same rules apply – the slot size is the largest reservation set on a powered on VM.
If no reservations are used, the slot size is deemed to be 32MGHz. Both the CPU and Memory slot
sizes can be controlled by a couple of HA advanced settings – das.slotCpuInMhz and
das.slotMemInMb (**Note – all HA advanced setting start with das. – so if you are doing the
test and you can’t remember one, simply open the Availability doc and search for das –
you’ll find them ). These do not change the default slot size values, but more so specify an upper
limit in wich a slot size can be.
So let’s have a look at these settings and slot size – first up, we can see our current slot size by
selecting the ‘Advanced Runtime Info’ link off of a clusters’ Summary tab. As shown below my
current slot size for CPU is 500Mhz and 32MB for memory, also I have 16 total slots, 4 of which
have been taken.
So let’s now set the advanced setting das.slotCpuInMhz setting to something lower than 500 – say
we only ever want our CPU slot size for a VM to be 64Mhz. Within the clusters’ HA settings (Right-
click cluster->Edit Settings, vSphere HA) you will see an Advanced Options button, select that and
set our das.slotCpuInMhz to 64 as shown below.

Now
we have essentially stated that HA should use the smallest of either the largest VM CPU
reservation, or the value for das.slotCpuInMhz as our CPU slot size. A quick check on our runtime
settings again reflects the change we just made. Also, if you look, you will see that we have also
increased our total available slots to 128, since we are now using a CPU slot size of 64 Mhz rather
than 500.
So that’s admission control and slot sizes in a nutshell. Seems like a good task to have you limit or
change some slot sizes on the exam. Also, I’m not sure how much troubleshooting needs to be
performed on the exam but if presented with any VMs failing to power on scenarios, slot sizes and
admission control could definitely be the answer.
More Advanced Settings
As you may have seen in the earlier screenshots there were a few other of those das. advanced
settings shown. Here’s a few that you may need to know for the exam, maybe, maybe not, either
way, good to know…

das.heartbeatDsPerHost – used to increase the number of heartbeat datastores used – default is
2, however can be overridden to a maximum of 5. Requires complete reconfiguration of HA on the
hosts.
das.vmMemoryMinMb – value to use for the memory slot size if no reservation is present – default
of 0
das.slotMemInMb – upper value of a memory slot size – meaning we can limit how large the slot
size can be by using this value.
das.vmCpuMinMhz – value to use for the cpu slot size if no reservations are present – default of
32.
das.slotCpuInMhz – upper value of a CPU slot size – meaning we can limit how large the slot size
can be by using this value
das.isolationAddress – can be used to change the IP address that HA pings when determining
isolation – by default this is the default gateway.
das.isolationAddressX – can be used to add additional IPs to ping – X can be any number
between 0 and 9.
das.useDefaultIsolationAddress – can be used to specify whether HA should even attempt to use
the isolation address.
Anyways, those are the most commonly used settings – again, any others will be listed in the
availability guide so use that if needed to find others on the exam – but remember, having to open
those pdf’s will take away valuable time.
Other random things
Just a few notes on some other parts of HA that I haven’t used that often. The first being VM
Monitoring. VM Monitoring is a process that will monitor for heartbeats and I/O activity from the
VMware tools service inside your virtual machines. If it doesn’t detect activity from the VM, it
determines that it has failed and can proceed with a reboot of that VM. vSphere has a few options
as it pertains to VM monitoring that we can use to help prevent false positives and un needed VM
reboots.
Failure Interval – Amount of time in seconds to check for heartbeats and I/O activity.
Minimum Uptime – The amount of time in seconds that VM monitoring will wait after a power on or
restart before it starts to poll.
Maximum Per VM Resets – the number of times that a VM can be reset in a given time period
(Reset Time Window)
Reset Time Window – used fo the maximum VM resets – specified in hours
The blueprint also mentions heartbeat datastore dependencies and preferences. Quickly, vSphere
will chose which datastores to use as HA heartbeat datastores automatically, depending on a
number of things like storage transport, number of hosts connected, etc. We can change this as
well in our options. We can instruct vSphere to only chose from our preferred list (and by which only
selecting 2 datastores will in turn allows us to determine which datastores are used) or we can say
to use our preferred if possible, but if you can’t, go ahead and chose the ones you want.

As well, most all of the settings we set for defaults such as isolation response and restart priority
can be set on a per-VM basis as well. This is pretty easy so I won’t explain it but just wanted to
mention that it can be done.
I’d say that’s enough for HA – it’s not a hard item to administer. That said, lab it, lab all of it!
Practice Practice Practice.
Fault Tolerance
You might know VMware Fault Tolerance already, since the VCAP exam builds on the VCP
knowledge. But still, it is in the blueprint, so it might be wise to go over it.
Fault Tolerance, often abbreviated as FT is a technique in which a shadow VM of a running VM is
kept in lockstep with the primary. This basically means that all memory and CPU calculations on the
primary VM also will be executed on the secondary VM.
In case of a host failover, a VM with fault tolerance enabled can switch over from the primary to the
second VM in a matter of seconds, taking right over where the primary stopped. This allows for a
better uptime of that VM and avoids the VM restart that HA would do.
There are a few host requirements for running FT:
-> You need to have a cluster where HA is enabled
-> All hosts needs to access the same (shared) datastores
-> There needs to be physical processor support
-> VMkernel ports need to be configured for vMotion and FT logging
There are also some VM requirements for running FT:
-> The VM can only have one (1) vCPU, so no vSMP
-> The VM disks need to be eager zeroed thick provisioned
-> No non re-playable devices (CD ROM, USB devices etc).
-> No snapshots
Configuring the VMkernel port for FT logging
Conform VMware best practices for FT, it it wise to use a dedicated NIC for FT logging (preferably
even 10 gigabit), but configuring FT logging is as easy as selecting a checkbox on a VMkernel port:

Enabling FT on a VM
Enabling FT is rather simple, right-click the VM -> Fault Tolerance -> Turn on Fault Tolerance. You
might get a popup saying that a reservation (memory) will be created for the full memory allocation
of this VM, and that the disk will be eager zeroed out.
After it walks through the process of enabling fault tolerance, you get a nice blue icon in your
inventory:
After powering on the FT VM, on the summary page, you also see some info about the FT status:

Testing VMware FT
Now that we have a running FT VM, we might as well test it. We have 2 options for testing it:
Test failover – The primary VM does a failover to the primary VM, and then spawns up a new
secondary VM.
Test restart secondary – The secondary VM is re-spawned and the FT configuration is protected
again.
After doing a failover of the primary VM, a new secondary VM will be spawned, so the status after
doing the failover might be like this:
Troubleshooting VMware FT
So, all is happy, but since we’re doing the VCAP exam, we might expect some troubleshooting.

On the summary page of the host, you can see if the host is configured and ready for FT. If it isn’t,
the reason why will also be mentioned:
In the image above, there isn’t a VMkernel port configured for FT logging. So go into your
networking and check that FT logging box.
Also, when the VM mentions something like this, the secondary VM is not running, so do a restart or
migrate secondary:
Netflow, SNMP, and Port Mirroring
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.
I'm going to practice setting these up until I can do it with my eyes closed. They are something that
I don't use that option in my day to day operations, but I also recognize that the VCAP may ask you
to do these are they can easily be scored.
The ESXi Firewall
Alright, continuing on the realm of security let's have a look at the built in firewall on ESXi. This post
will relate directly to Objective 7.2 on the blueprint! Basically, a lot of this work can be done in either
the GUI or the CLI, so chose what you are most comfortable with. I'll be jumping back and forth
from both! Some things are just easier in the GUI I find….anyways, I only have like 4 weeks to go
so let's get going…
First up, enable/disable pre configured services

Easy/Peasy! Hit up the 'Security Profile' on a hosts configuration tab and select 'Properties' in the
'Services' section. You should see something similar to that of below
I guess as far as enabling/disabling you would simply stop the service and set it to manual
automation.
Speaking of automation, that's the second skill
As you can see above we have a few options in regards to automation behavior. We can Start/Stop
with the host (basically on startup and shutdown), Start/Stop manually (we will go in here and do it),
or Start automatically when …( I have no idea what this means sorry – let me know in the
comments ). Anyways, that's all there is to this!
We are flying through this, Open/Close Ports
Same spot as above just hit the 'Properties' link on the Firewall section this time. Again, this is just
as easy – just check/uncheck the boxes beside the service containing the port you want to open or
close! Have a look below – it's pretty simple!

Another releavant spot here is the 'Firewall' button at the bottom. Aside from opening and closing a
port, we can also specify which networks are able to get through if our port is open. Below I'm

allowing access only from the 192.168.1.0/24 network.
Again this can be done within the CLI, but i find it much easier to accomplish inside of the GUI. But,
that's a personal preference so pick your poison!
That's what I get for talk about the CLI, custom services!
Aha! Too much talk of the CLI leads us to a task that can only be completed via the CLI; Custom
Services. Basically, if you have a service that utilizes ports that aren't covered off by the default
services you need to create your own spiffy little service so you can enable/disable it and
open/close those ports and allow access to it. So, off to the CLI we go…
The services in the ESXi firewall are defined by XML files located in /etc/vmware/firewall The
service.xml file contains the bulk of them and you can define yours in there, or you can simply add
any xml file in the directory and it will be picked up (so long as it is defined properly). If you have
enabled HA you are in luck – you will see an fdm.xml file there. Since the VCAP is time sensitive
this might be your quickest way out as you can just copy that file, rename it to your service and
modify as it fits. If not, then you will have to get into service.xml and copy text out of there. I'm
going to assume HA is enabled and go the copy/modify route.
So, copy fdm.xml to your service name
cp fdm.xml mynewservice.xml

Before modifying mynewservice.xml you will need to give root access to write to it, use the following
to do so…
chmod o+w mynewservice.xml
Now vi mynewservice.xml – if you don't know how to use 'vi', well, you better just learn, go find a
site Let's say we have a requirement to open up inbound tcp/udp 8000 and tcp/udp 8001 on the
outbound. We would make that file look as follows, simply replacing the name and ports and setting
the enabled flag.
Syslog scenario
Company policies state that every syslog capable device or server should send these logs to
an appropriate syslog collector. Your colleague has already set up the VMware syslog
collector on a separate machine, located at 10.10.20.45. You have been tasked with setting
up the syslog clients on the ESXi hosts, and ensuring that syslogs arrive on the syslog
server.
To configure the syslog collector on the ESXi hosts, we will be using the esxcli system
syslognamespace. This allows us to set different options regarding the local and remote (which is
what we want) syslog.
Let’s review the default config first by using the following command:
~ # esxcli system syslog config get
Default Rotation Size: 1024
Default Rotations: 8
Log Output: /scratch/log
Log To Unique Subdirectory: false
Remote Host: <none>
We see that no remote syslog is being used. Let’s configure one, using this command:
~ # esxcli system syslog config set –loghost=10.10.20.45
Now that we have configure a remote loghost, we need to reload the syslog daemon to apply the
configuration changes. Esxcli can help us once again:
~ # esxcli system syslog reload
You might think that we’re ready now, but when we check our syslog, we don’t see syslog yet.
Bummer! For this problem, I’ll reference to the ESXi firewall post

(http://blog.mwpreston.net/2013/11/19/8-weeks-of-vcap-the-esxi-firewall/) as with the default
security level, this outgoing traffic will be dropped. We need to enable the firewall rule for syslog
(udp/514, tcp/1514).
~ # esxcli network firewall ruleset set -r syslog -e true
And reload our changes:
~ # esxcli network firewall refresh
And now, we see our host logs coming in. The VMware syslog collector stores it logs by default in
C:ProgramDataVMwareVMware Syslog CollectorData
Alright, save that bad boy, and probably it's a good idea to run 'chmod o-w mynewservice.xml' and
take away that write permission. If you go and look at your services, or simply run 'esxcli network
firewall ruleset list' you might say, "hey, where's my new service?" Well, it won't show up until you
refresh the firewall – to do so, use the following command..
esxcli network firewall refresh
Now you can go check in the GUI or do the following to list out your services…
esxcli network firewall ruleset list

Woot! Woot! It's there!
But wait, it's disabled. No biggie, we can go ahead and enable it just as we did the others in the
steps earlier in this post – or, hey, since we are in the CLI let's just do it now!
esxcli network firewall ruleset set -r mynewservice -e true
And that's that! You are done! If asked to set the allowedIP information, I'd probably just jump back
to the GUI and do that!
Set firewall security level – More CLI goodness
Well before we can set the firewall security level let's first understand what security levels are
available to us. ESXi gives us three…
High – This is the default – basically, firewall blocks all incoming and outgoing ports except for the
the essential ports it needs to run.
Medium – All Incoming is blocked, except for any port you open – outgoing is a free for all
Low – Nada – have at it, everything is open.
Anyway, we can get the default action by specifying
esxcli network firewall get
and to change it we have a few options… Passing '-d false' would set us to DROP (the default
HIGH security level), passing a '-d true' will set us up to PASS traffic (I think this would be the

medium security) and setting a '-e false' will disable the firewall completely (the low settings). So, to
switch to medium we could do the following
esxcli network firewall set -d true
I could be wrong here, so if I am just let me know and I'll update it
And guess what? We are done with the firewall! I would practice this stuff as it's easy measurable
and can be quickly identified as you doing something right or wrong – I'd bet this will be on the exam
in one way or another. Good Luck!
Security
Just as I said I'm going to hop around from topic to topic, so without further ado we move from HA to
security. This post will be pretty much all of objective 7 on the blueprint – some things I may graze
over while focusing heavily on others.
So first up is Objective 7.1 – now there is a lot of information in here and I'll just pull out the most
important in my opinion, as well as the task I don't commonly perform. So that said, I'm going to
leave out the users, groups, lockdown mode, and AD authentication. These things are pretty simple
to configure anyways. Also, this whole authentication proxy thing – I'm just going to hope for the
best that it isn't on the exam So, let's get started on this beast of an objective.
SSH
Yeah, we all enable it right – and we all suppress that warning with that advanced setting. The point
is, ssh is something that is near and dear to all our hearts, and we like to have the ability to access
something via the CLI in the case the GUI or vCenter or something is down. So with that said, let's
have a look at what the blueprint states in regards to SSH – customization. Aside from enabling
and disabling this, which is quite easy so I won't go over it, I'm not sure what the blue print is getting
at. I've seen lots of sites referencing the timeout setting so we can show that. Simply change the
value in the Advanced Settings of a host to the desired time in seconds (Uservars-
>ESXiShellTimeOut) as shown below
As far as
'Customize SSH settings for increased security' goes, I'm not sure what else you can enable/disable
or tweak to do so. If you are familiar with sshd I suppose you could permit root from logging in and
simply utilize SSH with a local user account.

Certificates and SSL
The blueprint mentions the enabling and disabling of certificate checking. This is simply done by
checking/unchecking a checkbox in the SSL section of the vCenter Server settings.
The blueprint also calls out the generation of ESXi host certs. Before doing any sort of certificate
generation or crazy ssl administration always back your original certs up. These are located in
/etc/vmware/ssl – just copy them somewhere. To regenerate new certs simply shell into ESXi and
run generate-certificates – this will create new certs and keys, ignore the error regarding the config
file After doing this you will need to restart your management agents (/etc/init.d/hostd restart) and
quite possibly reconnect your host to vCenter.
To deploy a CA signed cert you can simply just copy your certs to the same directory
(/etc/vmware/ssl ) and be sure they are named rui.cert and rui.key and restart hostd the same as
above.
As far as SSL timeouts I couldn't find this located in any of the recommended tools for this objective,
it's actually in the security guide (which makes sense right, we are doing the security objective #fail
– either way, you need to edit the /etc/vmware/hostd/config.xml file and add the following two
entries to modify the SSL read and handshake timeout values respectively (they are in milliseconds
remember)
<readTimeoutMs>15000</readTimeoutMs>
<handshakeTimeoutMs>15000</handshakeTimeoutMs>
Once again you will need to restart hostd after doing this!
Password policies
Yikes! You want to get confused try and understand the pam password policies. I'll do my best to
explain it – keep in mind it will be high level though – this is in the blueprint however I'm not sure if
they are going to have you doing this on the exam. Either way, it's good to know… Honestly, I don't
think I'm going to memorize this, if you work with it daily then you might, but me, no! I'll just know
that it is also in the security guide (search for PAM). Anyways, here's the command
password requisite /lib/security/$ISA/pam_passwdqc.so retry=N
min=N0,N1,N2,N3,N4
Wow! So what the hell does that mean? Well, first off N represents numbers (N = retry attempts,
N0 = length of password if only using one character class, N1 = length if using two character
classes, N2 = length of words inside passphrases, N3 = length if using three character classes, N4
= length if using all four character classes). Character classes are basically lower case, upper case,
numbers and special characters. They also confuse things by slamming the passphrase settings
right in the middle as well – Nice! Either way, this is the example from the security guide.

password requisite /bin/security/$ISA/pam_passwdqc.so retry=3 min=12,9,8,7,6
This translates into three retry attempts, 12 character password min if using only one class, 9
character minimum if using two classes, 7 character minimum if using three classes, and 6
character minimum if using all four classes. As well, passphrases are required to have words that
are at least 8 characters long.
No way can I remember this, I'm just going to remember Security Guide + CTRL+F + PAM
I'm going to cut this post off here and give the ESXi firewall its' own post – my head hurts!!!!
vSphere Management Assistant (vMA)
So, first off, let's get started with installing and configuring the vMA. Installation really doesn't even
need to be described. It comes as an ovf and it's as simple as just importing that…
Configuration can get a bit tricky, especially if you haven't used IP Pools before. We will cover IP
Pools in another blog post so I'll just leave it at that. For the moment, I just went into the vMA VM
settings and disabled all of the vApp options!
Anyways, once you finally get the appliance booted up you will be prompted to enter in some
network information – pretty simple stuff, menu driven, and then prompted to change the default
password for vi-admin. Easy stuff thus far. Speaking of authentication the vMA utilizes 'sudo' to
execute commands. This basically allows vi-admin to execute commands under the root user
account. A bit of a security and safeguard mechanism utilized in some Linux OSes.
Alright, so we are now up and running so let's just go over some common tasks that we might
perform in relation to the vSphere Management Assistant. Probably a good idea to know all of
these for the exam as vMA does have its very own objective and is referenced in many others.
vMA and your domain!
Certainly we may want to join the appliance to our domain. This will give us plenty of benefits
security wise, the biggest being we will not have to store any of our target hosts passwords within
the vMA credential store – so long as the hosts are a member of the domain as well. Commands
related to vMA and domains are as follows…
To join vMA to a domain, obviously substituting your domain name and authentication…requires a
restart of the appliance afterwards.
sudo domainjoin-cli join FQDN user_with_priveledges
And, to remove the vMA it's the same command, different parameters
sudo domainjoin-cli leave
And to view information

sudo domainjoin-cli query
So as mentioned above we can do some un-attended active directory authentication to our hosts.
This is a pretty long drawn out process so I doubt it will be asked, but then again I'm wrong 100% of
50% of the time – I'd just know where this information is in the vSphere Management Assistant user
guide (HINT: Page 15).
Host Targets
Before we can use the vMA to execute commands on hosts we need to, well, add hosts to our vMA.
Within vMA terms, our hosts are called targets; targets on which we can execute commands. So
when adding hosts we have to provide the hostname and some credentials. Thus we have a couple
of options in regards to how we authenticate; adauth of fpauth (Default). Examples of adding a host
with both authentication types are below…along with some other host options..
Using local ESXi credentials
vifp addserver HOSTNAME
Using AD credentials
vifp addserver HOSTNAME --authpolicy adauth
Viewing the hosts we have added
vifp listservers
Removing a server
vifp removeserver HOSTNAME
Set a host as the target server – meaning set it up so you can run a command on the host without
authentication
vifptarget -s HOSTNAME
To clear the current target
vifptarget -c
Security and user related functions
The vMA also has a few commands we can run to help better secure our systems. When you add a
host to vMA, it actually creates a vi-admin and vi-user account on your ESXi host. You can tell vMA
to rotate these passwords using the following command.
vifp rotatepassword (--now, --never or --days #)
vMA also has a vi-user account locally, which by default is disabled, since it has no password. This
account can be used to run commands on an ESXi host that would not normally require

administrative priviledges. Enabling this account is as easy as simply setting a password on it using
the following
sudo passwd vi-user
For now that's it – That's all I can think of that is vMA related – Now we will be using it for some
other components in the futre, like setting up snmp and different things, but I wanted to keep this
post strictly about vMA specific commands. Happy Studying!

VMware vSphere Networking deep dive

More Related Content

What's hot (20)

Similar to VMware vSphere Networking deep dive (20)

Recently uploaded (20)

VMware vSphere Networking deep dive