Navigation  Back up to About Overview 
[+] Expand All
[-] Collapse All

New and Changed Features

This section describes the new features and enhancements to existing features in Junos OS Release 18.1R1 for the MX Series routers.

Authentication, Authorization, and Accounting (AAA) (RADIUS)

Class of Service

  • Support for policer actions before ingress queuing (MX Series)—Starting with Junos OS Release 18.1R1, on MPCs that support ingress queuing, you can implement policer actions on traffic before the traffic is assigned to ingress queues. To do this, create the desired policers, apply them to a standard firewall filter, and attach the filter as an ingress queuing policing filter [iq-policing-filter filter-name] to an interface at the [edit interfaces interface-name unit logical-unit-number family family] hierarchy level. The iq-policing-filter can only be attached to a static interface.

    [See Ingress Queuing Filter with Policing Functionality.]

  • Support for rewrite of the first three bits of IPv6 DSCP value (MX Series, vMX)—Starting with Junos OS Release 18.1R1, MX Series routers with MPCs support rewrite rules that rewrite only the first three bits of the IPv6 DSCP value. Junos OS provides a new rewrite rule option, inet6-precedence, at the [edit class-of-service rewrite-rules] hierarchy level that allows you to set a 3-bit code point for a particular forwarding class and loss priority for IPv6 traffic. This new rewrite rule option can also be applied to packets entering an MPLS LSP.

    [See inet6-precedence (CoS Rewrite Rules).]


  • Connectivity Fault Management Support in an EVPN network (MX Series)—Starting with Junos OS Release 18.1R1, Junos OS supports connectivity fault management (CFM) Up maintenance association endpoints (MEPs) on the attachment circuits (ACs) that are connected to a provider edge (PE) router in an EVPN network. You can configure up MEPs to monitor multiple attachment circuits on the same PE router as part of the same maintenance domain or maintenance association.

    To configure multiple Up MEPs, specify the mepmep-id statement at the [edit protocols oam ethernet connectivity-fault-management maintenance-domaindomain-name maintenance association ma-name] hierarchy level, with the MEP direction configured as direction up.

    [See Connectivity Fault Management Support for Layer 2 VPN.]

General Routing

  • Support for PTP over Ethernet encapsulation and G.8275.1 profile (MX10003 and MX204)—Starting in Junos OS Release 18.1R1, MX10003 and MX204 routers support the following features:

    • PTP over Ethernet—PTP over Ethernet enables effective implementation of packet-based technology that enables the operator to deliver synchronization services on packet-based mobile backhaul networks. PTP over Ethernet uses multicast addresses for communication of PTP messages between the slave clock and the master clock.

    • G.8275.1 profile—G.8275.1 is a PTP profile for applications that require accurate phase and time synchronization. It supports the architecture defined in ITU-T G.8275 to enable the distribution of phase and time with full timing support and is based on the second version of PTP defined in IEEE 1588. You can configure the G.8275.1 profile by including the profile-type g.8275.1 statement at the [edit protocols ptp] hierarchy level.

      [See Configuring G.8275.1 Profile.]

  • VRF support for NTP (MX Series)—Starting in Junos OS Release 18.1R1, NTP clients can send requests to servers that are reachable through VRF. The set system ntp server address routing-instance routing-instance-name and set date ntp routing-instance routing-instance-name commands let you specify the routing instance that the server can be reached through.

    [See Configuring the NTP Time Server and Time Services.]

  • Support for PTP, Synchronous Ethernet, and hybrid mode over link aggregation group (MX240, MX480, MX960, MX2010, MX2020,)—Starting in Junos OS Release 18.1R1, the MPC7E-10G, MPC7E–MRATE, MPC8E, and MPC9E MPCs support Precision Time Protocol (PTP), Synchronous Ethernet, and hybrid mode over a link aggregation group (LAG).

    Link aggregation is a mechanism of combining multiple physical links into a single virtual link to achieve linear increase in bandwidth and to provide redundancy in case a link fails. The virtual link is referred to as an aggregated Ethernet interface or a LAG.

    [See Precision Time Protocol Overview.]

High Availability and Resiliency

  • MX Series Virtual Chassis Unified ISSU support for MPC7E-10G, MPC7E–MRATE, MPC8E, and MPC9E line cards (MX Series Virtual Chassis)—Starting in Junos OS Release 18.1R1, MPC7E-10G, MPC7E–MRATE, MPC8E, and MPC9E line cards support Unified ISSU in MX Series Virtual Chassis environments. Unified ISSU enables you to upgrade between two different Junos OS releases with no disruption on the control plane and with minimal disruption of traffic.

    [See Unified ISSU in a Virtual Chassis.]

