Cumulus Networks: The Pros and Cons of Decoupling

The traditional approach to designing and building networks and network devices is undergoing radical rethinking. One startup, Cumulus Networks, separates network software from network hardware. The company's flagship product is Cumulus Linux, a network operating system designed to run on so-called white-box switches or merchant silicon.

There are upsides to decoupling network software and hardware, including faster product development and freedom from vendor lock-in. But Cumulus must also address key issues, including robustness of support, the feasibility of swapping out vendors and a lack of choice in form factors.

Do I Have Your Support?

The networking industry has long emphasized the integrated nature of networking hardware and software as vital to speed and reliability. Yet these claims were also made by mini-computer vendors in the late 1980s before SCO Xenix and Windows NT proved that Intel 80386 platform worked well enough for customers at a much cheaper price. Linux and Microsoft have comprehensively proven that the hardware and software work better when they are developed independently. (However, I must note that it took years for Microsoft Windows to achieve acceptable levels of reliability and stability.)

But if you separate network software and hardware, what happens to the customer on the support front? It's easy to imagine the customer's problem going unsolved while the software and hardware vendors point fingers at each other.

Cumulus Networks says it will support both its own software and the third-party hardware on which it runs, and will own fault resolution. In other words, the company promises to work with the customer to resolve any fault, whether it's hardware or software. The customer sees only a single support organization from Cumulus.

Admittedly, Cumulus is a very small company at this point, with a commensurately small (and new) support organization. These factors may represent a risk for companies, though it's possible some organizations may be willing to offset that risk against the significant cost savings they'll enjoy at purchase time.

Changing Suppliers

The decoupling of software and hardware also means that customers can replace either the operating system or the hardware. If you decide that Cumulus Linux isn't meeting your needs, you can choose another vendor for the operating system.

Or perhaps your current hardware provider isn't producing a physical switch with the features you need for the price you want, or there is a reliability problem. Simply choose a different manufacturer without changing the software vendor and retain the DevOps pipeline that you have already created.

On the surface this sounds great--an easy swap of either software or hardware rids you of a problematic vendor. But swapping out either software or hardware from a production network is always more complicated than a vendor makes it sound--we're not talking about switching laundry detergents because you want whiter whites.

To make this process more practical, Cumulus Networks has open-sourced the Open Network Install Environment (ONIE) on github. ONIE enables a "bare metal" network switch ecosystem where end users have a choice among different network operating systems. Cumulus invites hardware manufacturers to use the ONIE software to provide a consistent mechanism for loading the network OS.

ONIE is a key enabler for manufacturers in the same way that modern servers have common methods for booting operating systems with USB sticks or a CDROM today. If ONIE becomes widely adopted, few engineers will lament the end of the current arcane processes for loading software to switches and firewalls. This is a long overdue innovation.

And how do you configure a Cumulus device ? The short answer is using a bash prompt because the device runs the Cumulus Linux software. The long answer is also "use Linux." You can install Chef, Puppet or CFengine and use your DevOps pipeline to configure the network devices.

NSX Integration

Cumulus touts an open vendor ecosystem as one of the benefits it brings to customers. The company aims to demonstrate that value with the announcement that its network OS will integrate with VMware NSX to serve as a gateway for network overlay tunnels; in other words, Cumulus provides VTEP (VXLAN Tunnel End Point) support.

The upshot is that the NSX overlay can connect to physical Cumulus devices on the network, and via Cumulus can connect to other hardware devices such as firewalls and load balancers. Cumulus will implement an OVSDB server that effectively emulates an NSX agent. As a result, Cumulus Linux looks like an NSX node and is easily configured by the NSX controller.

Today, Cumulus is focused on cloud providers and very large data centers. When you can point at a customer with 5,000 deployed units, it's a compelling display of adoption and success. But it seems equally obvious that campus networking would be well served by this approach, where hardware cost is the paramount issue (well that and the removal of spanning tree).

However, one weakness for Cumulus is that it only supports 1RU network switches. A chassis switch OS is a much larger technical challenge and one that may take some time to solve, although Cumulus spokespeople assure me they are working on it. Customers are well trained to purchase chassis switches and expect to have this option.

In summary, Cumulus Networks is pledging full support for software and hardware, making a valuable use case for openness, and touting integration with VMware. On the negative side, scaling a support business to support thousands of customers is risky and expensive, and the product line offers limited hardware choices. In addition, the company requires customers to manage their network infrastructure with tools like Chef, Puppet and the Bash shell.

Customers will have to weigh these pros and cons and themselves if they are ready for the transition to a decoupled network environment.