When Arista first launched in 2008, the company presented itself as the nimbler and more innovative alternative to Cisco in the high performance networking space. But in the world of technology, even the nimblest can get out-nimbled. And when it comes to software defined networks (SDN), network virtualization and programmable networks, both Arista and Cisco may find themselves on defense.
Fabric is the most overused term in the networking industry.
Arista has claimed countless big-name cloud provider and financial firm customers with super-fast switching and its Extensible Operating System (EOS), which allows network engineers to program their networks and write completely isolated network segments for applications. But now SDN startups promise many of the same features and may even be able to do so by integrating with less-expensive switching equipment.
Arista had worked to secure its place in the software-driven networking world by partnering with VMware to create technology that links virtual and physical networks for better management and network resource provisioning. It's hard to tell how that partnership will fare now that VMware has acquired network virtualization vendor Nicira. VMware says it will continue to work with Arista and Cisco, but industry pundits predict VMware will become a competitor.
Arista CEO Jayshree Ullal (a former Cisco exec) says that SDN startups have a role in the world of high performance computing and network virtualization, but they will not replace network hardware vendors, and certainly not Arista's organically SDN-driven architecture. What's more, she says the overlay strategy that many SDN companies are pursuing is counterintuitive to IP networking.
SearchNetworking: You used the term "software defined cloud networking" in your blog. What does that mean?
Jayshree Ullal: Virtualization and mobility are driving what we call "cloud networking." It is different than enterprise networking. To make cloud networking capable, you have to build it off a strong software foundation; you centrally manage a cloud and then assign resources. I summarize it like this: the enterprise is about connectivity, while the cloud and software defined networking are more about optimizing transactions and applications.
There has been a disruption that requires a new kind of software answer. No more is there one physical server with one connection; there could be thousands of virtual machines. No longer is storage just storage area networking; now we have Hadoop clusters. Compute is pushing the number of cores from four to 32, and we are anticipating what can be done with tens of thousands of cores and then millions of cores. With such change, the network and the IO is the bottleneck. We need a clean sheet of paper.
Arista's selling point has always been network programmability enabled by our Extensible Operating System (EOS).
SN: Network programmability is now the driving force behind many SDN strategies. How is Arista's approach different than Nicira's, for example?
Ullal: Eight years ago, we had the vision that in order to make the cloud compartmentalized, every process had to run in its own space [with isolation]. Software defined networking talks broadly about separating the control plane from the data plane, but EOS actually micro-segments data planes. Every process has to talk through a database rather than inter-process communication, which is unreliable. This concept of separating the state from the process [and] from the database -- and having a publish-and-subscribe process in our EOS -- is our crown jewel. You don't want to overlay controllers to manage your network, you want the network to be software definable. If the network can't respond with the right partitions, then no amount of work you do on the top will help.
The second [difference] is the protocols themselves. Anyone that tries to invent 20 years of protocols will be challenged. TCP/IP and the Internet and Ethernet have well-defined network behaviors. You don't want to break the network. Software defined networking must be implemented ... adhering to these network standards. Whether its OpenFlow or VXLAN or virtualization or old-fashioned TCP/IP protocols, we can implement them in a more reliable, resilient, extensible, partitionable fashion.
More on software defined networks
Software defined networking is not OpenFlow, companies proclaim
OpenFlow and software defined networking for the campus LAN
Cisco spins its own concept of software defined networking
Cloud SLA-compliance with software defined networking
We can talk to management platforms like HP or IBM where the network is managed along with other variables like storage and compute, or increasingly we can talk to virtualization platforms like VMware vSphere and vCloud Director that look at port profiles and map them to the virtualization environment. A third case is [talking to] OpenStack, which is a new, emerging standard for defining and managing cloud environments.
Controllers connect to a physical switch and they are specific to certain applications. Nicira and Big Switch are trying to address specific applications. The OpenFlow community is trying to define a set of characteristics where they can manage a set of flows and potentially do data tap and port mirroring. They are building an overlay that manages it better. That's what InfiniBand does; it's what ATM did. There's nothing wrong with an overlay network, but it's not doing what mainstream IP is doing.
Nicira is trying to develop a tunneling protocol similar to VXLAN, but its proprietary, and they are [using] a controller to manage it. Nicira is basically making an open virtual switch for [virtual] environments. They took a non-standard approach in taking their own proprietary tag between the Open Virtual Switch [OVS] and the controller. We've demonstrated an OpenFlow client and an OVS client. [Meanwhile] we are showing more VXLAN clients. We look at these as protocols we have to support. We have the right APIs to talk to any controller or management platform. The key for us is that the "E" in EOS stands for extensible -- we have extensible APIs. Our biggest demonstration is what we've done with VMware. For the last three years with the VM Tracer we mapped vSphere and now vCloud Director and we can do easy portability. The work we have to do is to keep adding protocols and adding the right APIs that access controllers and management [tools].
SN:Essentially, Arista will be able to work with any OpenFlow controller?
Ullal: Arista will distribute the OpenFlow protocols in the switch and then the OpenFlow controller can manage multiple switches. If you look at SDN as the protocols, the architecture and the management controllers, Arista will do two out of the three and then work with a broad ecosystem of partners to do the third.
SN: If you move to a centralized controller how does that change the programmability of the individual switch?
Ullal: The fact that we have a distributed programmable EOS architecture makes central controllers even more possible. In order for central controllers to work, they have to collect information from everyone and everything. How do you do that? Either the controller has to go polling every device or the infrastructure platform has to have a publish-subscribe model and give out information in an active fashion. So there is the feeling that intelligent control creates a dumb network, but an intelligent network makes the controller more meaningful.
SN: SDN is at an intersection where some believe it can replace data center fabric and others believe it will work in conjunction with this technology. Where does Arista stand?
Ullal: Fabric is the most overused term in the networking industry. At one level fabric is simply the networking capacity you provide in a switch. The problem is [the term] fabric is now being used for storage and FCoE, etc. What it should mean at a software level is that you have built the right architecture so you can isolate processes.
Getting back to programmability -- there are three levels of programmability. One is management plane extensibility or how you talk to different APIs, whether it be OpenStack or VMware. The second is how you do control plane extensibility inside your physical software -- and this is where most vendors fail. They don't have the access to the existing database or control plane extensibility. The only way to get true control plane network extensibility is to take a state-oriented approach. This way customer extensions can be triggered based on change in the software. The fact that our system database is built on Linux so people can access it and write their own extensions, that's true SDN.
The third level of programmability is the data plane of a network. This is where Arista introduced the first application switch with an FPGA [field-programmable gate array]. [Currently] people use Arista switches or Cisco switches and they have to dedicate an application and a server to get the performance they need. [Data passes] through multiple hops from switch to server to another server, so you get hundreds of microseconds of latency. When Arista [first] built a low-latency switch, we didn't really solve the application latency problem. Now with the FX [application switch] you can take the Linux programming down to a unique environment and you can have consistent switching apps right on the FPGA. You can reduce the latency from tens of hundreds of microseconds to one microsecond.
SN: Is Arista's ability to micro-segment on demand the same as network virtualization?
Ullal: Yes and no. You can do programmable networking and never do network virtualization. The first step to building a software defined network is building the right network topology. The oversubscribed, three-tier architecture [in the enterprise] is gone. It will collapse into two tiers and even then someone will ask if you're building a flat enough network. We have got installed networks now with multipath technology using our software and hardware. You can have a cloud network with multipath technology using EOS features, and then also have a single point of management for all of this. That would all be SDN.
A lot of the use case for SDN is network virtualization. The mass deployment of server virtualization causes people to think about how they can change the network. Today for the most part the [physical] network and the virtual network are separate. This is why VXLAN is so exciting. With VXLAN you can now cross Layer 2 and Layer 3 boundaries and build an extremely large virtual and physical network, and they don't have to be [separate] islands.
SN: But NVGRE and VXLAN are still different from network virtualization. For real network virtualization, you need an orchestration layer, right?
Ullal: If you don't have the right protocol to scale, there's nothing you can show from an orchestration point of view. VXLAN is a protocol that allows you to scale from 4,000 to 16 million VLANs. You still need the orchestration layer and management layer, which is what VMware and Citrix and Nicira are doing to show the movement of VMs and the distribution between the physical and virtual switch. Before VXLAN, you had a virtual switch inside a VM environment and you would vMotion across switches. The VLAN limit was 4,000 -- and in many cases it was 1,000. You were limited to smaller network virtualization orchestration domains. Network virtualization explodes what you can manage and also what you can scale. The scale is done due to the protocol.