Automatic edge VLAN provisioning with VM Tracer from Arista

One of the implications of Virtual Machine (VM) mobility (as implemented by VMware’s vMotion or Microsoft’s Live Migration) is the need to have the same VLAN configured on the access ports connected to the source and the target hypervisor hosts. EVB (802.1Qbg) provides a perfect solution, but it’s questionable when it will leave the dreamland domain. In the meantime, most environments have to deploy stretched VLANs ... or you might be able to use hypervisor-aware features of your edge switches, for example VM Tracer implemented in Arista EOS.

The concepts behind the VM Tracer feature are incredibly simple, so one has to wonder why the same functionality hasn’t been implemented by more vendors. This is what you need to do to enable VM Tracer on an Arista’s switch:

  • Configure a vCenter monitoring session on each edge switch. EOS uses the standard VMware vSphere Web Services (SOAP) SDK. Each switch can establish monitoring sessions with up to four vCenters.
  • Configure a range of VLANs you want to auto-configure on ESX-facing ports (you wouldn’t want the server administrators to accidentally provision VM in a highly protected VLAN, would you?)
  • Enable VM Tracer on ESX-facing edge ports.

The vCenter username and password are stored in cleartext (or weakly encrypted) format in EOS configuration. It might be a good idea to create a dedicated username with read-only access limited to the relevant subset of vCenter objects, and use that username on the EOS switches.

And this is how VM Tracer works:

It sends CDP packets on VM Tracer-enabled ports. ESX servers listen to CDP packets (default setting) and cache the received information. You can inspect the CDP information received by an ESX host through vCenter client, ESX command line, PowerCLI or SOAP SDK. EOS uses the SOAP SDK to query the CDP information received by ESX hosts known to the monitored vCenters. The CDP information is then used to build a host-to-port mapping table.

It monitors VM-related events (VM start, VM stop or vMotion) to discover when a VM is moved away from or to an ESX host connected to a switch. Whenever the first VM is connected to a portgroup on an ESX host (or the last VM is disconnected from the port group), the VLAN list on the edge port to which the ESX host is connected might have to be adjusted.

It adjusts the VLAN list on the edge ports to which known ESX hosts are connected.

In an ideal world, Arista EOS would support GVRP or MVRP and the VLANs needed by the ESX hosts would be auto-provisioned across the entire network. In the imperfect world we live in, you still have to configure the VLANs on inter-switch trunk links. If you’re forced to implement “unrestricted VM mobility” environment, you still have to deploy stretched VLANs and all the floods (broadcasts, multicasts and unknown unicasts) consume the bandwidth on all inter-switch links ... but at least they don’t burn the CPU cycles of every ESX host connected to your network.

More information

The details of VMware networking (including Arista’s VM Tracer, Force10’s HyperLink, Cisco’s VN-Tag and VN-link, and EVB/VEPA) are described in VMware Networking Deep Dive webinar (register here or buy a recording). If you want to learn more about modern data center architectures, buy a recording of my Data Center 3.0 for Networking Engineers webinar. Both webinars are also part of the yearly subscription package.

2 comments:

  1. Great Functionality. Thats why we baked this feature into Network Director 1.5 which works across all of Juniper EX switches. Beginning with Release 1.5, you can use Network Director to discover and monitor VMware vCenter servers, virtual switches, and virtual machines that are part of your virtual network. You can also consistently and seamlessly orchestrate the physical components of your network. You can also view the connectivity details between the physical network and the virtual network by using the View Virtual Network Connectivity feature.

    ReplyDelete
    Replies
    1. Thanks for the notice - added corresponding entries (and "green light" status) to Data Center Fabric Architectures update session (scheduled for May 2014).

      Delete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.