Interfaces and Chassis

  • New speed configuration option introduced to change 10-Gbps port to operate in 1-Gbps speed (MX204, MX10003)—Starting in Junos OS Release 18.1R1, the 10-Gbps port can operate in 1-Gbps mode on MX204 and MX10003 routers. Currently, MX204 and MX10003 routers support different operation modes; that is, 10-Gbps, 40-Gbps, and 100-Gbps speed. When the port is operating in 10-Gbps speed, you can change the operating speed to 1Gpbs using a new CLI option, speed 1g/10g, for the existing set interfaces intf-name gigether-options command. Once you commit this configuration, the operating speed of the 10-Gbps port changes to 1-Gbps speed without any FPC, PIC, or interface bounce.

    The MX10003 MPC has one fixed PIC and one MIC (non-MACsec MIC/MACsec MIC). The fixed PIC has 6 ports that can operate in 40-Gbps or 4X10-Gbps mode. The MIC has 12 ports that can operate in 100-Gbps, 40-Gbps, or 4X10-Gbps mode. With this new speed configuration option, you can configure the 4X10-Gbps port on the fixed PIC and the non-MACsec MIC to 1-Gbps mode. You can also configure one or all ports that operate in 10-Gbps mode to 1Gbps mode.

    The MX204 contains two PICs—where one PIC contains 8 ports that can operate in 10-Gbps mode and the other PIC contains 4 ports that can operate in 4X10-Gbps, 40-Gbps, or 100-Gbps mode. Using this new speed configuration option, you can configure the 4X10-Gbps port on one of the fixed-port PICs to operate in 1-Gbps mode. And on the other fixed-port PIC, you can configure the 10-Gbps port to 1Gbps.


    • On the MX10003 router, the MACsec MIC does not provide 1-Gbps speed. If you attempt to change the operating speed to 1-Gbps, syslog displays that this feature is not supported on the MACsec MIC.

    • On MX204 and MX10003 routers, rate selectability at PIC level and port level does not support 1-Gbps speed.

    • On MX204 and MX10003 routers, 1-Gbps operation mode is only supported in no-autonegotiation mode.

    To view the speed configured for the interface, execute the show interfaces extensive command. The Speed Configuration output parameter in the command output indicates the current operation speed of the interface.

    If the interface is configured with 1-Gbps speed, then Speed Configuration displays 1G; if the interface is configured with 10-Gbps speed, Speed Configuration displays AUTO.

    For example:

    user@host>show interfaces xe-0/1/11:0 extensive
    Physical interface: xe-0/1/11:0, Enabled, Physical link is Up
      Interface index: 284, SNMP ifIndex: 609, Generation: 383
      Link-level type: Ethernet, MTU: 9192, MRU: 9200, LAN-PHY mode, Speed: 10Gbps,
      BPDU Error: None, Loop Detect PDU Error: None, MAC-REWRITE Error: None,
      Loopback: None, Source filtering: Disabled, Flow control: Enabled,
      Speed Configuration: 1G

    In this example, the Speed Configuration output parameter displays 1G, which means the operation speed of xe-0/1/11:0 interface is 1-Gbps speed.


    • The interface name prefix must be xe.

    • To set a port that is operating in 10-Gbps speed to 1-Gpbs speed, use the new CLI option speed 1g/10g for the existing set interfaces [intf-name] gigether-options command.

    • To view the speed configured for the interface, execute the show interfaces extensive command.

    [See MX10003 MPC Rate-Selectability Overview and MX204 Router Rate-Selectability Overview.]

  • Upgraded SSD size and RAM size (MX Series)—Starting in Junos OS Release 18.1R1, the Routing Engines on the MX240, MX480,MX960, MX2010, MX2020 routers support Secure Boot BIOS. The SSD size and the RAM size of the following Routing Engines are upgraded to 2x200-GB and 128-GB respectively:

    • RE-S-X6-128G-S on the MX240, MX480, and MX960 routers

    • RE-MX2K-X8-128G-S on the MX2010 and MX2020 routers

    [See Salient Features of the Routing Engines with VM Host Support.]

  • Limited encryption Junos OS image and boot restriction (MX10003)—Starting with Junos OS Release 18.1R1, MX10003 router with LT-SKU supports only Junos Limited image. The Junos Limited image does not have data-plane encryption and is intended only for countries in the Eurasian Customs Union because these countries have import restrictions on software containing data plane encryption. Unlike the Junos Worldwide image, the Junos Limited image supports control plane encryption through Secure Shell (SSH) and Secure Sockets Layer (SSL), thus allowing secure management of the system. The MX10003 LT SKU boots only the encryption free Junos software and fails to boot if the fully encrypted Junos software is used for booting. The Junos upgrade and VMHost upgrade using non-limited version of Junos software fails on the MX10003 LT SKU. The command show chassis hardware [models | clei-models | extensive] displays the model number and helps identifying the different SKUs. An alarm, Mixed Master and Backup RE types is displayed when dissimilar Routing Engines are present on the chassis.

    [See Junos OS Editions.]

  • Enhanced support for the non-default management instance mgmt_junos (MX Series)—Starting in Junos OS Release 18.1R1, syslog IPv6 addresses, RADIUS packets, and Automation scripts support the non-default management instance mgmt_junos, when the management-instance statement is configured. For syslog, statements at the [edit system syslog] hierarchy level now support IPv6 addresses when connecting to a remote host or an archival site. RADIUS authentication, authorization, and accounting packets can be configured to use the mgmt_junos instance. Also, Automation (commit, event, JET, op, or SNMP) scripts now can be refreshed over the mgmt_junos instance. To enable the non-default VRF management instance, you must also configure the mgmt_junos routing instance at the [edit system routing-instances] hierarchy level.

    [See Management Interface in a Non-Default Instance.]


  • IPV6 packet (pps) and byte (bps) rates included in interface traffic statistics (MX series)—Starting in Junos OS Release 18.1R1, the output of the following commands are modified:

    • The show interfaces command displays the input and output bytes (bps) and packets (pps) rates individually for IPv6 family in the IPv6 interface traffic statistics.

    • The monitor interface command displays the IPV6 interface traffic statistics along with input and output bytes (bps) and packets (pps) rates individually for IPv6 family.

    [See show interfaces and monitor interface.]

