ra2 studio - Fotolia
Looking for something else?
When it comes to IT, I always recommend getting your hands dirty, and software-defined networking is no exception. I've written some persnickety words about OpenDaylight security, and more recently cursed while struggling to set up NSX in the lab. I haven't given up on my dream of truly open SDN, unsullied by big vendor hardware agendas but also not limited to 21-inch racks in the cloud. I want SDN managing my campus LAN. With that in mind, I recently tested a new open SDN solution in my lab -- ONOS. And you should roll up your sleeves and dive in, too.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
A different approach
The Open Network Operating System (ONOS) is a different approach to the SDN operating system, in that it focuses on modularity, especially in separating the control and data planes. It also provides clustering and horizontal scalability for carrier-grade performance and availability from the beginning. Of course, I also like that it's open source under the auspices of ON.Lab, with independence a core tenant -- unlike vendor-led projects like OpenDaylight.
But its major differentiator is providing an Intent Framework that allows applications to simply declare their intended network controls, and then ONOS takes care of the rest. Once a policy directive is expressed as an intent, ONOS compiles them into installable intents that perform change operations on the managed network. Through modularization, those intents are applied by intent installation processes, allowing coherent distribution, retry, rollback and removal.
Shifting network service definitions to application definitions is key, and a major driver of container hosting platforms. To make SDN work, the fabric and its control plane must fade into the background so admins can focus on service delivery, not network configuration. With the Open Network Operating System, if a route goes down, the atomic nature of intents means applications don't need to intervene -- the controller finds a new route on its own, recompiling and redistributing new intents into the switches in the network.
Hands-on with ONOS
When evaluating new technology, I try to keep my DevOps hat screwed on tight, and ask only two questions during "Hello World": How quickly and painlessly can I get something up and running, and how quickly or comprehensively can I customize it based on specific requirements? Epic clean-sheet config-a-thons are academic and cumbersome -- I learn by taking things apart. It doesn't matter if you're working with enterprise application frameworks, your monitoring platform, software-defined infrastructure or hyper-convergence. If you can't get the basics running before enthusiasm fades, you're in for a long slog. With my first brush with ONOS, I was up and running in about 20 minutes.
Lab setup, though not trivial, is reasonably straightforward if you're familiar with virtual machines (VMs) and decent with Linux, and have a little Git in your blood. It also works great with Mininet, so like CoreOS, it's possible to do a single machine setup -- a huge plus for skills development and experimentation. By default, ONOS uses OpenFlow southbound by a pluggable API layer, with modularity supporting other control standards. (With legacy switches, it would use NETCONF and do southbound command-line interface, or CLI.)
Though vastly simplified for brevity, here's what you do: Grab a snapshot of ONOS with Git, install a handful of dependencies, build ONOS with Maven and you're off. I was running -- current as of this writing -- ONOS version 1.4.0 (Emu). Though I could perhaps have indulged my habit of abusing Raspberry Pi 2s, installing on a 2 GB Ubuntu server VM seemed like a more professional choice.
Basic configuration of a single network segment Mininet is easier than usual. In other projects, it's usually configured manually to simulate configured switch logic, but because ONOS will do that, only basic configuration of a simulated forwarding plane is required. The switches connect to ONOS over the OpenFlow channel, then ONOS does discovery and maps topology.
The Open Network Operating System CLI tools make it easy to examine the gory details inside the controller, like listing the discovery results and flow definitions in each device. By default, the flow instantiation is reactive -- unknown traffic on a switch is sent to the controller, which then figures out what to do with it. Conveniently, after discovery ONOS added default low-priority rules to the OpenFlow switches to get ARP to the controller.
In this mode, OpenFlow doesn't find flows unless there's traffic, and pinging between hosts in the Mininet CLI does the automation you'd expect. The default rules kick the ICMP to ONOS, which creates flows to allow it, deploys it to the switch(es), and then -- ping -- starts working. After that, traffic isn't flowing from host to controller to host, but from host to switch to host. Reloading routes in the ONOS CLI confirms this.
The ONOS GUI Web interface makes it easy to identify ONOS controller instances, switches and hosts. Adding flows is drag-and-drop, and for a relatively Spartan view, it's easy to see traffic, toggle layer views and get link details.
SDN with intent
But the real magic of the Open Network Operating System comes when you switch away from reactive flow instantiation. Creating and deploying OpenFlow rules can be a real pain, especially on a complex network. With Application Intents, however, you direct ONOS with application needs, plus endpoint IDs from discovery, and it creates, compiles, and distributes all the OpenFlow rules automatically. Too often with SDN we cheat with reactive or hybrid flow instantiation to skip this chore of defining selectors and treatments, determining the shortest path and identifying which switches need updates.
Happily, ONOS automates this, allowing admins to be much more proscriptive and manage by intent rather than accommodation. Best of all, security is likely improved when cleaning unused flows, because instead of scouring the network for unwanted flows, intents remember where all the distributed flow rules are instantiated and can remove them more reliably.
In theory, the Open Network Operating System's service provider DNA gives it a performance edge over OpenDaylight, with a target of one million flow ops per second, and phase two of my testing will include physical gear in the lab for benchmarking. In theory, ONOS' open source commitment may bring us closer to the white box, open SDN dream, in which we network engineers set requirements, not hardware vendors. In theory, adding a new SDN platform will spur development in OpenDaylight as CoreOS has with Docker. In theory, there is no difference between theory and practice. But in practice, there is. I'm with Yogi on this one.
Will ONOS and ODL collaborate on an open source controller?
ONOS Emu release updates to CORD
SDN starter kits relieve the need to DIY