Your Next Network Operating System Is Linux

jrepin writes "Everywhere you look, change is afoot in computer networking. As data centers grow in size and complexity, traditional tools are proving too slow or too cumbersome to handle that expansion. Dinesh Dutt is Chief Scientist at Cumulus Networks. Cumulus has been working to change the way we think about networks altogether by dispensing with the usual software/hardware lockstep, and instead using Linux as the operating system on network hardware. In this week's New Tech Forum, Dinesh details the reasons and the means by which we may see Linux take over yet another aspect of computing: the network itself."

Comments

2013 Year of the Linux Network

[Anonymous Coward]

If you can't make your goal just change the goal posts.

Re:2013 Year of the Linux Network

[robthebloke]

But all I want to know is, will sudo rm -rf / delete the internet?

Re:2013 Year of the Linux Network

[swilly]

sudo rm -rf / won't delete anything.

POSIX rules state that you cannot remove any parent of the current directory. The GNU rm command doesn't fully check this, but it does make sure that you don't remove / or .. (but if you give the path to any other parent directory, it will let you remove that). Try it for yourself and see (in a VM of course).

Doesn't matter

[Drewdad]

Network and SAN will go (are already going) virtual the same way hardware has.

Re:Doesn't matter

[Anonymous Coward]

Hey, why don't we move all of those cables and monitors and keyboards and mice into "the cloud" too. I saw some marketing presentation which says everything can go into the cloud. I'm not sure why anyone buys computers or even pays for electricity any more... just put it all in the cloud!

Re:Doesn't matter

[funwithBSD]

Electricity has always been in the cloud.

And this is news why?

[Anonymous Coward]

Did "Dinesh" just crawl out from under a rock?

Re:And this is news why?

[kijiki]

The big difference is that there is a hardware forwarding chip involved. A PC with 10G NICs is hard pressed to forward at 80 Gbit/sec, and draws a couple hundred watts. The 1U switches Dinesh is talking about can do 1.28 Tbit/sec with all features enabled, and draw around 100 watts.

- nolan
CTO/Cofounder, Cumulus Networks

Already happening - slowly

[Anonymous Coward]

Linux is already widely used on networking gear, especially fully pre-emptive variants like RT-Linux and Monta-Vista.

It will still take considerable time to displace some of the real performance/uptime critical stuff that's done using VxWorks and QNX and a number of other proprietary systems. Many companies are sort of vendor locked and have non-portable software too and so can't change easily. There are also engineers out there who strongly believe that what the currently use is superior for things like uptime (QNX), and simplistic hard real time response (VxWorks). I'm not saying that's the case either way - I'm simply saying there are numerous industry players who won't adopt Linux for some time because they think it's too big and not good enough.

Re:Already happening - slowly

[LoRdTAW]

Xenomai is already a threat to VxWorks as it supports the VxWorks API as well as its Native API, POSIX, uITRON and a few other RTOS API's. The current version is a dual kernel system with the Xenomai kernel running at priority but the next version will integrate with PREEMPT_RT which will expose its supported API's to PREEMPT_RT so you can run either kind of system.

Re:Cisco isn't going anywhere, yet

[Anonymous Coward]

Cisco is already there...

The heart of most of the "new" os's that Cisco is using is a modified linux kernel... I.E. NX-OS, IOS-XE, IOS-XR, CGR... Almost all the security platforms, ASA, ISE... etc...

Apollo Computer - Domain Operating System

[tedgyz]

Sadly, Apollo Computer had this concept 20+ years ago. The Apollo Domain Operating System was built from the ground up as a network operating system. Everything from the kernel up was designed with networking in mind. It was a brilliant yet ultimately dead operating system. The biggest downfall was being expensive and proprietary. Sun Microsystems won through a cheaper alternative and doomed us forever with NFS.

Re:Apollo Computer - Domain Operating System

[rwyoder]

Sadly, Apollo Computer had this concept 20+ years ago. The Apollo Domain Operating System was built from the ground up as a network operating system. Everything from the kernel up was designed with networking in mind. It was a brilliant yet ultimately dead operating system. The biggest downfall was being expensive and proprietary. Sun Microsystems won through a cheaper alternative and doomed us forever with NFS.

