Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

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 16.1R1 for the MX Series.

Hardware

  • New Routing Engine RE-S-X6-64G (MX240, MX480, and MX960)—Starting in Junos OS Release 16.1, the Routing Engine RE-S-X6-64G is supported on MX240, MX480, and MX960 routers. This Routing Engine has an increased computing capability and scalability to support the rapid rise in the data plane capacity. The Routing Engine is based on a modular, virtualized architecture and leverages the hardware-assisted virtualization capabilities.

    The Routing Engine has a 64-bit CPU and supports a 64-bit kernel and 64-bit applications. With its multicore capabilities, the Routing Engine supports symmetric multiprocessing in the Junos OS kernel and hosted applications.

    Note: The Routing Engine RE-S-X6-64G is supported only on SCBE2, and it is not compatible with the SCB or the SCBE.

  • New Routing Engine REMX2K-X8-64G (MX2010, MX2020)—Starting in Junos OS Release 16.1, the Routing Engine REMX2K-X8-64G is supported on MX2010 and MX2020 routers. This Routing Engine has an increased computing capability and scalability to support the rapid rise in the data plane capacity. The Routing Engine is based on a modular virtualized architecture and leverages the hardware-assisted virtualization capabilities.

    The Routing Engine has a 64-bit CPU and supports a 64-bit kernel and 64-bit applications. With its multicore capabilities, the Routing Engine supports symmetric multiprocessing in the Junos OS kernel and hosted applications.

Authentication, Authorization, and Accounting

  • Logging out idle root users from C shell or CLI console session (MX Series)— Starting with Junos OS Release 16.1, idle users (including root users) are logged out of their C shell or CLI console session after the expiry of the configured maximum idle timeout period.

EVPNs

  • EVPN with VXLAN data plane encapsulation (MX Series)–Starting in Junos OS Release 16.1, MX Series routers can use EVPN with VXLAN encapsulation to provide Layer 2 connectivity for end stations within a Virtualized Network (VN) created by the Contrail virtualization software. The end stations consist of virtual hosts connected to the virtualized server, and non-virtualized bare metal servers connected to top-of-rack platforms. MX Series routers also function as default gateways for the inter-VN traffic among end stations that belong to different VNs. EVPN is used as a Layer 2 overlay solution to provide Layer 2 connections over the IP underlay for the endpoints within a VN whenever Layer 2 connectivity is required by an end station.
  • Active-active multihoming support for EVPNs (MX Series with MPCs and MICs only)—Starting with Junos OS Release 15.1F6 and 16.1R1, the Ethernet VPN (EVPN) solution on MX Series routers with MPC and MIC interfaces is extended to provide multihoming functionality in the active-active redundancy mode of operation. This feature enables load balancing of Layer 2 unicast traffic across all the multihomed links on and toward a customer edge device.

    The EVPN active-active multihoming feature provides link-level and node-level redundancy along with effective utilization of resources.

    To enable EVPN active-active multihoming, include the all-active statement at the [edit interfaces esi] hierarchy level.

    [See EVPN Multihoming Overview, and Example: Configuring EVPN Active-Active Multihoming.]

General Routing

  • Support for fabric management on MPC7E-MRATE and MPC7E-10G MPCs (MX240, MX480, and MX960 routers)—Fabric management is implemented on MPC7E-MRATE and MPC7E-10G MPCs and is supported in Junos OS Release 16.1R1. The MX960 router supports a maximum of six fabric planes (two per MX-SCBE2), and the MX240, and MX480 routers support a maximum of eight fabric planes (four per MX-SCBE2).

    Note: The MPC7E-MRATE, and MPC7E-10G MPCs are supported only on MX-SCBE2.

    Note: Fabric management is supported on the MPC7E-MRATE and MPC7E-10G MPCs in Junos OS Releases,15.F4, 15.1F5 with respective JAM packages, and in 15.1F6.

Class of Service (CoS)

  • Support for suppressing the default classifier (MX Series)—Beginning with Junos OS Release 16.1R1, you can disable the application of the default classifier on an interface or a routing instance to preserve the incoming classifier. This is done by applying the no-default option at the [edit class-of-service routing-instances routing-instance-name classifiers] hierarchy level. This is useful, for example, in a bridge domain, where the default classifier for the interface overrides the configured classifier for the domain.

    [See Applying Behavior Aggregate Classifiers to Logical Interfaces.]

  • Support for queuing features on built-in ports to provide customized traffic shaping services (MX80, MX104)—Starting with Junos OS Release 16.1, support for hierarchical class-of-service (HCoS) features such as per-unit scheduling and hierarchical scheduling is extended to the built-in (fixed) ports on MX80 and MX104 routers. The MX104 has four built-in ports: xe-2/0/0, xe-2/0/1, xe-2/0/2, and xe-2/0/3. The MX80 also has four built-in ports: xe-0/0/0, xe-0/0/1, xe-0/0/2, and xe-0/0/3. You can enable scheduling and shaping on a logical interface and provide customized traffic shaping services for the logical interface, and this configuration is independent of any configuration on other logical interfaces on a given physical interface. You can configure per-unit scheduling by including the per-unit-scheduler statement at the [edit interfaces interface-name] hierarchy level. To configure hierarchical scheduling, include the hierarchical-scheduler statement at the [edit interfaces interface-name] hierarchy level.
  • Timestamping of class-of-service (CoS) queues for a configured Flexible PIC Concentrator (MX Series)—Starting in Junos OS Release 16.1, you can configure the Packet Forwarding Engine to collect the timestamp for all inbound and outbound queue counters for all subscribers that are configured on the Flexible PIC Concentrator (FPC) and, when requested, also return statistics corresponding to data traffic on the router.

    To configure the timestamp for an FPC, include the packet-timestamp enable statement at the [edit chassis fpc slot-number traffic-manager] hierarchy level.

    [See Enabling a Timestamp for Ingress and Egress Queue Packets]

  • Support for packet-marking schemes on a per-customer basis (MX Series)—Traditionally, packet marking in the Junos OS uses the forwarding class and loss priority determined from a BA classifier or multifield classifier. This approach does not allow rewrite rules to be directly assigned for each customer because of the limited number of combinations of forwarding class and loss priority.

    Beginning with Junos OS Release 16.1R1, a new packet-marking scheme, called policy map, enables you to define rewrite rules on a per-customer basis. Policy maps are defined at the [edit class-of-service policy-map] hierarchy level and can be assigned to a customer through a firewall action, an ingress interface, or a routing policy.

    [See Assigning Rewrite Rules on a Per-Customer Basis Using Policy Maps Overview.]

  • Enhanced ingress queuing support for built-in ports (MX80, MX104)—Starting with Junos OS Release 16.1, support for ingress queuing is extended to the built-in (fixed) ports on MX80 and MX104 routers. The MX104 has the following four built-in ports: xe-2/0/0, xe-2/0/1, xe-2/0/2, and xe-2/0/3. The MX80 also has four built-in ports: xe-0/0/0, xe-0/0/1, xe-0/0/2, and xe-0/0/3. In this release, for the MX80 and MX104, the maximum number of ports that can support ingress queuing is increased from 10 to 12. You can distribute the 12 ingress queuing ports among MIC ports and built-in ports. Therefore, you can select a combination of ports (including MIC ports and built-in ports) for ingress queuing. To enable ingress queuing, specify ingress-and-egress as the value of the mode statement at the [edit chassis fpc fpc-slot-number pic pic-slot-number traffic-manager] hierarchy level.

    Note: The systemwide hierarchical queuing bandwidth remains the same and is shared by built-in ports and MIC ports. Enabling ingress queuing on built-in ports results in a Packet Forwarding Engine restart, and requires a two-step commit operation.

    In releases before Junos OS Release 16.1, ingress queuing is supported only on MIC ports and not on built-in ports, and the maximum number of ports that support ingress queuing is 10.

  • Hierarchical CoS support for GRE tunnel interface output queues (MX Series routers with MPC5E)—Starting with Junos OS Release 16.1R1, you can manage output queuing of traffic entering GRE tunnel interfaces hosted on MPC5E line cards in MX Series routers. Support for the output-traffic-control-profile configuration statement, which applies an output traffic scheduling and shaping profile to the interface, is extended to GRE tunnel physical and logical interfaces. Support for the output-traffic-control-profile-remaining configuration statement, which applies an output traffic scheduling and shaping profile for remaining traffic to the interface, is extended to GRE tunnel physical interfaces.

    Note: Interface sets (sets of interfaces used to configure hierarchical CoS schedulers on supported Ethernet interfaces) are not supported on GRE tunnel interfaces.

    [See Configuring Traffic Control Profiles for Shared Scheduling and Shaping.]

High Availability and Resiliency

  • Support for unified in-service software upgrade (MX Series)—Starting in Release 16.1, Junos OS extends support for unified in-service software upgrade (unified ISSU) for the following MICs:
    • Channelized OC3/STM1 (Multi-Rate) Circuit Emulation MIC with SFP (MIC-3D-4COC3-1COC12-CE)
    • Channelized E1/T1 Circuit Emulation MIC (MIC-3D-16CHE1-T1-CE)
    • SONET/SDH OC3/STM1 (Multi-Rate) MICs with SFP (MIC-3D-4OC3OC12-1OC48)
    • SONET/SDH OC3/STM1 (Multi-Rate) MICs with SFP (MIC-3D-8OC3OC12-4OC48)

    Unified ISSU is a process to upgrade the system software with minimal disruption of transit traffic and no disruption of the control plane. You can use unified ISSU only to upgrade to a later version of the system software. When unified ISSU completes, the new system software state is identical to that of the system software when the system upgrade is performed through a cold boot.

  • Note: This feature is documented but not supported in Junos OS Release 16.1R1.

    High availability for IPsec on MS-MPCs—Starting in Junos OS Release 16.1, you can use the new one-to-one statement at the [edit interfaces interface-name load-balancing-options high availability-options ] hierarchy level to configure one-to-one redundancy (1:1) between a pair of interfaces. If the active interface fails, the backup interface takes over. The one-to-one statement configures synchronization between the two interfaces, which creates support for IPsec connections over the redundant interfaces.
  • Support for unified in-service software upgrade on MX Series routers with MPC5E and MPC6E (MX240, MX480, MX960, MX2010, and MX2020)—Starting with Release 15.1F2 and 16.1R1, Junos OS supports unified in-service software upgrade (unified ISSU) on MX Series routers with MPC5E (MPC5E-40G10G, MPC5E-100G10G), MPC5EQ (MPC5EQ-40G10G, MPC5EQ-100G10G), and MPC6E (MX2K-MPC6E). Also, in this release, Junos OS extends support for unified ISSU on the following MICs that are supported on MPC6E:
    • 10-Gigabit Ethernet MIC with SFP+ (24 Ports)
    • 10-Gigabit Ethernet OTN MIC with SFP+ (24 Ports) (non-OTN mode only)
    • 100-Gigabit Ethernet MIC with CFP2 (non-OTN mode only)
    • 100-Gigabit Ethernet MIC with CXP (4 Ports)

    Unified ISSU is a process to upgrade the system software with minimal disruption of transit traffic and no disruption of the control plane. You can use unified ISSU only to upgrade to a later version of the system software. When unified ISSU completes, the new system software state is identical to that of the system software when the system upgrade is performed through a cold boot.

  • Configure BFD over LAG using AE interface addresses (MX Series)—Beginning with Junos OS Release 16.1, you can configure BFD over child links of an AE or LAG bundle using AE interface addresses also, thereby conserving routable IP addresses. In earlier Junos releases, you could configure BFD over LAG using loopback addresses only. To configure BFD over LAG using AE interface addresses or loopback addresses, include the bfd-liveness-detection statement at the [edit interfaces aex aggregated-ether-options bfd-liveness-detection] hierarchy level. Disable duplicate address detection before configuring this feature for the IPv6 address family.

    [See Understanding Independent Micro BFD Sessions for LAG.]

