It is not every day that you get to create a new network operating system from a clean slate. The last time for me was in November of 2004 when we started EOS. Unencumbered by any installed base whatsoever and armed with lots of painful experience, we set off on a cathartic journey to build it the way we had always wanted it — open, modular, and multi-process. A place where you could install whatever subset of features you wanted. Where you could compile and update just one package at a time. Where you could code up a feature the same way you would on a Linux box, in the privacy of your own address space, without having to compile a 100-megabyte blob and without interference from your colleagues’ buggy software. Where you could install all of your favorite tools and have them just work.
The result is Arista EOS. It turns out that we were right — there is no good reason for a network switch to be a hostile alien being. A switch can be a plain old server with only one material difference: an extra PCI device, the forwarding ASIC, connected to a bunch of ports. But at its core, an Arista switch is really just a server.
Originally, we were a bit selfish about this, focused on making it more fun to develop software for our switch. But I still remember the moment in Februray 2005 when I realized, hey, if treating the switch as a server makes things so much nicer for us (and does it ever), why shouldn’t we open it up to everyone? So we did.
Log into your switch. Grab a shell, sudo bash. Install fping, mrt, ptpd, dhcpd, the tools of your choice. Run tcpdump or wireshark to see the control-plane traffic live. Use vmstat, top, lsof, or strace to see what’s going on under the hood. Kill agents and watch them restart to see if EOS is as resilient as we say it is. If you’re feeling more ambitious, tweak our cli commands or add your own by hacking the python source (it’s right on the switch). After all, it’s your server/switch, you should be able to do what you like with it.
Ken Duda (VP Engineering, Arista Networks)