I had the misery of working with Apollos at one employer.
There were two major issues in my opinion:

1. Security: There wasn't any. If you logged into just *one* host, you could change ANYTHING on ANY OTHER HOST.
        Imagine NFS-exporting "/" read/write to the world.

2. There was an environment variable that could be set to mimic either SYSV Unix, of BSD Unix.
        The reality was it didn't emulate either, making attempts to compile/run open-source sw an exercise in futility.

Network fabric != shell scripts

[mlts]

As it stands now, a Linux iptables list is sequential. Packets go through the input/output/forward queues.

If one wants a true network OS, this needs to be changed to a config-based system similar to what Cisco/Alcatel-Lucent/Juniper use. With this, each adapter gets a configuration attached for starters, then things go from there (VLANs, ACLs, etc.)

If Linux could make the jump from sequential parsing to configs, it might just be something that can do the job, but then it moves to the hardware, and a lot of routers have specific ASICs dedicated to packet crunching as opposed to general CPUs.

Re:Network fabric != shell scripts

[CRC'99]

each adapter gets a configuration attached for starters, then things go from there (VLANs, ACLs, etc.)

iptables -N eth0-in
iptables -N eth0-out
iptables -A FORWARD -i eth0 -j eth0-in
iptables -A FORWARD -o eth0 -j eth0-out

Then create all the rules you need in the specified chain.

The way to get the most performance out of iptables is to make each chain as small as possible. This can quite easily be split up into logical lists for what you actually do - ie:

iptables -N 10.1.1.1
iptables -N 10.1.1.2
iptables -N 10.1.1.3
iptables -A FORWARD -i eth0 -d 10.1.1.1 -j 10.1.1.1
iptables -A FORWARD -i eth0 -d 10.1.1.2 -j 10.1.1.2
iptables -A FORWARD -i eth0 -d 10.1.1.3 -j 10.1.1.3

This way, you can easily branch out and skip a fuckton of rules that will never apply to the packet that is being processed. Usually, you can bring each chain to less than 6 rules. Less rules == less overhead == more performance.

Re:Juniper uses FreeBSD

[jhealy1024]

On Juniper, you can even get shell access by default (log in as root). The "command line" interface is just a program that runs on the shell.

Not only that, but Juniper's configuration is not as "modal" as the article makes everything out to be. JUNOS has built-in scripting to make modifications to the config, along with templating/macros to take the drudgery out of repeated configs. The config is hierarchical (XML on the backend), which makes it well-structured and predictable. Overall, it's a pleasure to work with (once you get used to it), and much better than some more popular/expensive networking gear I could name. Oh, and they number their interfaces starting with zero, like you should. ;-)

Sure, it's not as open as a bash shell that you can muck with to your heart's content, but at the same time, having a standardized toolset means that it can be reasonably supported. Can you imagine calling up level 1 support and asking them to help you with a system that you had fully customized with local scripts, cron jobs, and the like?

Stating the obvious

[EmperorOfCanada]

I think many slashdot'rs will read this as "Your next network will use electricity." I am pretty sure most people around here have networks that are close to 100% Linux. Maybe the occasional switch or whatnot is running something proprietary.

Re:Bah

[Anonymous Coward]

BLAH, BLAH, BLAH...it's succeeding in becoming its fanbois worst enemy's mirror image: Ubiquitous, inescapable, and actually dragging us all down because of that. Including hysterical over-the-top marketing from both.

We need more, better choices, not yet another rehash of this same thing. This isn't innovation. This is stagnation. Useful, nicely low cost, but stagnation for all that.

I don't think that is true. Like the joke about the duck (all quiet up top, but paddling like heck underneath), Linux is continually evolving. Sometimes big steps and big improvements and sometimes small steps. Sometimes even steps that back up and take another direction. That's a feature, BTW. The Linux ecosystem has shown over and over that nothing is sacred. If there is a better way to do things then somebody somewhere is going to try it with Linux.