Interfaces and Chassis

  • Maximum generation rate for ICMP and ICMPv6 messages is configurable (MX Series)—Starting in Junos OS Release 16.1, you can configure the maximum rate at which ICMP and ICMPv6 messages that are not ttl-expired are generated by using the icmp rate limit and icmp6 rate limit configuration statements at the [edit chassis] hierarchy level.
  • Starting in Junos OS Release 16.1, the show pfe statistics traffic command now displays the following fabric statistics:
    • Fabric Input packets—Number and rate of incoming fabric packets
    • Fabric Output packets—Number and rate of outgoing fabric packets
  • Clock Synchronization feature support on non-Ethernet MICs—Starting in Release 16.1R1, Junos OS extends clock synchronization support for the MIC-3D-1OC192-XFP on the MX104 router. This feature enables the selection of the best timing source based upon the Synchronization Status Message (SSM).
  • Support for GPS external clock interface on the MX2020 Control Board (MX2020)—Starting with Junos OS Release 16.1, you can configure the external clock interface on the MX2020 Control Board to select the global positioning system (GPS) clock source as an input clock source to the centralized timing circuit. You can also configure the external clock interface to select either the chassis clock source or a recovered line clock source with GPS timing signals of 1 MHz, 5 MHz, or 10 MHz with 1 pulse per second (PPS) as the output clock source.
  • Support for inline Two-Way Active Measurement Protocol (TWAMP) server on MPC5E (MX240, MX480, MX960, MX2010, and MX2020)—You can now configure an inline TWAMP server as part of the inline services (si-) interface processing for MPC5E interfaces. TWAMP is an open protocol for measuring network performance between any two devices that support TWAMP. To configure the TWAMP server, specify the logical interface on the service PIC that provides the TWAMP service by including the twamp-server statement at the [edit interfaces si-fpc/pic/port unit logical-unit-number family inet] hierarchy level. You can also specify the TWAMP server properties by including the server statement at the [edit services rpm twamp] hierarchy level.
  • Support to monitor physical Ethernet (10G, 40G, and 100G) links, detect link degradation, and trigger fast-reroute to minimize packet loss (MX Series Routers with MPC3, MPCE, and MPC4E)—Starting with Junos OS Release 16.1R1, you can monitor the physical link degrade (indicated by bit error rate BER levels) and take corrective actions when [BER] levels drop in the range of 10-13 to 10 -5.

    Layer 2 and Layer 3 protocols support the monitoring of a physical link degrade and so does the Ethernet link through the Link Fault System (LFS). However, for both these monitoring mechanisms, the BER range of 10-13 to 10-5 is very low. Due to its low BER level, the physical link degrade goes undetected, causing disruption and packet loss on an Ethernet link.

    Following new configurations have been introduced at the [edit interfaces interface-name] hierarchy level to support this feature in Junos OS:

    • To monitor physical link degrade on Ethernet interfaces, configure the link-degrade-monitor statement.

    • To configure the BER threshold value at which the corrective action should be triggered or cleared from an interface, use the link-degrade-monitor thresholds (setvalue | clearvalue) statement. The value is the BER threshold value in a scientific notation. You can configure this value in the 1E-n format, where 1 is the mantissa (remains constant) and n is the exponent. For example, a threshold value of 1E-3 refers to the BER threshold value of 1X10-3.

      The supported exponent range is 1 through 16 and the default value is

    • To configure the link degrade interval value, use the link-degrade-monitor thresholds interval value statement. The interval value configured, determines the number of consecutive link degrade events that are considered before taking any corrective action. The supported value range for the interval is 1 through 256, and the default interval is 10.
    • To configure link degrade warning thresholds, use the link-degrade-monitor thresholds (warning-set value | warning-clear value) statement. The value is again specified in the 1E-n format and the supported value range for n is 1 through 16. With this configuration, every time the BER threshold value is reached, a system message is logged to indicate that a link degrade has occurred (warning-set) or the link degrade has been cleared (warning-clear) on an interface.
    • To configure the link degrade action that is taken on reaching the configured BER threshold levels, use the link-degrade action media-based statement. A media-based action brings down the physical interface at the local end of the interface, and stops BER monitoring on the interface (though link fail is active at the local end and the recovery fail is active on the remote end of the degraded link) until an autorecovery mechanism is triggered.
    • To configure the link degrade recovery options, use the link-degrade recovery (auto interval value | manual) statement. The recovery mechanism triggers the recovery of a degraded link.

      auto recovery is used with the media-based action when there are no Layer 2 or Layer 3 protocols configured on the interface. With the auto recovery option, you must configure the interval in seconds, after which the system triggers the auto recovery mechanism on a degraded link. The default interval is 1800 seconds.

      The manual recovery option is configured with media-based action configuration when Layer 2 and Layer 3 protocols are configured on an interface. To trigger manual recovery, use the request interface link-degrade-recovery interface-name statement.

  • Support for ITU-T Y.1731 ETH-LM, ETH-SLM, and ETH-DM on aggregated Ethernet interfaces (MX Series routers with MPCs)—Starting in Junos OS Release 16.1, you can configure ITU-T Y.1731 standard-compliant Ethernet loss measurement (ETH-LM), Ethernet synthetic loss measurement (ETH-SLM), and Ethernet delay measurement (ETH-DM) capabilities on aggregated Ethernet (AE) interfaces. These performance monitoring functionalities are supported on MX Series routers with MPCs, where the same level of support for the Ethernet services OAM mechanisms as the level of support on non-aggregated Ethernet interfaces is available on AE interfaces. ETH-DM is supported on MPC3E and MPC4E modules with only software timestamping. ETH-SLM is supported on MPC3E and MPC4E modules.
  • Optical transceiver support for MX104 —Starting with Release 16.1R1, Junos OS extends support for the following optical transceivers on MX104 routers:
    • SFP-1FE-FX-Manufactured by Fiberxon—supports Gigabit Ethernet MIC with SFP (MIC-3D-20GE-SFP), Gigabit Ethernet MIC with SFP (E) (MIC-3D-20GE-SFP-E), and Gigabit Ethernet with SFP (EH) (MIC-3D-20GE-SFP-EH)
    • SFP-1FE-FX-Manufactured by Avago—supports Gigabit Ethernet MIC with SFP (E) (MIC-3D-20GE-SFP-E) and Gigabit Ethernet with SFP (EH) (MIC-3D-20GE-SFP-EH), but does not support Gigabit Ethernet MIC with SFP (MIC-3D-20GE-SFP)
    • SFP-1GE-FE-E-T
    • SFP-1GE-LH
    • SFP-1GE-LX
    • SFP-1GE-SX-ET
    • SFP-GE10KT13R14
    • SFP-GE10KT14R13
    • SFP-GE40KM
    • SFP-GE40KT13R15
    • SFP-GE40KT15R13
    • SFP-GE80KCW1470-ET
    • SFP-GE80KCW1550-ET
    • SFP-GE80KCW1610-ET
    • SFP-T-ET
    • SFP-LX-ET
    • SFPP-10GE-ER
    • SFPP-10GE-ZR
  • Increased tunnel bandwidth for inline tunnel services (MX240, MX480, MX960, MX2010, and MX2020 routers)—Starting with Junos OS Release 16.1R1, the tunnel bandwidth is increased for MPC7E-10G, MPC7E-MRATE, MX2K-MPC8E, and MX2K-MPC9E. The maximum bandwidth per tunnel is 120 Gbps for MPC7E-10G, MPC7E-MRATE, and MX2K-MPC8E, and 200 Gbps for MX2K-MPC9E. The bandwidth command for tunnel services is enhanced to configure the tunnel bandwidth from 1 Gbps through 400 Gbps, with increments of 1 Gbps.
  • Support for Ethernet OAM on MPC7E-MRATE, MPC7E-10G, MX2K-MPC8E, and MX2K-MPC9E (MX240, MX480, MX960, MX2010, and MX2020 routers)— Starting in Release 16.1R1, Junos OS extends MPLS support for MPC7E-MRATE, MPC7E-10G, MX2K-MPC8E, and MX2K-MPC9E.
  • Support for Ethernet OAM on MPC7E-MRATE, MPC7E-10G, MX2K-MPC8E, and MX2K-MPC9E (MX240, MX480, MX960, MX2010, and MX2020 routers)— Starting in Release 16.1R1, Junos OS extends Ethernet OAM support for MPC7E-MRATE, MPC7E-10G, MX2K-MPC8E, and MX2K-MPC9E.
  • Support for scaling on MPC7E-MRATE, MPC7E-10G, MX2K-MPC8E, and MX2K-MPC9E (MX240, MX480, MX960, MX2010, and MX2020 routers)—Starting in Junos OS Release 16.1R1, MPC7E-MRATE, MPC7E-10G, MX2K-MPC8E, and MX2K-MPC9E are supported on MX Series routers. These MPCs support scaling and performance values that are equivalent to the scaling and performance values supported by MPCs such as MPC6E, MPC5E, MPC2E-3D-NG/NG-Q, and MPC2E-3D-NG/NG-Q.
  • Support for hyper mode feature on MPC7E-MRATE, MPC7E-10G, MX2K-MPC8E, and MX2K-MPC9E (MX240, MX480, MX960, MX2010, and MX2020)—The hyper mode feature is supported on MPC7E-MRATE, MPC7E-10G, MX2K-MPC8E, and MX2K-MPC9E. The hyper mode feature enhances the performance and throughput of a router by increasing the data packet processing rate and optimizes the lifetime of a data packet.

    To configure the hyper mode feature, use the hyper-mode statement at the [edit forwarding-options] hierarchy level.

    • Support for flexible queuing on MPC7E-MRATE, MPC7E-10G, MX2K-MPC8E, and MX2K-MPC9E (MX240, MX480, MX960, MX2010, and MX2020)— The flexible queuing feature is supported on non-hierarchical quality-of-service (non-HQoS) MPCs MPC7E-MRATE, MPC7E-10G, MX2K-MPC8E, and MX2K-MPC9E. By default, the non-HQoS MPCs do not support flexible queuing. You can enable flexible queuing on these MPCs by including the flexible-queuing-mode statement at the [edit chassis fpc] hierarchy level. When flexible queuing is enabled, non-HQoS MPCs support a limited queuing capability of 32,000 queues per slot, including ingress and egress.
  • Configuration support to improve MC-LAG Layer 2 and Layer 3 convergence (MX Series)—Starting with Junos OS Release 16.1R1, you can configure multichassis link aggregation (MC-LAG) interfaces to improve Layer 2 and Layer 3 convergence time to subsecond values when a multichassis aggregated Ethernet link goes down or comes up in a bridge domain.

    To use this feature, ensure that the interchassis link (ICL) is configured on an aggregated Ethernet interface. For Layer 2 convergence, configure the enhanced-convergence statement at the [edit interfaces aeX aggregated-ether-options mc-ae] hierarchy level. For Layer 3, configure the enhanced-convergence statement at the [edit interfaces irb unit unit-number] hierarchy level for an integrated routing and bridging (IRB) interface.

    Note:

    • If the enhanced-convergence feature is configured on an multichassis aggregated Ethernet interface of a bridge domain that has an IRB interface, the IRB interface must also be configured for the convergence feature.
    • All multichassis aggregated Ethernet interfaces that are part of a bridge domain must be configured for enhanced convergence in order to utilize this feature on any of them.
    • On enabling or disabling the enhanced convergence feature, all services get deleted and re-created.

    [ See Configuring Active-Active Bridging and VRRP over IRB in Multichassis Link Aggregation on MX Series Routers, Configuring Multichassis Link Aggregation on MX Series Routers.]

  • LACP hold-up timer configuration support on LAG interfaces—Starting with Junos OS Release 16.1R1, you can configure a Link Aggregation Control Protocol (LACP) hold-up timer value for link aggregation group (LAG) interfaces.

    You configure the hold-up timer to prevent excessive flapping of a child (member) link of a LAG interface due to transport layer issues. With transport layer issues, it is possible for a link to be physically up and still cause LACP state-machine flapping. LACP state-machine flapping can adversely affect traffic on the LAG interface. To prevent this, a hold-up timer value is configured. LACP monitors the PDUs received on the child link for the configured time value, but does not allow the member link to transition from the expired or defaulted state to current state. This configuration thus prevents excessive flapping of the member link.

    To configure the LACP hold-up timer for LAG interfaces, use the hold-time up timer-value statement at the [edit interfaces ae aeX aggregated-ether-options lacp] hierarchy level.

    Initialization delay timer feature support on LAG interfaces (MX Series)—Starting with Junos OS Release 16.1R1, you can configure an initialization delay timer value on link aggregation group (LAG) interfaces.

    When a standby multichassis aggregated Ethernet (MC-AE) interface reboots to come up in active-active MC-AE mode, the Link Aggregation Control Protocol (LACP) protocol comes up faster than the Layer 3 protocols. As soon as LACP comes up, the interface is UP and starts receiving traffic from the neighboring interfaces. In absence of the routing information, the traffic received on the interface is dropped, causing traffic loss.

    The initialization delay timer, when configured, delays the MC-AE node from coming UP for a specified amount of time. This gives the Layer 3 protocols time to converge on the interface and prevent traffic loss.

    To configure the initialization delay timer on an MC-AE interface, use the init-delay-timer statement at the [edit interfaces ae-interface-name aggregated-ether-options mc-ae] hierarchy level.

  • Support for ARP cache protection to prevent DOS attacks (M, MX, T Series)—Starting in Junos OS Release 16.1, you can configure an ARP cache limit for resolved and unresolved next-hop entries in the cache. This limits the maximum number of next hops that can be created. The benefit of configuring ARP cache limit is to protect the device from DOS attacks. You can configure the cache limit globally at the system level or for a particular interface. To configure the cache limit at the system level, include the arp-system-cache-limit statement at the [edit system] hierarchy level. To configure the cache limit at an interface level, include the arp-max-cache statement at the [edit interfaces interface-name unit interface-unit-number family inet] hierarchy level. To configure the maximum number of unresolved next-hop entries to hold for an interface, set the arp-new-hold-limit statement at the [edit interfaces interface-name unit interface-unit-number family inet] hierarchy level. To view ARP cache statistics at the system level, run the show system statistics arp command. To view the ARP cache statistics for an interface, run the show interfaces interface-name command.
  • Synchronous Ethernet support on MPC7E-MRATE, MPC7E-10G, MX2K-MPC8E, and MX2K-MPC9E (MX240, MX480, MX960, MX2010, and MX2020)—Starting with Junos OS Release 16.1R1, Synchronous Ethernet with Ethernet Synchronization Message Channel is supported on MPC7E-MRATE, MPC7E-10G, MX2K-MPC8E, and MX2K-MPC9E.

  • Disabling fabric grant bypass mode for better performance (MX2010 and MX2020)—Fabric grant bypass mode is enabled, by default, for all MPCs on MX2010 and MX2020 routers. Disabling fabric grant bypass mode controls congestion and thus improves system behavior and performance on MX2010 and MX2020 routers. Starting with Junos OS Release 16.1, you can disable fabric grant bypass mode on MX2010 and MX2020 routers by including the disable-grant-bypass configuration statement at the [edit chassis fabric] hierarchy level.

    Note: After disabling fabric grant bypass mode on the MX2010 and MX2020, you must reboot the router for the changes to take effect. MPC1 (MX-MPC1-3D), MPC2 (MX-MPC2-3D), and the 16-port 10-Gigabit Ethernet MPC (MPC-3D-16XGE-SFP) do not power on after you disable fabric grant bypass mode and reboot the router.

  • Support for aysnchronous notification on MIC-8OC3OC12-4OC48-SFP and MIC-1OC192-HO-VC-XFP (MX240, MX480, MX960, MX2010, and MX2020 routers)—Starting in Junos OS Release 16.1R1, the asynchronous-notification command is supported at the [edit interfaces interface-name sonet-options] hierarchy level for the MICs MIC-8OC3OC12-4OC48-SFP and MIC-1OC192-HO-VC-XFP .

    In a network comprising SONET and Ethernet interfaces connected through a TCC circuit, if an interface goes down, you can use the asynchronous–notification command to disable the physical interface on the remote end, thereby notifying the loss of signal (LOS) and loss of connection.

  • Routing Engine failover detection (MX240, MX480, MX960, MX2010, and MX2020)—Starting with Junos OS Release 16.1, you use the on-re-to-fpc-stale configuration statement at the [edit chassis redundancy failover] hierarchy level to instruct the backup Routing Engine to take the mastership if the em0 interface fails on the master Routing Engine.
  • Upgrading MPC8E bandwidth from 960 Gbps to 1600 Gbps (MX2010 and MX2020)—Starting in Junos OS Release 16.1R1, you can upgrade MPC8E to provide an increased bandwidth of 1600 Gbps (1.6 Tbps), by using an add-on license. After you purchase the license and perform the upgrade, MPC8E provides a bandwidth of 1.6 Tbps, which is equivalent to that of MPC9E. However, the MPC continues to be identified as MPC8E.

    Note: After you upgrade MPC8E to provide a bandwidth of 1.6 Tbps, the power consumption by MPC8E increases and is equivalent to the power that MPC9E consumes.

    You upgrade the bandwidth by using the set chassis fpc slot bandwidth 1.6T command. You can disable this feature by using the delete chassis fpc slot bandwidth 1.6T command.

    [See MPC8E on MX Series Routers Overview.]

  • Upgrading MPC8E bandwidth from 960 Gbps to 1600 Gbps—Starting in Junos OS Release 16.1R1, you can upgrade MPC8E to provide an increased bandwidth of 1600 Gbps (1.6 Tbps), by using an add-on license. After you perform the upgrade, MPC8E provides a bandwidth of 1.6 Tbps, which is equivalent to that of MPC9E. However, the MPC continues to be identified as MPC8E. You upgrade the bandwidth by using the bandwidth 1.6T statement.

