I’ve had the privilege of spending some time with the Arista product this week. For those of you who don’t follow HPE obsessively, some backstory – in the past, HPE led with the Comware product line in the datacenter, which was part of their 3COM acquisition. Comware was solid product and many of our clients had a good experience with the platform… even though the CLI was … “unique” compared to some. Really, it just took some getting used to.
However, last year HPE announced that they were opening a shared partner program of sorts with the Arista product. Arista had been making a lot of positive waves in the datacenter networking environment, so I was happy to add another tool to my arsenal. But then several months things became more serious as HPE announced that all new datacenter opportunities should be designed using the Arista lineup… and that the Comware gear wasn’t going to be their main focus moving forward.
Well, guess I better learn Arista then!
Arista uses Fedora Linux at the core, which allows a lot of cool tricks. Tools like grep, cat, zcat, tcpdump, awk and more are ready to go from boot. Administrators can choose to work in the bash shell or work in the Arista CLI, which will be very familiar to Cisco shops. Because of the Linux architecture, common networking protocols like STP, OSPF, BGP all run as individual processes and can be isolated if problems pop up. VXLAN, MLAG and other datacenter goodies are supported as well.
One tool that stood out to me during the boot camp was the VMtracer. VMtracer allows the Arista switch to keep an eye on the virtual environment by collaborating with the vCenter server. A few weeks ago I published a post around NSX and how it marries the physical network infrastructure with the virtual, solving a lot of problems for the large datacenter and the inherent scaling issues present there. Arista fully supports the VXLAN tunnel overlay I described (in fact Arista was one of the co-authors of the VXLAN standard), but the Arista gear presents a new convenient solution and QoL enhancement for smaller datacenters that still utilize a L2 topology with VMtracer.
It’s always better to show than tell, so here’s a quick walkthrough:
So first, within the CLI we configure VMtracer to communicate with vCenter – see below.
Once this is up and running the Arista switch and the VMware environment can exchange info. Running show vmtracer sess brings up the session and gives confirmation that we’re all set.
After a few minutes the VM database will populate. You can check this with show vmtracer vm, which lists out the VMs, their host, and what interface on the Arista switch they are connected to. In this case everything is connecting via the trunk port Ethernet1.
We can pull more information with the “detail” flag, showing more information on each VM.
Someone who is good with Linux will be able to use pipes and grep-esque commands to quickly filter through info, but frankly I am very rusty with Linux. Keep in mind that Arista does support XMMP for multi switch CLI, so you can pull info from multiple sources simultaneously through pre-defined XMMP groups. Here’s my attempt to pull up info on a specific VM – note that you can quickly determine where a VM is connected using this tool.
Now, VMtracer includes a very cool function called “autovlan” that is enabled by default. You can verify its function by pulling up the VMtracer session as shown below. If vmotion moves a VM from one host to another, the physical network infrastructure tied to the new host must support the same VLANs. This can lead to administrators enabling every VLAN for every host to avoid orphaning an unlucky VM that vmotioned to the wrong host. By using VMtracer, the Arista switch can dynamically add VLANs to switches to support VMs as they move around the datacenter.
Here I run a sho VLAN command to see what is active on my switch. Notice that VLANs tagged with an asterisk have been added to the switch dynamically with autovlan.
Cool, huh?
Never fear, you can reign this in as needed. Let’s say I want to ensure that VLAN 1001 does not automatically populate on my switch for some security reason. I can go back into the Lab VMtracer session and remove 1001 from the allowed-vlan pool:
To confirm that the change took, run sho vmtracer sess.
Now I can pull up the list of VLANs again and confirm that VLAN 1001 is no more.
Pretty cool, right?
There’s a bunch of stuff like this that you can do with the Arista lineup. Time to brush up on Linux!
Packet Wrangling 