Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Networking Operating Systems The Internet Linux Hardware

Your Next Network Operating System Is Linux 192

Posted by timothy from the it-even-runs-on-computers dept.
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."
This discussion has been archived. No new comments can be posted.

Your Next Network Operating System Is Linux More

Your Next Network Operating System Is Linux

Comments Filter:

  • 2013 Year of the Linux Network (Score:4, Funny)

    by Anonymous Coward on Sunday October 20, 2013 @07:21PM (#45184391)
    If you can't make your goal just change the goal posts.

  • Doesn't matter (Score:5, Interesting)

    by Drewdad ( 1738014 ) on Sunday October 20, 2013 @07:21PM (#45184401)

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

    • Re:Doesn't matter (Score:5, Funny)

      by Anonymous Coward on Sunday October 20, 2013 @07:32PM (#45184475)

      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: (Score:2)

      by nurb432 ( 527695 )

      They have been for a while now, if you wanted to pony up the cash and live on the bleeding edge But regardless of that, there is still an OS of some sort pushing those bits around, be it on virtual hardware or real.

      • Re: (Score:3)

        by msauve ( 701917 )
        There hasn't been "an OS of some sort pushing those bits around" for quite a while. OS's handle the control plane. The forwarding plane has been microcoded hardware for a decade or more, depending on how you define/count it.

  • And this is news why? (Score:4, Insightful)

    by Anonymous Coward on Sunday October 20, 2013 @07:21PM (#45184403)

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

    • Re: (Score:2)

      by ls671 ( 1122017 )

      Yeah, Linux is my Network Operating System since 1997. No kidding.

      • Re:And this is news why? (Score:4, Informative)

        by kijiki ( 16916 ) on Monday October 21, 2013 @01:52AM (#45186037) Homepage

        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

        • Re: (Score:2)

          by ls671 ( 1122017 )

          Hmmm... My dual core router with 3 NIC card in it is drawing 70 watts. The power supply is actually 450 watts but if you take care of actually measuring the power draw, you might find that you are overestimating a bit...

        • That's the aspect that I was curious about (and about which TFA gave me no useful insights whatsoever):

          Unless things have changed radically since the last time I ripped the top off a switch (purely for diagnostic purposes, boss, really), you've got your weedy little application processor that runs some unpleasant, approximately UNIXlike, proprietary embedded OS, whose sole purpose in life is to handle interactions on any config interfaces (local serial, SSH, SNMP, maybe a web page or vendor-proprietary '

  • Already happening - slowly (Score:5, Interesting)

    by Anonymous Coward on Sunday October 20, 2013 @07:23PM (#45184415)

    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 (Score:5, Interesting)

      by LoRdTAW ( 99712 ) on Sunday October 20, 2013 @09:22PM (#45185043)

      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.

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

      And if we follow the trend, pretty soon we'll be running Windows on those routers!

      Don't laugh too hard, we already have Windows for Workgroups to replace Netware, Windows Web Server [microsoft.com] to replace Apache/Linux, and even Windows for Warships [slashdot.org] to replace, uh, sanity... Windows for Routers [wikipedia.org] isn't too steep a slope.

      • Except windows has been actually removing some network functionality as time goes by. For example, Windows Server 2008 R2 removed support for OSPF, ISIS was removed sometime before that, and I'm fairly certain that 2012 only supports RIP.

        • Re: (Score:2)

          by smash ( 1351 )
          Well, Windows might be able to keep up with RIP.

          • Re: (Score:2)

            by Z00L00K ( 682162 )

            And RIP should go where it stands for - Rest In Peace.

            But if they keep that protocol it just means that it is simple enough for coders at Microsoft to understand and that they don't understand the other protocols.

            It's still pretty interesting that RIP is still in use even though it was seen as outdated 20 years ago...

            • Re: (Score:2)

              by smash ( 1351 )
              Yeah, i've never actually seen RIP used outside of the lab either, other than maybe on crappy home user networks. But most of those are so brain-dead simple that no routing protocol is required. I just find it hilarious that somebody decided to write an ipv6 capable version of RIP.

        • I'm sure the three remaining users of IS-IS were disapointed.

          I'm guessing OSPF was taken because Windows is just too heavyweight for a router, really. With linux you can easily enough strip it down to an absolutely minimal system - important not just to reduce memory footprint, but to make sure you don't lose performance when some OS service decides it is time to kick in and update something and minimise attack surface. Even the GUI-less varients of Windows Server are still pretty big and complex.

      • If I every get my Madcat II and that fucker runs Windows, I am gonna be pissed.

    • Re: (Score:2, Interesting)

      by Anonymous Coward

      High end networking gear (read datacenter switches) don't care about hard real time (or even soft real time). That's because it would be insane to switch packets in software. Yes, Linux or a BSD variant is already used in a lot of network operating systems - most of the modern network operating systems are in fact built on top of Linux (Arista EOS, Cisco NX-OS, Cisco IOS-XE for e.g.) or BSD (Juniper JunOS). The key difference is the degree to which the underlying operating system gets exposed to end users.

      • Re: (Score:3, Insightful)

        by kijiki ( 16916 )

        It is open source, except for a userspace device driver for the forwarding ASIC. Without the driver, everything works the same, you just don't get hardware accelerated forwarding, only the normal kernel softward forwarding.

        You can get the patches against Debian Wheezy here:
        http://oss.cumulusnetworks.com/ [cumulusnetworks.com]

        The biggest difference vs EOS is that if you want to add a route to the routing table in EOS, you have to use sysdb-specific commands/APIs. With Cumulus Linux, you use "ip route add" or any other program t

    • Why not?

      The internet is just a series of pipes, just like UNIX...

    • Re: (Score:2)

      by jon3k ( 691256 )
      Even more mainstream than that, Cisco IOS-XE is just linux running IOS as a module. Not to mention Arista is entirely Linux.
  • It's hard to beat free.Wish the article had touched on "traditional tools" a little more. They didn't really go into specifics. I've got some experience there, but it would have been nice to see their take on it.

  • Not news (Score:3, Informative)

    by ihtoit ( 3393327 ) on Sunday October 20, 2013 @07:30PM (#45184459)

    The Chinese have been using Busybox for years. I still have two routers that use Busybox - the Swiss Army Knife of embedded Linux.

    linky [busybox.net].

  • Juniper uses FreeBSD (Score:4, Insightful)

    by DiSKiLLeR ( 17651 ) on Sunday October 20, 2013 @07:37PM (#45184499) Homepage Journal

    Juniper uses FreeBSD as its OS? NetApp uses FreeBSD (or at least a heavily customized version of it.)

    Not everyone has gone with Linux but I suppose the majority have. Still, as long as its Unix embedded and not something crazy like Windows...

    • Re:Juniper uses FreeBSD (Score:5, Interesting)

      by jhealy1024 ( 234388 ) on Sunday October 20, 2013 @08:08PM (#45184683)

      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?

    • In terms of big stuff Juniper and Cisco are the kings. When you look at enterprise networks, they comprise the most by far. Well, neither of them use Linux. Juniper uses FreeBSD as the basis for JUNOS. Cisco's IOS, that most of their devices still run, it really is their own operating system. It is slightly POSIX-based, I suppose, but not really related to anything else. IOS XR is based on QNX a real-time operating system. That accounts for most of the high-end and even more midrange network gear out there.

      • IOS-XR is migrating to Linux in the next major release, NX-OS (the OS for their Nexus DC kit) is built on Linux, and IOS-XE which powers most of the smaller side of new Cisco kit is also Linux.

        As for Juniper they also have many products running on Linux.

    • Re: (Score:2)

      by Z00L00K ( 682162 )

      Most are going for Linux instead of an embedded proprietary solution like their own OS/software.

      What you put on top of Linux is another issue - it can be a web UI or you can probably run the Cisco IOS command interface too for those that prefer that.

      Even in cars Linux is used - some use it in the instrument cluster, but have removed the command line capability.

  • Cisco isn't going anywhere, yet (Score:4, Informative)

    by grahamsaa ( 1287732 ) on Sunday October 20, 2013 @07:44PM (#45184541)
    As much as I would like to see Linux / BSD being used to power network devices (and I admit that it's already happening), it's going to be a long time before most enterprises ditch their Cisco gear for equipment that runs an open source OS. Many large enterprises have already made significant investments in hardware and personnel. Even if a vendor were to come along with an excellent product at a great price point it would probably be at least 5-10 years before most enterprises move away from their Cisco switches, routers and other appliances. Don't get me wrong -- I'd like to see Cisco's dominance challenged, and to see a Linux / BSD based CLI used to configure network equipment instead of IOS -- but it seems unlikely in the near future.

    • Re:Cisco isn't going anywhere, yet (Score:5, Informative)

      by Anonymous Coward on Sunday October 20, 2013 @07:49PM (#45184561)

      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...

    • Cisco is already ahead of you there.
      Cisco's NX-OS is based on Linux, but with a IOS-like CLI on top of that.

    • Re: (Score:2)

      by LoRdTAW ( 99712 )

      Juniper Networks network operating system, JunOS, is based on FreeBSD but proprietary.

    • Re: (Score:3)

      by CAIMLAS ( 41445 )

      As much as I dislike them, Juniper switches (which run FreeBSD, iirc) seem to be pretty damn common these days.

      Enterprises won't move from Cisco for quite some time due to the institutional knowledge requirement: they've got a lot of equipment which requires people to maintain.

      In a recession or depression like we're in, things like network infrastructure changing is uncommon. The big companies don't change things because change is risky and expensive (unless change is their business, such as in IT). Upheava

    • That high-end networking gear usually outperforms any PC simply by having hardware designed for it. Switches have real CAM in their chips rather than having to awkwardly handle it in software, and routers likewise have hardware implimentations of routing decision-making. Software handles the routing protocol, but hardware decides where the packets actually go based on the resulting tables.

      It's the low-end and mid-range, SOHO-like things, where linux can get in and offer the advantages of commodity hardware,

  • Apollo Computer - Domain Operating System (Score:5, Interesting)

    by tedgyz ( 515156 ) on Sunday October 20, 2013 @07:56PM (#45184613) Homepage

    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: (Score:2)

      by Skapare ( 16644 )

      I remember contacting that company about their system, and specifically asked about open source. I talked to some guy who was the sales manager for my area, and he seemed to get angry that I was asking for open source. I think that company was doomed by bad management.

    • Re:Apollo Computer - Domain Operating System (Score:5, Interesting)

      by rwyoder ( 759998 ) on Sunday October 20, 2013 @09:22PM (#45185041)

      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.

      • We had time clock problems with our Apollo Domain systems, and there was no fix from Apollo - we had to avoid letting the year change. I can't remember if it was something like the Unix 2038 problem. Anyone remember that?

        • Incidentally, if you use one of those 'Magic Planet' display globes... when 2038 hits, roll back the clock. They suffer from it.

        • Yes. It hit right after Thanksgiving in 1998. Our vendor warned us 3 weeks before the deane, the bastard.

          The problem was a date issue where some of the system used signed dated and other unsigned. When it booted on the magic day one part thought it was something like 2100 B.C. and was waiting for 1998 before continuing on.

          Luckily where I worked had replacement Solaris systems sitting in a corner waiting for someone to find the time to set them up.

          • Thanks for the reminder. We weren't given much heads up time either. After that we went with a Solaris/HP-UX mix over ethernet, and we kept a couple of the Apollo Domain systems separate from everything else on their original token ring for legacy testing of app code by developers. The coders didn't care why the underlying machines and network had changed, so we felt that the transition had gone quite well.

            I think this was probably the reason why Apollo Domain could not survive: with the state of mainstream

    • Re: (Score:2, Insightful)

      by Gothmolly ( 148874 )

      You realize that NFS and iptables have almost nothing in common right? Oh wait, you DONT, else you wouldn't have written such a crap post.

    • I remember taking out a 21" apollo monitor with some friends for a night of shooting. (We wanted some fun stuff to blow up). That freaking monster took a 9mm at 15 yards... took several other smaller/slower calibers too. The 357 finally pierced the glass. I think they were so expensive because they were made of transparent aluminium. (Originally designed to hold large volumes of water in space ships)

    • Re: (Score:3)

      by LDAPMAN ( 930041 )

      There was another OS 20+ years ago that was designed from the ground up as a network OS...Netware!

  • Network fabric != shell scripts (Score:5, Interesting)

    by mlts ( 1038732 ) * on Sunday October 20, 2013 @07:58PM (#45184627)

    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.

    • All those configs get compiled down to sequential operations eventually. Some vendors have added configuration layers above linux. I've got an all-linux network core at home (Netgear, OpenWRT, Mikrotik) with each flavor having its own layer on top of the kernel.

      I must admit that my edge router/firewall is BSD, but with NFTables that might be up for a change.

      Granted, these aren't yet available on big iron, but the universal truth in tech is that the low end always eats the high end, so that's a matter of t

      • Re: (Score:2)

        by Bengie ( 1121981 )
        I wouldn't jump the gun too fast. FreeBSD just had a new network API added in 10 that doubles the packet throughput of legacy when using a wrapper and over 10x the throughput when using native. A single core ATOM cpu could handle full duplex routing of a 10gb interface while running in user mode, outside of the kernel.

        The new interface will allow crazy low overhead for usermode programs to access the NICs.

        • A single core ATOM cpu could handle full duplex routing of a 10gb interface while running in user mode, outside of the kernel.

          Whoa. </Neo>

          • Re: (Score:2)

            by msauve ( 701917 )
            You realize the GP is BS, right? Sure, a 64b processor at 2.5 GHz could copy 10Gb of full duplex data between 2 ports using 50% CPU while doing nothing else. But add the overhead required for control plan, then consider that a 2 port router is pretty useless (not much more than a bridge), and there's no meat.

            For a practical real world non-trivial router, you need 10s or 100s of ports. Now picture both control and forwarding planes which allows 10s or 100s of such CPUs to coordinate resources for both decis

            • As routing is all kernal level, there shouldn't be any copying. Packets go in to memory via DMA, and come out the same way. Number of packets is more important than number of bytes, CPU-wise. Which is all the more reason to get everything running jumbo frames properly and get rid of the 1500-byte legacy of 10base5.

        • Re: (Score:2)

          by jon3k ( 691256 )
          Just routing doesn't prove anything. ASICs are designed with a specific set of features based on the platform requirements. Routing (or really, multi-layer switching) is just one. Let's see them load up a bunch of additional features, you can start with just VACL and port mirroring.

    • Re: (Score:3)

      by Skapare ( 16644 )

      Config-based does not mean sequential or non-sequential. It only means whatever is configured can be changed. What is needed to improve iptables and the like is optimizations like smart address lookup tables. This is actually doable in ways that have been around longer than patent periods but it is not iptables compatible.

    • Re:Network fabric != shell scripts (Score:5, Informative)

      by CRC'99 ( 96526 ) on Sunday October 20, 2013 @08:51PM (#45184915) Homepage

      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.

    • Most current high available networking gear has an OS on a "general maintenance processor" that is used to handle the user interface. All the packet mangling is done in ASICs or on daughter boards running other OSes.

      Also, IPtables isn't a shell script, it's a binary that is used to manipulate kernel network filters. Once the tables are set up, packets don't leave the kernel, unless you use the userland filter kernel module. I've only seen one commercial linux packet mangling setup that does this and it per

    • Good thing iptables is being replaced with nftables, I guess.

  • Stating the obvious (Score:5, Insightful)

    by EmperorOfCanada ( 1332175 ) on Sunday October 20, 2013 @08:32PM (#45184805)
    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.

  • Buzzwordy market-speak summary pointing to the personal blog of an unknown company?

    Thanks, Timothy.

  • Back in the day, a network operating system was something that could run a file, print, and sometimes database services. Nowadays when the firmware of printers and NAS devices provide those services, I question the use of the term NOS at all.

    Sure you can use different firmware bases for network hardware, but it's not like you can arbitrarily install whatever you want on such devices.

  • So this is the year of the Linux "everything except the desktop": phones, tablets, networks, servers, entertainment units, cars, everything with Android, etc... even your Chromebook. But not your desktop.

    Yet.

  • Too commercial. Add news or something that matters?

  • Sorry, I can't find anything of substance in this (worthless, InfoWorld) article. There's a handful of reasons why "Linux will be the next network OS" isn't holding any water:

    * First and foremost, it's the license. No hardware vendor out there wants to be stuck supporting software in the way that a GPL'd product often requires. They want to control the platform, and they can't do that if it's truly open.
    * Second, Linux has had iptables (and the menagerie of other tools) to make it a 'network OS' for years a

  • Linux, not likely... (Score:3)

    by David_Hart ( 1184661 ) on Monday October 21, 2013 @12:39AM (#45185807)

    Customized UNIX kernels are being used today (mostly BSD) by a variety of vendors. These are heavily modified to support hardware (ASICS, etc.) based switching and routing. On top of that the OS needs to handle packet caching (for QoS), access lists and security features, encryption (VPN tunneling), etc. Most of which are handled in highly customized proprietary bits of hardware that can reliably handle a tonne of traffic flows. In my opinion, network hardware vendors will never hamstring their competitive edge by agreeing to standardized APIs and hardware calls.

  • In 2000 my next operating system on network hardware was linux. In 2013 it's looking just as likely to be FreeBSD.

    Did this article travel down a wormhole from 2000?

  • But one point dwarves everything else...

    Really? Not even if you're Walt Disney.

    "Dwarves" is a plural NOUN, but the author's use was as a VERB. That should have been "dwarfs", as in "makes small".

  • Linux is good for some things but as a network OS, OpenBSD is far better for security and routing. I would use Linux maybe as an internet server or desktop OS but OpenBSD hands down for anything security and network related. The Linux kernel may have a fast robust network stack but it's tool chain is an ineffective quagmire of different projects with different leadership. OpenBSD has a unified, open source tool chain all driven under the direction of a single organization. I would argue that the inefficient
  • All of our core switches are running real time linux and have so for many years. Linux became a network OS back in 2008, if not much earlier. Basically the only place it's not running is on edge switches and even there you can find switches that running it.

Slashdot Top Deals

This is the theory that Jack built. This is the flaw that lay in the theory that Jack built. This is the palpable verbal haze that hid the flaw that lay in...

Close