Junos OS XML, API and Scripting

  • Automation script library additions and upgrades (MX240, MX480, MX960, and vMX routers)—Starting in Junos OS Release 18.1R1, devices running Junos OS that support Python automation scripts include new and upgraded Python modules. Python automation scripts can leverage new on-box Python modules, including appdirs, asn1crypto, cffi, cryptography, idna, libffi, packaging, psutil, pyasn1, pyparser, and pyparsing, as well as upgraded versions of existing modules. The psutil module is available only on devices running Junos OS with upgraded FreeBSD, and only a subset of functions is supported.

    [See Overview of Python Modules Available on Devices Running Junos OS.]


  • Expanded support for chassis sensors for Junos Telemetry Interface (MX Series Transport Series Routers)—Starting with Junos OS Release 18.1R1, Junos Telemetry Interface (JTI) provides new sensors that expand optics and power information.

    To export telemetry data from Juniper equipment to an external collector requires both Junos Telemetry Interface (JTI) and gRPC to be configured.

    Enhanced sensor information is also supported through operational mode commands show chassis fpc detail , show chassis power detail, and show chassis pic fpc-slot id pic-slot id.

    Streaming telemetry data through gRPC also requires you to download the OpenConfig for Junos OS module.

    [See Guidelines for gRPC Sensors (Junos Telemetry Interface).]

  • “ON CHANGE” sensor support through Google Network Management Interface (gNMI) for Junos Telemetry Interface (MX Series)—Starting with Junos OS Release 18.1R1, ON_CHANGE streaming of Address Resolution Protocol (ARP), Network Discovery Protocol (NDP), and IP sensor information associated with interfaces is supported on Junos Telemetry Interface (JTI).

    Periodical streaming of OpenConfig operational states and counters has been supported since Junos OS Release 16.1, exporting telemetry data from Juniper equipment to an external collector. While useful in collecting all the needed information and creating a baseline “snapshot,” periodical streaming is less useful for time-critical missions. In such instances, you can configure ON_CHANGE streaming for an external collector to receive information only when operational states experience a change in state.

    To support ON_CHANGE streaming, Google has developed a new specification called gRPC Network Management Interface (gNMI) for the modification and retrieval of configurations from a network element. Additionally, the gNMI specification can be used to generate and control telemetry streams from a network element to a data collection system. Using the new gNMI specification, one gRPC service definition can provide a single implementation on a network element for both configuration and telemetry as well as a single NMS element to interact with a device by means of telemetry and configuration RPCs.

    Information about the RPCs supporting this feature can be found in the gNMI Proto file version 0.4.0 (the supported version) and the specification released by Google at:



    The telemetry RPC subscribe under gNMI service supports ON_CHANGE streaming. RPC subscribe allows a client to request the target to send it values of particular paths within the data tree. Values may be streamed (STREAM), sent one-off on a long-lived channel (POLL), or sent one-off as a retrieval (ONCE).

    If a subscription is made for a top level container with a sample frequency of 0, leaves with ON_CHANGE support are streamed based on events. Other leaves will not be streamed.

    Note: In order to permit a device to decide which nodes will be streamed as ON_CHANGE and which will SAMPLE, the collector should subscribe for TARGET_DEFINED with sample_interval.

    Streaming telemetry data through gRPC requires you to download the OpenConfig for Junos OS module.

    [See Understanding OpenConfig and gRPC on Junos Telemetry Interface.]

  • PIC services and IPSec sensors for Junos Telemetry Interface (MX Series)—Starting with Junos OS Release 18.1R1, Junos Telemetry Interface (JTI) provides support for gRPC-based IKE and GPB UDP-based PIC sensors. These sensors provide visibility for IPSec services on different service complexes and nodes.

    Exported data is defined using an IP address and a UDP port. When an export interval expires, the most recent statistics collected by the sensors are gathered, placed in the payload of a UDP packet, and forwarded to a collector. A timestamp indicating when counters are read is included with the exported data to allow collectors to collate data. The timestamp also can determine if and when an event happened, such as a PIC hardware restart or if counters were cleared by means of the CLI.

    The resource paths are:

    • /junos/services/spu/ipsec-vpn

    • /junos/ike-security-associations/ike-security-association/

    To export telemetry data from Juniper equipment to an external collector requires both Junos Telemetry Interface (JTI) and gRPC to be configured.

    [See Guidelines for gRPC Sensors (Junos Telemetry Interface).]

  • Fabric statistics support on Junos Telemetry Interface (JTI) (MX Series)—Starting with Junos OS Release 18.1R1, fabric statistics limited to streaming over GBP over UDP are now supported for export by means of gRPC. Statistics are exported whether encoded as native or as a third-party data model.

    Fabric statistic data is collected and exported by the following two types of fabric sensors:

    • Per Packet Forwarding Engine pair fabric sensor

    • Summary Flexible Pic Concentrator (FPC) fabric sensor

    Streaming telemetry data through gRPC requires you to download the OpenConfig for Junos OS module.

    [See Guidelines for gRPC Sensors (Junos Telemetry Interface).]

  • ON_CHANGE support for Junos Telemetry Interface (JTI) (MX Series)—Starting with Junos OS Release 18.1R1, OpenConfig support through Google Remote Procedure Calls (gRPC) and JTI is extended to support client streaming and bidirectional streaming of telemetry sensor information.

    APIs have been implemented in Junos based on Protobuf specifications released by Google for OpenConfig. These APIs perform configuration, operational state retrieval, and telemetry on Junos routers using gRPC as the transport mechanism.

    Starting in Junos OS 18.1R1, client streaming and bidirectional streaming are supported. With client streaming, the client sends a stream of requests to the server instead of a single request. The server typically sends back a single response containing status details and optional trailing metadata. With bidirectional streaming, both client and server send a stream of requests and responses. The client starts the operation by invoking the RPC and the server receives the client metadata, method name, and deadline. The server can choose to send back its initial metadata or wait for the client to start sending requests. The client and server can read and write in any order. The streams operate completely independently.

    Junos devices can be managed through API (RPC) prototypes:

    • rpc Capabilities (CapabilityRequest)

      Returns (CapabilityResponse). Allows the client to retrieve the set of capabilities that is supported by the target.

    • rpc Get (GetRequest)

      Returns (GetResponse). Retrieves a snapshot of data from the target.

    • rpc Set (SetRequest)

      Returns (SetResponse). Allows the client to modify the state of data on the target.

    • rpc Subscribe (stream SubscribeRequest)

      Returns (stream SubscribeResponse). Allows a client to request the target to send it values for particular paths within the data tree. These values may be streamed (STREAM) or sent one-off on a long-lived channel (POLL), or sent as a one-off retrieval (ONCE). If a subscription is made for a top-level container with a sample frequency of 0, leaves with ON_CHANGE support are streamed based on events. Other leaves will not be streamed.

    Juniper Extension Toolkit (JET) support provides insight to users regarding the status of clients connected to JSD. JET support for gRPC includes expanding the maximum number of clients that can connect to JSD from 8 to 30 (the default remains 5). To specify the maximum number of connections, include the max-connections statement at the [edit system services extension-service request-response grpc] hierarchy level.

    To provide information regarding the status of clients connected to JSD, issue the enhanced show extension-service client information command and include the clients or servers options. The clients option displays request-response client information. The servers option displays request-response server information.

    [See Understanding OpenConfig and gRPC on Junos Telemetry Interface.]


  • Translation for MVPN Type 5 routes to MSDP SA (MX Series)—Starting in Junos OS Release 18.1R1, Junos supports MVPN-Type-5 route to MSDP-SA conversion as defined in RFC draft-ietf-bess-mvpn-sa-to-msdp-00.txt. Previously, Junos only supported translation in the other direction, MSDP SA to MVPN Type 5.

    The ability to convert next-generation multicast virtual private network (MVPN) Type 5 routes to Multicast Source Discovery Protocol (MSDP) source active (SA) makes it possible to reduce the number of MSDP sessions running between VPN customer rendezvous points (C-RPs). For example, instead of having MSDP running among all C-RPs in a deployment, the C-RPs could instead run their MSDP sessions with a single PE router configured for multiple MSDP peers. The PE router, now acting as a C-RP device, would receive MVPN SA Type 5 routes from the RP-PE or source PE router, convert those routes to MSDP, and then advertise the MSDP routes to its MSDP peers.

    MVPN Type 5 SA routes are added to MVPN table and include a new Extended Community (EC), with the IPv4 address of the RP where the MVPN SA was generated. The Type 5 routes source and EC are additionally added to the MSDP table. Stale routes, including the EC, are removed via MSDP once the MVPN type 5 SA route is gone from the MVPN table.

    Enable MVPN to MSDP conversion at the [edit routing-instance name protocols mvpn mvpn-mode spt-only convert-sa-to-msdp] hierarchy level.

    You can verify whether MVPN type 5 routes are being correctly converted to MSDP SA by running the [show msdp source-active instance name] command.

    [See MVPN Concepts and Protocols.]


  • RSVP-TE pop-and-forward LSP tunnels (MX Series routers with MPCs and MICs)—Pop-and-forward LSPs introduce the notion of pre-installed per traffic engineering link pop labels that are shared by RSVP-TE LSPs that traverse these links. A transit label-switching router (LSR) allocates a unique pop label per traffic engineering link with a forwarding action to pop the label and forward the packet over that traffic engineering link should the label appear at the top of the packet. Starting in Junos OS Release 18.1R1, you can configure pop-and-forward LSPs to significantly reduce the required forwarding plane state, enabling the pop-and-forward tunnels to couple the feature benefits of the RSVP-TE control plane with the simplicity of the shared MPLS forwarding plane.

    All the existing RSVP-TE functionalities, such as bandwidth admission control, LSP priorities, preemption, auto-bandwidth, and MPLS fast reroute continue to work with pop-and-forward tunnels.

    [See RSVP-TE Pop-and-Forward LSP Tunnels Overview.]

  • Localization of next-hop-based dynamic tunnels—(MX Series) Next-hop-based dynamic generic routing encapsulation (GRE) tunnels and MPLS-over-UDP tunnels distribute forwarding information to all line cards on a device. As a result, the origination and termination states of all tunnels are built on the Packet Forwarding Engines (PFEs) on every line card on the device, limiting the maximum number of tunnels supported on the device to the tunnel capacity of a single line card. Starting in Junos OS Release 18.1R1, you can configure next-hop-based dynamic tunnel localization to create the forwarding information only on the PFE of a line card that is designated as the anchor PFE. The PFEs on the other line cards on the device have state forwarding information to steer the packets to the anchor PFE.

    [See Next-Hop-Based Dynamic Tunnel Localization Overview.]

  • Support for static segment routing label switched path (MX Series)—Starting with Junos OS 18.1R1 release, a set of explicit segment routing paths are configured on the ingress router of a non-colored static segment routing label switched path (LSP) by configuring the segment-list statement at the [edit protocols source-packet-routing] hierarchy level. You can configure the segment routing LSP by configuring the source-routing-path statement at [edit protocols source-packet-routing] hierarchy level. The segment routing LSP has a destination address and one or more primary paths and optionally secondary paths that refer to the segment list. Each segment list consists of a sequence of hops. For non-colored static segment routing LSP, the first hop of the segment list specifies an immediate next hop IP address and the second to Nth hop specifies the segment identifies (SID) labels corresponding to the link or node which the path traverses. The route to the destination of the segment routing LSP is installed in inet.3 table. The adjacency segments, node segments, and prefix segments can be provisioned on transit routers by configuring static MPLS segment LSPs at the [protocols mpls static-label-switched-path] hierarchy level

    [See static segment routing lsp.]