IPv4

  • IPv4 address conservation method for hosting providers (MX Series)—Starting with Junos OS Release 14.2R4, Release 15.1R1, Release 16.1R1, and later releases, you can configure a static route on an integrated routing and bridging (IRB) interface with or without pinning to a specific underlying interface, thereby conserving the usage of IP address space.

    When a customer needs servers to be assigned within a block of IP addresses, several IP addresses are consumed. These include the network and broadcast IP addresses, the addresses for the router gateway that the servers are connected to, and the addresses of the individual servers. When this effect is multiplied across thousands of hosting providers, IP address space is underutilized.

    This issue can be resolved by configuring the router interface with an address from the reserved IPv4 prefix for shared address space (RFC 6598) and by using static routes pointed at that interface. Internet Assigned Numbers Authority (IANA) has recorded the allocation of an IPv4 /10 for use as shared address space. The shared address space address range is 100.64.0.0/10.

    This way, the router interface is allocated an IP address from the shared address space, so it is not consuming publicly routable address space, and connectivity is handled with static routes on the interface. The interface in the server is configured with a publicly routable address, but the router interfaces are not. Network and broadcast addresses are consumed out of the shared address space rather than the publicly routable address space.

Junos OS XML API and Scripting

  • Support for Python language for commit, event, op, and SNMP scripts (MX Series)—Starting in Junos OS Release 16.1, you can author commit, event, op, and SNMP scripts in Python on devices that include the Python extensions package in the software image. Creating automation scripts in Python enables you to take advantage of Python features and libraries as well as leverage Junos PyEZ APIs supported in Junos PyEZ Release 1.3.1 and earlier releases to perform operational and configuration tasks on devices running Junos OS. To enable execution of Python automation scripts, which the root user must own, configure the language python statement at the [edit system scripts] hierarchy level, and configure the filename for the Python script under the hierarchy level appropriate to that script type. Supported Python versions include Python 2.7.x.

    [See Understanding Python Automation Scripts for Devices Running Junos OS.]

Layer 2 Features

  • Support for MAC pinning to prevent loops (MX Series)—A MAC move occurs when a MAC address frequently appears on a different physical interface than the one it was learned on. Frequent MAC moves indicate the presence of loops in Layer 2 bridges and in VPLS networks. To avoid loops, you can enable the MAC pinning feature on an interface.

    Starting in Junos OS Release 16.1, support for MAC pinning is provided to prevent loops in Layer 2 bridges and in VPLS networks.

    When you enable MAC pinning on an interface in a bridge domain or VPLS domain, a MAC address learned over that interface cannot be relearned on any other interface in the same bridge domain or VPLS domain until the MAC address either ages out on the first interface or is cleared from the MAC table. If a packet with the same MAC address arrives at any other interface in the same bridge domain, then the packet is discarded. This action, effectively, controls MAC moves and prevents the creation of loops in Layer 2 bridges and VPLS domains.

    Note: If you do not specify the timeout interval for the MAC addresses by configuring the mac-table-aging-time statement, the MAC addresses learned over the MAC pinning interface are pinned to the interface until the default timeout period expires.

  • Enhanced convergence time required for IRB ARP resolution (MX Series)—Starting with Junos OS Release 16.1, the convergence of IRB ARP resolution when the underlying L2 IFL association with the MAC changes due to link failure or MAC move improves when both enhanced-convergence and enhanced-ip chassis is configured. The show arp and show ipv6 neighbor command does not display the underlying IFL information if the destination interface is IRB.
  • Support for Layer 2 port mirroring to a remote collector over a GRE Interface (MX Series)—Starting with Junos OS Release 16.1, Layer 2 port mirroring to a remote collector over a GRE interface is supported.

Management

  • YANG module that defines CLI formatting for RPC output (MX Series)—Starting with Junos OS Release 16.1, Juniper Networks provides the junos-extension-odl YANG module. The module contains definitions for Junos OS Output Definition Language (ODL) statements, which determine the CLI formatting for RPC output when you execute the operational command corresponding to that RPC in the CLI or when you request the RPC output in text format. You can use statements in the junos-extension-odl module in custom RPCs to convert the XML output into a more logical and human-readable representation of the data. The junos-extension-odl module is bound to the namespace URI http://yang.juniper.net/yang/1.1/jodl and uses the prefix junos-odl.

    [See Understanding Junos OS YANG Extensions for Formatting RPC Output.]

  • YANG module that defines Junos OS operational commands (MX Series)—Starting with Junos OS Release 16.1, Juniper Networks provides the juniper-command YANG module, which represents the operational command hierarchy and collective group of modules that define the remote procedure calls (RPCs) for Junos OS operational mode commands. You can download Juniper Networks YANG modules from the website, or you can generate the modules by using the show system schema format yang module juniper-command operational command on the local device. The juniper-command module is bound to the namespace URI http://yang.juniper.net/yang/1.1/jrpc and uses the prefix jrpc.

    [See Understanding the Juniper Networks YANG Modules for Operational Commands.]

  • Support for adding non-native YANG modules to the Junos OS schema (MX Series)–Starting with Junos OS Release 16.1, you can load standard (IETF, OpenConfig) or custom YANG models on devices running Junos OS to add data models that are not natively supported by Junos OS but can be supported by translation. Doing this enables you to augment the configuration hierarchies and operational commands with data models that are customized for your operations. The ability to add data models to a device is also beneficial when you want to create device- and vendor-agnostic operational and configuration models that enable the same RPC or configuration to be used on different devices from one or more vendors. You can load YANG modules that add configuration hierarchies or custom RPCs by using the request system yang add operational command.

    [See Understanding the Management of Non-Native YANG Modules on Devices Running Junos OS.]

  • Juniper Extension Toolkit for Junos (JET for Junos) provides a modern programmatic interface for developers of third-party applications—As of Junos OS Release 16.1, JET for Junos, an evolution of the Junos SDK, allows customers and partners to build and run applications either directly on Junos OS devices or off-box. These applications can interact with Junos OS native features. A framework is provided in the Python language for Python JET for Junos application developers. This framework allows your applications to run directly on Junos OS devices. JET for Junos is based on Apache Thrift; thus, it also supports multiple languages running off-box to interact with the same JET for Junos APIs. This gives developers true flexibility to adapt Junos OS devices to business processes.

    Developers can view JET guides at http://www.juniper.net/techpubs/en_US/jet1.0/information-products/pathway-pages/product/1.0/index.html. For the JET Applications Guide, see http://www.juniper.net/techpubs/en_US/junos16.1/information-products/pathway-pages/config-guide-jet-applications/jet-apps-administration-guide-jet.html.

MPLS

  • Longest matching route for label mapping (MX Series)— Starting with Junos OS Release 16.1, LDP uses the longest match to learn the routes aggregated or summarized across OSPF areas or IS-IS levels in the interdomain.
  • Explicit notifications for pseudowire termination (MX Series)—Starting with Junos OS Release 16.1R1, MX Series routers can provide notifications on the service node when the access pseudowire goes down, and provide efficient termination capabilities when Layer 2 and Layer 3 segments are interconnected. This feature also provides termination of pseudowire into virtual routing and forwarding (VRF) and virtual private LAN service (VPLS) routing instances without pseudowire redundancy, which includes:
    • Termination of an access pseudowire into VRF.
    • Termination of an access pseudowire into a VPLS instance.
  • Support for NIST Deterministic Random Bit Generator (DRBG) recommendations (MX Series)—Starting with Release 16.1, Junos OS supports NIST computer security standards recommended in Recommendation for Random Number Generation Using Deterministic Random Bit Generators, NIST Special Publication 800-90A; Recommendation for the Entropy Sources Used for Random Bit Generation, NIST DRAFT Special Publication 800-90B; and Recommendation for Random Bit Generator (RBG) Constructions, DRAFT NIST Special Publication 800-90C.

    Note: Junos OS supports Recommendation for the Entropy Sources Used for Random Bit Generation, NIST DRAFT Special Publication 800-90B and Recommendation for Random Bit Generator (RBG) Constructions, DRAFT NIST Special Publication 800-90C only when the system is operating in Junos-FIPS mode.

  • BGP Prefix-Independent Convergence (PIC) Edge for RSVP (MX Series)—Starting with Junos OS Release 16.1, BGP PIC Edge for RSVP enables you to implement a solution where a protection path is calculated in advance to provide an alternative forwarding path in case of path failure.

    With BGP PIC Edge in an MPLS VPN network, IGP failure triggers a repair of the failing entries and causes the Packet Forwarding Engine to use the pre-populated protection path until global convergence has re-resolved the VPN routes. This feature helps to reduce the convergence time taken to repair the remote provider edge (PE) link failure, when compared to the traditional approach of re-resolving each prefix. The convergence time is no longer dependent on the number of prefixes.

    Earlier, this feature used LDP as the transport protocol, which is now extended to support BGP PIC Edge with RSVP as the transport protocol. When RSVP receives a tunnel down notification at the ingress PE router, it sends a notification to the Packet Forwarding Engine to start making use of the tunnel to the alternate egress PE router. The tunnel route to the alternate egress PE router is calculated and installed in advance.

  • Protection against incorrect label injection across ASBRs (MX Series)—Starting in Junos OS Release 16.1, you can use regular BGP export policies to control route advertisement to a VPN ASBR peer in a given routing instance. This is especially useful in the service provider context of Inter-AS VPN Option-B ASBRs because it prevents peer ASBRs in a neighboring AS from injecting a VPN label intended for a different peer-AS, or intra-AS PEs, into the common ASBR. The common ASBR only accepts MPLS packets from a peer ASBR that has explicitly advertised the label to the common ASBR.

    To support this new functionality, the statement forwarding-context is introduced at the [edit protocols bgp group] hierarchy level, and the instance type mpls-forwarding is introduced at the [edit routing-instances] hierarchy level.

  • Support for inet and inet6 families on pseudowire subscriber logical interface (MX Series)—Starting with Junos OS Release 16.1R1, inet and inet6 families are supported on the services side of an MPLS pseudowire subscriber as well as non-subscriber logical interfaces. You use family inet6 to assign an IPv6 address. You use family inet to assign an IPv4 address. A logical interface can be configured with both an IPv4 and IPv6 address.

    [See Pseudowire Subscriber Logical Interfaces Overview.]

  • Support for Inline IPFIX on pseudowire subscriber logical interface (MX Series)—Starting with Junos OS Release 16.1R1, Inline IPFIX is supported on the services side of an MPLS pseudowire subscriber logical interface. With Inline IPFIX you can configure active sampling to be performed on an inline data path without the need for a services Dense Port Concentrator (DPC). To enable this feature, define a sampling instance with specific properties. One Flexible PIC Concentrator (FPC) can support only one instance. For each instance, either services PIC-based sampling or inline sampling is supported per family. As a result, a particular instance can define PIC-based sampling for one family and inline sampling for a different family. Both IPv4 and IPv6 are supported for inline sampling.
  • RSVP scalability (MX Series)—Starting with Junos OS Release 16.1, RSVP Traffic Engineering (TE) protocol extensions for fast reroute (FRR) facility protection are introduced to allow greater scalability of LSPs and faster convergence times. RSVP-TE runs in enhanced FRR profile mode by default and includes FRR extensions as defined in RFC 2961. In mixed environments, where a subset of LSPs traverse nodes do not include this feature, RSVP-TE behavior is unchanged—backward compatibility is fundamentally supported in the design.
  • Enhancements to MPLS RSVP-TE LSP (MX Series)—The Junos OS implementation of MPLS RSVP-TE is scaled to enhance the usability, visibility, configuration, and troubleshooting of label-switched paths (LSPs) in Junos OS Release 16.1 and later releases.

    These enhancements make the RSVP-TE configuration easier at scale by:

    • Ensuring that the LSP data-plane readiness during LSP resignaling (before traffic traverses the LSP) by using the RSVP-TE LSP self-ping mechanism.
    • Removing the current hard limit of 64K LSPs on an ingress router, and thereby enabling scaling to be constrained only by the total number of LSPs RSVP-TE signaling can sustain.
    • Preventing abrupt tearing down of LSPs by the ingress router because of delay in signaling the LSP at the transit routers.
  • Leaking MPLS routes to nondefault routing instances (MX Series with MPC/MIC interfaces)—Starting in Junos OS Release 16.1, you can use the import-labeled-routes statement to specify one or more nondefault routing instances where you want MPLS pseudowire labeled routes to be leaked from the mpls.0 path routing table in the master routing instance.

    This capability prevents traffic loss in an L2VPN/VPLS configuration where the remote PE router is learned from the IGP in a nondefault routing instance. Because ingress-labeled routes are installed only in the master mpls.0 table by default, no route is found in the routing-instance-name.mpls.0 table when L2VPN/VPLS traffic is received on the core-facing interface, and that traffic is dropped.

  • Support for Ethernet circuit cross-connect (CCC) encapsulation on pseudowire subscriber logical interface (MX Series)—Starting with Junos OS Release 15.1R3 and 16.1R1 and later releases, CCC encapsulation is supported on the transport side of an MPLS pseudowire subscriber logical interface. This feature helps in migrating or deploying seamless MPLS architectures in access networks. Customers deploying either business edge or broadband residential edge access networks use this feature to configure interfaces over the virtual Ethernet interface similar to what is already available on physical Ethernet interfaces.

    You can define only one transport logical interface per pseudowire subscriber logical interface. Although the unit number can be any valid value, we recommend that unit 0 represent the transport logical interface. Two types of pseudowire signaling are allowed: Layer 2 circuit and Layer 2 VPN.

  • Support for DDoS on pseudowire subscriber logical interface (MX Series)—Starting with Junos OS Release 15.1R3 and 16.1R1 and later releases, distributed denial-of-service (DDoS) protection is supported on the services side of an MPLS pseudowire subscriber logical interface. DDoS protection identifies and suppresses malicious control packets while enabling legitimate control traffic to be processed. This protection enables the device to continue functioning, even when attacked from multiple sources. Junos OS DDoS protection provides a single point of protection management that enables network administrators to customize a profile appropriate for the control traffic on their networks.
  • Support for Policer and Filter on pseudowire subscriber logical interface (MX Series)—Starting with Junos OS Release 15.1R3 and 16.1R1 and later releases, Policer and Filter are supported on the services side of an MPLS pseudowire subscriber logical interface. Policer defines a set of traffic rate limits and sets consequences for traffic that does not conform to the configured limits. Firewall filters restrict traffic destined for the Routing Engine based on its source, protocol, and application. Also, firewall filters limit the traffic rate of packets destined for the Routing Engine to protect against flood or denial-of-service (DoS) attacks.
  • Support for accurate transmit logical interface statistics on pseudowire subscriber logical interface (MX Series)—Starting with Junos OS Release 15.1R3 and 16.1R1 and later releases, accurate transmit statistics on logical interface are supported on the services side of an MPLS pseudowire subscriber logical interface. These statistics report actual transmit statistics instead of the offered load statistics given by the router for the pseudowire subscriber service logical interfaces.
  • Longest matching route for label mapping (MX Series)— Starting with Junos OS Release 16.1, LDP uses the longest match to learn the routes aggregated or summarized across OSPF areas or IS-IS levels in the interdomain.
  • Egress peer engineering of service labels (BGP, MPLS) and egress peer protection for BGP-LU (MX Series)—Beginning with Junos OS Release 14.2R4, you can enable traffic engineering of service traffic, such as MPLS LSP traffic between autonomous systems (ASs), using BGP-labeled unicast for optimum utilization of the advertised egress routes. You can specify one or more backup devices for the primary egress AS boundary router. Junos OS installs the backup path in addition to the primary path in the MPLS forwarding table, which enables MPLS fast reroute (FRR) when the primary link fails.
  • MPLS Encapsulated Payload load-balancing (MX Series)—Starting with Junos OS Release 16.1, configure zero-control-word option to indicate the start of Ethernet frame in an MPLS ether-pseudowire payload. On seeing this control word, four bytes having numerical value of all zeros, the hash generator assumes the start of the Ethernet frame and continues to parse the packet from here and generate hash. For DPC I-chip based cards, configure the zero-control-word option at the [edit forwarding-options hash-key family mpls ether-pseudowire] hierarchy level, and for MPC cards, configure zero-control-word option at the [edit forwarding-options enhanced-hash-key family mpls ether-pseudowire] hierarchy level.
  • LDP native IPv6 support (MX Series)— Starting with Junos OS Release 16.1, LDP is supported in an IPv6 network only, and in an IPv6 or IPv4 dual-stack network. Configure the address family as inet for IPv4 or inet6 for IPv6. By default, IPv6 is used as the TCP transport for an LDP session with its peers when both IPv4 and IPv6 are enabled. The dual-transport statement allows Junos OS LDP to establish the TCP connection over IPv4 with IPv4 neighbors, and over IPv6 with IPv6 neighbors as a single-stack LSR. The inet-lsr-id and inet6-lsr-id are the two LSR IDs that have to be configured to establish an LDP session over IPv4 and IPv6 TCP transport. These two IDs should be non-zero and must be configured with different values.
  • MPLS-TP enhancements for on-demand connectivity verification (MX Series)—Starting with Junos OS Release 16.1, the transport profile (TP) of MPLS supports two additional channel types for the default LSPING channel type. These additional channel types provide on-demand connectivity verification (CV) with and without IP/UDP encapsulation.

    With this feature, the following channel types are supported in the MPLS-TP mode:

    • On-demand CV (0x0025)—This channel type is a new pseudowire channel type and is used for on-demand CV without IP/UDP encapsulation, where IP addressing is not available or non-IP encapsulation is preferred.
    • IPv4 (0x0021)—This channel type uses the IP/UDP encapsulation and provides interoperability support with other vendor devices using IP addressing.
    • LSPING (0x0008)—This is the default channel type for Junos OS, and the GACH-TLV is used along with this channel type.

    As per RFC 7026, GACH-TLV is deprecated for 0x0021 and 0x0025 channel types.

    To configure a channel type for MPLS-TP, include the lsping-channel-type channel-type statement at the [edit protocols mpls label-switched-path lsp-name oam mpls-tp-mode] and [edit protocols mpls oam mpls-tp-mode] hierarchy levels.

