- play_arrow Junos Node Slicing Overview
- play_arrow Upgrading and Managing Junos Node Slicing
- play_arrow Configuration Statements and Operational Commands
ON THIS PAGE
Configuring an MX Series Router to Operate in BSYS Mode (External Server Model)
Installing JDM RPM Package on x86 Servers Running RHEL (External Server Model)
Installing JDM Ubuntu Package on x86 Servers Running Ubuntu 20.04 (External Server Model)
Configuring Abstracted Fabric Interfaces Between a Pair of GNFs
SNMP Trap Support: Configuring NMS Server (External Server Model)
Setting Up Junos Node Slicing
Before proceeding to perform the Junos node slicing setup tasks, if you are using the external server model, you must have completed the procedures described in the chapter Preparing for Junos Node Slicing Setup.
Configuring an MX Series Router to Operate in BSYS Mode (External Server Model)
Ensure that the MX Series router is connected to the x86 servers as described in Connecting the Servers and the Router.
Junos node slicing requires the MX Series router to function as the base system (BSYS).
Use the following steps to configure an MX Series router to operate in BSYS mode:
A router in the BSYS mode is not expected to run features other than the ones required to run the basic management functionalities in Junos node slicing. For example, the BSYS is not expected to have interface configurations associated with the line cards installed in the system. Instead, guest network functions (GNFs) will have the full-fledged router configurations.
Installing JDM RPM Package on x86 Servers Running RHEL (External Server Model)
Before installing the JDM RPM package for x86 servers, ensure that you have installed the additional packages, as described in Installing Additional Packages for JDM.
Download and install the JDM RPM package for x86 servers running RHEL as follows:
To install the package on x86 servers running RHEL, perform the following steps on each of the servers:
Repeat the steps for the second server.
Installing JDM Ubuntu Package on x86 Servers Running Ubuntu 20.04 (External Server Model)
Before installing the JDM Ubuntu package for x86 servers, ensure that you have installed the additional packages. For more details, see Installing Additional Packages for JDM.
Download and install the JDM Ubuntu package for x86 servers running Ubuntu 20.04 as follows:
To install the JDM package on the x86 servers running Ubuntu 20.04, perform the following steps on each of the servers:
Repeat the steps for the second server.
Configuring JDM on the x86 Servers (External Server Model)
Use the following steps to configure JDM on each of the x86 servers.
Configuring Non-Root Users in JDM (Junos Node Slicing)
In the external server model, you can create non-root users on Juniper Device Manager (JDM) for Junos node slicing, starting in Junos OS Release 18.3R1. You need a root account to create a non-root user. The non-root users can log in to JDM by using the JDM console or through SSH. Each non-root user is provided a username and assigned a predefined login class.
The non-root users can perform the following functions:
Interact with JDM.
Orchestrate and manage Guest Network Functions (GNFs).
Monitor the state of the JDM, the host server and the GNFs by using JDM CLI commands.
The non-root user accounts function only inside JDM, not on the host server.
To create non-root users in JDM:
Table 1 contains the predefined login classes that JDM supports for non-root users:
Login Class | Permissions |
|---|---|
super-user |
|
operator |
|
read-only | Similar to operator class, except that the users cannot restart daemons inside JDM. |
unauthorized | Ping and traceroute operations. |
Configuring JDM interfaces (External Server Model)
If you want to modify the server interfaces configured in the JDM, perform the following steps:
In the JDM, you must configure:
The two 10-Gbps server ports that are connected to the MX Series router.
The server port to be used as the JDM management port.
The server port to be used as the GNF management port.
Therefore, you need to identify the following on each server before starting the configuration of the ports:
The server interfaces (for example,
p3p1andp3p2) that are connected toCB0andCB1on the MX Series router.The server interfaces (for example,
em2andem3) to be used for JDM management and GNF management.
For more information, see the figure Connecting the Servers and the Router.
You need this information for both
server0andserver1.These interfaces are visible only on the Linux host.
To configure the x86 server interfaces in JDM, perform the following steps on both the servers:
For sample JDM configurations, see Sample Configuration for Junos Node Slicing.
If you want to modify the server interfaces configured in the JDM, you need to delete the GNFs (if they were configured), configure the interfaces as described above, reboot JDM from shell, reconfigure and activate the GNFs, and commit the changes,
Starting in Junos OS Release 19.2R1, Junos node slicing supports the assignment of a globally unique MAC address range (supplied by Juniper Networks) for GNFs. .
Configuring MX Series Router to Operate in In-Chassis Mode
To configure in-chassis Junos node slicing, the MX Series router must have one of the following types of Routing Engines installed:
RE-S-X6-128G (used in MX480 and MX960 routers)
REMX2K-X8-128G (used in MX2010 and MX2020 routers)
REMX2008-X8-128G (used in MX2008 routers)
In in-chassis model, the base system (BSYS), Juniper Device Manager (JDM), and all guest network functions (GNFs) run within the Routing Engine of the MX Series router. BSYS and GNFs run on the host as virtual machines (VMs). You need to first reduce the resource footprint of the standalone MX Series router as follows:
All files in the /var/ location, including the log files (/var/log) and core files (/var/crash), are
deleted when you reboot VM host after configuring the set vmhost
resize vjunos compact statement. You must save any files currently
in /var/log or /var/crash before proceeding with the VM host resize configuration if you want
to use them for reference.
Installing and Configuring JDM for In-Chassis Model
Steps listed in this topic apply only to in-chassis Junos node slicing configuration.
- Installing JDM RPM Package on MX Series Router (In-Chassis Model)
- Configuring JDM (In-Chassis Model)
Installing JDM RPM Package on MX Series Router (In-Chassis Model)
Before installing the Juniper Device Manager (JDM) RPM package on an MX Series router, you must configure the MX Series router to operate in the in-chassis BSYS mode. For more information, see Configuring MX Series Router to Operate in In-Chassis Mode.
The RPM package jns-jdm-vmhost is meant for
in-chassis Junos node slicing deployment, while the RPM package jns-jdm is used for external servers based Junos node slicing
deployment.
Configuring JDM (In-Chassis Model)
Use the following steps to configure JDM on both the Routing Engines of an MX Series router:
In in-chassis Junos node slicing, you cannot ping or send traffic between the management interfaces of the same Routing Engine (for example, from the Routing Engine 0 of GNF1 to the Routing Engine 0 of GNF2 or from the Routing Engine 0 of GNF1 to JDM).
In in-chassis mode, you cannot perform an
scpoperation between the BSYS and the JDM management interfaces.You must have done the ssh key exchange as described in the Step 7 before attempting the Step 8. If you attempt the Step 8 without completing the Step 7, the system displays an error message as shown in the following example:
Failed to fetch JDM software version from server1. If authentication of peer server is not done yet, try running request server authenticate-peer-server.
Starting in Junos OS Release 19.2R1, Junos node slicing supports the assignment of a globally unique MAC address range (supplied by Juniper Networks) for GNFs. .
Assigning MAC Addresses to GNF
Starting in Junos OS Release 19.2R1, Junos node slicing supports the assignment of a globally unique MAC address range (supplied by Juniper Networks) for GNFs.
To receive the globally unique MAC address range for the GNFs, contact your Juniper Networks representative and provide your GNF license SSRN (Software Support Reference Number), which will have been shipped to you electronically upon your purchase of the GNF license. To locate the SSRN in your GNF license, refer to the Juniper Networks Knowledge Base article KB11364.
For each GNF license, you will then be provided an ‘augmented SSRN’, which includes the globally unique MAC address range assigned by Juniper Networks for that GNF license. You must then configure this augmented SSRN at the JDM CLI as follows:
root@jdm#set system vnf-license-supplement vnf-id gnf-id license-supplement-string augmented-ssrn-stringroot@jdm#commit
An augmented SSRN must be used for only one GNF ID. In the JDM, the GNF VMs are referred to as virtual network functions (VNFs). GNF ID is one of its attributes. Attributes of a VNF are fully described in the follow-on section Configuring Guest Network Functions.
By default, the augmented SSRN will be validated. Should you ever need to skip this validation, you can use the no-validate attribute in the CLI as follows: Example:
set system vnf-license-supplement vnf-id gnf-id license-supplement-string augmented-ssrn-string [no-validate].
You can configure the augmented SSRN for a GNF ID only when the GNF is not operational and has not yet been provisioned as well. You must first configure the augmented SSRN for a GNF ID before configuring the GNF. If the GNF ID is already provisioned, you must first delete the GNF for that GNF ID on both the servers (in case of the external server model) or on both the Routing Engines (in case of the in-chassis Junos node slicing model) before configuring the augmented SSRN.
Similarly, you must first delete the GNF for a given GNF ID on both the servers (in case of the external server model) or on both the Routing Engines (in case of the in-chassis Junos node slicing model) before deleting the augmented SSRN for the GNF ID.
You cannot apply an augmented SSRN to a GNF that is based on Junos OS 19.1R1 or older.
To confirm that the assigned MAC address range for a GNF has been applied, when the GNF becomes operational, use the Junos CLI command
show chassis mac-addresses- the output will match a substring of the augmented SSRN.
Configuring Guest Network Functions
Configuring a guest network function (GNF) comprises two tasks, one to be performed at the BSYS and the other at the JDM.
- Before attempting to create a GNF, you must ensure that you have configured
commit synchronization as part of JDM configuration so that the random MAC
prefixes generated by the JDM instances are in sync. To check if the random
MAC prefixes are in sync, use the CLI command
show server connectionsorshow system random-mac-prefixat JDM. If the random MAC prefixes are not in sync, the software raises the following major alarm:Mismatched MAC address pool between GNF RE0 and GNF RE1. To view the alarm, use the show system alarms command. Before attempting to create a GNF, you must ensure that the servers (or Routing Engines in the case of in-chassis model) have sufficient resources (CPU, memory, storage) for that GNF.
You need to assign an ID to each GNF. This ID must be the same at the BSYS and the JDM.
At the BSYS, specify a GNF by assigning it an ID and a set of line cards by applying the configuration as shown in the following example:
user@router# set chassis network-slices guest-network-functions
gnf 1 fpcs 4
user@router# commit
In the JDM, the GNF VMs are referred to as virtual network functions (VNFs). A VNF has 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.
A Junos OS image to be used for the GNF, which can be downloaded from the Juniper Downloads page.
From the Downloads page, select All Products > Junos Node Slicing - Guest Network Function to download a Junos image for the GNF.
The VNF server resource template.
At the JDM, to configure a VNF, perform the following steps:
Use the JDM shell command
scpto retrieve the Junos OS Node Slicing image for GNF and place it in the JDM local directory /var/jdm-usr/gnf-images (repeat this step to retrieve the GNF configuration file).content_copy zoom_out_maproot@jdm:~#
scp source-location-of-the-gnf-image /var/jdm-usr/gnf-imagesroot@jdm:~#scp source-location-of-the-gnf-configuration-file /var/jdm-usr/gnf-configAssign this image to a GNF by using the JDM CLI command as shown in the following example:
content_copy zoom_out_maproot@test-jdm-server0>
request virtual-network-functions test-gnf add-image /var/jdm-usr/gnf-images/junos-install-ns-mx-x86-64-17.4R1.10.tgz all-serversServer0: Added image: /vm-primary/test-gnf/test-gnf.img Server1: Added image: /vm-primary/test-gnf/test-gnf.imgConfigure the VNF by applying the configuration statements as shown in the following example:
root@test-jdm-server0#
set virtual-network-functionstest-gnfid1root@test-jdm-server0#
set virtual-network-functionstest-gnfchassis-type mx2020root@test-jdm-server0#
set virtual-network-functionstest-gnfresource-template2core-16groot@test-jdm-server0#
set system vnf-license-supplement vnf-id 1 license-supplement-string RTU00023003204-01-AABBCCDDEE00-1100-01-411CFor in-chassis model, do not configure the platform type (
set virtual-network-functionstest-gnfchassis-type mx2020). It will be detected automatically.Starting in Junos OS Release 19.2R1, Junos node slicing supports the assignment of a globally unique MAC address range (supplied by Juniper Networks) for GNFs.
To also specify a baseline or initial Junos OS configuration for a GNF, prepare the GNF configuration file (example: /var/jdm-usr/gnf-config/test-gnf.conf) on both the servers (server0 and server1) for external server model, and on both the Routing Engines (re0 and re1) for the in-chassis model, and specify the filename as the parameter in the
base-configstatement as shown below:root@test-jdm-server0#
set virtual-network-functions test-gnf base-config /var/jdm-usr/gnf-config/test-gnf.confroot@test-jdm-server0#
commit synchronizeNote:Ensure that:
You use the same GNF ID as the one specified earlier in BSYS.
The baseline configuration filename (with the path) is the same on both the servers / Routing Engines.
The syntax of the baseline file contents is in the Junos OS configuration format.
The GNF name used here is the same as the one assigned to the Junos OS image for GNF in the step 2.
To verify that the VNF is created, run the following JDM CLI command:
root@test-jdm-server0>
show virtual-network-functions test-gnfLog in to the console of the VNF by issuing the following JDM CLI command:
root@test-jdm-server0>
request virtual-network-functions test-gnf consoleNote:Remember to log out of the VNF console after your have completed your configuration tasks. We recommend that you set an idle time-out using the command
set system login idle-timeout minutes. Otherwise, if a user forgets to log out of the VNF console session, another user can log in without providing the access credentials. For more information, see system login (Junos Node Slicing).Configure the VNF the same way as you configure an MX Series Routing Engine.
The CLI prompt for in-chassis model is
root@jdm#.For sample configurations, see Sample Configuration for Junos Node Slicing.
In the case of the external server model, if you had previously brought down any physical x86 CB interfaces or the GNF management interface from Linux shell (by using the command
ifconfig interface-name down), these will automatically be brought up when the GNF is started.
Configuring Abstracted Fabric Interfaces Between a Pair of GNFs
Creating an abstracted fabric (af) interface between two guest network functions
(GNFs) involves configurations both at the base system (BSYS) and at the GNF. Abstracted
fabric interfaces are created on GNFs based on the BSYS configuration, which is then
sent to those GNFs.
Only one
afinterface can be configured between a pair of GNFs.- In a Junos node slicing setup where each GNF is assigned with a single FPC, if
the Packet Forwarding Engines of the FPC assigned to the remote GNF becomes
unreachable over fabric, the associated
abstracted
fabric
interface goes down. Examples of errors that could cause this behavior include
pfe fabric reachability errors and cmerror events causing
pfe disableaction (use theshow chassis fpc errorscommand for the details). If a GNF has multiple FPCs assigned to it, the local FPCs that report all peer Packet Forwarding Engines to be down are removed from determining the abstracted fabric interface state.
To configure af interfaces between a pair
of GNFs:
At the BSYS, apply the configuration as shown in the following example:
content_copy zoom_out_mapuser@router#
set chassis network-slices guest-network-functions gnf 2 af4 peer-gnf id 4user@router#set chassis network-slices guest-network-functions gnf 2 af4 peer-gnf af2user@router#set chassis network-slices guest-network-functions gnf 4 af2 peer-gnf id 2user@router#set chassis network-slices guest-network-functions gnf 4 af2 peer-gnf af4In this example,
af2is the abstracted fabric interface instance 2 andaf4is the abstracted fabric interface instance 4.Note:The allowed
afinterface values range fromaf0throughaf9.The GNF
afinterface will be visible and up. You can configure anafinterface the way you configure any other interface.At the GNF, apply the configuration as shown in the following example:
content_copy zoom_out_mapuser@router-gnf-b#
set interfaces af4 unit 0 family inet address 10.10.10.1/24user@router-gnf-d#set interfaces af2 unit 0 family inet address 10.10.10.2/24
If you want to apply MPLS family configurations on the
afinterfaces, you can apply the commandset interfaces af-name unit logical-unit-number family mplson both the GNFs between which theafinterface is configured.For sample
afconfigurations, see Sample Configuration for Junos Node Slicing.
Class of Service on Abstracted Fabric Interfaces
Class of service (CoS) packet classification assigns an incoming packet to an output queue based on the packet’s forwarding class. See CoS Configuration Guide for more details.
The following sections explain the forwarding class- to-queue mapping, and the behavior aggregate
(BA) classifiers and rewrites supported on the abstracted fabric
(af) interfaces.
Forwarding Class-to-Queue Mapping
An af interface is a simulated WAN interface with
most capabilities of any other interface except that the traffic designated
to a remote Packet Forwarding Engine will still have to go over the
two fabric queues (Low/High priority ones).
Presently, an af interface operates in 2-queue mode
only. Hence, all queue-based features such as scheduling, policing,
and shaping are not available on an af interface.
Packets on the af interface inherit the fabric queue
that is determined by the fabric priority configured for the forwarding
class to which that packet belongs. For example, see the following
forwarding class to queue map configuration:
[edit]
user@router# show class-of-service forwarding-classes
class Economy queue-num 0 priority low; /* Low fabric priority */
class Stream queue-num 1;
class Business queue-num 2;
class Voice queue-num 3;
class NetControl queue-num 3;
class Business2 queue-num 4;
class Business3 queue-num 5;
class VoiceSig queue-num 6 priority high; /* High fabric priority */
class VoiceRTP queue-num 7;
As shown in the preceding example, when a packet gets classified
to the forwarding class VoiceSig, the code in the forwarding
path examines the fabric priority of that forwarding class and decides
which fabric queue to choose for this packet. In this case, high-priority
fabric queue is chosen.
BA Classifiers and Rewrites
The behavior aggregate (BA) classifier maps a class-of-service (CoS) value to a forwarding class and loss priority. The forwarding class and loss-priority combination determines the CoS treatment given to the packet in the router. The following BA classifiers and rewrites are supported:
Inet-Precedence classifier and rewrite
DSCP classifier and rewrite
MPLS EXP classifier and rewrite
You can also apply rewrites for IP packets entering the MPLS tunnel and do a rewrite of both EXP and IPv4 type of service (ToS) bits. This approach will work as it does on other normal interfaces.
DSCP v6 classifier and rewrite for IP v6 traffic
The following are not supported:
IEEE 802.1 classification and rewrite
IEEE 802.1AD (QinQ) classification and rewrite
See CoS Configuration Guide for details on CoS BA classifiers.
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)user@router#commit
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.
See Also
SNMP Trap Support: Configuring NMS Server (External Server Model)
The Juniper Device Manager (JDM) supports the following SNMP traps:
LinkUp and linkDown traps for JDM interfaces.
Standard linkUp/linkDown SNMP traps are generated. A default community string
jdmis used.LinkUp/linkDown traps for host interfaces.
Standard
linkUp/linkDownSNMP traps are generated. A default community stringhostis used.JDM to JDM connectivity loss/regain traps.
JDM to JDM connectivity loss/regain traps are sent using generic syslog traps (jnxSyslogTrap) through the host management interface.
The JDM connectivity down trap
JDM_JDM_LINK_DOWNis sent when the JDM is not able to communicate with the peer JDM on another server overcb0orcb1links. See the following example:content_copy zoom_out_map{ SNMPv2c C=host { V2Trap(296) R=1299287309 .1.3.6.1.2.1.1.3.0=42761992 .1.3.6.1.6.3.1.1.4.1.0=.1.3.6.1.4.1.2636.4.12.0.1 .1.3.6.1.4.1.2636.3.35.1.1.1.2.1="JDM_JDM_LINK_DOWN" .1.3.6.1.4.1.2636.3.35.1.1.1.3.1="" .1.3.6.1.4.1.2636.3.35.1.1.1.4.1=5 .1.3.6.1.4.1.2636.3.35.1.1.1.5.1=24 .1.3.6.1.4.1.2636.3.35.1.1.1.6.1=0 .1.3.6.1.4.1.2636.3.35.1.1.1.7.1="jdmmon" .1.3.6.1.4.1.2636.3.35.1.1.1.8.1="JDM-HOST" .1.3.6.1.4.1.2636.3.35.1.1.1.9.1="JDM to JDM Connection Lost" .1.3.6.1.6.3.1.1.4.3.0.0=”” } }The JDM to JDM Connectivity up trap
JDM_JDM_LINK_UPis sent when either thecb0orcb1link comes up, and JDMs on both the servers are able to communicate again. See the following example:content_copy zoom_out_map{ SNMPv2c C=host { V2Trap(292) R=998879760 .1.3.6.1.2.1.1.3.0=42762230 .1.3.6.1.6.3.1.1.4.1.0=.1.3.6.1.4.1.2636.4.12.0.1 .1.3.6.1.4.1.2636.3.35.1.1.1.2.1="JDM_JDM_LINK_UP" .1.3.6.1.4.1.2636.3.35.1.1.1.3.1="" .1.3.6.1.4.1.2636.3.35.1.1.1.4.1=5 .1.3.6.1.4.1.2636.3.35.1.1.1.5.1=24 .1.3.6.1.4.1.2636.3.35.1.1.1.6.1=0 .1.3.6.1.4.1.2636.3.35.1.1.1.7.1="jdmmon" .1.3.6.1.4.1.2636.3.35.1.1.1.8.1="JDM-HOST" .1.3.6.1.4.1.2636.3.35.1.1.1.9.1="JDM to JDM Connection Up" .1.3.6.1.6.3.1.1.4.3.0.0="" } }VM(GNF) up/down—
libvirtGuestNotifnotifications.For GNF start/shutdown events, the standard
libvirtGuestNotifnotifications are generated. ForlibvirtMIBnotification details, see this web page. Also, see the following example:content_copy zoom_out_mapHOST [UDP: [127.0.0.1]:53568->[127.0.0.1]]: Trap , DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (636682) 1:46:06.82, SNMPv2-MIB::snmpTrapOID.0 = OID: LIBVIRT-MIB::libvirtGuestNotif, LIBVIRT-MIB::libvirtGuestName.0 = STRING: "gnf1", LIBVIRT-MIB::libvirtGuestUUID.1 = STRING: 7ad4bc2a-16db-d8c0-1f5a-6cb777e17cd8, LIBVIRT-MIB::libvirtGuestState.2 = INTEGER: running(1), LIBVIRT-MIB::libvirtGuestRowStatus.3 = INTEGER: active(1)
SNMP traps are sent to the target NMS server. To configure the target NMS server details in the JDM, see the following example:
[edit]
root@jdm#show snmp | display setroot@jdm#set snmp name nameroot@jdm#set snmp description descriptionroot@jdm#set snmp location locationroot@jdm#set snmp contact user's emailroot@jdm#set snmp trap-group tg-1 targets target ip address1root@jdm#set snmp trap-group tg-1 targets target ip address2
JDM does not write any configuration to the host snmp configuration file (/etc/snmp/snmpd.conf). Hence, JDM installation and subsequent configuration do not have any impact on the host SNMP. The SNMP configuration CLI command in JDM is used only to configure the JDM’s snmpd.conf file which is present within the container. To generate linkUp/Down trap, you must manually include the configuration as shown in the following example in the host server’s snmpd.conf file (/etc/snmp/snmpd.conf):
createUser trapUser iquerySecName trapUser rouser trapUser defaultMonitors yes notificationEvent linkUpTrap linkUp ifIndex ifAdminStatus ifOperStatus ifDescr notificationEvent linkDownTrap linkDown ifIndex ifAdminStatus ifOperStatus ifDescr monitor -r 10 -e linkUpTrap "Generate linkUp" ifOperStatus != 2 monitor -r 10 -e linkDownTrap "Generate linkDown" ifOperStatus == 2 trap2sink <NMS-IP> host
In the above example, replace <NMS-IP> with the IP address of Network Management Station (NMS).
Chassis Configuration Hierarchy at BSYS and GNF
In Junos node slicing, the BSYS owns all the physical components
of the router, including the line cards and fabric, while the GNFs
maintain forwarding state on their respective line cards. In keeping
with this split responsibility, Junos CLI configuration under the chassis hierarchy (if any), should be applied at the BSYS or
at the GNF as follows:
Physical-level parameters under the
chassisconfiguration hierarchy should be applied at the BSYS. For example, the configuration for handling physical errors at an FPC is a physical-level parameter, and should therefore be applied at the BSYS.content_copy zoom_out_mapAt BSYS Junos CLI: [edit] user@router#
set chassis fpc fpc slot error major threshold threshold value action alarmLogical or feature-level parameters under the
chassisconfiguration hierarchy should be applied at the GNF associated with the FPC. For example, the configuration for max-queues per line card is a logical-level parameter, and should therefore be applied at the GNF.content_copy zoom_out_mapAt GNF Junos CLI: [edit] user@router#
set chassis fpc fpc slot max-queues valueAs exceptions, the following two parameters under the
chassisconfiguration hierarchy should be applied at both BSYS and GNF:content_copy zoom_out_mapAt both BSYS and GNF CLI: [edit] user@router#
set chassis network-services network services modeuser@router#set chassis fpc fpc slot flexible-queueing-mode
Configuring Sub Line Cards and Assigning Them to GNFs
For an overview of sub line cards, see Sub Line Card Overview.
This feature is applicable to the MPC11E line card (model number: MX2K-MPC11E) on the MX2010 and MX2020 routers used in the external server-based Junos node slicing setup.
Ensure that each Routing Engine of all GNFs and the BSYS run Junos OS Release 21.2R1 or later versions.
To slice an MPC11E further into sub line cards (SLCs), you must use the
fpc-slice CLI option under the set chassis
network-slices guest-network-functions gnf hierarchy in BSYS.
Before committing the configuration, you must configure all the SLCs supported by the line card and assign all the required resources such as core, DRAM and the Packet forwarding Engines to the SLCs. An MPC11E line card supports two SLCs.
GNFs support the following combinations of full line cards and SLCs:
GNF with MPC11E SLCs
GNF with MPC11E SLCs and MPC9
GNF with MPC11E SLCs and MPC11E
GNF with MPC11E SLCs, MPC9, MPC11E
To configure SLCs and assign them to GNFs, use the following steps:
You must configure all the following CLI statements at once for all the SLCs (as shown in the steps below). Any modification to this configuration later causes the entire line card to reboot.
- If you configure any incorrect values (for example, unsupported Packet Forwarding Engine ranges, CPU cores, or DRAM values), the configuration commit fails with an appropriate message to indicate the error.
See Also
Sample Configuration for Junos Node Slicing
This section provides sample configurations for Junos node slicing.
- Sample JDM Configuration (External Server Model)
- Sample JDM Configuration (In-Chassis Model)
- Sample BSYS Configuration with Abstracted Fabric Interface
- Sample Abstracted Fabric Configuration at GNF with Class of Service
- Sample Output for Abstracted Fabric Interface State at a GNF
Sample JDM Configuration (External Server Model)
root@test-jdm-server0> show configuration
groups {
server0 {
system {
host-name test-jdm-server0;
}
server {
interfaces {
cb0 p3p1;
cb1 p3p2;
jdm-management em2;
vnf-management em3;
}
}
interfaces {
jmgmt0 {
unit 0 {
family inet {
address 10.216.105.112/21;
}
}
}
}
routing-options {
static {
route {
0.0.0.0/0 next-hop 10.216.111.254;
}
}
}
}
server1 {
system {
host-name test-jdm-server1;
}
server {
interfaces {
cb0 p3p1;
cb1 p3p2;
jdm-management em2;
vnf-management em3;
}
}
interfaces {
jmgmt0 {
unit 0 {
family inet {
address 10.216.105.113/21;
}
}
}
routing-options {
static {
route {
0.0.0.0/0 next-hop 10.216.111.254;
}
}
}
}
}
}
apply-groups [ server0 server1 ];
system {
root-authentication {
encrypted-password "..."; ## SECRET-DATA
}
services {
ssh;
netconf {
ssh;
rfc-compliant;
}
}
}
virtual-network-functions {
test-gnf {
id 1;
chassis-type mx2020;
resource-template 2core-16g;
base-config /var/jdm-usr/gnf-config/test-gnf.conf;
}
}
Sample JDM Configuration (In-Chassis Model)
root@test-jdm-server0> show configuration
groups {
server0 {
system {
host-name test-jdm-server0;
}
interfaces {
jmgmt0 {
unit 0 {
family inet {
address 10.216.105.112/21;
}
}
}
}
routing-options {
static {
route {
0.0.0.0/0 next-hop 10.216.111.254;
}
}
}
}
server1 {
system {
host-name test-jdm-server1;
}
interfaces {
jmgmt0 {
unit 0 {
family inet {
address 10.216.105.113/21;
}
}
}
routing-options {
static {
route {
0.0.0.0/0 next-hop 10.216.111.254;
}
}
}
}
}
}
apply-groups [ server0 server1 ];
system {
root-authentication {
encrypted-password "..."; ## SECRET-DATA
}
services {
ssh;
netconf {
ssh;
rfc-compliant;
}
}
}
virtual-network-functions {
test-gnf {
id 1;
resource-template 2core-16g;
base-config /var/jdm-usr/gnf-config/test-gnf.conf;
}
}
Sample BSYS Configuration with Abstracted Fabric Interface
user@router> show configuration chassis
network-slices {
guest-network-functions {
gnf 1 {
af2 {
peer-gnf id 2 af1;
}
af4 {
peer-gnf id 4 af1;
}
description gnf-a;
fpcs [ 0 19];
}
gnf 2 {
af1 {
peer-gnf id 1 af2;
}
af4 {
peer-gnf id 4 af2;
}
description gnf-b;
fpcs [ 1 6 ];
}
gnf 4 {
af1 {
peer-gnf id 1 af4;
}
af2 {
peer-gnf id 2 af4;
}
description gnf-d;
fpcs [ 3 4 ];
}
}
}
Sample Abstracted Fabric Configuration at GNF with Class of Service
Assume that there is an abstracted fabric (af) interface between GNF1 and GNF2.
The following sample configuration illustrates how to apply rewrites on the
af interface at GNF1 and apply classifiers on the
af interface on GNF2, in a scenario where traffic comes from
GNF1 to GNF2:
GNF1 Configuration
interfaces {
xe-4/0/0 {
unit 0 {
family inet {
address 22.1.2.2/24;
}
}
}
af2 {
unit 0 {
family inet {
address 32.1.2.1/24;
}
}
}
}
class-of-service {
classifiers {
dscp testdscp {
forwarding-class assured-forwarding {
loss-priority low code-points [ 001001 000000 ];
}
}
}
interfaces {
xe-4/0/0 {
unit 0 {
classifiers {
dscp testdscp;
}
}
classifiers {
dscp testdscp;
}
}
af1 {
unit 0 {
rewrite-rules {
dscp testdscp; /*Rewrite rule applied on egress AF interface on GNF1.*/
}
}
}
}
rewrite-rules {
dscp testdscp {
forwarding-class assured-forwarding {
loss-priority low code-point 001001;
}
}
}
}
GNF2 Configuration
interfaces {
xe-3/0/0:0 {
unit 0 {
family inet {
address 42.1.2.1/24;
}
}
}
af1 {
unit 0 {
family inet {
address 32.1.2.2/24;
}
}
}
}
class-of-service {
classifiers {
dscp testdscp {
forwarding-class network-control {
loss-priority low code-points 001001;
}
}
}
interfaces {
af1 {
unit 0 {
classifiers {
dscp testdscp; /*Classifier applied on AF at ingress of GNF2*/
}
}
}
}
}
Sample Output for Abstracted Fabric Interface State at a GNF
user@router-gnf-b> show interfaces af9
Physical interface: af9, Enabled, Physical link is Up
Interface index: 209, SNMP ifIndex: 527
Type: Ethernet, Link-level type: Ethernet, MTU: 1514, Speed: 370000mbps
Device flags : Present Running
Interface flags: Internal: 0x4000
Link type : Full-Duplex
Link flags : None
Current address: 00:90:69:2b:00:4c, Hardware address: 00:90:69:2b:00:4c
Last flapped : 2018-09-12 01:44:01 PDT (00:01:02 ago)
Input rate : 0 bps (0 pps)
Output rate : 0 bps (0 pps)
Bandwidth : 370 Gbps
Peer GNF id : 9
Peer GNF Forwarding element(FE) view :
FPC slot:FE num FE Bandwidth(Gbps) Status Transmit Packets Transmit Bytes
6:0 130 Up 0 0
12:0 120 Up 0 0
12:1 120 Up 0 0
Residual Transmit Statistics :
Packets : 0 Bytes : 0
Fabric Queue Statistics :
FPC slot:FE num High priority(pkts) Low priority(pkts)
6:0 0 0
12:0 0 0
12:1 0 0
FPC slot:FE num High priority(bytes) Low priority(bytes)
6:0 0 0
12:0 0 0
12:1 0 0
Residual Queue Statistics :
High priority(pkts) Low priority(pkts)
0 0
High priority(bytes) Low priority(bytes)
0 0
Logical interface af9.0 (Index 332) (SNMP ifIndex 528)
Flags: Up SNMP-Traps 0x4004000 Encapsulation: ENET2
Input packets : 0
Output packets: 13
Protocol inet, MTU: 1500Sample Configuration for Sub Line Cards
This section provides sample configurations for sub line cards (SLCs).
- Sample Configuration for Symmetric Sub Line Card Profile
- Sample Configuration for Asymmetric Sub Line Card Profile
Sample Configuration for Symmetric Sub Line Card Profile
In the symmetric profile, only one combination of resources is possible.
The following is a sample configuration to slice the FPC 1 (MPC11E) in symmetric sub line card profile:
set chassis network-slices guest-network-functions gnf 1 fpc-slice fpc 1 slc 1 pfe-id-list 0-3set chassis network-slices guest-network-functions gnf 1 fpc-slice fpc 1 slc 1 cores 4set chassis network-slices guest-network-functions gnf 1 fpc-slice fpc 1 slc 1 dram 13set chassis network-slices guest-network-functions gnf 2 fpc-slice fpc 1 slc 2 pfe-id-list 4-7set chassis network-slices guest-network-functions gnf 2 fpc-slice fpc 1 slc 2 cores 4set chassis network-slices guest-network-functions gnf 2 fpc-slice fpc 1 slc 2 dram 13
This configuration would appear as shown below:
root@bsys> show chassis network-slices guest-network-functions
gnf 1{
fpc-slice {
fpc 1{
slc 1{
pfe-id-list 0-3;
cores 4;
dram 13;
}
}
}
}
gnf 2{
fpc-slice {
fpc 1{
slc 2{
pfe-id-list 4-7;
cores 4;
dram 13;
}
}
}
}
Sample Configuration for Asymmetric Sub Line Card Profile
In the asymmetric profile, two configurations are possible, depending on how the PFEs or Packet Forwarding Engines [0-7] are split between the two SLCs. In one example configuration, the first two Packet Forwarding Engines [0-1] are assigned to one SLC, and the remaining Packet Forwarding Engines [2-7] to the other SLC. In the other example configuration, the last two Packet Forwarding Engines [6-7] are assigned to one SLC, and the remaining Packet Forwarding Engines [0-5] to the other SLC.
The sample configuration below is an example of [0-1 2-7] split.
In the example below, the CPU core and DRAM assignments for the SLCs match one of the columns under the ‘Asymmetric Profile’ resource combination as shown in the table SLC Profiles Supported by MPC11E on the Sub Line Card Overview page.
set chassis network-slices guest-network-functions gnf 1 fpc-slice fpc 1 slc 1 pfe-id-list 0-1set chassis network-slices guest-network-functions gnf 1 fpc-slice fpc 1 slc 1 cores 4set chassis network-slices guest-network-functions gnf 1 fpc-slice fpc 1 slc 1 dram 17set chassis network-slices guest-network-functions gnf 2 fpc-slice fpc 1 slc 2 pfe-id-list 2-7set chassis network-slices guest-network-functions gnf 2 fpc-slice fpc 1 slc 2 cores 4set chassis network-slices guest-network-functions gnf 2 fpc-slice fpc 1 slc 2 dram 9
This configuration would appear as below:
root@bsys> show chassis network-slices guest-network-functions
gnf 1{
fpc-slice {
fpc 1{
slc 1{
pfe-id-list 0-1;
cores 4;
dram 17;
}
}
}
}
gnf 2{
fpc-slice {
fpc 1{
slc 2{
pfe-id-list 2-7;
cores 4;
dram 9;
}
}
}
}
