Arista Networks - Their approach to cloud networking

Published in Technology & Innovation

September 01, 2009

5 min read

Intellectual capital driving the cloud

It is wise to follow the movements of thought leaders in Silicon Valley. Why is that? Because when enough smart people land at the same company, it is only a matter of time something great happens. This “human network” of intellectual capital has been the seed of many successful tech companies, and will continue to be true in the future.

One of these tech companies with a wealth of intellectual capital is Arista Networks. There are A LOT of ex Cisco folks walking the halls of Arista. Many of them come from the Granite Systems acquisition (Cisco’s 4500 platform). This platform, while designed with line card oversubscription to keep it between the 3560 and 6500 platforms in price and performance has an extremely elegant internal architecture. Case in point, the 4500 platform has had in service software upgrade (ISSU) for over two years, something that the 6500 still struggles with.

Now that this team, and key leaders from Cisco and other tech companies are putting together a network platform, what can they do? And more importantly, what will they do?

Before I dive into that answer, I think it is important to take a quick overview of the two major camps of network platform development, and what the advantages and drawbacks of each method is.

Creating your own ASICS in house

The first way is to create your own ASICS that handle switching and security functions. In this case, you are effectively a chipset manufacturer, who then bundles your own chipsets into routing, switching and security platforms. On one hand, developing your own ASICS can give you a competitive advantage by rolling in features that are not available to your competitors.

On the downside however because of the high cost of developing these chipsets you are forced to design for a very long lifecycle (7+ years). Another downside is that if you have any problems with manufacturing, you cannot just call up another supplier and change your sourcing strategy because you are that supplier. In the case of any Fab issues you are forced to slip your product delivery dates.

Utilizing market silicon

The second way is to utilize routing, switching, and security ASICS that are commercially available through many manufacturers and wrap your own software and chassis integration around them. This is commonly referred to as “market silicon”. In this case, your focus is end to end integration of commodity ASICS and most importantly creating software differentiation to add value to your product.

The positive aspects of this model is that you are not locked into your own chipset design time lines. If your primary chipset supplier has a Fab issue, then you can easily change your supplier and hit your deployment time lines.

The downsides of this model is that every single networking manufacture in the world has access to the same chipsets. This forces a vendor to differentiate through better software, support, and integration of these “Market Silicon” ASICS into a superior platform.

Who uses what?

With all the talk of Market Silicon being evil, the reality is that the major networking manufacturers use a mix of home grown ASICS and market silicon to drive their products. I can’t say who uses what, but feel free to crack open your switch and take a look at the chipsets on the line cards. Don’t be surprised if you can find some market silicon sprinkled here and there. Now that doesn’t mean that these platforms are bad, it just means that for certain functions it is cheaper to source ASICS externally then to create them in house.

How does Arista approach this problem?

Aristas focus is to create an extensible network operating system that can manage and enable multiple switching ASICS and switching platforms (VMware Virtual Network Distributed Switch - vNDS).

Extensible Operating System (EOS/vEOS)

Arista created a new operating platform, based on Linux that manages both the physical and virtual implementations of switching devices (ASIC and Virtual Switches). It is called the Extensible Operating System. This operating system has hooks into all the ASICS and vSwitches that it supports. Most importantly it provides one single operating system for all supported platforms both physical and virtual.

sysDB

Core to the functionality of EOS is the sysDB. What is the sysDB? It is a custom real time database written specifically for the interaction of individual system processes. These include routing, switching, security, management processes. By centralizing all of this information in a central location the time to react to events is minimized. This is especially true when compared to classic networking implementations where independent processes keep independent state.

vEOS

Virtual Extensible Operating system is just that - A virtualized instance of the items mentioned above. This can be run inside a VMware virtual machine. It is the same operating system, database, and daemons that run on Arista’s physical hardware. The only difference that it happens to run inside of your virtual infrastructure.

You may ask the question, why would you want to take a network operating system / hardware combination and split it apart?

vEOS and VMware Virtual Distributed Network Switch

EOS and vEOS have implemented a hook into VMware’s vNetwork Distributed Switch (vNDS) API. In effect, you can think of the vNDS as just another ASIC to the operating system. Instead of connected through a device driver, EOS and vEOS connect in through an XML API. This accomplished the function of both retrieving status and performance information that the vNDS provides, and creating policies inside EOS and publishing them into your VMware switching infrastructure.

If you have an Arista switch directly northbound of your ESX servers, you get this monitoring and configuration feature for free. If you don’t have Arista switches, (say you have Cisco, HP, Juniper or Foundary) you can use vEOS (the virtual instance) and pay a fee to get a CLI interface into the VDS.

vEOS vs Nexus 1000V

This is a likely to be a highly contested item, complete with competing bumper stickers. In my opinion it isn’t that big of a deal. The reason being is that the 1000v and Arista’s vEOS implementation are completely different. Cisco’s 1000V is a dedicated piece of code running on your ESX servers that handles switching differently then VMware’s vNDS. Arista’s implementation of EOS and vEOS is more of a management interface to VMwares vNDS. vEOS does not replace the switch inside VMware, it configures and monitors it through the vNetwork API.

When comparing the two products head to head, the discussion is really a VMware vNDS vs Nexus 1000v discussion. If you have already decided to move to the 1000V because of the feature differential between the native vNDS then nothing really changes.

This doesn’t mean that vEOS does not add value. In smaller environments where the 1000V is not an option, or in an intercloud situation where state needs to be passed between disparate network instances vEOS’s vNDS implementation can be very valuable. If the vNDS features are all you need, but you would prefer a CLI for your VMware switching and cannot justify the expense for the 1000V licenses, then Arista might be right for you.