Archive for January 2013

Configure Explicit Failover to conform with VMware Best Practice

dilbert

Best Practices

  • When configuring load balancing on the physical switch, some switches require that both interfaces be sourced to the same switch. Check with your vendor, but ideally, you should separate pNIC connections on separate switches just like you do with separate buses for a network team
  • When a failover or fallback event occurs, the delay may sever communication. To speed up the process of bringing the port online, you may want to enable portfast on your pSwitch uplinks to the ESXi host. Portfast avoids the unnecessary negotiation that takes place when a port tries to determine what it is connected to on the other end
  • Separate VM traffic and infrastructure traffic (vMotion, NFS, iSCSI)
  • Use separate pNICs and vSwitches where possible
  • VLANs can be used to isolate traffic(both from a broadcast and security perspective)
  • When using NIC teams use pNICs from separate buses (ie don’t have a team comprising two pNICs on the same PCI card – use one onboard adapter and one from an expansion card)
  • Keep FT logging on a separate pNIC and vSwitch(ideally 10GB)
  • Use dedicated network infrastructure (physical switches etc) for storage (iSCSI and NFS)
  • Use consistent port names on VLANs for virtual machine networks on all ESXi hosts
  • Every physical network adapter connected to the same vSphere standard switch or vSphere distributed switch should also be connected to the same physical network.
  • Configure all VMkernel network adapters to the same MTU. When several VMkernel network adapters are connected to vSphere distributed switches but have different MTUs configured, you might experience network connectivity problems
  • Under NIC Teaming > Network Failover Detection, Do not set to beacon probing if using route based on IP-hash
  • Notify Switches, this should be set to No if you are using Microsoft NLB in Unicast Mode
  • The Failback setting must be set to No if using IP based storage.  This is because if the link were to go up and down quickly it could have a negative impact on iSCSI traffic performance. Best practice is to leave this set to yes if not

Identify common network protocols

protocol

What is a Network Protocol?

A network protocol defines rules and conventions for communication between network devices. Protocols for computer networking all generally use packet switching techniques to send and receive messages in the form of packets.

Network protocols include mechanisms for devices to identify and make connections with each other, as well as formatting rules that specify how data is packaged into messages sent and received. Some protocols also support message acknowledgement and data compression designed for reliable and/or high-performance network communication. Hundreds of different computer network protocols have been developed each designed for specific purposes and environments.

In modern protocol design, protocols are “layered” according to the OSI 7 layer model or a similar layered model. Layering is a design principle which divides the protocol design into a number of smaller parts, each part accomplishing a particular sub-task and interacting with the  other parts of the protocol only in a small number of well-defined ways. Layering allows the parts of a protocol to be designed and tested while keeping each design relatively simple. Layering also permits familiar protocols to be adapted to unusual circumstances

Common Network protocols

  • Fibre Channel network protocols
  • Internet Protocol Suite or TCP/IP model or TCP/IP stack (TCP/UDP)
  • OSI protocols family of information exchange standards developed jointly by the ISO and the ITU-T
  • Routing protocols EIGRP, OSPF and BGP
  • List of IP protocol numbers, protocol numbers used in the Protocol field of the IPv4 header and the Next Header field of IPv6 header
  • RTPS protocol, an interoperability protocol
  • SSH Secure Shell
  • FTP File Transfer Protocol
  • SMTP Simple Mail Transfer Protocol
  • Telnet Telephone Network
  • HTTP Hyper Text Transfer Protocol
  • HTTPS Secure Hyper Text Transfer Protocol
  • SFTP Secure File Transfer Protocol
  • SSL Secure Socket Layer
  • TLS Transport Layer Security
  • POP post office protocol
  • ARP Address Resolution Protocol
  • ICMP Internet Control Mangement Protocol
  • H.323 Real-time transfer of audio and video data over packet networks
  • SNMP Monitor network availability and performance
  • SOCKS Allow clients to communicate with proxy servers (or VPN servers) through network firewalls.
  • NTP Network Time Protocol
  • CDP Cisco Discovry Protocol
  • LLDP Link Layer Discovery Protocol
  • NNTP Network News Transfer Protocol
  • Telnet
  • SSH Secure Shell
  • DNS

NIC Teaming Protocols used in vSphere

Etherchannel

EtherChannel technologies create a single logical link by bundling multiple physical Ethernet-based links (such as Gigabit Ethernet or Ten Gigabit Ethernet links) together. As such, EtherChannel links can provide for increased redundancy, capacity, and load-balancing. To optimize the load balancing of traffic over multiple links, it is recommended to deploy EtherChannels in powers of two (two, four, or eight) physical links. EtherChannel links can operate at either L2 or L3

