Build the Next-Generation Data Center
6 week online course starting in spring 2017

Whitebox Switching and Open-Source Networking Are not SDN

One of my readers left this comment to the Four Paths to SDN blog post:

You didn't mention Cumulus. SDN protocols become much less important when you have an open Linux switch platform. You can compile and install your own management daemon and implement whatever protocol best suits the task (and blend local and remote control).

Here’s my usual response to this line of thinking:

The above slide is from the keynote I'll have @ SDN Architectures event in Zurich in two days. There are still a few places left; registration instructions are at the bottom of this page.

Let’s start with what SDN is. According to the orthodox definition it’s the separation of control and data plane (in words of one of the engineers attending my SDN workshop: that’s exactly like SNA, we’ve seen how well that works). A more useful definition focuses on abstraction layer that allows everyone to focus on network services, not on implementation details.

Watch SDN 101 and Network Programmability 101 webinars for more details. The easiest way to access them is to register for the free Introduction to SDN course.

Linux-based networking does not give you one or the other. It might be easier to implement network automation with existing Linux tools, but that won’t give you an SDN solution – the individual Linux-based switches still have to talk to each other, and they usually do that using traditional networking protocols, because people who know what they’re doing (like engineers working for Cumulus Networks) have better things to do in their life than reinventing 20 years of well-running wheels.

Now let’s focus on the second part of the comment:

You can compile and install your own management daemon and implement whatever protocol best suits the task (and blend local and remote control).

You can do the same thing on a Junos box, and it’s even easier to do it on an Arista switch (listen to Software Gone Wild Episode 19 for a real-life case study). Cisco and HP still have a problem with this approach because most of their gear run on proprietary operating systems, but then keep in mind that you could use Tcl in Cisco IOS for almost a decade; Python was added to NX-OS a few years ago.

Writing Tcl code isn’t exactly fun for most people, but the point is that you could “program” Cisco IOS (the same way you “program” a Linux box with iptables CLI) a long time ago if you really wanted to. The fact that most people didn’t do that has more to do with the mindset (don’t touch a running box) than with the programming capabilities of the box.

On the other hand, the real beauty of Linux-based network operating systems (Cumulus Linux, Arista EOS and to a smaller extent Junos) is the ability to take any one of the zillion off-the-shelf packages and install it on your switch.

How could we ever survive without having figlet on our switches?. See Cumulus presentation @ NFD9 for more details.

Summary

Linux-based network operating systems make our lives easier (assuming you know your way around Linux), but apart from ease of integration with existing configuration management tools like Ansible, Puppet or Chef, they haven’t given us dramatic new functionality.

Finally, open-source networking and software-hardware disaggregation have nothing to do with network automation or software-defined networks. They are just different business models used by vendors who want to disrupt the existing status quo (see also: Be Wary of Geeks Bearing Gifts).

Disclosure: Cumulus Networks was indirectly covering some of the costs of my attendance at the Network Field Day 9 event. More…