Multicast

  • Improved multicast convergence and RPT-SPT support for BGP-MVPN (MX Series)—Starting with Junos OS Release 16.1, support for multicast forwarding-cache threshold is extended to rendezvous-point tree shortest-path tree (RPT-SPT) mode for BGP-MVPN. In addition, for both Rosen and next-generation MVPNs, PE routers across all sites should see the same set of multicast routes even if the configured forwarding-cache limit is exceeded.

    To configure a specific threshold for MVPN RPT, set one or both of the mvpn-rpt-suppress and mvpn-rpt-reuse statements at the [edit routing-instances name routing-options multicast forwarding-cache] or [edit logical system name routing-instances name routing-options multicast forwarding-cache] hierarchy level.

    In addition, the show multicast forwarding-cache statistics command provides information about both the general and RPT suppression states. Likewise, a list of suppressed customer-multicast states can be seen by running the show mvpn suppressed general| mvpn-rpt inet| inet6 instance name summary command.

  • Improved scaling for multicast OIFs (MX Series)—Starting with Junos OS Release 16.1, for both Rosen and NGEN-MVPN, improvements have been made to increase the number of possible outgoing interfaces (OIFs) used in virtual routing and forwarding (VRF). Changes have also been made to improve the efficiency of PIM Join/Prune message processing and to support the increased scaling.

    These changes are implemented by default and do not need to be explicitly enabled. The following operational commands support the increased scale:

    • show multicast next-hops terse
    • show multicast route oif-count
    • show multicast statistics interface
    • show pim join downstream-count
  • Fast-failover according to flow rate (MX Series with MPCs)—Starting in Junos OS Release 16.1, for routers operating in Enhanced IP Network Services mode, you can configure a threshold that triggers fast failover in NG MVPNs with hot-root standby on the basis of aggregate flow rate. For example, fast failover (as defined in Draft Morin L3VPN Fast Failover 05) is triggered if the flow rate of monitored multicast traffic from the provider tunnel drops below the set threshold.
  • SAFI 129 NLRI compliance with RFC 6514 (MX Series)—Starting in Junos OS Release 16.1, the Network Layer Reachability Information (NLRI) format used for BGP VPN multicast has changed. Now Junos OS uses Subsequent Address Family Identifier (SAFI) 129, as defined in RFC 6514, which is length, prefix. Previous releases of Junos OS use SAFI 128 (which is length, label, prefix).
  • Latency fairness optimized multicast (MX Series)—Starting with Junos OS Release 16.1R1, you can reduce latency in the multicast packet delivery by optimizing multicast packets sent to the Packet Forwarding Engines. You can achieve this by enabling the ingress or local-latency-fairness option in the multicast-replication configuration statement at the [edit forwarding-options] hierarchy level. The multicast-replication statement is supported only on platforms with the enhanced-ip mode enabled. This feature is not supported in VPLS networks and Layer 2 bridging.

Network Management and Monitoring

  • Support for RFC 4878 (MX Series)—Starting with Release 16.1, Junos OS supports IETF standard RFC 4878, Definitions and Managed Objects for Operations, Administration, and Maintenance (OAM) Functions on Ethernet-Like Interfaces.

    To enable generation of SNMP traps, dot3OamThresholdEvent and dot3OamNonThresholdEvent, you must configure the new dot3oam-events statement at the [edit snmp trap-groups <group-name> categories] hierarchy level.

    Note:

    • Junos OS does not support the dot3oamFramesLostDueToOam object in the dot3OamStatsEntry table. In addition, Junos OS does not support the SNMP set operations for the OAM MIBs.
    • On an Aggregated Ethernet bundle if link fault management (LFM) is configured, you must do SNMP operations individually for each interface in the AE bundle because some OAM MIB tables are maintained only for member interfaces in the AE bundle.
  • SNMP support to monitor the total number of subscribers per PIC and per slot—Starting in Junos OS Release 16.1R1, you can monitor the total number of subscribers per PIC and per slot. The MIB tables jnxSubscriberPicCountTable and jnxSubscriberSlotCountTable are added to the Juniper Networks enterprise-specific Subscriber MIB to support this feature. In releases earlier than Junos OS Release 16.1, you need to use the show subscribers summary pic and show subscribers summary slot operational commands, respectively, to display the total number of subscribers per PIC and per slot.
  • SNMP support for the timing feature on MPC5E and MPC6E—Starting in Junos OS Release 16.1R1, SNMP supports the timing feature on MPC5E and MPC6E. Currently, SNMP support is limited to defect and event notifications through SNMP traps. The enterprise-specific MIB, Timing Feature Defect/Event Notification MIB, allows you to monitor the operation of PTP clocks within the network. The trap notifications are disabled by default. To enable trap notifications for timing events and defects, include the timing-event statement at the [edit snmp trap-group trap-group object categories] hierarchy level.
  • Support for Entity State MIBs (T Series)—Starting with Junos OS Release 16.1, support for IETF standard RFC 4268, Entity State MIB, is extended to the T Series. Junos OS provides only read-only support to Entity State MIB.
  • IPv6 support for traceroute with AS number lookup (MX Series)—Starting with Junos OS Release 16.1R1, IPv6 is supported for traceroute with the as-number-lookup option. Traceroute is an application used to display a list of routers between the device and a specified destination host. Traceroute also provides an option to look up the autonomous system (AS) number of each intermediate hop on the path from the host to the destination.

    [See traceroute.]

  • Support for the interface-set SNMP index (MX Series)—Starting with Release 16.1, Junos OS supports the interface-set SNMP index that provides information about interface-set queue statistics. The following interface-set SNMP index MIBs are introduced in the Juniper Networks enterprise-specific Class-of-Service MIB:
    • jnxCosIfTable in jnxCos MIB
    • jnxCosIfsetQstatTable in jnxCos MIB
  • SNMP support for fabric queue depth, WAN queue depth, and fabric counter (MX240, MX480, MX960, MX2010, and MX2020)—Starting with Release 16.1, Junos OS provides SNMP support for WAN queue depth, fabric queue depth, and fabric counter. The following SNMP MIB tables include the associated objects:
    • jnxCosQstatTable table
    • jnxCosIngressQstatTable table
    • jnxFabricMib table

    In addition, this feature supports the following traps for the Packet Forwarding Engine resource monitoring MIBs:

    • jnxPfeMemoryTrapVars
    • jnxPfeMemoryNotifications
  • New SNMP MIB object for RADIUS accounting subscribers (MX Series)—Starting with Release 16.1R1, Junos OS supports a new SNMP MIB object, jnxSubscriberAccountingTotalCount, in JUNIPER-SUBSCRIBER-MIB whose object identifier is {jnxSubscriberGeneral 7}. The jnxSubscriberAccountingTotalCount object provides information about the total number of subscribers that have RADIUS accounting enabled.
  • Support for Agent Capabilities MIB (MX Series)—Starting with Release 16.1, Junos OS introduces the Agent Capabilities MIB, which provides information about the implementation characteristics of an Agent subsystem in a network management system. The MIB provides you details of the MIB objects and tables that are supported by an Agent, the conformance and variance information associated with the managed objects in the Agent, and the access level of each object. Currently, the Agent Capability MIB is applicable only for the MPLS and multicast MIBs.
  • New indicators for the jnxLEDState MIB (MX5, MX10, MX40, MX80, MX104, and MX240 routers)—Starting with Release 16.1, Junos OS introduces the following six new indicators for the jnxLEDState MIB object in the jnxLEDEntry MIB table:
    • off—Offline, not running
    • blinkingGreen—Entering state of ok, good, normally working
    • blinkingYellow—Entering state of alarm, warning, marginally working
    • blinkingRed—Entering state of alert, failed, not working
    • blinkingBlue—Entering state of ok, online as an active primary
    • blinkingAmber—Entering state of offline, not running
  • New knob for filtering text substring in system log messages (MX Series)—Starting with Junos OS Release 16.1, a new configuration statement, match-string <string-name>, helps you display specified text substrings in the system log messages when using the show system syslog statement. The match-string <string-name> configuration statement can be configured at the following hierarchy levels:
    • edit system syslog file <file-name>
    • edit system syslog host <host-name>
    • edit system syslog user <user-name>

    This statement can be configured along with the match <string-name> configuration statement. In addition, it reduces the CPU usage while filtering the text substring in the system log messages.

    [See match-string.]

  • Support for RFC 5132, IP Multicast MIB (MX Series)—Starting with Junos OS Release 16.1, Junos OS supports tables and objects defined in RFC 5132, IP Multicast MIB, except the ipMcastZoneTable table. RFC 5132, IP Multicast MIB, obsoletes RFC 2932, IPv4 Multicast Routing MIB.

Routing Policy and Firewall Filters

  • New load-balancing options using source or destination IP address only (MX Series)–Starting in Junos OS Release 16.1, new load-balancing options based solely on the source or destination IP address are available. Using only source IP or destination IP as the basis for generating load-balancing hashes helps service providers to ensure that both incoming and outgoing traffic through provider edge (PE) routers is sent toward the content server that maintains subscriber state for a given subscriber. These options are intended for use in deep packet inspection (DPI) networks with per-subscriber awareness and in environments that employ transparent caching.
  • Policer overhead adjustment at the interface level—Starting in Junos OS Release 16.1, policer-overhead adjustment for ingress and egress policers is defined on a per IFL/direction granularity in order to address MEF CE 2.0 requirements to the bandwidth profile. The policer-overhead adjustment is the range of -16 bytes to +16 bytes. It is applied for all the policers that take into account L1/L2 packet length that are exercised in the specified IFL/direction, including corresponding IFF feature policers, and is applied only to interface/filter-based policers.
  • New packet-per-second (pps)-based policer for transit and control traffic (MX Series)–Starting in Junos OS Release 16.1, a new pps-based policer is available at the [edit firewall policer policer-name] hierarchy level. This new policer is configured using the if-exceeding-pps configuration statement. Compared to bandwidth-based policers, the pps-based policer is more effective at combating low-and-slow types of DDoS attacks. The pps-based policer can be applied in the same manner and the same locations as bandwidth-based policers, but it cannot be used as a percentage-based policer.
  • New route-filter-list and source-address-filter-list configuration statements (MX Series)–Starting in Junos OS Release 16.1, the new route-filter-list and source-address-filter-list statements provide an additional means of configuring route filters and source address filters. Now you can configure route-filter-list or source-address-filter-list at the [edit policy-options] hierarchy level for later use in a policy statement. The lists are used in the same contexts as the route-filter and source-address-filter statements. You can use the lists in multiple policy statements.
  • Priority for Route Prefixes in RPD Infrastructure (MX Series)—Starting in Junos OS Release 16.1, you can specify a priority of high or low through the existing import policy in protocols. Through priority, you can control the order in which the routes get updated from LDP/OSPF to RPD, and RPD to kernel. In the event of a topology change, high priority prefixes are updated in the routing table first, followed by low priority prefixes. Routes that are not explicitly assigned a priority are treated as medium priority.
  • New multifield ingress queuing classifier filter (MX Series with MPCs)–Starting in Junos OS Release 16.1, you can apply the ingress-queuing-filter filter-name statement at the [edit interfaces interface-name family family-name] hierarchy level for the following protocol families: bridge, cc, inet, inet6, mpls, and vpls. The ingress-queuing-filter statement allows you to set the forwarding class and loss priority for a packet prior to ingress queue selection by applying a previously configured firewall filter. Multiple fields within the packet header can be matched based on the configured protocol family within the firewall filter.
  • Support for logical queue-depth in the PFE for IP options packets for a given protocol (MX Series)— Starting with Junos OS Release 16.1R1, you can configure logical queue-depth in the PFE for IP options packets for a given protocol. The queue-depth indicates the number of IP options packets which can be enqueued in the PFE logical queue, beyond which it would start dropping the packets.

