This week Arista announced three new applications for its Extensible Operating System (EOS), which is the software that runs Arista's network switches. The applications--OpenWorkload, Network Telemetry and Smart System Upgrade--integrate with third-party programs such as VMware NSX, F5 and Splunk.
Arista is taking a page from the SDN playbook by providing a programmable switch environment and creating applications that let network administrators solve real-world problems.
I'll go so far as to say that EOS is Arista's raison d'être. I don't mean to diminish Arista's high port density, low latency and reasonable cost of acquisition, but let's face it: That's an off-the-shelf silicon product that anyone who put their mind to it could build. (And some have.) Arista's magic is in EOS--not just what the switch can do, but in how a network operator can make that switch do what is required.
EOS is also more than just a cool CLI. I understand that the CLI is the primary configuration tool for most network engineers. I've spent thousands of hours at various CLIs programming switches, routers, firewalls load balancers, and so on. I used to pride myself on my "CLI-fu."
But you know what? At the end of the day, I have tasks to complete: build a VLAN, create a routing adjacency, apply a stateful filter, and so on. While accomplishing such tasks via CLI indicates a degree of skill, the fact is network automation should take the place of the CLI for as many tasks as possible.
I don't want to be the guy writing hundreds of lines of vendor-proprietary CLI commands in preparation for the next round of network maintenance. I want to build a network fabric once, be done with it and automate the rest.
[It's easy to get caught up in the technical details regarding SDN, but don't lose sight of the overall goals. Find out more in "SDN Is A Use Case, Not A Technology."]
The desire for full network automation is idealistic, of course. Network engineers know the devil is in the details, and in networking, there are lots of details. Every network is different as a result. Even so, I believe there's enough commonality among disparate networks that automation can progress. Arista hopes to prove it with three new applications.
The OpenWorkload application facilitates automatic provisioning of the network underlay to support virtual machine mobility in the data center. Most notably, OpenWorkload is the connector between EOS and VMware NSX. NSX is the virtual networking platform announced at VMworld this week, and Arista partnered with VMware to integrate NSX and OpenWorkload. OpenWorkload will also integrate with OpenStack.
Arista points out a number of key network operations tasks that OpenWorkload automates. The company describes them in the context of the hypervisor and the software driving it. Here are a few of them.
--A controller instantiates a new virtual machine. OpenWorkload provisions the VLANs and tunnel endpoints (VTEPs, which are required for an overlay network) on the network hardware.
--A controller maintains a database of MAC address-to-VTEP bindings. These bindings are how hosts are contained in a particular overlay network. OpenWorkload automatically syncs this data to the network hardware.
--A controller moves a virtual machine from one cluster to another, which can happen for many reasons. OpenWorkload ensures that the destination network switch is provisioned to support to the move.
Operational automation is obviously a key point here. Performing these tasks by hand would be error-prone, with a potentially long lead time bogged down by corporate processes. Automation reduces that risk and lead time.
But Arista has another point to make with OpenWorkload: The network contains valuable information that higher-level applications could benefit from, so make that information available.
For example, when moving a virtual machine, a virtualization administrator can look at utilization of cluster resources and decide the best destination for that VM. But the network utilization is usually not a part of that equation. The LANZ+ component of OpenWorkload provides congestion information, so that an administrator can make a fully informed decision.
In another example, the pathTracer element of OpenWorkload monitors flows across an equal cost multipath network fabric, and can determine any degradation of quality in a given path. Any engineer that's bashed his or her way through router and switch hashing algorithms to determine the exact physical path a flow has followed can appreciate the benefits presented here.
Expanding on the idea of sharing network data, Arista's Network Telemetry application feeds detailed network performance data into partner applications to automate fault detection, isolation and resolution. Here are the two examples that interested me the most.
First, Arista partner Splunk accepts sFlow data (similar to Netflow data for Cisco-oriented folks) and generates per-flow analysis.
Second, real-time network analysis vendor ExtraHop partnered with Arista to take advantage of Arista's Data ANalyZer (DANZ) to capture data with precision time stamps. The promise of this application is effective monitoring of an entire data center's L2-L7 infrastructure before, during and after a change. Considering the volume of data that goes through a data center, this is a useful achievement.
Next page: Smart System Upgrade