The bottom line: Open source is in Cumulus’ DNA and it always will be. From the beginning, we were built on open source and we continue to contribute regularly.
When Cumulus Networks was founded, we were fighting a very different battle. Virtually every data center was proprietary and engineers saw no other alternative. There was no open networking movement, no disaggregation, no ONIE and little or no access to the underlying Linux system. And that’s where we started — by igniting the open networking revolution with ONIE (we’ll get into that later). Our mission was to disaggregate every network so that businesses could leverage any software and hardware they want, including open source projects. We believed (and still do) that this would allow businesses to create better, faster networks. Since then, we’ve continued to work closely with the community, contribute regularly and leverage open source technology as much as possible.
Flash forward to today, and the canvas has changed (for the better). Open networking and disaggregation are commonly used terms, and various solutions and software have sprouted up in the space. We now support over 70 whitebox hardware platforms and hundreds of applications, and we’re heading into an era where open is the new normal. We like to think our open source contributions had a lot to do with that.
Our open source philosophy
By nature and on principle, we are against closed, proprietary technology in the data center. It’s true that we sell a proprietary product, but large amounts of our products are built on open source, shared with the open source community, are compatible with open solutions and have helped us contribute innovation. When we think we can help the community with an innovative contribution, we do just that.
One recent study by New Stack found that organizations with open source programs created these program to reap the following benefits: “1) awareness of open source usage/dependencies, 2) increased developer agility/speed, and 3) better license compliance.”
Similarly, to us, open source isn’t just about sharing code. It’s so much more than that. We believe open source is about working together, about standing on the shoulders of giants, about driving for more innovation, always. It’s about making technology more secure by having more people review the code and cranking a feature up just another notch because an outsider made a thoughtful suggestion. It’s about connecting engineers and innovators and creating something together that’s better than anything that could have been created in the dungeons of a large, proprietary, traditional organization. It’s in our culture, it’s within our employees and it’s who we are.
Every single day at Cumulus, we ask ourselves how we can make the industry, not just our products, better. And we know we can only truly make a difference by working with the open source community intimately and religiously. So that’s where we stand.
Our contributions to the open source community
In addition to having a cultural philosophy, we also actively contribute to the open networking community. In the next few paragraphs, we will summarize a few of our biggest contributions. But if you’re the type who likes the weeds and wants to see the code for yourself, we recommend you check out our OSS page, which contains links to the packages we ship with every software version.
The Open Network Install Environment (ONIE)
In 2013, we brought you ONIE. ONIE is the open source initiative that enabled the open networking movement and ecosystem by allowing users to use bare metal switches and choose any network operating system. ONIE enables switch hardware suppliers to manage their operations based on a small number of hardware SKUs. This in turn creates economies of scale in manufacturing and distribution, enabling a thriving ecosystem of both network hardware and operating system alternatives. ONIE was the start of it all. This one project allowed us to work with whitebox hardware vendors and enable disaggregation as you know it today. ONIE is now part of the Open Compute Project.
ifupdown2 is an open source network interface manager. It’s a rewrite of Debian’s ifupdown in Python and helps solve the limitations of existing network interface configuration tools. ifupdown2 retains the pluggable/extensible architecture of ifupdown but also uses existing Linux native network interface configuration tools to configure interfaces while maintaining backward compatibility with ifupdown.
ifupdown2 simplifies a network administrator's tasks by providing a solution to the problems of interface dependency, incremental updates and complex configuration.
VRF for Linux
In any solution, VRF (virtual routing and forwarding) provides traffic isolation at layer 3 for routing. Most networking operating systems can support 1000’s of VRF instances, giving customers flexibility in deploying their networks.
Over the years, there have been multiple attempts to add proper support for VRF to the Linux kernel, but those attempts were rejected by the community. We knew there needed to be a better solution, so naturally, we took on the task. Our solution for VRF, which was accepted into the kernel, is both resource efficient and operationally efficient. It does not require an overhaul in how programs are written to add VRF support or in how the system is configured, monitored and debugged. Everything maintains a logical and consistent view while providing separation of the routing tables.
Because of our commitment to open networking, the VRF for Linux solution is now rolling out in OS distributions allowing it to be used for everything: routing on the host, servers, containers, and switches. Based on the number of inquiries as well patches and feature requests, the end result appears to be a hit for both networking vendors and Linux users.
FRRouting was developed by a group of contributing companies, including us, in the open networking space. It is an IP routing protocol suite for Unix and Linux platforms, forked from Quagga. FRR includes protocol daemons for BGP, IS-IS, LDP, OSPF, PIM, and RIP.
Prescriptive Topology Manager (PTM)
PTM introduces a software abstraction layer that ensures certain wiring rules are followed by doing a simple runtime verification of connectivity as determined by an operator’s specified wiring plan. This “prescriptive” layer dynamically ensures the desired logical topology and can take some defined actions based on the results of the topology verification, including running scripts and communicating with the routing protocol suite.
PTM is written entirely in Python and C code and developed and tested on the Wheezy and Jessie releases of Debian Linux. The source code is available under the Eclipse Public License (EPL) in keeping with the Cumulus Networks ethos of participation in the Linux community. It is available on GitHub.
This contribution enabled two major enhancements to the kernel and Cumulus Linux: 1) it enabled support for 25G, 50G and 100G speeds and 2) it allows support for FEC encoding control.
We’ve made various contributions in multiple areas of Linux to support Ethernet VPNs. In the kernel, we’ve made updates to the bridge, VXLAN and neighbor subsystem. We’ve also worked heavily on FRRouting to both launch the project itself (see above) and enhance the control plane for EVPN. Finally, we’ve made various config updates in ifupdown2 to make deploying EVPN possible. Because of these contributions, we now offer a robust EVPN feature for Cumulus Linux and enabled the open community to also reap many of these benefits.
The Modular Layer 2 (ML2) plugin is a framework that allows OpenStack Networking to utilize a variety of non-vendor-specific layer 2 networking technologies. The ML2 framework simplifies adding support for new layer 2 networking technologies, requiring much less initial and ongoing effort — specifically, it enables dynamic provisioning of VLAN/VXLAN on switches in OpenStack environment instead of manually provisioning layer 2 connectivity for each VM. We helped develop the driver that enables Cumulus Linux to work intimately with OpenStack.
Transponder Abstraction Interface for Voyager
Voyager is open transponder hardware contributed by Facebook that uses Open Packet DWDM (dense wavelength division multiplexing). This is an approach Facebook developed that separates hardware from software in metro and long-haul fiber optic transport networks. Facebook contributed both Open Packet DWDM and Voyager to the Telecom Infrastructure Project (TIP) last year. We worked closely with Facebook on the Voyager transponder project to ensure an open operating system like ours with standard ASIC technology.
Cumulus Networks created the Transponder Abstraction Interface (TAI) and contributed it to the Telecom Infra Project. TAI defines an API for providing a vendor-independent way to control transponders from various vendors and implementations in a uniform manner. One such implementation is the AC400 transponder used in Facebook Voyager. Cumulus Networks wrote the device driver and open sourced it. The project's code resides in the Telecom Infra Project GitHub repository.
One of our earliest contributions, VXFLD is a suite of tools that provides the ability to do VXLAN broadcast, unknown unicast, and multicast (BUM) flooding using unicast instead of the traditional multicast. It enables easy-to-deploy, scalable, virtual switched networks built on top of a layer 3 fabric. Learn more on GitHub. This technology is superseded by our EVPN solution. We encourage our customers to embrace EVPN instead, as it’s now a robust feature in part due to some of our open source contributions.
Other contributions to the kernel:
- Lightweight tunnels
- Multicast routing enhancements
- Linux bridge enhancements and features
- Linux policy routing enhancements
- VXLAN enhancements
- New stats API : for vlan, mpls and future stats
- Kernel tracepoints for fib and bridge fdb database debugging
How we leverage open source
Being purely Linux, our products offer complete interoperability with almost all open source solutions. But behind the curtains, we also continually leverage open source technology directly in our products and solutions. These technologies include (but or most definitely not limited to):
- FRR developments by third parties, leveraged by NetQ for container connectivity
- Redis database for NetQ troubleshooting and monitoring
- snmpd for our package
- rsyslog for logging
- lldpd as an LLDP agent
- Support of open hardware innovations like Open19 and Voyager
- Linux kernel networking stack with contributions from not just us, but the rest of the community
What you see here is just a glimpse of how Cumulus Networks works with the open source community. We’ll continue to drive innovation and scale in the industry, and we’re excited for what’s to come. Many of our employees are also thought leaders in the space, developing new ideas and contributions regularly. If you’d like to keep an eye on what they’re doing, keep an eye on our blog for more on how our employees and company as a whole drive innovation in open source.