The Junos Fusion solution simplifies network provisioning, operation and programmability by providing a single point of management for a large number of network elements and combines the best of Juniper advanced silicon and merchant silicon. The solution leverages standalone Juniper products and requires no specialized or proprietary components.
The following diagram illustrates a minimal Fusion deployment to help define the solution terminology for subsequent discussion.
Figure 1: Junos Fusion simple single Aggregation Device (AD) deployment
Conceptually, the Junos Fusion solution combines aggregation and satellites devices into a single logical switch and/or router. The aggregation device (AD) acts as a single-point of management for the combined solution. Each satellite device (SD) is modeled as a logical remote line-card in the aggregation device, providing the same plug-and-play experience that customers are used to with “physical” line-cards in a chassis system.
All provisioning and operational aspects of satellite devices are managed from the AD without user having to access satellite device – similar to users not having to access line-cards for any management task. There is only one configuration file for the entire Fusion network.
Each component of the solution is a standalone Juniper product. For example when a standalone switch running Junos is connected to an AD on a port configured to accept satellite devices, this switch automatically becomes a satellite of the AD.
Satellites can also be dual-homed across the two aggregation devices where both aggregation devices operate in active-active mode and traffic load-balanced across all uplink interfaces between aggregation and satellite device.
Remote management of satellites operates as follows:
IEEE 802.1BR Mode: This is a simple forwarding mode based on the IEEE 802.1BR standard where the forwarding plane of the satellites simply hosts the physical interface, but all forwarding decisions are made by forwarding plane of the aggregation device. In the aggregation device, each satellite port is represented as a standard Junos port with full functionality (IFD in Junos parlance). Each satellite device operates as a simple mux-demux.
API Management Mode: This is an extension of the 802.1BR mode that provides the following APIs at each satellite:
Forwarding APIs: Allows the satellite forwarding plane to be remotely programmed by the aggregation device via well-defined APIs. Unlike 802.1BR mode, using these APIs, the satellite forwarding plane can be programmed to make all forwarding decision locally on satellite device.
Management APIs: Enables aggregation device to collect device/interface operational state, perform software upgrade, and environment monitoring tasks. These APIs are used in 802.1BR mode also.
The API management mode of satellite devices is consistent with SDN principles where the aggregation device can be viewed as a controller hosting the management/control-plane of all satellite devices and programming the forwarding-state of satellite device via well-defined interfaces.
Besides providing a single-point of management it’s equally important for customers to have a homogeneous set of features across all ports in the network that typically built using heterogeneous devices with wide-ranging PFE/CPU capabilities optimized around different cost points. Junos Fusion solution meets this requirement by representing each satellite device (and it’s physical ports) as an extension to Aggregation device and thus providing consistent set of features/services across all satellites device ports as available for aggregation device native ports.
The solution is designed for diverse applications providing the necessary feature-sets for it to be deployed across different networks: Data Center, Campus and Service-Provider. For more information, read the excellent blog on Junos Fusion in the data center.
To meet such diverse deployment requirements, the solution allows a wide variety of existing Juniper devices to be deployed as AD or SD role. Supported AD platforms are based on Juniper silicon providing rich forwarding features and necessary scale to represent the forwarding state of large number of satellites port. Whereas, supported satellite platforms are based on merchant silicon optimized for cost and different speeds.
Table 1: Juniper products available as Aggregation and Satellite device
One of the examples of providing homogeneous features across all ports in Junos Fusion solution is the availability of advanced forwarding features such as EVPN/VXLAN/MPLS supported by MX/QFX10K platforms across all satellite device ports on EX4300/QFX5100 devices.
The Junos Fusion solution models satellites as remote line-card but build on a modern software architecture compare to traditional chassis based system. The aggregation device is based on the feature-rich, high-performance, carrier-grade JUNOS operating system enhanced to support both 802.1BR and API management mode. However, for satellite device we’ve build a simple networking OS from ground-up that contains minimal platform/PFE and control-plane software necessary for device to be remotely managed.
The satellite OS, also referred to as the Linux Forwarding Operating System (LFOS), is independent of the AD OS and of the interface between AD and SD is designed around extensible and scalable protocols/APIs that decouples AD and SD software and allowed both these devices OS to evolve independently.
This software architecture based on the minimalistic networking OS on the satellites combined with extensible protocol/API based management interface produce numerous benefits:
The AD and the SD can run different software versions and upgraded independently
It’s not mandatory for all satellites to run same software version. Thus making it possible to group satellites into upgrade groups that can be upgraded independently instead of upgrading all satellites at the same time
Protocols/APIs developed from ground-up to enable solution to scale across large number of satellites
Satellite software upgrades very fast due to small footprint of LFOS and also upgrade mostly involves restarting LFOS daemons/services without rebooting the device as base OS upgrade should be a rare event
New satellite hardware (say next-generation QFX/EX devices with improved port density or supporting different set of ports like 25G) can be introduced without requiring AD software upgrade. Conceptually same as supporting next-generation line-cards in a chassis system without upgrading chassis software.
The satellite device is modeled as an independent fundamental building block and can evolved to be integrated in other controller architectures.
The satellite OS is standard unmodified Linux and primarily consists of daemons/services running in Linux user space and can easily run on white-box switches -- enabling disaggregation between hardware and software as well offering a huge number of access switch options. In a way, this disaggregation already manifests itself as all supported satellite device hardware (QFX/EX) capable to run both JUNOS and LFOS. Moreover, OS installation is managed from AD itself avoiding any pre-staging step needed to deploy the solution and offers flexibility for customers to repurpose device as standalone or satellite easily.
Deployment of a new satellite or replacements (RMA) of deployed satellites provides plug-and-play experience all that the users needs to do is to connect the new satellite to same port on the aggregation device and rest of the processing is all automated:
AD discovers directly attached standalone/satellite device
If device running JUNOS then AD installs LFOS
If device running old LFOS then AD upgrade it to latest OS
Once device operating in satellite mode managed centrally from AD
To summarize, Junos Fusion is all about simplicity and ease of use. It stands out in comparison to Juniper’s previous solutions as well as competitors by offering flexibility in choosing various standalone devices (as listed in Table 1) with diverse capabilities as a building-blocks of a software-enabled-solution. Thus, realizing each customer unique network requirements/constraints around type of features, services, scale, port-speed and desired cost point.