Routing Protocols

  • BGP flow specification for IPv6 (MX Series)—Starting with Junos OS Release 16.1, this feature extends IPv6 support to the BGP flow specification and allows propagation of traffic flow specification rules for IPv6 and IPv6 VPN. The BGP flow specification automates coordination of traffic filtering rules in order to mitigate distributed denial-of-service attacks. In earlier Junos OS releases, flow-specific rules were propagated for IPv4 over BGP as network layer reachability information.

    To enable the BGP flow specification for IPv6, include the flow statement at the [edit routing-options] hierarchy level for global configuration or at the [edit routing-instances routing-instance-name routing-options] hierarchy level for instance-level configuration.

    [See flow-ipv6.]

  • Support for PTP over Ethernet (MX Series)—Starting in Junos OS Release 16.1R1, the Precision Time Protocol (PTP) is supported over IEEE 802.3 or Ethernet links on MX Series routers. This functionality is supported in compliance with the IEEE 1588-2008 specification.

    For the base station vendors that support only packet interfaces by using Ethernet encapsulation for PTP packets for time and phase synchronization, you can configure any node (an MX Series router) that is directly connected to the base station to use the Ethernet encapsulation method for PTP on a master port to support a packet-based timing capability.

    To configure Ethernet as the encapsulation type for transport of PTP packets on master or slave interfaces, use the transport 802.3 statement at the [edit protocols ptp slave interface interface-name multicast-mode] or [edit protocols ptp master interface interface-name multicast-mode] hierarchy level.

  • Maximum period for autogeneration of keepalives by the kernel using precision timer feature (MX Series)— Starting with Junos OS Release 16.1, precision timers in the kernel autogenerate keepalives on behalf of BGP after a switchover event from standby to master for a specified maximum period of time.
  • IS-IS Layer 2 mapping (MX Series)—Beginning with Junos OS Release 16.1, you can enable Layer 2 mapping of next-hop addresses using the IS-IS LAN and point-to point Hellos that supply all relevant Layer 2 and Layer 3 binding address information for address resolution. The device at the receiving end can extract the information and populate the ARP or Neighbor Discovery table even before the installation of routes. Layer 2 mapping is a topology driven rather than traffic driven next-hop resolution that minimizes traffic loss while activating an Ethernet link.

    [See Layer 2 Mapping for IS-IS.]

  • IPv6 support for IS-IS BFD (MX Series)—Starting with Junos OS Release 16.1, you can configure IS-IS BFD sessions for IPv6. You can enable IS-IS BFD sessions by including the bfd-liveness-detection statement at the [edit protocols isis interface interface-name family inet|inet6] hierarchy level. Currently, IS-IS BFD configuration is available at the [edit protocols isis interface interface-name] hierarchy level. At present, BFD configuration is supported at both of these hierarchy levels.

    [See bfd-liveness-detection.]

  • IS-IS FRR route convergence (MX Series)—Starting with Junos OS Release 16.1R1, IS-IS fast reroute (FRR) route convergence enables you to restore sub-second service. Sub-second service restoration is a key requirement for service providers on MPLS and native IP-based networks.

    There are many ways to achieve fast reroute with suboptimal next hop to reach a destination, such as loop-free alternate (LFA) and remote loop-free alternate (RLFA). In these cases, IGP downloads the primary and backup next hops beforehand in the forwarding information base (FIB). The Packet Forwarding Engine does a local repair when the primary next hop loses its reachability to a given destination. Because the Packet Forwarding Engine already has an alternative path to reach its destination, sub-second restoration is possible. If the destination is reachable through equal-cost multipath (ECMP), only the primary path is downloaded to the FIB. When the bandwidth of the ECMP links is lower than the required bandwidth for a destination, fast convergence is not possible.

    The best ECMP links are grouped as a unilist of primary next hops to reach the destination. Suboptimal ECMP links are grouped as a unilist of backup next hops to reach the destination. If the bandwidth of the primary next hops falls below the desired bandwidth, the Packet Forwarding Engine does a local repair and traffic switch to back up the unilist next hops.

    [See IS-IS Fast Reroute Route Convergence Overview.]

  • Advertising IPv4 routes over BGP IPv6 sessions(MX Series)—Beginning with Junos OS Release 16.1, you can configure BGP to advertise IPv4 unicast reachability with IPv4 next hop over an IPv6 BGP session. In earlier Junos OS releases, BGP could advertise only inet6 unicast, inet6 multicast, and inet6 labeled unicast address families over BGP IPv6 sessions. This feature allows BGP to exchange all the BGP address families over an IPv6 BGP session.

    [See Advertising IPv4 Routes over IPv6 Overview.]

  • BGP route prefix prioritization (MX Series)–Starting in Junos OS Release 16.1, you can prioritize BGP route updates using output queues. The output queues are serviced using a token mechanism that allows you to assign routes to queues using policies. There is an expedited queue and 16 numbered queues that range in priority from lowest priority (1) to highest priority (16). The lowest priority queue (1) is designated as the default queue. Routes that are not explicitly assigned to a queue by automatic protocol determination or by user policy are placed in this queue.
  • ISIS Purge Originator Identification TLV (MX Series) Beginning with Junos OS Release 15.1 F4, Junos OS supports RFC 6232, Purge Originator Identification TLV for IS-IS , which defines a type, length, and value (TLV) for identifying the origin of a purge initiated by the IS-IS protocol. You can configure this feature to add this TLV to a purge along with the system ID of the Intermediate System (IS) that has initiated this purge. This makes it easier to locate the origin of the purge and its cause. A new show command show isis purge log is introduced to view the purge history and to identify the purge originator.

    [See IS-IS Purge Originator Identification Overview.]

  • Weighted ECMP support for one-hop IS-IS neighbors (MX Series)—Beginning with Junos OS Release 15.1F4, you can configure the IS-IS protocol to get the logical interface bandwidth information associated with the gateways of equal-cost multipath (ECMP) next hop. During per-packet load balancing, traffic distribution is based on the available bandwidth to facilitate optimal bandwidth usage for incoming traffic on an ECMP path of one hop distance. The Packet Forwarding Engine does not distribute the traffic equally, but considers the balance values and distributes the traffic according to the bandwidth availability. However, this feature is not available for ECMP paths that are more than one hop away.

    [See Weighted ECMP Traffic Distribution on One Hop IS-IS Neighbors Overview.]

  • Statements introduced to delay the DHCP-OFFER and DHCP-ADVERISE for DHCPv4 and DHCPv6 server bindings—Starting in Junos OS 16.1R1, you can delay the DHCP-OFFER/DHCP-ADVERTISE sent to the subscribers. This feature is applicable only for DHCPv4 and DHCPv6 server bindings. You can configure the OFFER/ADVERTISE delay per ACI/ARI. You can configure the delay time between 1 and 30 seconds. If you don't configure any delay time, then the default value of 3 seconds will be used.

    To configure the DHCP-OFFER delay for DHCPv4 server bindings, use the delay-offer delay-time <time in seconds> statement at the [edit system services dhcp-local-server overrides] hierarchy level. The delay will take effect only if at least one of the options (option-60/option-70/option-82) are configured. To configure options, go to the [edit system services dhcp-local-server overrides based-on] hierarchy level.

    To configure the DHCP-ADVERTISE delay for DHCPv6 server bindings, use delay advertise delay-time <time in seconds> at the [edit system services dhcp-local-server dhcpv6 overrides] hierarchy level. The delay will take effect only if at least one of the options (option-15/option-16/option-17/option-37) are configured. To configure options, go to the [edit system services dhcp-local-server dhcpv6 overrides based-on] hierarchy level.

  • Support for BGP Optimal Route Reflection (BGP-ORR) (MX Series)—Starting with Junos OS Release 16.1R1, you can configure BGP-ORR with IS-IS as the interior gateway protocol (IGP) on a route reflector to advertise the best path to the BGP-ORR client groups by using the shortest IGP metric from a client's perspective, instead of the route reflector's view.

    To enable BGP-ORR, include the optimal-route-reflection statement at the [edit protocols bgp group group-name] hierarchy level.

    Client groups sharing the same or similar IGP topology can be grouped as one BGP peer group. You can configure optimal-route-reflection to enable BGP-ORR in that BGP peer group. You can also configure one of the client nodes as the primary node (igp-primary) in a BGP peer group so that the IGP metric from that primary node is used to select the best path and advertise it to the clients in the same BGP peer group. Optionally, you can also select another client node as the backup node (igp-backup), which is used when the primary node (igp-primary) goes down or is unreachable.

  • Flow-aware transport pseudowire for BGP L2VPN and BGP VPLS (MX Series)— Starting with Junos OS Release 16.1, the flow-aware transport (FAT) label that is supported for BGP-signaled pseudowires such as L2VPN and VPLS is configured only on the label edge routers (LERs). This causes the transit routers or label-switching routers (LSRs) to perform load balancing of MPLS packets across equal-cost multipath (ECMP) paths or link aggregation groups (LAGs) without the need for deep packet inspection of the payload. The FAT flow label can be used for LDP-signaled forwarding equivalence class (FEC 128 and FEC 129) pseudowires for VPWS and VPLS pseudowires.
  • Control word feature for LDP VPLS and FEC129 VPLS (MX Series)— Starting with Junos OS Release 16.1, the control word feature is supported for LDP VPLS and FEC129 VPLS.
  • Flow-aware transport pseudowire for BGP L2VPN and BGP VPLS (MX Series)— Starting with Junos OS Release 16.1R1, the flow-aware transport (FAT) label is supported for BGP-signaled pseudowires such as L2VPN and VPLS. Configuring flow-label-receive and flow-label-trasmit on the label edge routers (LERs) enables the transit routers or label-switching routers (LSRs) to perform load balancing of MPLS packets across equal-cost multipath (ECMP) paths or link aggregation groups (LAGs) without the need for deep packet inspection of the payload.
  • Support for PTP over Ethernet (MX Series)—Starting in Junos OS Release 16.1R1, Precision Time Protocol (PTP) is supported over IEEE 802.3 or Ethernet links on MX Series routers. This functionality is supported in compliance with the IEEE 1588-2008 specification.

    For the base station vendors that support only packet interfaces by using Ethernet encapsulation for PTP packets for time and phase synchronization, you can configure any node (an MX Series router) that is directly connected to the base station to use the Ethernet encapsulation method for PTP on a master port to support a packet-based timing capability.

    To configure Ethernet as the encapsulation type for transport of PTP packets on master or slave interfaces, use the transport 802.3 statement at the [edit protocols ptp slave interface interface-name multicast-mode] or [edit protocols ptp master interface interface-name multicast-mode] hierarchy level.

Security

  • Support for IPv6 NDP DoS issue (MX Series)—Starting with Junos OS Release 16.1R1, you can address the IPv6 Neighbor Discovery Protocol (NDP) denial-of-service (DoS) issue at the Routing Engine.

    Unlike IPv4 subnets, IPv6 subnets have large address spaces in which a majority of them remain unassigned. When a network scan tool or an attacker initiates traffic to nonexistent hosts through a router on a subnet that is directly connected to the router, the router attempts to perform address resolution on a large number of destinations. This condition can cause the inability to resolve new neighbors, unreachability to the existing neighbors, and can also result in a DoS attack.

    NDP inspection or protection addresses the NDP DoS issue by implementing the prioritization of NDP activities on the Routing Engine. At the ingress router, neighbor discovery (ND) packets are classified and handled according to a predefined priority with multiple ingress queues. On the egress path, neighbor solicitations (NS) sent for previously not seen hosts are handled with a lower priority by deferring the process of next-hop creation and sending out the packet.

  • Support for mitigating potential DDoS issues with IPv6 NDP and resolve traffic (MX Series)—Starting with Junos OS Release 16.1R1, you can resolve potential distributed denial-of-service (DDoS) issues with the IPv6 Neighbor Discovery Protocol (NDP) and traffic.

    The fundamental challenge of IPv6 NDP DDoS is the large address space of IPv6 that allows attackers to trigger a huge number of resolves that exhaust the router resources. The resolution mechanism and DDoS NDP policer help mitigate the problem to some extent.

    The functionality primarily extends the flow-detection CLI and optimizes the hostbound classification (HBC) filter to make packet-type searching faster. It also extends the NDP DDoS protocol group to classify the NDP types. Full Ethernet or IPv6 fields support is added by allowing destination addresses.