Network Management and Monitoring

  • sFlow support on MX Series devices—Starting in Junos OS Release 18.1R1, you can configure sFlow technology (as a sFlow agent) on a MX Series device, to continuously monitor traffic at wire speed on all interfaces simultaneously. The sFlow technology is a monitoring technology for high-speed switched or routed networks. sFlow monitoring technology randomly samples network packets and sends the samples to a remote monitoring station, which presents quantifiably accurate network traffic visibility information after collecting data for a reasonably long period. These remote monitoring stations are called collectors.

    [See the Understanding How to Use sFlow Technology for Network Monitoring on a MX Series Router.]

  • Resource monitor support for PS and RLT interfaces (MX Series)—Starting in Junos OS Release 18.1R1, PS and RLT interfaces support resource monitoring throttling. If a configured resource limit is exceeded for any member of a PS or RLT interface, the resource monitor prevents subscriber login and increments a denied counter. The denied counters can be verified with the show system resource-monitor summary command. In addition, the show subscribers command displays subscribers per PIC/PFE/Slot for PS and RLT interfaces.

    [See resource-monitor.]

  • The bbe-mibd component is enhanced with additional MIB objects (MX Series)—In the next-generation broadband edge architecture, subscribers are represented by flows instead of logical interfaces. The SNMP subagent bbe-mibd was implemented to handle SNMP requests for subscriber interfaces. As of Junos OS Release 18.1R1, the following MIB objects are made available for flow-based dynamic interfaces as part of bbe-mibd:

    • ifChassisTable

    • ipv6IfTable

    • ipv6IfStatsTable

    • jnxIpv6

    [See the SNMP MIB Explorer.]

  • Enhancement to Junos OS SNMP MIB PCC funtionality (MX Series)—Starting in Junos OS Release 18.1R1, Junos OS provides enhanced MIB support for Path Computation Clients. This enhancement enables the Path Computation Client (PCC) process to accept SNMP get and getnext commands for Path Computation Client Protocol (PCEP) peer and PCEP session tables and reply to them. This feature monitors PCEP interactions between a PCC and a Path Computation Element (PCE). Not all members of PCEP peer and PCEP session tables mentioned in the RFC (RFC 7420) are supported. For exceptions, see Standard SNMP MIBs Supported by Junos OS.

    [See MIB Explorer. Name of MIB is pcep.mib.]

