Meet your new network admin: The Linux admin (and vice versa)

Last week in InfoWorld’s New Tech Forum, Dinesh Dutt outlined the thinking behind Cumulus Networks’ Linux-based networking solution. The whole piece is a great read, but to distill his point, he makes the case for running Linux on network switches and discusses how Cumulus uses constant inspection of the Linux netlink socket family to modify the actions of ASICs within the switch.

Essentially, you make changes to various network configuration elements within Linux, and those are translated into directives that work at wire-speed across the switch. Thus, the kernel itself is not in the middle of the packet flow, but merely forming the directives to control that traffic.

[ Also on InfoWorld: Your next network operating system is Linux | Get expert networking how-to advice from InfoWorld’s Networking Deep Dive PDF special report. | For the latest practical data center info and news, check out Paul Venezia’s Deep End blog and InfoWorld’s Data Center newsletter. ]

This is a very interesting solution, especially since Cumulus doesn’t use any type of custom UI to achieve these results. Rather than collect all the configuration elements required in modern data center switching within a restricted shell, you manage the box just like any other Linux box.

Want L3 switching and VLANs? Use the 802.1q module and vconfig, and configure routing. Port aggregation? Use the bonding driver or the teaming driver, just as you would on any Linux server. Need OSPF? Go configure Quagga. In fact, the whole idea is that you treat a 52-port 10G switch as a Linux server with 52 10G interfaces.

Naturally, it also blurs the lines between server and network admins.

The old boundaries

On the one hand, most network administrators have been working in what are essentially restricted shells for their entire career. When you log into most switches or routers, you find some form of command-based configuration, with a central configuration file. Everything from IP address assignments to BGP directives live in the same file, and they are configured in the same way using similar syntax. This is how it’s always been, leaving aside those woeful attempts at menu-based network device configuration. Network admins are used to dealing with purpose-built UIs and a high level of consistency between devices.

Linux admins, on the other hand, are used to dealing with a wide variety of interfaces and configuration elements. Depending on what needs to be configured, one package might have a smattering of different configuration files that follow a particular syntax, while a different package will have only one configuration file with a completely different configuration syntax. Changing parameters in /etc/ssh/sshd_config is nowhere close to adjusting a Postfix configuration, for instance. The only commonality is the need for a text editor like vi to make those changes. And using a text editor is much different than logging into a switch CLI and issuing commands for a live application, then saving the configuration.

These differences mean that admins tasked with working on Linux-based network devices, such as Cumulus Networks switches, will have to contend with quite a learning curve. Unless they’re already versed in Linux/Unix concepts, the overall playing field will look wildly different and cause quite a bit of initial consternation. Network admins will know what they need to do in order to implement and configure OSPF, for example, but they might face a significant challenge in implementing those changes. On the flip side, Linux admins will obviously be right at home on the switch, but they may lack enough knowledge of OSPF to make the right changes.

The fact of the matter is that while there’s a wide range of deep networking functionality within Linux, it isn’t used by most Linux admins. The vast majority of Linux servers have an extremely simple network configuration: a few live interfaces with fixed IPs, perhaps a bonded interface here and there. While those servers could obviously handle OSPF and BGP, there’s no need for that, so it’s unused. This is the separation presented by merging these two functions into a real networking platform.

A two-way street

It’s hard to gauge which side would have an easier time assimilating to Linux-based network switching. Clearly, it’s a network admin’s job, and Linux admins should stick with actual servers. That said, the combination of these skill sets provides a benefit to just about all involved. If network admins become more comfortable with Linux administration and Linux admins become more knowledgeable about networking concepts and routing protocols, that can only lead to good things all the way around.

Of course, the upshot of running Linux on network devices is that if you wanted a restricted CLI to handle configuration tasks, you could simply write one. It’s just Linux, after all. Fire up an editor and write whatever you need. The same goes for running other custom code and performing tasks. Want to gather stats, mash them around, and ship them off to a server for processing? Sure. Script it up, throw it in cron.

Ah, but scripting is generally the domain of Linux admins, not network admins, and we see that if networking moves in this direction, we may simply dispense with the distinction altogether. Network admins will necessarily be Linux admins, and vice-versa.

That is a whole new world indeed.

This story, “Meet your new network admin: The Linux admin (and vice versa),” was originally published at InfoWorld.com. Read more of Paul Venezia’s The Deep End blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.