19 comments:

  1. I like this point especially.

    "On the other hand, the real beauty of Linux-based network operating systems (Cumulus Linux, Arista EOS and to a smaller extent Junos) is the ability to take any one of the zillion off-the-shelf packages and install it on your switch."

    Novell NLM anyone?

    or
    What about the certification of approved "packages" to install on your shining open source switch that is supporting a critical application.

    Believe it or not sometimes the proprietary can be more secure.

    ReplyDelete
    Replies
    1. I don't think security through obscurity is a good idea, unless you prefer to be spied only by governments http://www.engadget.com/2014/05/16/nsa-bugged-cisco-routers/

      Delete
  2. SDN is a business model of not buying HW and SW from same vendor. Underneath this definition Cumulus would still qualify as SDN.

    ReplyDelete
    Replies
    1. What Vignesh wrote is wrong and stupid. SDN is marketing term. Cumulus is a network operating system. You can call it what you want but the inventors of "SDN" were actually focused on network virtualization and not all of this other stuff.

      Delete
    2. I would love to see where Vignesh got his definition of SDN. You can't simply call whatever you like SDN ;)

      Delete
    3. Depending on how you read the ONF definition for SDN - https://www.opennetworking.org/sdn-resources/sdn-definition, one could extract some the items listed and claim this is SDN although the definition is for an 'SDN architecture'. I think the following statement is the closest to what we are actually seeing: "Cumulus NOS contributes to some aspects of an SDN architecture" and I would add an architecture is not built around a single product especially for SDN.

      Delete
    4. The ONF definition of SDN is very clear (and useless) - read the first paragraph on the page you quoted (under the "What is SDN" heading).

      After that they tout the supposed beauties of their architecture, not list the criteria you could use to figure out whether something is SDN or not.

      Delete
    5. Ivan, your post is perfect example of interpretation :-)
      I could do the same and argue that "SDN architecture is:" somehow defines what an SDN architecture is supposed to be based around.

      Anyway, it's your blog and your way of "discussing" things by being a critic, nothing wrong here, just the Internet attitude I suppose.

      Carry on as we need the hype to be addressed.

      I, therefore, make you knight of SDN (although it does not make me king of SDN...maybe this needs to get full approval from his holiness Martin Casado)

      Long live SDN ! Long live Rocket turtle !

      Delete
    6. I'm guessing you might be missing some of the context and background, but it's obviously impossible to make any conclusions in an anonymous conversation ("just the Internet attitude" as you say).

      Delete
    7. This comment has been removed by the author.

      Delete
    8. Don't we quote Facebook and Google as example of SDN. They do develop their software and buy white-box hardware. This as a definition of SDN one could argue as wrong but definitely not stupid especially from a business model standpoint.

      Delete
    9. Actually I was told that Google also bought NX-OS-mode-only Cisco Nexus 9000 switches for their SND networks.

      Delete
    10. @Anonymous:Now that's classic stupid, everyone has some cisco or other incumbent box including Google. I talk to customers on a daily basis there is nothing wrong with l2/l3 based networks with good NMS, they just want to invest and keep the software that they have learnt to maintain and swap out the underlying hardware when the time comes for refresh. ONF and its definition of SDN does not mean squat in the real world ruled by OpEx and CapEx savings. Technology can do all tricks but what matters is the cost of the ticket !

      Delete
  3. The real funny thing is that it does not matter.

    What matters are getting packets to right place as fast/secure/reliable as possible and that includes provisioning of getting them moving.

    :)

    ReplyDelete
  4. We have been working on an interesting SDN open source project http://www.openmul.org/prism-sdn-router.html. We are trying to build a scale-out SDN solution with multiple data plane and single control plane abstraction. Once we are able to solve exporting legacy switch tables to controller using Openflow, this will give a real run for the money for these so called fake SDN solutions.

    ReplyDelete
    Replies
    1. Interesting. When you're ready to talk about your project let me know.

      Thank you!

      Delete
  5. Anonymous comments are a way for people to say things they are not so sure of because there is no blame or risk of getting exposed, so its really useless.

    Ivan, If i were you, I would disable Anonymous comments because they are rarely important and are always considered "internet attitude" of trolling.

    ReplyDelete
  6. You can still install an openflow sdn app like nuage networks on a linux switch and get the benefits of linux and sdn, no? :)

    ReplyDelete
  7. Ivan, I agree with many of your points, but I think your conclusion "open-source networking and software-hardware disaggregation have nothing to do with network automation or software-defined networks" misses an important point.

    Art Fewell's recent interview with Rob Sherwood has an interesting exchange in which Rob states, "I think OpenFlow is very valuable but it's also, it's a technical solution to a business problem that we've had. This is to say, if you flashed back 7, 8 years when I started working on this; the idea that you could actually buy a switch and put your own software on it and there was enough hardware documentation and enough open source software to make that happen, it was actually, it just wasn't even on the table. The next best thing that we could hope for was a remote API into the low level forwarding plane on the box. That was how the OpenFlow was designed. Fast forward to today, we have things like, if I could put a small plug-in for my open source project, Open Network Linux. You can grab something like that and either deploy our OpenFlow, or write your own OpenFlow, or write something else."

    You Four Paths to SDN article listed "Vendor-specific APIs" as one of the paths to SDN, but raised the objection that relying on a vendor specific API results in vendor lock in. Moving to Linux APIs to interface with network hardware avoid vendor lock in and allows operators to benefit from the Linux ecosystem of "zillion off-the-shelf packages" and as the ecosystem expands, hopefully zillions more. The Linux netlink API provides a good abstraction for interfacing with routing which is used by open source distributed routing agents like Quagga or Bird, or if you want a standardized remote API, you could use something like IETF Forces protocol.

    Open networking hardware and Linux is moving SDN from being primarily concerned about protocols (which are required to communicate with closed systems) to APIs and software which seems to me the essence of software defined networking.

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.