Services Applications

  • Data plane inline support for 6rd and 6to4 tunnels connecting IPv6 clients to IPv4 networks (MX Series with MPC5E and MPC6E)—Starting with Release 16.1R1, Junos OS supports inline 6rd and 6to4 on MPC5E and MPC6E line cards. In releases earlier than Junos OS Release 16.1R1, inline 6rd and 6to4 was supported on MPC3E line cards only.
  • Support for inline MPLS Junos Traffic Vision with IPFIX and v9 (MX Series)—Starting in Junos OS Release 15.1F2 and 16.1R1, support of the MX Series routers for the inline Junos Traffic Vision feature is extended to the MPLS family (MPLS and MPLS-IPv4 templates) consisting of the IP Flow Information Export (IPFIX) protocol and flow monitoring version 9 (v9). In previous releases, the inline Junos Traffic Vision feature is supported only for IPv4, IPv6, and VPLS families. In this release, Inline Junos Traffic Vision feature is extended to MPC5E and MPC6E for the VPLS address family.

  • Support for inline video monitoring on MPC5 and MPC6 (MX Series routers)—Starting in Junos OS Release 16.1, support for video monitoring using media delivery indexing (MDI) criteria is expanded to include the MPC5 and MPC6.

    [See Inline Video Monitoring Overview.]

  • Support for RFC 2544-based benchmarking tests (MX Series)—Junos OS Release 16.1 extends support for the reflector function and the corresponding RFC 2544-based benchmarking tests on MX Series routers with MPC1 (MX-MPC1-3D), MPC2 (MX-MPC2-3D), and the 16-port 10-Gigabit Ethernet MPC (MPC-3D-16XGE-SFP). The RFC 2544 tests are performed to measure and demonstrate the service-level agreement (SLA) parameters before activation of the service. The tests measure throughput, latency, frame loss rate, and back-to-back frames.

    RFC 2544-based benchmarking tests on MX Series routers support the following reflection functions:

    • Ethernet pseudowire reflection (ingress and egress direction) (ELINE service—supported for family ccc)
    • Layer 2 reflection (egress direction) (ELAN service—supported for family bridge, vpls)
    • Layer 3 IPv4 reflection (limited support)

    To run the benchmarking tests on the MX Series routers, you must configure reflection (Layer 2 or pseudowire) on the supported MPC. To configure the reflector function on the MPC, use the chassis fpc fpc-slot-no slamon-services rfc2544 statement at the [edit] hierarchy level.

  • Support for RPM probes with IPv6 sources and destinations (MX Series routers with MPCs)—Starting in Junos OS Release 16.1, the RPM client router (the router or switch that originates the RPM probes) can send probe packets to the RPM probe server (the device that receives the RPM probes) that contains an IPv6 address. To specify the destination IPv6 address used for the probes, include the target (url ipv6-url | address ipv6-address) statement at the [edit services rpm probe owner test test-name] hierarchy level. You can also define the RPM client or the source that sents RPM probes to contain an IPv6 address. To specify the IPv6 protocol-related settings and the source IPv6 address of the client from which the RPM probes are sent, include the inet6-options source-address ipv6-address statement at the [edit services rpm probe owner test test-name] hierarchy level.
  • Provide egress VLAN ID and flow direction information in sampling records (MX Series)—Starting in Junos OS Release 16.1R1, Junos OS can include flow direction and egress VLAN ID information in the output records when you perform inline sampling on IPv4 or IPv6 traffic by using the IPFIX or version 9 templates. You can optionally include VLAN IDs in both the ingress and egress directions in the flow key.

    [See Configuring Flow Aggregation to Use Version 9 Flow Templates and Configuring Flow Aggregation to Use IPFIX Flow Templates.]

  • Support for inline MPLS Junos Traffic Vision with IPFIX and v9 (MX Series)—Starting in Junos OS Release 16.1, support for the inline Junos Traffic Vision feature on MX Series routers is extended to the MPLS family (MPLS and MPLS-IPv4 templates), consisting of the IP Flow Information Export (IPFIX) protocol and flow monitoring version 9 (v9). In previous releases, the inline Junos Traffic Vision feature is supported only for IPv4, IPv6, and VPLS families.

    The inline Junos Traffic Vision feature is extended to the MPC5E and MPC6E for VPLS address family. Also, Inline Junos Traffic Vision support using version 9 templates is extended to the VPLS family.

  • Note: This feature is documented but not supported in Junos OS Release 16.1R1.

    IPsec multipath forwarding with UDP encapsulation (MX Series routers with MS-MPCs and MS-MICs)—Starting in Junos OS Release 16.1, you can enable the UDP encapsulation of the IPsec encapsulated packets between peers, which appends a UDP header after the ESP header. Doing this provides Layer 3 and 4 information to the intermediate routers, and the IPsec packets are forwarded over multiple paths, which increases the throughput.

    [See IPsec Multipath Forwarding With UDP Encapsulation.]

  • Note: This feature is documented but not supported in Junos OS Release 16.1R1.

    Subscriber-aware and application-aware traffic treatment (MX Series with MS-MPC)—Although present in the code, the subscriber-aware and application-aware traffic treatment features are not supported in Junos OS Release 16.1R1. Subscriber-aware and application-aware traffic treatment identifies the mobile or fixed-line subscriber and enforces traffic treatment based on policies assigned to the subscriber. A subscriber policy can be based on Layer 7 application information for the IP flow (for example, YouTube) or can be based on Layer 3/Layer 4 information for the IP flow (for example, the source and destination IP address). Subscriber policy actions can include:
    • Redirecting HTTP traffic to another URL or IP address
    • Forwarding packets to a routing instance so that packets are directed to external service chains (predefined sequence of services)
    • Setting the forwarding class
    • Setting the maximum bit rate
    • Performing HTTP header enrichment
    • Setting the gating status to blocked or allowed
  • Note: This feature is documented but not supported in Junos OS Release 16.1R1.

    Service redundancy daemon support for redundancy across multiple gateways (MX Series with MPC)—Although present in the code, the service redundancy daemon support for redundancy across multiple service gateways is not supported in Junos OS Release 16.1R1. The redundancy actions are based on the results of monitoring system events.
  • Note: This feature is documented but not supported in Junos OS Release 16.1R1.

    Traffic load balancer (MX Series with MS-MPC or MPC)—Although present in the code, the traffic load balancer (TLB) features are not supported in Junos OS Release 16.1R1. TLB runs on MX Series routers with Multiservices Modular Port Concentrator (MS-MPC) services PICs and Modular Port Concentrator (MPC) line cards. TLB enables you to distribute traffic among multiple next-hop servers. TLB employs an MS-MPC-based control plane and a data plane using the MX Series router forwarding engine.
  • Note: This feature is documented but not supported in Junos OS Release 16.1R1.

    Enhancements to stateful synchronization (MS-MIC, MS-MPC)—Although present in the code, enhancements to stateful synchronization for long-running flows is not supported in Junos OS Release 16.1R1. These enhancements include:
    • Automatic replication of NAT flows for all service sets: NAT44 flows are automatically synchronized for all eligible service sets. You can selectively disable replication for individual service sets by including the disable-replication-capability statement at the [edit services service-set service-set-name replicate-services] hierarchy level.
    • Checkpointing of IPv4 and IPv6 stateful firewall flows and NAPT-44 with address pooling paired (APP): To manage the frequency of checkpointing, include the replication-threshold seconds statement at the [edit interfaces interface-name redundancy-options] hierarchy level.

Software Installation and Upgrade

  • Validate system software against running configuration on remote host—Beginning with Junos OS Release 16.1R1, you can use the on (host host <username username> | routing-engine routing-engine) option with the request system software validate package-name command to verify candidate system software against the running configuration on the specified remote host or Routing Engine.
  • Validate system software add against running configuration on remote host or routing engine—Beginning with Junos OS Release 16.1R1, you can use the validate-on-host hostname and validate-on-routing-engine routing-engine options with the request system software add package-name command to verify a candidate software bundle against the running configuration on the specified remote host or Routing Engine.

    [See request system software add.]

  • ISSU support for upgrading from FreeBSD 6.1-based Junos OS to FreeBSD 10.x-based Junos OS (MX Series)—Starting with Junos OS Release 16.1R1, you can upgrade from a FreeBSD 6.1-based Junos OS MX Series router to a FreeBSD 10.x-based Junos OS MX Series router by peUpgrading Junos OS with Upgraded FreeBSDrforming unified in-service software upgrade (ISSU). A unified (ISSU) enables you to upgrade between two different Junos OS releases with minimal disruption on the control plane and with minimal disruption of traffic.

    Before performing a unified ISSU from a FreeBSD 6.1-based Junos OS to an upgraded FreeBSD 10.x-based Junos OS, the configuration must be validated on a remote host or on a routing engine. The remote host or the routing engine must be running a Junos OS with an upgraded FreeBSD.

    [See Example: Performing a Unified ISSU.]

    [See Upgrading Junos OS with Upgraded FreeBSD.]

  • New way to provision new routers automatically (MX Series)—As of Junos OS Release 16.1, zero touch provisioning (ZTP) allows you to provision new routers in your network automatically either by executing a script file or by loading a configuration file. In either case, the information is detected in a file on the Dynamic Host Control Protocol (DHCP) server. In releases earlier than Junos OS Release 16.1, automatically provisioning a new device was available only for switches.

    [See Configuring Zero Touch Provisioning.]

  • Limited encryption Junos image (“Junos Limited”) created for customers in Armenia, Belarus, Kazakhstan, Kyrgyzstan, and Russia (MX80, MX104, MX240, MX480, MX960, MX2010, MX2020)—Starting in Junos OS Release 16.1R1, customers in the Eurasian Customs Union (currently comprised of Armenia, Belarus, Kazakhstan, Kyrgyzstan, and Russia) should use the “Junos Limited” image for MX240, MX480, MX960, MX2010, and MX2020 routers instead of the “Junos Worldwide” 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.

    Note: The limited encryption Junos image (“Junos Limited”) is to be used by customers in Armenia, Belarus, Kazakhstan, Kyrgyzstan, and Russia. Customers in all other countries should use “Junos” image which was introduced in 15.1R1 to replace “Junos Domestic” image.

  • Limited encryption Junos image (“Junos Limited”) created for customers in Armenia, Belarus, Kazakhstan, Kyrgyzstan, and Russia (MX80 and MX104)—Starting in Junos OS Release 16.1R1, customers in the Eurasian Customs Union (currently comprised of Armenia, Belarus, Kazakhstan, Kyrgyzstan, and Russia) should use the “Junos Limited” image for MX80 and MX104 routers instead of the “Junos Worldwide” 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.

    Note: The limited encryption Junos image (“Junos Limited”) is to be used by customers in Armenia, Belarus, Kazakhstan, Kyrgyzstan, and Russia.

Subscriber Management and Services