EtherChannel links can be created using Cisco Port Aggregation Protocol (PAgP), which performs a negotiation prior to forming a channel, to ensure compatibility and administrative policies.   You can configure PAgP in four channeling modes:

  • On: Forces the LAN port to channel unconditionally. In the on mode, a usable EtherChannel exists only when a LAN port group in the on mode is connected to another LAN port group in the on mode. Ports configured in the on mode do not negotiate to form EtherChannels: They just do or do not, depending on the other port’s configuration.
  • Off: Precludes the LAN port from channeling unconditionally.
  • Desirable: Places a LAN port into an active negotiating state in which the port initiates negotiations with other LAN ports to form an EtherChannel by sending PAgP packets. A port in this mode forms an EtherChannel with a peer port that is in either auto or desirable PAgP mode.
  • Auto: (Default) Places a LAN port into a passive negotiating state in which the port responds to PAgP packets it receives but does not initiate PAgP negotiation. A port in this mode forms an EtherChannel with a peer port that is in desirable PAgP mode (only)

LACP

Alternatively, EtherChannels can be negotiated with the IEEE 802.3ad Link Aggregation Control Protocol (LACP), which similarly allows a switch to negotiate an automatic bundle by sending LACP packets to the peer. LACP supports two channel negotiation modes:

  • Active: Places a port into an active negotiating state in which the port initiates negotiations with other ports by sending LACP packets. A port in this mode forms a bundle with a peer port that is in either active or passive LACP mode.
  • Passive: (Default) Places a port into a passive negotiating state in which the port responds to LACP packets it receives but does not initiate LACP negotiation. A port in this mode forms a bundle with a peer port that is in active LACP mode (only).

Similar to PAgP, LACP requires only a single command on the physical interface when configured as a L2 link. Optionally, you can change the LACP mode from the default “passive” negotiation mode

Note that PAgP and LACP do not interoperate with each other; ports configured to use PAgP cannot form EtherChannels with ports configured to use LACP, and can ports configured to use LACP cannot form EtherChannels with ports configured to use PAgP.   EtherChannel plays a critical role in provisioning network link redundancy, especially at the campus distribution and core layers. Furthermore, an evolution of EtherChannel technology plays a key role the Cisco Virtual Switching System

Understand the NIC Teaming failover types and related physical network settings

etherchannel

What is Network Teaming and Load Balancing?

Network Teaming is the process of combining NICs to provide bandwidth and failover to a switch. Load balancing and failover policies allow you to determine how network traffic is distributed between network adapters and how to re-route traffic in the event of adapter failure.

You can set NIC Teaming on the following objects

  • Standard Switch
  • Distributed Switch
  • Standard Port Group
  • Distributed Port Group

Settings Overview for a Standard Switch

portgroup_network_policies

Procedure for a Standard Switch and a Standard Port Group

  • Log in to the vSphere Client and select the server from the inventory panel.
    The hardware configuration page for this server appears.
  • Click the Configuration tab and click Networking.
  • Select a Standard Switch or Standard Port Group and click Edit.
  • Click the Ports tab.
  • To edit the Failover and Load Balancing values, select the standard switch item and click Properties.
  • Click the NIC Teaming tab
  • You can override the failover order at the port group level. By default, new adapters are active for all policies. New adapters carry traffic for the standard switch and its port group unless you specify otherwise.

