I’ve been privileged to hear in person Arista Networks present their products to a couple of Tech Field Day delegations of which I’ve been a part, and it’s clear that they know who they are and the market space their product fits into. Arista makes Ethernet switches for data centers. Period.
Now, a lot of other companies make Ethernet switches. Some companies have even rolled their own, or are buying Ethernet switches as a dirt-cheap commodity. That puts a networking vendor selling switches for a premium in a challenging spot. There’s got to be a tangible difference in the product to make it salable to cynics, skeptics, and skinflints, especially if the product doesn’t say “Cisco” on the front.
So what’s the Arista difference? Is it the hardware? Arista gear has desirable low latency numbers and lots of raw forwarding power, but a lot of switch vendors post impressive speeds and feeds. Line-rate is as fast as you can go after all, so when you’re comparing a bunch of line-rate hardware, raw forwarding speed becomes a moot point, at least at L2 where most of the concerns are in the data center.
The Arista product set page or handy Quick Reference Guide PDF will feel immediately familiar to you. Lots of ToR options, in a variety of speeds. A couple of chassis (“modular spine”) switches. In fairness, there is one unusual switch: the 7124FX has a built-in customer-programmable FPGA that can manipulate data-plane traffic for the very special use cases of certain Arista customers. But most of us won’t buy the 7124FX. We don’t need it. And if we’re looking at the balance of the hardware by itself, a purchase order heading to Arista (or not) might come down to a pricing exercise. Back to the original question then – what is the Arista difference?
To my mind, the Arista difference is the positive impact an Arista networking environment can have on day-to-day operations. And that comes from their software. Let’s take a step back for a moment, and consider the elephant in the room. For all the Cisco kit I’ve installed, operated, upgraded, replaced, and maintained over the years, one thing is sure: Tasman Drive has no answers when it comes to ease-of-use, convenience, or modifying operating system behavior to cater to the teams of people that work on the gear. Yes, Cisco has bolted on an assortment of tools (like EEM) that vary in availability by hardware and OS flavor. But the bolt-ons always feel a bit…risky….to this network engineer. A network engineer with any amount of experience with Cisco gear develops a sixth sense about what fancy features to turn on, and what to limit to the whiteboard. Enough tracebacks, memory leaks, and CPU hogs will make one paranoid that way.
So, back to Arista. What’s the foundation of their operating system, EOS? Linux. Yeah. EOS is therefore modular, not monolithic. Processes are isolated from one another. Networking processes run as daemons. And perhaps most importantly, it’s not “Linux” like “Yeah, it’s Linux, but we locked it down so tight that you can’t get at it, so don’t get excited.” Just the opposite is true, in fact. EOS is open to you to do with what you will. Arista even has a whole community built around this concept. Think back to the FPGA in the 7124FX – throwing a chip in the box that the customers can do with what they please is a natural progression of this philosophy of custom extensibility.
Try that with IOS. Or NX-OS. I’m making a rhetorical point…you can’t do it. If you’re a big enough Cisco customer, you can bend the ear of the powers that be to get some feature baked into the OS, but write it yourself? Not going to happen.
What sorts of things can you do with an Arista switch to make your life easier? I think the best way to describe it is to think of an Arista switch as a Linux box running on some sweet hardware that’s really good at forwarding packets and frames lickety-split. This Linux box has all the network sorts of services running already that you’d need like spanning-tree, OSPF, etc. And from there, you can do what you like (read that last link to get the vibe). Run Wireshark or tcpdump? Well, *yeah*. Naturally. And to get your gears spinning, here’s some more ideas from Doug Gourlay’s presentation embedded below:
- “Reload” on steriods. When “reload” is typed, the switch takes a snapshot of the number of MACs it knew, peers it had, which ports were up, LLDP neighbor list, software version running, and (oh yeah) who typed “reload”. Then when the switch comes back up, it shoots an e-mail with a diff so you know what issues to pursue.
- Historical tracking of route flaps or duplicate MAC addresses. You can log changes into an onboard SQL database, so that you can go back to a point in time and have some clue as to what actually happened during a network event. Imagine being able to pull up the routing table from the past as a way to help reconstruct the timeline.
- Determining when traffic was slow and on what ports due to congestion – and maybe even what caused the congestion. That allows the network team to be proactive / offensive instead of getting caught by surprise with every unusual event that gets reported.
You get the idea. From my standpoint, this sort of customizable, extensible functionality is what sets Arista apart and explains why they’ve taken a chink out of Cisco’s armor.
If this way of running a network intrigues you, watch the videos of all of the Arista presentations below. There’s a lot more there that will spin your brain up and get you thinking about the possibilities. REAL possibilities. Practical, useful possibilities. Not pie-in-the-sky SDN possibilities, but tangible, useful ideas that would make your network work better and your life easier in the process.
Disclaimer – I was not paid to write this or to attend Tech Field Day, where the embedded videos were recorded (and where you can see my balding head in some of the shots). Yes, my expenses to attend Tech Field Day were covered, but the point is that this article is my own opinion. There’s no money talking.
About Ethan Banks
