ON THIS PAGE
Understanding Junos Node Slicing
Junos Node Slicing Overview
Junos node slicing enables service providers and large enterprises to create a network infrastructure that consolidates multiple routing functions into a single physical device. It helps leverage the benefits of virtualization without compromising on performance. In particular, Junos node slicing enables the convergence of multiple services on a single physical infrastructure while avoiding the operational complexity involved. It provides operational, functional, and administrative separation of functions on a single physical infrastructure that enables the network to implement the same virtualization principles the compute industry has been using for years.
Using Junos node slicing, you can create multiple partitions in a single physical MX Series router. These partitions are referred to as guest network functions (GNFs). Each GNF behaves as an independent router, with its own dedicated control plane, data plane, and management plane. This enables you to run multiple services on a single converged MX Series router, while still maintaining operational isolation between them. You can leverage the same physical device to create parallel partitions that do not share the control plane or the forwarding plane, but only share the same chassis, space, and power.
You can also send traffic between GNFs through the switch fabric by using an Abstracted Fabric (af) interface, a pseudo interface that behaves as a first class Ethernet interface. An Abstracted Fabric interface facilitates routing control, data, and management traffic between GNFs.
Junos node slicing offers two models - an external server model and an in-chassis model. In the external server model, the GNFs are hosted on a pair of industry-standard x86 servers. For the in-chassis model, the GNFs are hosted on the Routing Engines of the MX Series router itself.
Junos node slicing supports multiversion software compatibility, thereby allowing the GNFs to be independently upgraded.
Benefits of Junos Node Slicing
Converged network—With Junos node slicing, service providers can consolidate multiple network services, such as video edge and voice edge, into a single physical router, while still maintaining operational separation between them. You can achieve both horizontal and vertical convergence. Horizontal convergence consolidates router functions of the same layer to a single router, while vertical convergence collapses router functions of different layers into a single router.
Improved scalability—Focusing on virtual routing partitions, instead of physical devices, improves the programmability and scalability of the network, enabling service providers and enterprises to respond to infrastructure requirements without having to buy additional hardware.
Easy risk management—Though multiple network functions converge on a single chassis, all the functions run independently, benefiting from operational, functional, and administrative separation. Partitioning a physical system, such as Broadband Network Gateway (BNG), into multiple independent logical instances ensures that failures are isolated. The partitions do not share the control plane or the forwarding plane, but only share the same chassis, space, and power. This means failure in one partition does not cause any widespread service outage.
Reduced network costs—Junos node slicing enables interconnection of GNFs through internal switching fabrics, which leverages Abstracted Fabric (af) interface, a pseudo interface that represents a first class Ethernet interface behavior. With af interface in place, companies no longer need to depend on physical interfaces to connect GNFs, resulting in significant savings.
Reduced time-to-market for new services and capabilities—Each GNF can operate on a different Junos software version. This advantage enables companies to evolve each GNF at its own pace. If a new service or a feature needs to be deployed on a certain GNF, and it requires a new software release, only the GNF involved requires an update. Additionally, with the increased agility, Junos node slicing enables service providers and enterprises to introduce highly flexible Everything-as-a-service business model to rapidly respond to ever-changing market conditions.
Components of Junos Node Slicing
Junos node slicing allows a single MX Series router to be partitioned to appear as multiple, independent routers. Each partition has its own Junos OS control plane, which runs as a virtual machine (VM), and a dedicated set of line cards. Each partition is called a guest network function (GNF).
The MX Series router functions as the base system (BSYS). The BSYS owns all the physical components of the router, including the line cards and the switching fabric. The BSYS assigns line cards to GNFs.
The Juniper Device Manager (JDM) software orchestrates the GNF VMs. In JDM, a GNF VM is referred to as a virtual network function (VNF). A GNF thus comprises a VNF and a set of line cards.
Through configuration at the BSYS, you can assign line cards of the chassis to different GNFs.
Junos node slicing supports two models:
External server model
In the external server model, JDM and VNFs are hosted on a pair of external industry standard x86 servers.
Figure 1 shows three GNFs with their dedicated line cards running on an external server.
See Connecting the Servers and the Router for information about how to connect an MX Series router to a pair of external x86 servers.
In the in-chassis model, all components (JDM, BSYS, as well as GNFs) run within the Routing Engine of the MX Series router. See Figure 2.
Base System (BSYS)
In Junos node slicing, the MX Series router functions as the base system (BSYS). The BSYS owns all the physical components of the router, including all line cards and fabric. Through Junos OS configuration at the BSYS, you can assign line cards to GNFs and define Abstracted Fabric (af) interfaces between GNFs. The BSYS software runs on a pair of redundant Routing Engines of the MX Series router.
Guest Network Function (GNF)
A guest network function (GNF) logically owns the line cards assigned to it by the base system (BSYS), and maintains the forwarding state of the line cards. You can configure multiple GNFs on an MX Series router (see Configuring Guest Network Functions). The Junos OS control plane of each GNF runs as a virtual machine (VM). The Juniper Device Manager (JDM) software orchestrates the GNF VMs. In the JDM context, the GNFs are referred to as virtual network functions (VNF).
A GNF is equivalent to a standalone router. GNFs are configured and administered independently, and are operationally isolated from each other.
Creating a GNF requires two sets of configurations, one to be performed at the BSYS, and the other at the JDM.
A GNF is defined by an ID. This ID must be the same at the BSYS and JDM.
The BSYS part of the GNF configuration comprises giving it an ID and a set of line cards.
The JDM part of the GNF configuration comprises specifying the following attributes:
A VNF name.
A GNF ID. This ID must be the same as the GNF ID used at the BSYS.
The MX Series platform type (for the external server model).
A Junos OS image to be used for the VNF.
The VNF server resource template.
The server resource template defines the number of dedicated (physical) CPU cores and the size of DRAM to be assigned to a GNF. For a list of predefined server resource templates available for GNFs, see the Server Hardware Resource Requirements (Per GNF) section in Minimum Hardware and Software Requirements for Junos Node Slicing.
After a GNF is configured, you can access it by connecting to the virtual console port of the GNF. Using the Junos OS CLI at the GNF, you can then configure the GNF system properties such as hostname and management IP address, and subsequently access it through its management port.
Juniper Device Manager (JDM)
The Juniper Device Manager (JDM), a virtualized Linux container, enables provisioning and management of the GNF VMs.
JDM supports Junos OS-like CLI, NETCONF for configuration and management and SNMP for monitoring.
In the in-chassis model, JDM does not support SNMP.
A JDM instance is hosted on each of the x86 servers in the external server model, and on each Routing Engine for the in-chassis model. The JDM instances are typically configured as peers that synchronize the GNF configurations: when a GNF VM is created on one server, its backup VM is automatically created on the other server or Routing Engine.
An IP address and an administrator account need to be configured on the JDM. After these are configured, you can directly log in to the JDM.
Abstracted Fabric Interface
Abstracted Fabric (af) interface is a pseudo interface that represents a first class Ethernet interface behavior. An af interface facilitates routing control and management traffic between guest network functions (GNFs) through the switch fabric. An af interface is created on a GNF to communicate with its peer GNF when the two GNFs are configured to be connected to each other. Abstracted Fabric interfaces must be created at BSYS. The bandwidth of the af interfaces changes dynamically based on the insertion or reachability of the remote line card/MPC. Because the fabric is the communication medium between GNFs, af interfaces are considered to be the equivalent WAN interfaces. See Figure 3.
Understanding Abstracted Fabric Interface Bandwidth
An Abstracted Fabric (af) interface connects two GNFs through the fabric and aggregates all the Packet Forwarding Engines (PFEs) that connect the two GNFs. An af interface can leverage the sum of the bandwidth of each Packet Forwarding Engine belonging to the af interface.
For example, if GNF1 has one MPC8 (which has four Packet Forwarding Engines with 240 Gbps capacity each), and GNF1 is connected with GNF2 and GNF3 using af interfaces (af1 and af2), the maximum af interface capacity on GNF1 would be 4x240 Gbps = 960 Gbps.
Here, af1 and af2 share the 960 Gbps capacity.
For information on the bandwidth supported on each MPC, see Table 1.
Features Supported on Abstracted Fabric Interfaces
Abstracted Fabric interfaces support the following features:
Unified in-service software upgrade (ISSU).
Abstracted Fabric interfaces do not support ISSU on MPC11E line cards.
Hyper mode configuration at the BSYS level (starting in Junos OS Release 19.3R2). This feature is supported on MPC6E, MPC8E, MPC9E, and MPC11E line cards.
You cannot have different hyper mode configurations for individual GNFs as they inherit the configuration from the BSYS.
The MX2020 and MX2010 routers with SFB3 come up in hyper mode by default. If you require hyper mode to be disabled at any GNF, you must configure it at the BSYS, and it will apply to all GNFs of that chassis.
Load balancing based on the remote GNF line cards present
Class of service (CoS) support:
Inet-precedence classifier and rewrite
DSCP classifier and rewrite
MPLS EXP classifier and rewrite
DSCP v6 classifier and rewrite for IP v6 traffic
Support for OSPF, IS-IS, BGP, OSPFv3 protocols, and L3VPN
The non-af interfaces support all the protocols that work on Junos OS.
Graceful Routing Engine switchover (GRES)
MPLS applications where the af interface acts as a core interface (L3VPN, VPLS, L2VPN, L2CKT, EVPN, and IP over MPLS)
The following protocol families are supported:
Junos Telemetry Interface (JTI) sensor support
The MPC11E line card does not support Abstracted Fabric interface fabric-stats sensor.
Starting in Junos OS Release 19.1R1, guest network functions (GNFs) support Ethernet VPNs (EVPN) with Virtual Extensible LAN protocol (VXLAN) encapsulation. This support is available with non-af (that is, physical) interface and af interface as the core facing interface. This support is not available for the MPC11E line card.
With the af interface configuration, GNFs support af-capable MPCs. Table 1 lists the af-capable MPCs, the number of PFEs supported per MPC, and the bandwidth supported per MPC.
Table 1: Supported Abstracted Fabric-capable MPCs
Number of PFEs
MPC2E NG Q
MPC3E NG Q
2x100GE + 8x10GE MPC4E
Multiservices MPC (MS-MPC)
A GNF that does not have the af interface configuration supports all the MPCs that are supported by a standalone MX Series router. For the list of supported MPCs, see MPCs Supported by MX Series Routers.
We recommend that you set the MTU settings on the af interface to align to the maximum allowed value on the XE/GE interfaces. This ensures minimal or no fragmentation of packets over the af interface.
Abstracted Fabric Interface Restrictions
The following are the current restrictions of Abstracted Fabric interfaces:
Configurations such as single endpoint af interface, af interface-to-GNF mapping mismatch or multiple af interfaces mapping to same remote GNF are not checked during commit on the BSYS. Ensure that you have the correct configurations.
Bandwidth allocation is static, based on the MPC type.
There can be minimal traffic drops (both transit and host) during the offline/restart of an MPC hosted on a remote GNF.
Interoperability between MPCs that are af-capable and the MPCs that are not af-capable is not supported.
Optimizing Fabric Path for Abstracted Fabric Interface
You can optimize the traffic flowing over the abstracted fabric (af) interfaces between two guest network functions (GNFs), by configuring a fabric path optimization mode. This feature reduces fabric bandwidth consumption by preventing any additional fabric hop (switching of traffic flows from one Packet Forwarding Engine to another) before the packets eventually reach the destination Packet Forwarding Engine. Fabric path optimization, supported on MX2008, MX2010, and MX2020 with MPC9E and MX2K-MPC11E, prevents only a single additional traffic hop that results from abstracted fabric interface load balancing.
You can configure one of the following fabric path optimization modes:
monitor—If you configure this mode, the peer GNF monitors the traffic flow and sends information to the source GNF about the Packet Forwarding Engine to which the traffic is being forwarded currently and the desired Packet Forwarding Engine that could provide an optimized traffic path. In this mode, the source GNF does not forward the traffic towards the desired Packet Forwarding Engine.
optimize—If you configure this mode, the peer GNF monitors the traffic flow and sends information to the source GNF about the Packet Forwarding Engine to which the traffic is being forwarded currently and the desired Packet Forwarding Engine that could provide an optimized traffic path. The source GNF then forwards the traffic towards the desired Packet Forwarding Engine.
To configure a fabric path optimization mode, use the following CLI commands at BSYS.
user@router# set chassis network-slices guest-network-functions gnf id af-name collapsed-forward (monitor | optimize)
After configuring fabric path optimization, you can use the command show interfaces af-interface-name in GNF to view the number of packets that are currently flowing on the optimal / non-optimal path.
Choosing Between External Server Model and In-Chassis Model
The external server model allows you to configure more instances of GNFs with higher scale, since you can choose a server of sufficient capacity to match GNF requirements. With the in-chassis model, the number of GNFs that can be configured is a function of the scale requirements of the constituent GNFs and the overall capacity of the Routing Engine.
The external server and in-chassis models of Junos node slicing are mutually exclusive. An MX Series router can be configured to operate in only one of these models at one time.
Mastership Behavior of BSYS and GNF
The following sections address the mastership behavior of BSYS and GNF in the context of Routing Engine redundancy.
Figure 4 shows the mastership behavior of GNF and BSYS with Routing Engine redundancy.
The BSYS Routing Engine mastership arbitration behavior is identical to that of Routing Engines on MX Series routers.
The GNF VM mastership arbitration behavior is similar to that of MX Series Routing Engines. Each GNF runs as a master-backup pair of VMs. A GNF VM that runs on server0 (or re0 for in-chassis) is equivalent to Routing Engine slot 0 of an MX Series router, and the GNF VM that runs on server1 (or re1 for in-chassis) is equivalent to Routing Engine slot 1 of an MX Series router.
The GNF mastership is independent of the BSYS mastership and that of other GNFs. The GNF mastership arbitration is done through Junos OS. Under connectivity failure conditions, GNF mastership is handled conservatively.
The GNF mastership model is the same for both external server and in-chassis models.
As with the MX Series Routing Engines, you must configure graceful Routing Engine switchover (GRES) at each GNF. This is a prerequisite for the backup GNF VM to automatically take over the mastership when the master GNF VM fails or is rebooted.
Junos Node Slicing Administrator Roles
The following administrator roles enable you to carry out the node slicing tasks:
BSYS administrator—Responsible for the physical chassis, as well as for GNF provisioning (assignment of line cards to GNFs). Junos OS CLI commands are available for these tasks.
GNF administrator—Responsible for configuration, operation, and management of Junos OS at the GNF. All regular Junos OS CLI commands are available to the GNF administrator for these tasks.
JDM administrator—Responsible for the JDM server port configuration (for the external server model), and for the provisioning and life-cycle management of the GNF VMs (VNFs). JDM CLI commands are available for these tasks.
Multiversion Software Interoperability Overview
Starting from Junos OS Release 17.4R1, Junos node slicing supports multiversion software compatibility, enabling the BSYS to interoperate with a guest network function (GNF) which runs a Junos OS version that is higher than the software version of the BSYS. This feature supports a range of up to two versions between GNF and BSYS. That is, the GNF software can be two versions higher than the BSYS software. Both BSYS and GNF must meet a minimum version requirement of Junos OS Release 17.4R1.
The restrictions in multiversion support are also applicable to the unified ISSU upgrade process.
While JDM software versioning does not have a similar restriction with respect to the GNF or BSYS software versions, we recommend that you regularly update the JDM software. A JDM upgrade does not affect any of the running GNFs.
Next Gen Services on Junos node slicing
Junos node slicing supports MX-SPC3 Services Card, a security services card that provides additional processing power to run the Next Gen Services on the MX platforms. You can enable Next Gen Services at guest network function (GNF), by using the CLI request system enable unified-services at GNF. To support an MX-SPC3, a GNF must have a line card associated with it.
In a Junos node slicing setup, you can use both MX-SPC3 and MS-MPC on the same chassis but on different GNF Routing Engines. If you have enabled Next Gen Services at GNF, by using request system enable unified-services, the MX-SPC3 comes online. If you have not enabled Next Gen Services, the MS-MPC comes online.
The software installation or upgrade of an MX-SPC3 card happens when you install or upgrade the associated GNF Routing Engine.
The MX-SPC3 does not support abstracted fabric interfaces. Therefore, a GNF that has an MX-SPC3 card linked to it must also have a line card associated with it.
Comparing Junos Node Slicing with Logical Systems
Junos node slicing is a layer below logical systems in Junos. Both technologies have some overlapping capabilities but differ in other aspects. With Junos node slicing, complete line cards, and therefore, physical interfaces, are assigned to a GNF, while with logical systems, a single physical interface itself can be shared across different logical systems, since multiple logical interfaces defined over a physical interface can all be assigned to separate logical systems. This means, logical systems allow finer granularity of sharing than Junos node slicing. But all logical systems share a single Junos kernel, thus necessarily running the same Junos version, besides having to share the Routing Engine and line card physical resources such as CPU, memory and storage. With Junos node slicing, each GNF gets its own equivalent of a pair of Routing Engines, as also line cards dedicated to that GNF, so the GNFs do not share most physical resources – they only share the chassis and switch fabric. GNFs, unlike logical systems, can be independently upgraded and administered like a MX standalone router.
Junos node slicing is a technology that complements, and even augments logical systems, since a GNF can itself have multiple logical systems within it. Where physical isolation, guaranteed resources and complete administrative isolation is paramount, Junos node slicing would be a better match. And where fine granularity of sharing, down to the logical interface level, is paramount, a logical system would be the better match.
Licensing for Junos Node Slicing
Operating Junos node slicing requires licenses for the GNFs and Abstracted Fabric interfaces to be installed at the BSYS. Running a GNF without a license installed at the BSYS will result in the following syslog message and minor alarm:
CHASSISD_LICENSE_EVENT: License Network-Slices: Failed to get valid license('216') 'gnf-creation' Minor alarm set, 1 Guest network functions creation for JUNOS requires a license.
Please contact Juniper Networks if you have queries pertaining to Junos node slicing licenses.