Note: Although present in the code, the subscriber management features are not supported in Junos OS Release 16.1R1. Documentation for subscriber management features is included in the Junos OS Release 16.1 documentation set.

  • Wildcard domain map (MX Series)—Starting in Junos OS Release 16.1R1, you can configure a wildcard domain map that is used by subscribers when there is no exact match to the subscriber’s domain name, but there is a partial match. For example, if you create a wildcard domain map with the name xyz*.com, subscribers with the domain names xyz-eastern.com and xyz-northern.com are both mapped to that wildcard domain when there was no exact match for the subscriber’s domain name.

    To configure a wildcard domain map, you include the asterisk wildcard character in the map domain-map-name statement at the [edit access domain] hierarchy level.

    Wildcard domain mapping is also useful to provide a partial match when subscriber management derives subscriber usernames from the DHCPv4 Agent Remote ID (option 82 suboption 2) or the DHCPv6 Remote-ID (option 37). For example, a username might be EricSmith#premiumTier1#314159265#0000 (where the # character is the delimiter). For domain mapping for this subscriber, you might create the wildcard domain map, domain map premiumTier1*.

    [See Configuring a Wildcard Domain Map.]

  • DHCP-initiated service change based on client Remote ID (MX Series)—Starting in Junos OS Release 16.1R1, DHCP local server enables you to update a client’s current service based on the client’s remote ID. DHCP-initiated service updates are particularly useful in dual-stack environments and other networks that do not include RADIUS support.

    When a DHCP client is initially established, DHCP preserves the client’s incoming remote ID in the DHCP client database. You can configure DHCP local server to compare the client’s initial remote ID to the remote ID that the server subsequently receives in DHCP Renew or Rebind messages. If DHCP local server detects a mismatch between the two remote IDs, the server tears down the existing binding, which initiates a client reconnect sequence. The service change is encoded within the new remote ID string, and is activated when the client reconnects.

    DHCP local server receives the remote ID in option 82, suboption 2 for DHCPv4 clients, and in DHCPv6 option 37 for DHCPv6 clients.

    To configure DHCP local server to support the remote ID service change feature, use the remote-id-mismatch disconnect statement at the [edit system services dhcp-local-server] hierarchy level. You can configure support globally or for a specific group.

    [See DHCP-Initiated Service Change Based on Remote ID.]

  • New support for Framed-IP-Netmask for access-internal routes (MX Series)—Starting in Junos OS Release 16.1, the mask value returned by RADIUS in the Framed-IP-Netmask attribute during PPP negotiation is considered for application to the access-internal route for the subscriber session. In earlier releases, the attribute mask is ignored and a /32 netmask is always applied, with the consequence that the address is set to the value of the Framed-IP-Address attribute returned by RADIUS.

    Now, when the SDB_FRAMED_PROTOCOL attribute is equal to AUTHD_FRAMED_PROTOCOL_PPP, the value of SDB_USER_IP_MASK is set to 255.255.255.255 by default. This value is overridden by the Framed-IP-Netmask value, if present.

    When the SDB_FRAMED_PROTOCOL attribute is equal to AUTHD_FRAMED_PROTOCOL_PPP, the show subscribers command now displays the actual value of Framed-IP-Netmask in the IP Netmask field. Otherwise, the field displays the default value of 255.255.255.255.

  • Disabling DHCP snooping filters for DHCP traffic that can be directly forwarded (MX Series)—Starting in Junos OS Release 16.1, you can disable DHCP snooping filters for an address family in the routing context in which snooping is configured.

    When you first enable DHCP snooping, all DHCP traffic is snooped by default and only DHCP packets associated with subscribers (or their creation) will be handled; all other DHCP packets will be discarded. You can optionally modify this dropping behavior based on the type of interface:configured interfaces, non-configured interfaces, or all interfaces. All snooped DHCP traffic is still forwarded to the routing plane in the routing instance, and in some cases, this results in excessive DHCP traffic being sent to the routing plane for snooping. The no-snoop statement disables snooping filters for DHCP traffic that can be forwarded directly from the hardware control plane, such as Layer 3 unicast traffic with a valid route, preventing that DHCP traffic from being forwarded to the slower routing plane of the routing instance.

    [See DHCP Snooping Support.]

  • Changes to AAA accounting statistics counters (MX Series)—Starting in Junos OS Release 16.1, 17 new statistics counters have been added to the output of the show network-access aaa statistics accounting detail command to report accounting information that is backed up when RADIUS accounting servers are unreachable and RADIUS backup accounting options are configured.

    In earlier releases, the general statistics counters display aggregate values for original accounting events plus backup events. Now the Accounting response success, Accounting retransmissions, and Requests received counters no longer include requests that are sent to the backup accounting mechanism.

    Two non-backup statistics counters have also been added, Accounting request failures and Accounting request success.

    The Timed out requests counter has been renamed to Accounting request timeouts.

    [See show network-access aaa statistics.]

  • New option for service type added to test aaa commands (MX Series)—Starting in Junos OS Release 16.1, you can include the service-type option with the test aaa ppp user and test aaa dhcp user commands to test the AAA configuration of a subscriber. You can use this option to distinguish a test session from an actual subscriber session. The option specifies a value for the Service-Type RADIUS attribute [6] in the test Access-Request message; when you do not include this option, the test uses a service type of Framed. You can specify a number in the range 1 through 255, or you can specify a string that corresponds to an RFC-defined service type. When the Service-Type RADIUS attribute [6] is received in an Access-Accept message, it overrides the value inserted in the Access-Request message by this command.

    [See test aaa dhcp user and test aaa ppp user.]

  • New predefined variable for dynamic underlying interfaces (MX Series)—Starting in Junos OS Release 16.1, you can use the Juniper Networks predefined variable, $junos-underlying-ifd-name, to reference the underlying physical interface when you configure CoS properties for an underlying logical interface in a dynamic profile. The new variable is useful when the $junos-interface-ifd-name variable already references a different physical interface, such as in configurations with stacked logical interfaces. For example, in a PPPoE session where the PPP logical interface is stacked over a demux VLAN logical interface, $junos-interface-ifd-name is set to the pp0 physical interface. In this case you can specify the $junos-underlying-ifd-name predefined variable with the interfaces statement at the [edit dynamic-profiles profile-name class-of-service] hierarchy level to reference the underlying physical interface.
  • Support for service session termination causes (MX Series)—Starting in Junos OS Release 16.1, new internal identifiers are available that identify the reasons that authd initiates termination of individual service sessions. In earlier releases, the termination cause for a service session is the same as that for the parent subscriber session.

    The service termination causes map to default code values that are reported in the RADIUS Acct-Terminate-Cause attribute (49) in Acct-Stop messages for the service. You can use the new service-shutdown option with the terminate-code aaa statement at the [edit access] hierarchy level to remap any of the new termination causes to any number in the range 1 through 4,294,967,295:

    • network-logout—Termination was initiated by deactivation of one family for a dual-stack subscriber, typically triggered by termination of the corresponding Layer 3 access protocol. Default code value is 6.
    • remote-reset—Termination was initiated by an external authority, such as a RADIUS CoA service-deactivation. Default code value is 10.
    • subscriber-logout—Overrides the default inheritance of the subscriber session value with a different value when you map it to a different value. Default code value is 1, meaning that it inherits the terminate cause from the parent subscriber session.
    • time-limit—Service time limit was reached. Default code value is 5.
    • volume-limit—Service traffic volume limit was reached. Default code value is 10.

    The show network-access aaa terminate-code aaa detail command displays the new termination causes and their current code values.

    [See Understanding Session Termination Causes and RADIUS Termination Cause Codes.]

  • Support for a static unnumbered interface with $junos-routing-instance (MX Series)—Starting in Junos OS Release 16.1, you can configure a static logical interface as the unnumbered interface in a dynamic profile that includes dynamic routing instance assignment by means of the $junos-routing-instance predefined variable.

    Note: This configuration fails commit if you also configure a preferred source address, either statically with the preferred-source-address statement or dynamically with the $junos-preferred-source-address predefined variable for IPv4 (family inet) addresses or the $junos-preferred-source-ipv6-address predefined variable for IPv6 (family inet6) addresses.

    Note: The static interface must belong to the routing instance; otherwise the profile instantiation fails.

    In earlier releases, when the dynamic profile includes the $junos-routing-instance predefined variable, you must do both of the following, else the commit fails:

    • Use the $junos-loopback-interface-address predefined variable to dynamically assign an address to the unnumbered interface. You cannot configure a static interface address.
    • Use the $junos-preferred-source-address or $junos-preferred-source-ipv6-address predefined variable to dynamically assign a secondary IP address to the unnumbered interface. You cannot configure a static preferred source address.

    [See Configuring an Unnumbered Interface.]

  • Logical interface option for show ptp port command (MX Series)—Starting in Junos OS Release 16.1, you can display PTP port information for a specific logical interface by using the ifl logical-interface-name option with the show ptp port command:
    user@host> show ptp port ifl ge-1/0/5.0
    PTP port-data:
    Local Interface   : ge-1/0/5.0
    Local Address     : 2001:db8:00:05:85:73:b0:aa
    Remote Address    : 2001:db8:01:80:c2:00:00:0e
    Clock Stream      : 0              Clock Identity    : 2001:db8::85:ff:fe:73:b7:d0
    Port State        : Master         Delay Req Interval: -4
    Announce Interval : 1              Announce Timeout  : 3
    Sync Interval     : -6             Delay Mechanism   : End-to-end
    Port Number       : 1              Operating Mode    : Master only
    
  • Enhancements to test aaa statements for VLAN-OOB subscribers (MX Series)—Starting in Junos OS Release 16.1, you can use the no-address-request option with the test aaa dhcp user and test aaa ppp user statements for testing subscribers in a Layer 2 scenario where no address allocation request is required.

    The output of these two statements now displays two additional user attributes. Dynamic Profile is the name of the profile received in the Client-Profile-Name VSA (26-174). Routing Instance is the name of the routing instance conveyed by the Virtual-Router VSA (26-1). The existing Virtual Router Name attribute is the locally configured name of the logical system.

    [See Testing a Subscriber AAA Configuration.]

  • New predefined variables and Juniper Networks VSAs for family any interface filters (MX Series)—Starting in Junos OS Release 16.1, you can use the $junos-input-interface-filter and $junos-output-interface-filter predefined variables to attach a filter to a dynamic interface created for family any. The filter names are derived from the Juniper Networks VSAs, Input-Interface-Filter (26-191), and Output-Interface-filter (26-192). These VSAs are conveyed in the following RADIUS messages: Access-Request, Acct-Start, Acct-Stop, and Acct-Interim-Interval. You can specify the variables as the filter names with input and output statements at the [edit dynamic-profiles profile-name interfaces interface-name unit logical-interface-number filter] hierarchy level.

    [See Juniper Networks VSAs Supported by the AAA Service Framework.]

  • New predefined variable to group subscribers on a physical interface (MX Series)—Starting in Junos OS Release 16.1, you can specify the new Juniper Networks predefined variable, $junos-phy-ifd-interface-set-name, with the interface-set statement at the [edit dynamic-profiles profile-name interfaces] hierarchy level to configure an interface set associated with the underlying physical interface in a dynamic profile. This predefined variable enables you to group all the subscribers on a specific physical interface so that you can apply services to the entire group of subscribers.

    Another use case is optimizing CoS level 2 node resources by grouping residential subscribers into an interface set associated with the physical interface in a topology where residential and business subscribers share the interface, enabling the use of CoS level 2 nodes for the interface set rather than for each residential interface.

    [See CoS for Interface Sets of Subscribers Overview.]

  • Configuring default values for routing instances (MX Series)—Starting in Junos OS Release 16.1, you can define a default value for the Juniper Networks predefined variable, $junos-routing-instance. This value is used in the event RADIUS does not supply a value for $junos-routing-instance. To configure a default value, use the predefined-variable-defaults statement at the [edit dynamic-profiles] hierarchy level. For example, to set the default value to RI-default:
    [edit dynamic-profiles profile-name]user@host# set predefined-variable-defaults routing-instance RI-default
  • Address-assignment pool hold-down (MX Series)—Starting in Junos OS Release 16.1, you can place an active address-assignment pool in a hold-down state. When a pool is in the hold-down state, no additional addresses are allocated from that pool. However, the hold-down state does not affect any existing subscribers that are using addresses previously assigned from the pool.

    As the existing subscribers disconnect, their IP addresses are marked as free in the pool, but the addresses are not reallocated because of the pool’s hold-down state. Eventually, when all subscribers have disconnected and their addresses are returned to the pool, the pool becomes inactive. When the pool is in the inactive state, you can safely perform maintenance on the pool (such as adding, changing, or deleting addresses) without affecting any active subscribers.

    [See Configuring Address-Assignment Pool Hold Down.]

  • Support for subscriber management and services feature parity (MX104)—Starting in Release 16.1, the MX104 supports all subscriber management and services features that are supported on the MX240, MX480, and MX960 routers as of Junos OS Release 14.1R1. Previously, the MX104 matched feature support with the MX80 as of Junos OS Release 13.3R1.
  • PPPoE-over-ATM support and other enhancements to PPPoE subscriber session lockout (MX Series)—Starting in Junos OS Release 16.1, PPPoE subscriber session lockout supports PPPoE-over-ATM subscriber interfaces and also adds the following enhancements:
    • Persistence of the lockout condition after automatic removal of dynamic VLAN or VLAN demultiplexing (demux) subscriber interfaces.
    • Termination of the lockout condition after administratively clearing the lockout or resetting the interface module.
    • Ability to clear the lockout condition or display information about the lockout status by specifying encapsulation type identifier characteristics when no underlying interface exists for the subscriber session:
      • VLAN identifiers (device name, S-VLAN ID, and VLAN ID) in the clear pppoe lockout vlan-identifier and show pppoe lockout vlan-identifier commands
      • ATM identifiers (device name, VPI, and VCI) in the clear pppoe lockout atm-identifier and show pppoe lockout atm-identifier commands

    [See PPPoE Subscriber Session Lockout Overview.]

  • New reject action for a LAC receiving change requests from the LNS (MX Series)—Starting in Junos OS Release 16.1, you can configure the LAC to reject change requests received in SCCRP messages from the LNS. During tunnel establishment, the LNS might include a request for the LAC to change the destination IP address, UDP port, or both, that it uses to communicate with the LNS. When a LAC that is configured to reject these requests receives one, it sends a StopCCN message to the original address or port and then terminates the connection to that LNS. This reject option is in addition to the previously available accept and ignore options.

    [See Configuring How the LAC Responds to Address and Port Changes Requested by the LNS.]

  • Enhanced subscriber management support for Ethernet OAM on S-VLANs with associated C-VLANs and subscriber interfaces (MX Series routers with MPCs/MICs)—This feature is supported in Junos OS Release 16.1 with no changes from the original 13.2R1 implementation. As such, when Ethernet IEEE 802.1ag Operation, Administration, and Maintenance (OAM) connectivity fault management (CFM) is configured on a static single-tagged service VLAN (S-VLAN) logical interface on a Gigabit Ethernet, 10-Gigabit Ethernet, or Aggregated Ethernet physical interface, you can configure the router to propagate the OAM state of the S-VLAN to the associated dynamic or static double-tagged customer VLAN (C-VLAN) logical interfaces. If the CFM continuity check protocol detects that the OAM state of the S-VLAN is down, you can configure the underlying physical interface to bring down all associated C-VLANs on the interface with the same S-VLAN (outer) tag as the S-VLAN interface. In addition, the router brings down all DHCP, IP demultiplexing (IP demux), and PPPoE logical subscriber interfaces configured on top of the C-VLAN. Propagation of the S-VLAN OAM state to associated C-VLANs ensures that when the OAM state of the S-VLAN link is down, the associated C-VLANs and all subscriber interfaces on top of the C-VLANs go down as well.

    To enable propagation of the S-VLAN OAM state to associated C-VLAN logical interfaces, use the oam-on-svlan option when you configure a Gigabit Ethernet (ge), 10-Gigabit Ethernet (xe), or Aggregated Ethernet (ae) interface.

    Ethernet OAM support for S-VLANs and associated C-VLANs is not currently supported for use with dynamic profiles, S-VLAN trunk interfaces, or C-VLAN trunk interfaces.

  • Support for manual targeting—Starting in Junos OS Release 16.1R1, service providers can configure manual targeting-assigning specific member links as primary and backup links per subscriber so that all traffic goes through those links. Manual targeting enhances the distribution of targeted VLANs or subscribers across member links of an aggregated Ethernet bundle by making it bandwidth-aware.

    You configure the targeting options by including the targeted-options statement at the [edit interfaces aex aggregated-ether-options] hierarchy level.

    You can select the targeting type for an aggregated Ethernet bundle as manual or auto at the [edit interfaces aex aggregated-ether-options targeted-options] hierarchy level.

    When you configure manual targeting, you must always configure a primary link. Configuring a backup link is optional. You specify the primary and backup links for a subscriber in the individual interface configuration.

    If the aggregated Ethernet bundle is configured for manual targeting, then all the subscribers in that bundle can be optionally configured for manual targeting, but none of them can be configured for autotargeting (targeted distribution). That is, you cannot have a configuration that contains a mix of manual targeting and autotargeting among subscribers. If the aggregated Ethernet bundle is not configured for manual targeting, then you can optionally configure autotargeting for all the subscribers, but you cannot configure manual targeting for any of them. Manual targeting and autotargeting are supported only on static interfaces.

  • Grouping of subscribers with similar bandwidth usage—Junos OS Release 16.1R1 supports grouping of subscribers with similar bandwidth usage and ensures even distribution of subscribers in each group across the member links of an aggregated Ethernet bundle. Service providers can group together subscribers with similar bandwidth usage and optionally assign a group name. Subscribers that are configured for targeted distribution without a group name are added to the default group and distributed evenly across member links. Grouping of subscribers is supported only for static subscribers.

    You can specify the group name by including the group statement at the [edit interfaces interface-nameunit logical-unit-number targeted-options] hierarchy level.

  • Configurable session limits for L2TP (MX Series)—Starting in Junos OS Release 16.1, you can configure a limit on the maximum number of L2TP sessions allowed for the chassis, for all tunnels, for a tunnel-group, for a client group, and for a client. When the session limit is reached, no new sessions can be established until the number of current sessions drops below the configured limit. One use of this feature is to control the number of sessions from an enterprise customer that is connected over LACs in multiple locations. These configured session limits have no effect on the maximum supported chassis limits that are imposed through the Juniper Networks license.

    [See Limiting the Number of L2TP Sessions Allowed by the LAC or LNS.]

  • Ensuring IPCP negotiation for IPv4 DNS addresses (MX Series)—Starting in Junos OS Release 16.1, the router can prompt customer premises equipment (CPE) to negotiate both primary and secondary IPv4 DNS addresses during IPCP negotiation. This feature is useful when the CPE fails to send DNS address options in the IPCP configure request message, or when the options are sent but rejected. In earlier releases, either situation results in no DNS address negotiation even though IPv4 DNS addresses are available on the router. This DNS option enables the router to control IPv4 DNS address provisioning for dynamic and static, terminated PPPoE and LNS subscribers.

    [See Ensuring IPCP Negotiation for Primary and Secondary DNS Addresses.]

  • Filters for duplicate RADIUS accounting interim reports (MX Series)—Starting in Junos OS Release 16.1, you can specify which accounting servers receive the RADIUS accounting interim reports when RADIUS accounting duplicate reporting is active.

    Subscriber management supports the following filtering for RADIUS accounting duplicate reporting:

    • Duplicated accounting interim messages—The accounting messages are sent only to RADIUS accounting servers in the subscriber’s access profile.
    • Original accounting interim messages—The accounting messages are sent only to servers in a duplication access profile other than the subscriber’s access profile.
    • Excluded RADIUS attributes—RADIUS attributes in accounting messages are filtered based on the exclude statement configuration.

      The exclude statement supports new attributes.

      [See Understanding RADIUS Accounting Duplicate Reporting.]

  • Multiple DHCPv6 IA_NA and IA_PD requests (MX Series)—Starting in Junos OS Release 16.1, DHCPv6 relay agent supports multiple DHCPv6 IA_NA or IA_PD requests within the same Solicit message, up to a maximum of eight requests. This support enables each negotiated lease to have its own lease expiration time and also allows one lease to expire without tearing down any other active leases. The multiple IA address support also enables customers to delegate multiple address blocks to a CPE router, which simplifies flow classification and service monetization.

    In Junos OS releases before Release 16.1, the router supports one IA_NA request or one IA_PD request, or a combination of one of each type of request.

    [See Multiple DHCPv6 IA_NA and IA_PD Requests Per Client Interface.]

  • New VSAs for IPv4 and IPv6 link addresses of first DHCP relay into RADIUS Auth and Accounting Messages (MX Series)—Starting in Junos OS Release 16.1, two new VSAs, DHCP-First-Relay-IPv4-Address and DHCP-First-Relay-IPv6-Address, are available for configuration of a RADIUS server. The values of these new VSAs are the link address of the first relay of a DHCPv4 or DHCPv6 client/server binding. These new VSAs are sent to RADIUS as part of Access-Request, Accounting-Start, Accounting-Interim, and Accounting-Stop Messages. These VSAs enable RADIUS to identify clients uniquely for your business purposes, such as keeping track of your billing clients.

    [See Juniper Networks VSAs Supported by the AAA Service Framework.]

  • Five-Level Hierarchical CoS (MX240, MX480, MX960, and MX2020 Series)—Starting in Junos OS Release 16.1, the Broadband Network Gateway (BNG) supports 5-level hierarchical CoS (HCoS) in dynamic configurations. It allows you to differentiate and shape traffic at the following levels:

    • Level 1—Physical interface (port level)
    • Level 2—Interface set, for example, S-VLAN (access node)
    • Level 3—Customer VLAN (C-VLAN)
    • Level 4—Session logical interface (ppp or dhcp)
    • Level 5—Service queues (up to 8)

    The use cases that five-level HCoS supports include:

    • Residential and business traffic on the same access node (if business interfaces are dynamic).
    • Multiple retail ISPs on the same access node.
    • Multiple subscriber sessions for a household on the same C-VLAN.
    This feature is not supported on agent circuit identifier (ACI) sets or aggregated Ethernet (AE) interfaces.

    [See Understanding Hierarchical CoS for Subscriber Interfaces.]

  • Support for IP reassembly on an L2TP connection (MX Series routers with MPC5E)—Starting in Junos OS Release 16.1, you can configure the service interfaces on MX Series routers with MPC5E to support IP packet reassembly on a Layer 2 Tunneling Protocol (L2TP) connection. The IP packet is fragmented over an L2TP connection when the packet size exceeds the maximum transmission unit (MTU) defined for the connection. Depending on the direction of the traffic flow, the fragmentation can occur either at the L2TP access concentrator (LAC) or at the L2TP network server (LNS), and reassembly occurs at the peer interface. (In an L2TP connection, a LAC is a peer interface for the LNS and vice versa.)

    You can configure the service interfaces on the LAC or on the LNS to reassemble the fragmented packets before they can be further processed on the network. On a router running Junos OS, a service set is used to define the reassembly rules on the service interface. The service set is then assigned to the L2TP service at the [edit services l2tp] hierarchy level to configure IP reassembly for L2TP fragments.

    [See IP Packet Fragment Reassembly for L2TP Overview.]

  • Diameter Network Access Server Requirements (NASREQ) authentication and authorization (MX Series)—Starting in Junos OS Release 16.1, Junos OS supports the Diameter-based Network Access Server Requirements (NASREQ) protocol for authentication and authorization at login. NASREQ is described in RFC 7155. Junos OS supports the following NASREQ protocol exchanges:
    • AA-Request/Answer—The authentication/authorization request at login.
    • Session-Termination-Request/Answer—Notification that the subscriber’s session has been terminated.
    • Abort-Session-Request/Answer—Request to terminate the subscriber’s session from a NASREQ server.

    [See Diameter Based Network Access Server Requirements (NASREQ).]

  • Communicating with RADIUS servers over IPv6 (MX Series)—Starting in Junos OS Release 16.1, subscriber management supports RADIUS connectivity over IPv6, in addition to IPv4 connectivity. This support enables you to specify the IPv6 addresses of your targeted RADIUS servers, and also enables you to specify IPv6 addresses for the source address configuration of your RADIUS servers.

    Also in Release 16.1, the AAA process now supports the NAS-IPv6-Address RADIUS attribute (attribute 95), which identifies the IPv6 address of the NAS that requests subscriber authentication.

    [See Configuring Router or Switch Interaction with RADIUS Servers.]

  • Limiting the subscriber sessions per aggregated Ethernet or Packet Forwarding Engine bundle (MX Series)—Starting in Junos OS Release 16.1, you can restrict the number of Point-to-Point Protocol over Ethernet (PPPoE) subscriber sessions per aggregated Ethernet or Packet Forwarding Engine bundle by using the existing PPPoE Service-Name table. You can modify the existing PPPoE Service-Name table by changing its default configuration to eliminate the default empty Service-Name entry in the Service-Name table.

    In earlier releases, each PPPoE service name table in the service (PPPoE) configuration statement included one empty service entry by default.

  • Support for unlocking destinations during LAC tunnel selection (MX Series)—Starting in Junos OS Release 16.1, the tunnel selection process for a subscriber login enables the LAC to cycle through the tunnel preference levels until it establishes a session to a destination or has attempted to contact every valid destination but failed.

    In earlier releases, if the LAC reaches the lowest level and all valid destinations at that level are locked, it selects the destination with the shortest remaining lockout time, removes the lockout, and attempts to connect to that destination. If it fails, it does not cycle back through the preference levels.

    You can use the new clear services l2tp destination lockout command to manually clear all locked destinations or only locked destinations that match the specified local or remote gateway address.

    [See LAC Tunnel Selection Overview.]

  • Support for DHCPv6 duplicate client DUIDs (MX Series)—Starting in Junos OS Release 16.1, you can configure DHCPv6 relay agent and DHCPv6 local server to support DHCP clients that have the same DHCP unique identifier (DUID) when the DHCPv6 requests are received on different underlying interfaces.

    Typically, the router treats a request from a duplicate client as a renegotiation, and replaces the existing client entry with a new entry. However, in some cases, the duplicate request is from a different client, and replacement is not desired. When you enable duplicate client support, the router uses the underlying interfaces to differentiate between two clients with the same DUID, enabling both clients to be granted leases. The router retains the existing client entry, and creates a new entry for the duplicate client.

    [See DHCPv6 Duplicate Client DUIDs.]

  • Improved multicast convergence and RPT-SPT support for BGP-MVPN (MX Series)—Starting with Junos OS Release 16.1, support for multicast forwarding-cache threshold is extended to rendezvous-point tree shortest-path tree (RPT-SPT) mode for BGP-MVPN. In addition, for both Rosen and next-generation MVPNs, PE routers across all sites should see the same set of multicast routes even if the configured forwarding-cache limit is exceeded.

    To configure a specific threshold for MVPN RPT, set one or both of the mvpn-rpt-suppress and mvpn-rpt-reuse statements at the [edit routing-instances name routing-options multicast forwarding-cache] or [edit logical system name routing-instances name routing-options multicast forwarding-cache] hierarchy level.

    In addition, the show multicast forwarding-cache statistics command provides information about both the general and RPT-suppression states. Likewise, a list of suppressed customer-multicast states can be seen by running the show mvpn suppressed general|mvpn-rpt inet|inet6 instance name summary command.

  • Targeted distribution for VLAN demux logical interface sets over aggregated Ethernet (MX Series)—Starting in Junos OS Release 16.1R1, you can enable targeted distribution to guarantee that subscribers, who are members of the same interface set of VLAN demux logical interfaces over an aggregated Ethernet bundle, each receive the same link selection. By collectively configuring link selection for an entire interface set of subscribers, you can effectively eliminate possible human errors by having to configure link selection on a per-subscriber basis.

