Several people have asked about the disaggregated Junos software recently. Allow me to explain some of the reasons behind the decision to disaggregate Junos, our intended goals, and a few of the benefits of disaggregation.
While Juniper had several goals related to the disaggregation of Junos, two in particular stand out. First, we wanted to provide an architecture that completely decoupled platform software and network functions from the underlying hardware. This simply means that, when you purchase your QFX5200 switch, you’ll notice that Junos is now a virtual control plane called vJunos.
This separation allows Junos to focus solely on control plane activities like OSPF, BGP and MPLS VPN without regard for platform-specific details or what packet forwarding engine is associated with the switch ASIC. This gives Juniper the ability to ship next-generation platforms with minimal changes to the OS, yielding a much faster “time to innovation” from a hardware perspective.
Another goal of disaggregation is to offer open, direct access to the hardware forwarding engine through standard, open APIs via a SDK. The emphasis here is on “standard” and “open”; at Juniper, providing an open platform means providing direct hardware programming capabilities through support for a Switch Abstraction Interface (SAI) and direct control over the hardware via a set of well-known APIs, regardless of the hardware.
It is worth noting that the QFX5200 switches are the first Juniper platforms to offer completely open and unprecedented container and VM support. The internal environment allows any application (third-party, native binaries, RPMs and VMs) to be integrated into a root container, giving the user a “sandbox” area where installed software is completely isolated from the native host Linux OS.
This approach is in contrast to other vendors who allow applications or RPMs to be installed directly on their systems, exposing serious vulnerabilities and creating the potential for catastrophic system failure should an application go berserk. That said, the QFX5200 is the first Juniper platform to offer a completely open virtualized environment, opening a window of opportunity for anyone looking at NFV, Service-Chaining, SDN, or just looking to run a third-party application.
The Virtualized Infrastructure of Disaggregated Junos
The Future of Disaggregated Junos
While the QFX5200 is the first Juniper platform to offer a truly open architecture, as software capabilities evolve with every release, other products will adopt the same architecture and offer the same capabilities. These include a complete virtualization infrastructure capable of creating a sandbox environment that allows any native binary, container, RPM or VM to be installed without requiring code to be compiled or waiting for a third party to integrate new software.
The virtualization infrastructure interacts directly with the data plane, providing a dedicated internal connection to the front-panel ports. This allows users to push probes directly from any third-party VM into the data path and perform analytics. That’s just one example; there are many more. Juniper also gives customers who know and love CLI the option to continue using it; those who aren’t familiar with the CLI have direct access to the Linux environment. Junos itself is now a virtual construct, running as a VM and focused primarily on the control plane, which is completely abstracted from the hardware and platform details.
On the API side, a set of control plane, data plane and platform-specific APIs are provided. This is essential to managing, monitoring, and creating networks today. With all of these capabilities at the forefront, it means only one thing: if you’re a network engineer, Junos hasn’t really changed, but if you’re in DevOps, your world just got a lot better.
For more information about the disaggregated Junos, please take a look at these related blogs: