Junos Fusion – Part I – Overview, Components, Ports and Software
This is the first part of the series about Junos Fusion and these are the topics:
Junos Fusion allows to significantly increase the number of interfaces on a device(called aggregation device, AD) by interconnecting the AD with satellite devices(SD).
The resulting system(Junos Fusion) presents itself to the rest of the network as a single, highly dense-port device.
The AD acts as a single point of management for all devices in Junos Fusion. The SDs provide the interfaces through which the traffic enters and exits Junos Fusion.
LLDP is used for device discovery and provisioning and 802.1BR is used for satellite management. There are few enhancements done to these standard protocols when they are used with Junos Fusion.
It is important to note that it is possible to use 2 ADs in one Junos Fusion for redundancy, therefore calling it Dual AD deployment. Junos Fusion with only one AD is called Single AD deployment.
This is the simplest deployment possible, one AD and one SD:
There are three types of Junos Fusion based on use case, each of them having a different type of AD.
Multiple types of SDs are available and not all the SDs can be part of any given Junos Fusion.
These are three Junos Fusion:
- Junos Fusion Provider Edge
- Junos Fusion Enterprise
- Junos Fusion Datacenter
When the post was written these ADs and SDs are available to create Junos Fusion. Keep in mind that in the future, other ADs and SDs types will have support.
This table should provide additional about the types of ADs, SDs, deployment modes:
| JF Provider Edge | JF Enterprise | JF Datacenter | |
| Aggregation Device | MX Series | EX9200 Series | QFX10002 |
| Satellite Device | EX4300, QFX5100 | QFX5100, EX4300, EX3400, EX2300 | EX4300, QFX5100 |
| Deployment mode | Single AD | Single AD / Dual AD | Dual AD |
Some of the benefits of using Junos Fusion are:
- Port density – Thanks to the existing ports from SD, you are allowed to use a much higher number of interfaces
- Flexibility – In case you run out of available interfaces, you can expand Junos Fusion by adding new SDs
- Simplified network topology – The combination of ADs and SDs appears as a single device to the network
- Manageability – Instead of managing separately 1 AD and, let’s say 10 SDs, you will need to manage only one device
- Investment protection – You can re-use the existing devices to implement Junos Fusion
Below is a diagram that contains all the components of a Junos Fusion setup(in this case is a Dual AD setup):
Aggregation Device(AD)
The AD is running Junos and is the single point of management for the Junos Fusion. The AD has to have at least one link to each satellite device(there is an exception with the satellite clusters, multiple satellites acting as a group, where the AD must have at least one link to the cluster). The AD is also responsible for the satellites interfaces configuration.
In case of Dual AD Fusion, load balancing and increased redundancy are the two benefits that come with this type of deployment
Dual AD Fusion is supported through the use of MC-LAG groups and ICCP. The Dual AD Fusion is an MC-LAG with a single redundancy group. The redundancy group has two peering chassis IDs and the satellites(in one of the next parts we will see this particular configuration).
For simplicity, Dual AD Fusion has automatic ICCP provisioning and automatic VLAN provisioning of an interchassis Link(ICL). The parameters can be altered if necessary.
Satellite Device(SD)
The SD provides the interfaces through which the traffic enters and exits Junos Fusion and it is controlled by the AD. The SD runs a lightweight version of Linux and each SD must have one link connecting it to the AD(again based on the type of Fusion, this requirement is more or less required). In case of Dual AD Fusion DC, the SD must have a link to each AD. In case of Dual AD Fusion Enterprise, the SD does not need necessarly to have a link to each AD. Also in case of the satellite clusters, not all SDs must have a link to at least one AD, it is enough that only one SD has a link to any of the ADs.
Below is an example of satellite cluster where one of the member is not connected at all to any of the AD. The interfaces connecting the satellites within the cluster are called cluster interfaces and they can be 10G or 40G:
Ports
There are several types of ports in a Junos Fusion and each of them has specific purposes.
Cascade Port(CP)
A CP is a physical port on the AD that provides a connection to the SD. The CP on the AD connects a SD on the uplink port(UP). There can be multiple CPs between an AD and a SD. If this is happening, all the ports are automatically added to a LAG interface and the traffic is load balanced across all the links. The traffic is balanced according to the hash algorithm configured on the AD(which is changable). Any physical port configured as CP cannot be configured a Layer 2 or Layer 3 interface.
Uplink Port(UP)
An UP is a physical port on a SD that provides a connection to the AD. The traffic from SD to AD in case there are multiple links is hashed based on source/destination (IPv4|IPv6) address and (TCP|UDP) ports if the traffic has an IPv4 or IPv6 header and based on source/destination MAC, ethertype and outer VLAN ID if the traffic does not have an IPv4 or IPv6 header
Extented Port(EP)
An EP is a physical port on SD that connects hosts and other devices to SD. The EP naming is tied to the FPC ID that the satellite gets in the configuration. To AD, a SD appears as a FPC.
For instance, if a SD is assigned FPC ID 100, then the local SD interface xe-0/0/0 becomes xe-100/0/0.
On an EP you can configure filters, Layer 2 protocols, COS policies.
The FPC ID in a Junos Fusion can be assigned in two ways:
- unique ID based FPC assignment – the FPC is identified in the configuration using its serial number regardless to which CP is that SD connected(for instance, SD with S/N X will always be FPC100 regardless to which CP is connected)
- connectivity based FPC assignment – the FPC is tied to the CP(for instance, any SD connected to CP xe-0/0/0 will be FPC100)
Each type of SD has a default set of interfaces that act as uplink ports. In case of clusters, there is also another default set of interfaces that act as cluster interfaces. The default role for these sets of interfaces can be changed using an uplink port policy and will be covered in a later post.
As said, the AD is running Junos through which all the ports Fusion and non-Fusion are controlled.
The SD runs a lightweight Linux version called satellite network operation system(SNOS).
Junos Fusion uses satellite software upgrade groups where multiple satellites are grouped in order to be upgraded to the same SNOS. Multiple upgrade groups can be configured and they allow parallel upgrading of the SDs in order to speed the upgrade process and to minimize the downtime.
If a satellite get a FPC ID that is part of an upgrade group, then that satellite is upgraded to the SNOS associated with the upgrade group, unless the satellite is already running the same SNOS.
If the software associated with an upgrade group is changed, then only few of the satellites from that upgrade group are upgraded at a time in order to minimize the potential traffic disruption.
There are multiple methods to convert a standalone device to a satellite device among which two are most comon: auto-conversion and manual conversion(we will see all conversion methods in a later part of the series).
There are two types of SNOS: aggregation device install software that is used in combination with a satellite software upgrade group and standalone installation software that is used to convert a device to satellite prior connecting it to Fusion.
And at this point we covered pretty much that is required to understand what Junos Fusion is. In the next part we will discuss about Junos Fusion Enterprise and we will how does a Dual AD Fusion Enterprise looks like.
I hope you found this post interesting.
Paris ARAU
Latest posts by Paris ARAU (see all)
- Junos Fusion – Part IV – Satellite policies and uplink failure detection - 30 July 2018
- Junos Fusion – Part III – Satellite commands and traffic forwarding - 16 July 2018
- Junos Fusion – Part II – Configuration, Administration and Operation - 16 July 2018
- Junos Fusion – Part I – Overview, Components, Ports and Software - 11 July 2018
- Vagrant – Part IV – Network topology using Juniper and Cumulus - 26 April 2018
Thanks for sharing. Very informative. How this is different from Cisco fex. Puttiing qfx5100 as a satellite device is really worth ..?.
Hi Mehul,
You can use QFX5100 if you need 10G connectivity on satellites.
The benefits of using Fusion include investment protection(you can use a device as a satellite or as a standalone device running Junos). Advanced features can be implemented thanks to the more capable SD(not acting just as an extender). In case of JFD(Datacenter), you can use l2 local switching.
Thanks,
Paris
Dear Paris,
thanks for your clarification here. I thank you lot for your link that showing vagrant include QFX container. can do some handson. :) …
[…] the first part, I explained the concepts behind Junos […]
[…] first and second parts covered the basics and how to bring up and verify that Junos Fusion is working […]