System Logging

  • System log messages to indicate checksum errors on the DDR3 interface—Starting in Junos OS Release 13.3 R9, two new system log messages, XMCHIP_CMERROR_DDRIF_INT_REG_CHKSUM_ERR_MINOR and XMCHIP_CMERROR_DDRIF_INT_REG_CHKSUM_ERR_MAJOR, are added to indicate memory-related problems on the interfaces to the double data rate type 3 (DDR3) memory. These error messages indicate that an FPC has detected a checksum error, which is causing packet drops.

    The following error threshold values classify the error as a major error or a minor error:

    • Minor error— 6-254 errors per second
    • Major error—255 and more errors per second

System Management

  • Statement introduced to deny hidden commands—Starting in Release 16.1, Junos OS allows users to deny hidden commands to all users except root. To deny hidden commands to all users except root, use the set system no-hidden-commands statement at the [edit] hierarchy level.
  • Maximum period for autogeneration of keepalives by the kernel using precision timer feature (MX Series)— Starting with Junos OS Release 16.1, precision timers in the kernel autogenerate keepalives on behalf of BGP after a switchover event from standby to master for a specified maximum period of time.

Timing and Synchronization

User Interface and Configuration

  • Support for JSON format for configuration data (MX Series)–Starting with Junos OS Release 16.1, you can configure devices running Junos OS using configuration data in JavaScript Object Notation (JSON) format in addition to the existing text, Junos XML, and Junos OS set command formats. You can load configuration data in JSON format in the Junos OS CLI by using the load (merge | override | update) json command or from within a NETCONF or Junos XML protocol session by using the <load-configuration format="json"> operation. You can load JSON configuration data either from an existing file or as a data stream. Configuration data that is provided as a data stream must be enclosed in a <configuration-json> element.

    [See load, Defining the Format of Configuration Data to Upload in a Junos XML Protocol Session, and Mapping Junos OS Configuration Statements to JSON.]

Virtual Chassis

  • MX Series Virtual Chassis support for L2TP LNS (MX Series)—Starting in Junos OS Release 16.1, MX Series Virtual Chassis configurations support L2TP LNS functionality.

    [See L2TP for Subscriber Access Overview.]

  • MX Series Virtual Chassis commit time improvements (MX Series with MPCs/MICs)—Starting in Junos OS Release 16.1, the commit process for MX Series Virtual Chassis is optimized to provide faster commit times. No additional configured is required to take advantage of the improved commit times. You can use the commit | display detail command to monitor the steps of the new commit process.
  • MX Series Virtual Chassis support for MX240 and MX480 member routers in a VC containing MX2010 or MX2020 member routers (MX Series with MPCs/MICs)—Starting in Junos OS Release 16.1, you can configure a MX240 router or MX480 router as a member router in an MX Series Virtual Chassis that contains a MX2010 or MX2020 member router. In earlier releases, MX2010 routers and MX2020 routers could only interoperate with MX960 routers.

    The following member router combinations are introduced in Junos OS Release 15.2 for a two-member Virtual Chassis configuration:

    • MX240 router and MX2010 router
    • MX240 router and MX2020 router
    • MX480 router and MX2010 router
    • MX480 router and MX2020 router

VPNs

  • Redundant virtual tunnels on MPCs (MX Series)—In multicast Layer 3 VPNs, virtual tunnel (VT) interfaces are needed to facilitate virtual routing and forwarding (VRF) table lookup based on MPLS labels. Beginning with Junos OS Release 16.1, support for redundant VTs at the Packet Forwarding Engine level is provided to improve resiliency in delivering multicast traffic.

    [See Redundant Virtual Tunnels Providing Resiliency in Delivering Multicast Traffic Overview.]

  • MVPN source-active upstream multicast hop selection and redundant source improvements (MX Series)–Starting in Junos OS Release 16.1, you can use new configuration statements available at the [edit protocols mvpn] hierarchy level to influence the source-active upstream multicast hop selection process. You can use the umh-selection-additional-input statement to influence the upstream multicast hop selection by making the MVPN consider a combination of route preference and RSVP tunnel status. You can use the source-redundancy statement so that the MVPN acts on all redundant sources sending to a specific group address as the same source.
  • Note: This feature is documented but not supported in Junos OS Release 16.1R1.

    Support for common Public Key Infrastructure (PKI) functionality (MX Series)—Starting in Junos OS Release 16.1R1, MX Series devices support the following common PKI functionalities:
    • Certificate chaining—Certificate-based authentication is an authentication method supported on MX Series devices during IKE negotiation. In large networks, multiple certificate authorities (CAs) can issue end entity (EE) certificates to their respective end devices. It is common to have separate CAs for individual locations, departments, and organizations. With a single-level hierarchy for certificate-based authentication, all EE certificates in the network must be signed by the same CA. All firewall devices must have the same CA certificate enrolled for peer certificate validation. The certificate payload sent during IKE negotiation only contains EE certificates.

      In Junos OS Release 16.1R1, the certificate payload sent during IKE negotiation can contain a chain of EE and CA certificates. A certificate chain is the list of certificates required to certify the subject in the EE certificate. The certificate chain includes the EE certificate, intermediate CA certificates, and the root CA certificate. CA certificates can be enrolled using the Simple Certificate Enrollment Process (SCEP) or loaded manually. There is no new CLI configuration statement or command for certificate chains; however, every end device must be configured with a CA profile for each CA in the certificate chain.

      The network administrator needs to ensure that all peers participating in IKE negotiation have at least one common trusted CA in their respective certificate chains. The common trusted CA does not have to be the root CA. The number of certificates in the chain, including certificates for EEs and the topmost CA in the chain, cannot exceed 10.

    • Online Certificate Status Protocol (OCSP)—OCSP checks the revocation status of X509 certificates. Requests are sent to the OCSP server(s) configured in a CA profile with the ocsp url statement at the [edit security pki ca-profile profile-name revocation-check] hierarchy level. The use-ocsp option must also be configured. If there is no response from the OCSP server, the request is then sent to the location specified in the certificate's AuthorityInfoAccess extension.
    • Digital certificate validation—The PKI daemon on MX Series devices performs X509 certificate policy, path, key usage, and distinguished name validation, as specified in RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile.
  • New configuration statement to manage VCCV BFD session state (MX Series)—Starting with Junos OS Release 16.1, the ping-multiplier statement is introduced to delay the virtual circuit connectivity verification (VCCV) Bidirectional Forwarding Detection (BFD) session from going down by the specified number of LSP ping packets. The VCCV BFD session is signaled down only after the specified number of LSP ping packets are lost. This feature is supported for Layer 2 Circuit, Layer 2 VPN, and VPLS technologies.

    To configure the LSP ping multiplier feature, include the ping-multiplier number-of-packets statement at the [edit protocols l2circuit neighbor neighbor-address interface interface-name oam], [edit routing-instances routing-instances-name protocols l2vpn oam], and [edit routing-instances routing-instances-name protocols vpls oam] hierarchy levels for Layer 2 circuit, Layer 2 VPN, and VPLS, respectively.

Related Documentation

Modified: 2017-07-24