Data Center Technologists
Showing results for 
Search instead for 
Do you mean 

Junos Fusion Overview

by Juniper Employee ‎10-01-2015 04:24 PM - edited ‎10-08-2015 02:48 PM

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.


Figure 2: Junos Fusion dual Aggregation device deployment


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

Aggregation Device



Juniper Silicon



Juniper Trio



Juniper Q5



Juniper Trio


Satellite Device


Merchant Silicon



Broadcom Trident-2



Broadcom Triumph



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.

on ‎08-23-2016 04:02 AM

Hi Shukla,


Thank you for putting it all together.

I have one question, Is there any distance restriction between AD and SD?


I am thinking of using fusion as an option for Carrier networks.

In that case, distance going to be a key factor.





Juniper Design & Architecture Center - Mobile Cloud
About the Author
  • Anil Lohiya is a Principal Engineer in the Campus and Data Center Business unit in Juniper Networks. In his current role, he is leading some of the SDN and Network Virtualization initiatives.
  • I am an Engineer with expertise in Data Packet Forwarding, Software Design & Programming with major domain expertise in QoS (Quality of Services). I have worked across the domains in Data communications field. I love water and am a good swimmer too.
  • Jai Kumar is a DE with Juniper Networks. He is one of the key architects of QFabric. He is also an author and architect of OpenFlow support on MX platforms, Open Convergence Framework (OCF) for converged wireless and wired networks, MPLS in data centers and Juniper Cloud Analytics Engine (an Open Analytics Platform). He holds 18 patents on various technologies.
  • Remarkably organized stardust.
  • I have been in the networking industry for over 35 years: PBXs, SNA, Muxes, ATM, routers, switches, optical - I've seen it all. Twelve years in the US, over 25 in Europe, at companies like AT&T, IBM, Bay Networks, Nortel Networks and Dimension Data. Since 2007 I have been at Juniper, focusing on solutions and services: solving business problems via products and projects. Our market is characterized by amazing technological innovations, but technology is no use if you cannot get it to work and keep it working. That is why services are so exciting: this is where the technology moves out of the glossy brochures and into the real world! Follow me on Twitter: @JoeAtJuniper For more about me, go to my LinkedIn profile:
  • Jonathan Davidson is executive vice president and general manager, Juniper Development and Innovation (JDI). In this role, he is responsible for driving strategy, development, and business growth for Juniper's entire portfolio including routing, switching, and security, as well as for the ongoing evolution of silicon technology and the Junos operating system. Prior to his current position, Davidson was senior vice president and general manager for Juniper’s Security, Switching and Solutions Business Unit (S3BU). In this role, he was responsible for leading innovation, growth and product development in data center, campus, branch, and cloud. Davidson joined Juniper in 2010 as vice president, Product Line Management for the Edge and Aggregation Business Unit where he was responsible for the product lifecycle management, strategy, implementation, solutions and go-to-market activity for a range of leading edge routing product families, such as the E, M and MX Series. Before joining Juniper, Davidson had a 15-year career in various leadership positions at Cisco.
  • Ken Briley is Data Center TME at Juniper Networks focused on Juniper switching product lines. Prior to Juniper Networks, Ken worked at Cumulus Networks as a TME supporting the dis-aggregation movement and before that he spent 15 years at Cisco Systems working in various roles: Technical Support, Technical Marketing Engineer, Network Consulting Engineer and Product Management. Ken has an MS in Electrical Engineering and is CCIE # 9754.
  • Lakshmi Namboori is a Senior Product Line Manager with Juniper Networks and focuses on datacenter switching portfolio and fabric architectures. Lead product manager for optical solutions and strategy and Enterprise solutions. She is certified in switching and routing technologies. She is CCIE # 15656. She held various roles in Cisco for 9 years before moving to Juniper. She is passionate about networking industry and her work.
  • Michael Pergament, JNCIE-SP #510, JNCIE-ENT #23, JNCIP-SEC
  • Raj is a Sr. Cloud Technology Architect with Juniper Networks and focuses on technologies such as VMware, SDN, and OpenStack etc.
  • Rakesh Dubey is the engineering head for Campus and Data Center business unit at Juniper Networks. He has been with Juniper for past six years leading multiple switching products.
  • Sarath Chandra Mekala is a staff engineer with Juniper networks and focuses on implementing Juniper's Openstack Neutron plugins in the areas of Switching, Routing, Firewall and VPN. He is an official contributor to Openstack Neutron FWaaS v2.
  • Sriram is a Sr. Manager in the Campus and Datacenter Business Unit. He is part of the Network Director team and focuses on technologies such as VMware integration, OpenStack etc.