Well, I’m back in the UK after my trip to the USofA last week for the 10th annual VMworld Fest. I was rushed off my feet last week, so I wasn’t able to write up all of my “What’s New” content. Today’s post is all about networking in vSphere. As ever there are big and small improvements to the overall networking stack. So firstly, vSphere5.5 ships with support for 40Gps networking interface. Support is limited to Mellanox ConnectX3 VPI Adapters, but I’m sure others will follow on the HCL in due course.
LACP support has been about for sometime in VMware’s DvSwitches, but previously only one LACP configuration was allowed per DvSwitch. That meant you needed to setup more than one DvSwitch (and have the pNICs to do that) if you wanted more. vSphere5.5 introduces support for LACP Link Aggregation Groups (LAG – an unfortunate industry acronymn, after all who wants lags in their networking!) You can have upto 64 LAGs per ESX hosts, and 64 per DvSwitch (1xDvSwitch with 64 LAGs, or 64xDvSwitch with 1 LAG or any combination therein). It now supports upto 22 different algorithms for load-balancing (not just IP hash).
In this example LACP deployment there’s two portgroups which are associated with two LAGs backed by one DvSwitch – each portgroup/LAG is backed by two different pNICs.
New Packet Capture Tool
vSphere5.5 will introduce a new packet capturing tool. In previous editions of ESX there was fully-fledge console based on RHEL, and folks would use tools such as tcpdump to capture packets. We used to use this in train courses to show how security could be weakened on the vSwitch to allow promiscuous mode captures. Don’t forget that a DvSwitch supports Netflow and Port Mirroring methods of gathering network information as well. The new utility can capture at three different levels the vmnic, the vSwitch, and the DvUplink.
Port Security via Traffic Filtering
This is sometimes referred to as ACL on physical switches. What it allows you to do is drop packets based on ethernet header information such that traffic that matches the rule never even gets to leave the switch. You can drop based on source/destination MAC address, IP TCP Port, or source/destination IP Address. It’s even possible to drop internal vmkernal communications such as vMotion, although the usage case for doing so has yet to be found. The traffic can be dropped whether its ingress or egress.
QoS Tagging for end-to-end SLA
vSphere5.5 introduces support for Differential Service Code Point (DSCP) marking or tagging. DvSwitches have support for sometime vSphere Network IO Control (NIOC), and for many customers this per-portgroup priority/bandwidth allocations fit their needs. However, they only go so far – and so its been determined to offer a greater level of granularity which allows of tagging of traffic based on the type. For example we can tag and prioritise traffic to a database server based on HTTP or HTTPs. A combination of NIOC and Tagging should allow customers to meet their SLA needs. DSCP Tagging works at L3, and adds 6-bits to define the type of traffic supporting up-to 64 different traffic classes. Whether folks will actually configure this feature will vary upon need, but its likely to keep the network teams happy from a “tick box” perspective. As ever virtualization admins often experience resistance to change, merely because networking guys expect a virtual switch to have ALL the features and functionality of a physical switch.