Operation, Administration, and Maintenance (OAM)

  • CFM Action Profile to Bring Down a Group of Logical Interfaces(MX Series Routers)—Starting with Junos OS Release 18.1R1, you can create a CFM Action Profile and define an action to bring down a group of logical interfaces using CFM session configured on a single IFL. Following new configuration statements are introduced:

    • To mark the interface group down configure interface-group-down at the [edit protocols oam ethernet connectivity-fault-management action-profile action-profile-name hierarchy level.

    • To mark the interface group down for the action profile configured with the action interface-group-down, configure interface-group(interface-device-name| unit-list) at the [edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name maintenance-association ma-name mep mep-id remote-mep mep-id action-profile profile-name] hierarchy level. The interface-device-name represents an Ethernet interface device. The unit-list defines a string of logical unit numbers.

    [See Ethernet OAM Connectivity Fault Management.]

Routing Policy and Firewall Filters

  • Firewall filters and policers for abstracted fabric interface (MX Series)—Starting with Junos OS Release 18.1R1, you can configure firewall filters and policers on an abstracted fabric (AF) interface, a pseudointerface that facilitates routing control and management traffic between guest network functions (GNFs) through the switch fabric. AF interfaces support single-rate two-color policer, single-rate three-color policer, two-rate three-color policer, and hierarchical policer. The AF interface firewall filters are supported on Inet, Inet6, MPLS, and CCC protocol families.

    Note: The AF interface bandwidth is assigned to all FPCs linked to that AF interface. Therefore, a policer bandwidth limit configuration on an AF interface is applicable to all the PFEs associated with the AF interface.

    [See Understanding the Use of Policers in Firewall Filters.]

Routing Protocols

  • Support for BGP multipath at global level (MX Series)—Starting with Junos OS Release 18.1R1, BGP multipath is available at the global level in addition to the group and neighbor level. In earlier Junos OS releases BGP multipath is supported only at the group and neighbor levels. A new configuration option disable is available at the [edit protocols bgp multipath] hierarchy level to disable BGP multipath for specific groups or neighbors. This allows you to configure BGP multipath globally and disable it for specific groups according to your network requirements.

    [See disable.]

  • Support for BGP Labeled Unicast traffic statistics collection (MX Series) —Starting in Junos OS Release 18.1R1, you can enable traffic statistics collection for BGP labeled unicast traffic at the ingress router. In a network configured with segment routing, traffic statistics can be collected periodically based on the label stack received in the BGP route update and saved in a specified file. Traffic statistics collection is supported only for IPv4 and IPv6 address families.

    [See Enabling Traffic Statistics Collection for BGP Labeled Unicast.]

  • Multipath optimization to improve RIB learning rate—Starting in Junos OS Release 18.1R1, you can defer multipath calculation until all BGP routes are received. When multipath is enabled, BGP inserts the route into the multipath queue each time a new route is added or whenever an existing route changes. When multiple paths are received through BGP add-path feature, BGP might calculate one multipath route multiple times. Multipath calculation slows down the RIB (also known as the routing table) learning rate. To speed up RIB learning, multipath calculation can be either deferred until the BGP routes are received or you can lower the priority of the multipath build job as per your requirements until the BGP routes are resolved.

    To defer the multipath calculation configure defer-initial-multipath-build at [edit protocols bgp] hierarchy level. Alternatively, you can lower the BGP multipath build job priority using multipath-build-priority configuration statement at [edit protocols bgp] hierarchy level to speed up RIB learning.

    [See defer-initial-multipath-build.]


  • Secure Boot (MX240, MX480, MX960, MX2010, and MX2020 that use Routing Engines RE-S-X6-128G or RE-MX2K-X8-128G)—Starting in Junos OS Release 18.1R1, a significant system security enhancement, Secure Boot, has been introduced. The Secure Boot implementation is based on the UEFI 2.4 standard. The BIOS has been hardened and serves as a core root of trust. The BIOS updates, the bootloader, and the kernel are cryptographically protected and thus safeguarded from tampering or modification. Secure boot is enabled by default on supported platforms.

    [See Feature Explorer and enter Secure Boot.]

Services Applications

  • Support for additional DS-Lite features on MS-MPCs and MS-MICs (MX Series routers)—Starting in Junos OS Release 18.1R1, dual-stack lite (DS-Lite) running on MS-MPCs and MS-MICs adds support for the following features:


    • Configurable MTU per softwire concentrator

    • IPv6 fragmentation and reassembly

    • NAPT-44 port block allocation

    • Receiving and transmitting IPv4 fragments in IPv6

    • Traceroute through the softwire tunnel

    • Hairpinning with NAPT-44 EIF

    Prior to Junos OS Release 18.1R1, DS-Lite did not support these feature on the MS-MPCs and MS-MICs.

    [See Tunneling Services for IPv4-to-IPv6 Transition Overview.]

  • Support for IPv6 version 9 templates for inline active flow monitoring (MX Series)—Starting in Junos OS Release 18.1R1, you can apply version 9 flow templates to IPv6 traffic when using inline flow monitoring. In addition, fields have been added to several IPFIX and version 9 templates for inline flow monitoring to make the templates more uniform for each supported family.

    [See Understanding Inline Active Flow Monitoring.]

  • Support for additional filtering on show command output of RPM probes generated on an MS-MPC or MS-MIC (MX Series)—Starting in Junos OS Release 18.1R1, you can use new filters to limit the output of the show services rpm probe-results and show services rpm history-results commands for real-time processing (RPM) probes that are generated on an MS-MPC or MS-MIC.

    [See show services rpm probe-results and show services rpm history-results.]

  • Support for generating IPv6 RPM probes on MS-MPCs and MS-MICs (MX Series)—Starting in Junos OS Release 18.1R1, you can configure an MS-MPC or MS-MIC to generate icmp6-ping real-time performance monitoring (RPM) probes. Generating RPM probes on an MS-MPC or MS-MIC increases the number of probes that can run at the same time, compared to probes that are generated on the Packet Forwarding Engine.

    [See Configuring RPM Probes.]

Software Defined Networking

  • MS-MIC and MS-MPC support for Junos Node Slicing (MX480, MX960, MX2010, MX2020)—Starting from Junos OS Release 18.1R1, Junos Node Slicing supports assignment of MS-MICs and MS-MPCs to guest network functions (GNFs). MS-MICs and MS-MPCs provide improved scaling and high performance, and possess enhanced memory (16 GB for MS-MIC; 32 GB per NPU of MS-MPC) and processing capabilities. The MS-MIC supports the Layer 3 services such as stateful firewall, NAT, IPsec, active flow monitoring, RPM, and graceful Routing Engine switchover (GRES).

    [See Multiservices MIC and Multiservices MPC (MS-MIC and MS-MPC) Overview.]

Subscriber Management and Services

  • Controlling search behavior for address allocation from linked pools (MX Series)—Starting in Junos OS Release 18.1R1, you can use the linked-pool-aggregation statement at the [edit access address-assignment pool pool-name] hierarchy level to change how addresses are allocated from linked IP address pools. When you configure the statement, addresses can be assigned from a later pool in the chain before an earlier pool is depleted. When the statement is not configured, IP addresses are assigned contiguously, so that all addresses are allocated from the matching pool and then the first pool in the chain before addresses are assigned from a linked pool.

    [See Configuring Address-Assignment Pool Linking.]

  • Support for Packet triggered subscriber functionality (MX Series)—Starting with Junos OS 18.1R1, support for packet triggered subscriber functionality creates IP demux IFL on receiving a data packet from clients with pre-assigned IP address using a new demux configuration at the hierarchy level [edit interfaces interface-name unit unit-number].

    [See IP demultiplexing interfaces on Packet-Triggered Subscribers Services Overview.]

  • BPCEF Gy Assume Positive CCR-T File Support (MX Series)—Starting with Junos OS 18.1R1, broadband PCEF provides the file backup for OCS data when both primary and alternative paths to the OCS are not available. The CCR-GY-T frames are stored in the files on remote location. The backup is supported at the hierarchy [edit access ocs partition partition-name].

    [See Gy File Backup Overview.]

  • Support for per-subscriber MTU for dynamic profiles of IP v4 or IPv6 protocol family (MX Series)—Starting with Junos OS 18.1R1, maximum transmission unit (MTU) can be configured per subscriber for dynamic profiles. The value of MTU can be static or represented through $junos-interface-mtu variable. By default, the variable value is the MTU of the payload that is less than the MTU of the physical interface minus the family protocol overhead. A specific value is returned through RADIUS authentication through the framed MTU attribute. If the RADIUS fails to return framed MTU value for $junos-interface-mtu variable then the default value from interface-mtu statement at [edit dynamic-profiles profile-name predefined-variable-defaults] hierarchy level. You can configure value for mtu statement at [edit dynamic-profiles name interfaces name unit name family inet] hierarchy level or at [edit dynamic-profiles name interfaces name unit name family inet6] hierarchy level.

    [See Per-subscriber support of maximum transmission unit for dynamic profiles.]

  • Enhancements to dual-stack, single-session authentication and reauthentication (MX Series)—Starting in Junos OS Release 18.1R1, reauthentication is supported in response to DHCP discover and solicit messages, in addition to the previously supported renew and rebind messages.

    Reauthentication is supported for DHCP dual-stack, single-session subscribers when on-demand address allocation is configured. Both authentication and reauthentication for dual-stack, single-session supports are performed per family in the stack, using separate Access-Requests to the RADIUS server.

    [See RADIUS Reauthentication As an Alternative to RADIUS CoA for DHCP Subscribers.]

  • Excluding addresses or ranges to manage address allocation pools for DHCP local server (MX Series)—Starting in Junos OS Release 18.1R1, you can exclude IPv4 or IPv6 individual addresses or ranges of consecutive addresses within an address pool from being allocated to subscribers. If you exclude an address that has already been allocated, the subscriber is logged out, the address is deallocated, and then marked for exclusion.

    [See Preventing Addresses from Being Allocated from an Address Pool.]

  • Preventing validation of magic numbers in PPP peer-originated keepalive messages (MX Series)—Starting in Junos OS Release 18.1R1, you can include the ignore-magic-number-mismatch statement to disable the Packet Forwarding Engine from validating PPP magic numbers received during PPP keepalive (Echo-Request/Echo-Reply) exchanges. Because validation is not performed, the Packet Forwarding Engine does not detect whether the remote peer sends a magic number that does not match the number agreed upon during LCP negotiation. This prevents PPP from tearing down the session in the event of a mismatch. This capability is useful when the remote PPP peers include arbitrary magic numbers in the keepalive packets. Configuring this statement has no effect on LCP magic number negotiation or on the exchange of keepalives when the remote peer magic number is the expected negotiated number.

    [See Preventing the Validation of PPP Magic Number During PPP Keepalive Exchanges and Understanding How the Router Processes Subscriber-Initiated PPP Fast Keepalive Requests.]

  • Local dynamic service profile activation on L2TP login (MX Series)—Starting in Junos OS Release 18.1R1, you can use dynamic service profiles to apply services to all subscribers in a tunnel group or to all subscribers using a particular LAC without involving RADIUS. In multivendor environments, customers might use only standard RADIUS attributes to simplify management by avoiding the use of vendor-specific attributes (VSAs) from multiple vendors. However, VSAs are generally required to apply services. Local service profile activation enables you to avoid that problem. It can also be a way to provide default services when RADIUS servers are down. You can also pass parameters to the services as they are applied, such as a downstream shaping rate for a CoS service.

    [See Applying Services to an L2TP Session Without Using RADIUS.]

  • Changes to JSRC Provisioning for Dual-Stack Subscribers (MX Series)—Starting in Junos OS Release 18.1R1, you can include the dualstack-support statement at the [edit jsrc] hierarchy level to configure JSRC provisioning for dual-stack subscribers so that JSRC reports information about the separate stacks for a given subscriber, using a single JSRC session. Accounting statistics are reported separately for each family. In earlier releases, the remote SRC peer is not informed about whether only on family or both families are active, and all statistics are aggregated across the families.

    [See JSRC Provisioning for Dual-Stack Subscribers.]

  • Providing L2TP service rate limits at subscriber login (MX Series)—Starting in Junos OS Release 18.1R1, you can specify the name of the dynamic service profile that provides values for the transmit (Tx) and receive (Rx) connect speeds for traffic between the LAC and the subscriber. When that profile name is returned in the Juniper Networks Activate-Service VSA (26-65) in the RADIUS Access-Accept message at subscriber login, the values are converted from Kbps to bps and stored in the session database. You can also modify the rates with parameters passed in the VSA or specify an adjustment for the values, up or down, in the CLI. The rates are sent in the ICCN message from the LAC to the LNS as AVP 24 and AVP 38.

    [See Specifying a Rate-Limiting Service Profile for L2TP Connection Speeds.]

  • Flexible filtering of RADIUS attributes and VSAs (MX Series)—Starting in Junos OS Release 18.1R1, a flexible configuration method is supported for filtering undesirable RADIUS standard attributes and vendor-specific attributes (VSAs). Attributes received from RADIUS take precedence over internally provisioned attributes; filtering ensures that the corresponding internally provisioned attribute values are used.

    The flexible configuration enables you to specify RADIUS standard attributes with the attribute number, and to specify VSAs with the IANA-assigned vendor ID and the VSA number. Some attributes can be ignored when received in Access-Accept messages; other attributes can be excluded from Access-Request and accounting messages. Only those standard attributes and VSAs supported by your platform can be filtered. You can configure unsupported standard attributes, vendors, and VSAs, but the configuration has no effect.

    In earlier releases, you must specify dedicated keywords (options) for attributes to filter. This method is still supported. If you configure filtering with both methods, attributes that are specified with either method are filtered.

    [See Enabling the Use of Local Values by Filtering RADIUS Attributes and VSAs.]

  • Additional RADIUS attributes and VSAs supported for filtering (MX Series)—Starting in Junos OS Release 18.1R1, you can filter the following attributes from RADIUS Access-Accept messages with the ignore statement:

    Standard RADIUS attributes:

    • Session-Timeout (27)

    • Idle-Timeout (28)

    Microsoft (IANA vendor-id 311) vendor specific attributes:

    • MS-Primary-DNS-Server (26-28)

    • MS-Secondary-DNS-Server (26-29)

    [See ignore.]


  • Support for seamless migration from BGP-VPLS to EVPN (MX Series)—Starting in Junos OS Release 18.1R1, a solution is introduced for enabling staged migration from BGP-VPLS toward EVPN on a site-by-site basis for every VPN routing instance. In this solution, the PE devices running EVPN and VPLS for the same VPN routing instance and single-homed segments can co-exist. The solution supports single-active redundancy of multi-homed networks and multi-homed devices for EVPN PEs. With single-active redundancy, the participant VPN instances may span across both EVPN PEs and VPLS PEs as long as single-active redundancy is employed by EVPN PEs.

    [See Migrating From BGP-VPLS to EVPN Overview.]

Modified: 2018-04-19