A Pathway to Disaggregation via Juniper OS
Numerous clients have enquired regarding the disaggregated Junos software lately. Let me elaborate a few of the motives behind the resolution to disaggregate Junos, Juniper’s stated goals for this new implementation, and some of the advantages associated with this disaggregation.
While Juniper had numerous objectives associated with the disaggregation of Junos, 2 in particular stand out. Firstly, Juniper wanted to supply an architecture which totally decoupled platform software and network functionalities from the essential hardware. This clearly implies that, when you buy a QFX5200 switch, you’ll see that Junos is now a virtual control plane known as vJunos.
This separation permits Junos to concentrate singularly on control plane undertakings like OSPF, BGP and MPLS VPN minus concerns for platform-centric particulars or what packet forwarding engine is linked with the switch ASIC. This allows Juniper the capability to supply next-generation platforms with negligible modifications to the OS, returning a much quicker “time to innovation” from a hardware viewpoint.
Another objective of disaggregation is to provide open, direct access to the hardware forwarding engine via standard, open APIs via a SDK. The focus here is on “standard” and “open”; at Juniper, supplying an open platform implies supplying direct hardware programming abilities via support for a Switch Abstraction Interface (SAI) and direct control over the hardware through a set of famous APIs, irrespective of the hardware.
It is worth remembering that the QFX5200 switches are the earliest Juniper platforms to provide totally open and unparalleled container and VM support. The inside environment permits any application (3rd-party, native binaries, RPMs and VMs) to be assimilated into a root container, allowing the user a “sandbox” area where deployed software is totally secluded from the innate host Linux OS.
This method is in divergence to other sellers who permit applications or RPMs to be deployed directly on their systems, revealing severe susceptibilities and generating the possibility for disastrous system failure should an application go crazy. That being said, the QFX5200 is the foremost Juniper platform to supply a totally open virtualized environment, opening a window of opportunity for anybody interested in NFV, Service-Chaining, SDN, or just wanting to run a 3rd-party application.
Disaggregated Junos and the Future
Although the QFX5200 is the initial Juniper platform providing a truly open architecture, as software abilities advance with each release, other products will embrace the same architecture and supply the same abilities. These consist of a total virtualization infrastructure adept at making a sandbox environment which permits any native binary, container, RPM or VM to be deployed devoid of needing code to be compiled or waiting for a 3rd party to incorporate new software.
The virtualization substructure interacts directly with the data plane, supplying a dedicated inside connection to the front-panel ports. This permits users to push probes straight from any 3rd-party VM into the data path and carry out analytical activities. This is just one instance; there are many more. Juniper also allows users who are aware of and like CLI the choice to continue using it; those who aren’t acquainted with the CLI have direct access to the Linux environment. Junos itself is now a virtual construct, running as a VM and fixated predominantly on the control plane, which is totally distant from the hardware and platform particulars.
On the API flank, a set of control plane, data plane and platform-centric APIs are supplied. This is indispensable to administering, monitoring, and crafting networks today. With all of these abilities at the vanguard, it implies only one thing: if you’re a network engineer, Junos hasn’t actually changed, but if you’re in DevOps, your life just got a lot better.
Need more guidance? Just contact us today.