Specify how to choose an uplink.

  • Route based on the originating virtual port
  1. Choose an uplink based on the virtual port where the traffic entered the distributed switch. This is the default configuration and the one most commonly deployed.
  2. When you use this setting, traffic from a given virtual Ethernet adapter is consistently sent to the same physical adapter unless there is a failover to another adapter in the NIC team.
  3. Replies are received on the same physical adapter as the physical switch learns the port association.
  4. This setting provides an even distribution of traffic if the number of virtual Ethernet adapters is greater than the number of physical adapters.
  5. A given virtual machine cannot use more than one physical Ethernet adapter at any given time unless it has multiple virtual adapters.
  6. This setting places slightly less load on the ESX Server host than the MAC hash setting.
  • Route based on ip hash
  1. Choose an uplink based on a hash of the source and destination IP addresses of each packet. For non-IP packets, whatever is at those offsets is used to compute the hash.
  2. Evenness of traffic distribution depends on the number of TCP/IP sessions to unique destinations. There is no benefit for bulk transfer between a single pair of hosts.
  3. You can use link aggregation — grouping multiple physical adapters to create a fast network pipe for a single virtual adapter in a virtual machine.
  4. When you configure the system to use link aggregation, packet reflections are prevented because aggregated ports do not retransmit broadcast or multicast traffic.
  5. The physical switch sees the client MAC address on multiple ports. There is no way to predict which physical Ethernet adapter will receive inbound traffic.
  6. All adapters in the NIC team must be attached to the same physical switch or an appropriate set of stacked physical switches. (Contact your switch vendor to find out whether 802.3ad teaming is supported across multiple stacked chassis.) That switch or set of stacked switches must be 802.3ad-compliant and configured to use that link-aggregation standard in static mode (that is, with no LACP).
  7. All adapters must be active. You should make the setting on the virtual switch and ensure that it is inherited by all port groups within that virtual switch
  • Route based on source MAC hash
  1. Choose an uplink based on a hash of the source Ethernet MAC Address
  2. When you use this setting, traffic from a given virtual Ethernet adapter is consistently sent to the same physical adapter unless there is a failover to another adapter in the NIC team.
  3. Replies are received on the same physical adapter as the physical switch learns the port association.
  4. This setting provides an even distribution of traffic if the number of virtual Ethernet adapters is greater than the number of physical adapters.
  5. A given virtual machine cannot use more than one physical Ethernet adapter at any given time unless it uses multiple source MAC addresses for traffic it sends.
  • Use explicit failover order

Always use the highest order uplink from the list of Active adapters which passes failover detection criteria.

NOTE IP-based Hash teaming requires that the physical switch be configured with etherchannel. For all other options, etherchannel should be disabled.

Settings Overview for a Distributed Switch

Capture

Procedure for a Distributed Switch and a Distributed Port Group

  • Log in to the vSphere Client and select the server from the inventory panel. The hardware configuration page for this server appears.
  • Click the Configuration tab and click Networking.
  • Select a Distributed Switch or Distributed Port Group and click Edit.
  • Click the Ports tab.
  • To edit the Failover and Load Balancing values, select the standard switch item and click Properties.
  • Click the NIC Teaming tab
  • You can override the failover order at the port group level. By default, new adapters are active for all policies. New adapters carry traffic for the standard switch and its port group unless you specify otherwise.

Specify how to choose an uplink.

  • Route based on the originating virtual port
  1. Choose an uplink based on the virtual port where the traffic entered the distributed switch. This is the default configuration and the one most commonly deployed.
  2. When you use this setting, traffic from a given virtual Ethernet adapter is consistently sent to the same physical adapter unless there is a failover to another adapter in the NIC team.
  3. Replies are received on the same physical adapter as the physical switch learns the port association.
  4. This setting provides an even distribution of traffic if the number of virtual Ethernet adapters is greater than the number of physical adapters.
  5. A given virtual machine cannot use more than one physical Ethernet adapter at any given time unless it has multiple virtual adapters.
  6. This setting places slightly less load on the ESX Server host than the MAC hash setting.
  • Route based on ip hash
  1. Choose an uplink based on a hash of the source and destination IP addresses of each packet. For non-IP packets, whatever is at those offsets is used to compute the hash.
  2. Evenness of traffic distribution depends on the number of TCP/IP sessions to unique destinations. There is no benefit for bulk transfer between a single pair of hosts.
  3. You can use link aggregation — grouping multiple physical adapters to create a fast network pipe for a single virtual adapter in a virtual machine.
  4. When you configure the system to use link aggregation, packet reflections are prevented because aggregated ports do not retransmit broadcast or multicast traffic.
  5. The physical switch sees the client MAC address on multiple ports. There is no way to predict which physical Ethernet adapter will receive inbound traffic.
  6. All adapters in the NIC team must be attached to the same physical switch or an appropriate set of stacked physical switches. (Contact your switch vendor to find out whether 802.3ad teaming is supported across multiple stacked chassis.) That switch or set of stacked switches must be 802.3ad-compliant and configured to use that link-aggregation standard in static mode (that is, with no LACP).
  7. All adapters must be active. You should make the setting on the virtual switch and ensure that it is inherited by all port groups within that virtual switch
  • Route based on source MAC hash
  1. Choose an uplink based on a hash of the source Ethernet MAC Address
  2. When you use this setting, traffic from a given virtual Ethernet adapter is consistently sent to the same physical adapter unless there is a failover to another adapter in the NIC team.
  3. Replies are received on the same physical adapter as the physical switch learns the port association.
  4. This setting provides an even distribution of traffic if the number of virtual Ethernet adapters is greater than the number of physical adapters.
  5. A given virtual machine cannot use more than one physical Ethernet adapter at any given time unless it uses multiple source MAC addresses for traffic it sends.
  • Route based on physical NIC Load
  1. Load based teaming uses the same inital port assignment as the “Originating Port ID” policy. The first virtual NIC is affiliated to the first physical NIC, the second virtual NIC to the second physical NIC etc. After initial placement, load based teaming examines both ingress and egress load of each uplink in the team. Load based teaming then adjusts the virtual NIC to Physical mapping if an uplink is congested. the NIC team load balancer flagas a congestion condition of an uplink experiences a mean use of 75% or more over a 30 second period
  • Use explicit failover order

Always use the highest order uplink from the list of Active adapters which passes failover detection criteria.

NOTE: IP-based Hash teaming requires that the physical switch be configured with etherchannel. For all other options, etherchannel should be disabled.

Further Information on Route based on the originating Port ID

it’s important to understand the basic behavior in this configuration. Because the vSwitch is set to “Route based on originating virtual port ID”, network traffic will be placed onto a specific uplink and won’t use any other uplinks until that uplink fails. Every VM and every VMkernel port gets its own virtual port ID. These virtual port IDs are visible using esxtop (launch esxtop, then press “n” to switch to network statistics)

  • Each VM will only use a single network uplink, regardless of how many different connections that particular VM may be handling. All traffic to and from that VM will be place on that single uplink, regardless of how many uplinks are configured on the vSwitch.
  • Each VMkernel NIC will only use a single network uplink. This is true both for VMotion as well as IP-based storage traffic, and is true regardless of how many uplinks are configured on the vSwitch.
  • Even when the traffic patterns are such that using multiple uplinks would be helpful—for example, when a VM is copying data to or from two different network locations at the same time, or when a VMkernel NIC is accessing two different iSCSI targets—only a single uplink will be utilized.
  • It’s unclear at what point VMware ESX creates the link between the virtual port ID and the uplink. In tests, rebooting the guest OS and power cycling the VM results in  having it come back on the same uplink again. Only a VMotion off the server and back again caused a VM to move to a new uplink.
  • There is no control over the placement of VMs onto uplinks without the use of multiple port groups. (Keep in mind that you can have multiple port groups corresponding to a single VLAN.)
  • Because multiple VMs could be assigned to the same uplink, and because users have no control over the placement of VMs onto uplinks, it’s quite possible for multiple VMs to be assigned to the same uplink, or for VMs to distributed unevenly across the uplinks. Organizations that will have multiple “network heavy hitters” on the same host and vSwitch may run into situations where those systems are all sharing the same network bandwidth.

These considerations are not significant, but they are not insignificant, either. The workaround for the potential problems outlined above involves using multiple port groups with different NIC failover orders so as to have more fine-grained control over the placement of VMs on uplinks. In larger environments, however, this quickly becomes unwieldy. The final release of the Distributed vSwitch will help ease configuration management in this sort of situation.

Useful Blogs on VMware NIC Teaming. (Thanks to Scott Lowe)

http://blog.scottlowe.org/2008/10/08/more-on-vmware-esx-nic-utilization/
http://blog.scottlowe.org/2008/07/16/understanding-nic-utilization-in-vmware-esx/

Use command line tools to troubleshoot and identify VLAN configurations

images

Valid Commands

Note: With the release of 5.0, the majority of the legacy esxcfg-*/vicfg-* commands have been migrated over to esxcli. At some point, hopefully not in the distant future, esxcli will be parity complete and the esxcfg-*/vicfg-* commands will be completely deprecated and removed including the esxupdate/vihostupdate utilities.

  • esxcfg-nics
  • vicfg-nics
  • esxcfg-route
  • vicfg-route
  • esxcfg-vmknic
  • vicfg-vmknic
  • esxcfg-vswitch
  • vicfg-vswitch
  • esxcli network nic
  • esxcli network interface
  • esxcli network vswitch
  • esxcli network ip

What to use When

cli

Examples

DCUI

You can also either connect to the console screen to look at Network Settings or connect via Putty/vMA/vCLI and type DCUI to get the following screen

DCUI

 ESXCLI and VICFG

Retrieving Network Port Information

nic2

Setting Virtual Switch Attributes

nic3

Listing, Creating and Deleting Standard Switches

nic4

Managing a VMKernel Port

nic5

Listing, Adding and Removing Port Groups

nic6

Configuring a PortGroup with a VLAN ID

nic7

Linking and Unlinking Uplink Adapters

nic8

Configure DNS and Routing

nic10

Managing uplinks in Distributed switches

nic13

Command Line reference

http://pubs.vmware.com

Command Line Interface – Getting Started

vCLI Poster of example commands

http://blogs.vmware.com