Man is a tool-using animal. Without tools he is nothing, with tools he
is all. – Thomas Carlyle
The most satisfactory definition of man from the scientific point of view is probably Man the Tool-maker. – Kenneth Oakley

The Artist and the Scientist both agree that tools are an integral part of what it means to be human. Even human history is divided into ages based on the power and sophistication of the tools: Stone Age, Bronze Age, Iron Age and now, Information Age. Our capabilities are enormously magnified by the tools we have at hand.

A server admin has the tools to manage 100,000 servers fairly easily, while the network admin struggles to manage a small fraction of that size of networking equipment. In the modern data center, where scale, agility and flexibility are part of its DNA, this lack of netadmin tools is a major hurdle in the operation of the data center. Subsequently, a big part of the transformation and turmoil in networking today is an attempt to get rid of this limitation.

Among the tools the server admin has at his or her disposal, automation is key.  It is impossible to manually manage devices at the scale and speed of the modern data center. What makes automation so hard you ask. What sort of magic does the server admin have that the network admin does not ?

Consider a simple enough task that any admin has to manage, an image install or upgrade. Using PXE or some modern variant of it, the server admin can install a new OS image on as many servers as they desire. For a network admin, it’s a horrendously laborious manual process. Furthermore, package management tools enable a server admin to upgrade individual applications or utilities without upgrading the entire image and rebooting the box. Network admins can mostly just dream about this.

Or consider monitoring. Syadmins have a vast array of tools to monitor thousands of application instances, whether it be a general tool such as ganglia or an application’s own inbuilt monitoring.  People can even write their own extensions or programs that gather data that is relevant to them in their context rather than something predefined by others. On a router, until recently, SNMP has been the only monitoring choice; sFlow, more specifically some vendor-specific variant of it has been the only new addition. Furthermore, for monitoring processes and processors, every vendor has their variant of the tool for the job. Transparency of what can be monitored is another issue, not just how.

Configuring a router or a switch makes the picture only more lopsided. Server admins have a plethora of sophisticated and mature tools such as Puppet, CFEngine, Ansible, and Chef. Something so trivial as the CLI is vastly different in scope and power between a server and a switch. Given their original limited capabilities, routers and switches have a modal CLI where what you can type is determined largely by where you are in the parse tree. In other words, even the shell is meant for manual typing, not automatable scripts. In Linux, a shell is designed from the ground up to be programmable. However, it lends itself quite well to manual work as well.

So, whats to be done ? Declaring network admins persona non grata doesn’t fix the problem. Declaring networking is completely broken is a rather convoluted way to view the problem. Routing and bridging work fine, thank you. For most network engineers behind every successful solution is a protocol. So, we see solution with proposals for new protocols to solve the problem. But many of the problems are not protocol problems. As the server admin tools have ably demonstrated, the problems can be solved with an agent or without. Using protocols and tools at hand, not inventing new ones.

We can unify the tool kits, leverage the innovation, and eliminate the unnecessary complexity of innovating, developing, and managing two different toolkits. The operating system defines in large part, the way we interact with the system, be it a server or a router. And reasonable people agree that a key reason for the sophistication, innovation and maturity of server admin toolkits comes from the server operating system, Linux. So a simple, elegant way to empower the network admins, is to make Linux the OS that powers the routers and switches.

Cumulus Linux does just that. It provides the missing piece in the networking revolution. It provides a native Linux experience for routers and switches, enabling network admins to successfully adapt the tools that server admins use, to managing networks. By making the native Linux mechanisms and abstractions the way to interact with the networking boxes, users are not held hostage to any vendor’s API or interface. As network admins grow in sophistication with Linux, they can even write apps or python (pick your favorite language) scripts to customize management. Heck, you can even compile programs on a router running Cumulus Linux. By allowing the users to control and choose the way they interact with the system, Cumulus Linux becomes an enabler of the networking ecosystem, not a gatekeeper.

Empowering network admins with tools is an integral part of the transformation of networking. And Cumulus Linux shows how this can be done without inventing new tools or tearing apart networking as we know it.