Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation
Guide That Contains This Content
[+] Expand All
[-] Collapse All

    New and Changed Features

    This section describes the new features and enhancements to existing features in Junos OS Release 16.1R4 for the MX Series and T Series.

    Release 16.1R4 New and Changed Features

    Class of Service

    • Propagating CoS shaping rate adjustments that are based on multicast traffic (MX Series)—Starting in Junos OS Release 16.1R4, you can set up CoS shaping rate adjustments that are based on multicast traffic to be propagated to the parent in the scheduler hierarchy. For service providers that are using interface sets to deliver services such as voice and data and multicast VLANs (M-VLANs) to deliver broadcast television, you can set up CoS so that when a subscriber begins receiving multicast traffic, the shaping rate of the subscriber interface is adjusted to account for the multicast traffic.

      You can now set up the CoS multicast adjustment to be propagated from the subscriber interface to the interface set, which is the parent in the scheduler hierarchy. This feature prevents oversubscription of the subscriber, which can result in dropped traffic and service disruption.

    EVPN

    • VPWS service with EVPN mechanisms (MX Series)—Starting in Junos OS Release 16.1R4, Junos OS enables Ethernet VPN-virtual private wire service (EVPN-VPWS) to present a framework for delivering point-to-point EVC (E-Line) VPWS service with EVPN-signaling mechanisms. VPWS service with EVPN-signaling mechanisms enables single-active and all-active multihoming capabilities and support for inter-autonomous system (AS) options associated with BGP-signaled virtual private network service (VPNS).

      The Metro Ethernet Forum (MEF) describes two models for E-Line service, Ethernet private line (EPL) and Ethernet virtual private line (EVPL). EPL provides a point-to-point Ethernet virtual connection (EVC) between a pair of dedicated user-to-network interfaces (UNIs), with transparency. EVPL differs from EPL in that it enables service multiplexing; that is, multiple EVCs per UNI.

      Associating MEF definitions with EVPN terms, the services are defined as:

      • EVPL—Service between Ethernet segment identifier (ESI) and VLAN pairs {ESI,VLAN}.
      • EPL—Service between two ESIs. For this service, the circuit maps to a whole port; that is, all VLANs coming into a port are trunked together to the other endpoint of the service.

      The EVPN-VPWS feature enables using an autodiscovery route per ESI and an autodiscovery route per Ethernet private instance (EVI) for E-Line service. There is no bridging for EVPN-VPWS service. Type 2 and Type 3 routes are not required. Type 4 routes are used for designated forwarder election, as they are for EVPN multipoint-to-multipoint EVC (E-LAN) services. However, designated forwarder election is useful only for single-active service. For all-active service, designated forwarder election is not required, because there is no broadcast, unknown unicast, and multicast (BUM) traffic in VPWS.

    • EVPN MAC Pinning (MX Series)—Starting in Junos OS Release 16.1R4, Junos OS enables MAC pinning for Ethernet VPN (EVPN), including customer edge (CE) interfaces and EVPN over MPLS core in both all-active mode or active-standby mode.

      MAC pinned over CE interfaces in EVPN is synchronized to remote EVPN PEs by adding the Sticky bit (in accord with RFC 7432, Section 7.7, MAC Mobility Extended Community). On a remote EVPN PE, MAC received with Sticky bit enabled is pinned over MPLS core. Therefore, MAC address advertisement and learning that is conducted through the control plane is enabled according the design of the MAC Mobility Extended Community.

    • EVPN E-Tree (MX Series)—Starting in Junos OS Release 16.1R4, Junos OS enables you to configure an Ethernet VPN E-Tree service.

      The EVPN E-Tree feature implements E-Tree service as defined by the Metro Ethernet Forum (MEF) in draft-sajassi-l2vpn-evpn-etree-03. The E-Tree service is a rooted-multipoint service that is supported only with EVPN over MPLS in the core.

      In an EVPN E-Tree service, each circuit attached to the service is either a root or a leaf. The service adheres to the following forwarding rules:

      • A leaf can send or receive traffic only from a root.
      • A root can send traffic to another root or any of the leaves.
      • A leaf or root can be connected to provider edge (PE) devices in single homing mode or multihoming mode.
    • NSR for EVPN (MX Series)—Starting in Junos OS Release 16.1R4, Junos OS ensures minimal loss of traffic when a Routing Engine switchover occurs with nonstop active routing (NSR) and graceful Routing Engine switchover (GRES) enabled. The forwarding state of the Packet Forwarding Engine remains intact during switchover. The signaling state on the primary Routing Engine and on the standby Routing Engine are built in parallel.

      Note: Expect a traffic loss pertaining to a topology change if the topology change occurs during a switchover.

      EVPN reproduces dynamically generated data (such as labels and sequence numbers), and data obtained from peers on the primary Routing Engine, on the standby Routing Engine. EVPN also monitors BGP ingress and egress routing table messages on the standby Routing Engine to populate its signaling plane data structures. Local MAC addresses are obtained by the Layer 2 address learning process, which transfers the data to the EVPN module in the route processing software. In the network layer reachability information (NLRI) fields of its packets, BGP transfers the MAC addresses to peers in the network.

    General Routing

    • Enhancement to memory utilization (MX Series)—Junos OS Release 16.1R4 supports an enhanced method for calculating the memory utilization by a Routing Engine. The inactive memory is now considered free and is no longer included in the calculation of memory utilization. That is, the value for used memory shown in the output of the show chassis routing-engine command decreases and results in more memory to be available for other processes.

    High Availability and Resiliency

    • Support for unified ISSU on MX Series routers and MX Series Virtual Chassis with MPC3E-3D-NG, MPC3E-3D-NG-Q, MPC2E-3D-NG, MPC2E-3D-NG-Q, and MPC5E (MX240, MX480, MX960, MX2010, and MX2020)—Starting with Release 16.1R4, Junos OS supports unified in-service software upgrade (ISSU) on MX Series routers and MX Series Virtual Chassis with MPC3E-3D-NG, MPC3E-3D-NG-Q, MPC2E-3D-NG, MPC2E-3D-NG-Q, and MPC5E.

      Unified ISSU is supported on MPC5E with the following MICs in non-optical transport network (non-OTN) mode:

      • 3X40GE QSFPP
      • 12X10GE-SFPP OTN
      • 1X100GE-CFP2
      • 2X10GE SFPP OTN

      Note: Unified ISSU is not supported on MPC3E-3D-NG, MPC3E-3D-NG-Q, MPC2E-3D-NG, and MPC2E-3D-NG-Q with the following MICs:

      • MS-MIC-16G
      • MIC-3D-8DS3-E3
      • MIC-3D-1OC192-XFP

      Unified ISSU enables you to upgrade between two different Junos OS releases with no disruption on the control plane and with minimal disruption of traffic.

    Interfaces and Chassis

    • Enhancement to policer configuration—Starting in Junos OS Release 16.1R4, you can configure the MPC to take a value in the range 0 through 5 for the policer tick byte by using the policer-limit statement at the [edit chassis] hierarchy level. If this statement is not configured, the policer tick byte can take values till 7, which is the default behavior. You can use the set chassis policer-limit command to enable this feature.

      You must restart the MPC or the router for the changes to take effect.

    IPV6

    • Preserving and restoring IPv6 prefixes assigned using DHCPv6 PD (MX Series)—Starting in Junos OS Release 16.1R4, when IPv6 addresses are assigned using DHCPv6 prefix delegation (PD), you can configure the router to preserve and restore a subscriber's delegated prefix through multiple logins. This feature prevents an IA-PD change, which triggers renegotiation for all hosts attached to the residential gateway. This feature requires the use of agent circuit identifiers (ACIs) to identify subscribers.

    Layer 2 VPN

    • Support for FEC 128 and FEC 129 in the same routing instance—Starting in Junos OS Release 16.1R4, Junos OS supports t forwarding equivalence class (FEC) 128 or FEC 129-based mesh groups in a FEC 129 VPN instance. You can configure a FEC 129 VPLS instance to support both BGP autodiscovery as defined in FEC 129 as well as statically configured LDP neighbors as defined by FEC 128. This feature allows a router to use a common MAC table to forward traffic between a FEC 128 LDP VPLS domain and a FEC 129 domain.

    Management

    • Support for gRPC streaming for Junos Telemetry Interface firewall filter statistics (MX Series)—Starting with Junos OS Release 16.1R4, you can use gRPC interfaces to provision sensors to subscribe to and receive firewall filter telemetry data. If your Juniper Networks device is running a version of Junos OS with the upgraded FreeBSD kernel, you must download the Junos Network Agent package, which provides the interfaces to manage gRPC subscriptions. The package is available on the All Junos Platforms software download URL on the Juniper Networks webpage. Hierarchical policer statistics are included in telemetry data for firewall filters. Use the /junos/system/linecard/firewall/ path to provision a sensor for firewall filter statistics.

      [See Guidelines for gRPC Sensors.]

    • Support for gRPC streaming for Junos Telemetry Interface LSP statistics (MX Series)—Starting with Junos OS Release 16.1R4, you can use gRPC interfaces to provision sensors to subscribe to and receive telemetry data for label-switched paths (LSPs). If your Juniper Networks device is running a version of Junos OS with the upgraded FreeBSD kernel, you must download the Junos Network Agent package, which provides the interfaces to manage gRPC subscriptions. The package is available on the All Junos Platforms software download URL on the Juniper Networks webpage. Data is collected only for ingress LSPs, bypass LSPs, and bidirectional LSPs for ultimate-hop popping (UHP). The router should operate in enhanced mode. You must also configure the sensor-based-stats statement at the [edit protocols mpls] hierarchy level. Use the /junos/services/label-switched-path/usage/ path to provision a sensor for LSP statistics.

      [See Guidelines for gRPC Sensors.]

    • Support for gRPC streaming for Junos Telemetry Interface physical interface queue statistics (MX Series)—Starting with Junos OS Release 16.1R4, physical interface sensors provisioned through gRPC interfaces also collect egress and ingress queue statistics. If your Juniper Networks device is running a version of Junos OS with the upgraded FreeBSD kernel, you must download the Junos Network Agent package, which provides the interfaces to manage gRPC subscriptions. The package is available on the All Junos Platforms software download URL on the Juniper Networks webpage. On MX Series routers, queue statistics are exported by each slot on which an interface is configured. Use the /junos/system/linecard/interface/ path to provision sensors for physical interface statistics.

      [See Guidelines for gRPC Sensors.]

    Network Management and Monitoring

    • Support for mplsL3VpnIfConfTable object (MX Series, and T Series)— Starting in Junos OS Release 16.1R4, support is provided for the mplsL3VpnIfConfTable object described in RFC 4382, MPLS/BGP Layer 3 Virtual Private Network (VPN) MIB. The mplsL3VpnIfConfTable object represents the Layer 3 VPN enabled interfaces that are associated with a specific Virtual Routing and Forwarding (VRF) instance and shows the bitmask values of the supported protocols. The mplsL3VpnIfConfTable object creates entries for the interfaces that are associated with the VRF instances. If an interface is later removed from a VRF instance, the corresponding entry in the mplsL3VpnIfConfTable object gets deleted. To view details of the mplsL3VpnIfConfTable object, use the show snmp mib walk mplsL3VpnIfConfTable command.

      [See SNMP MIB Explorer.]

    Platform and Infrastructure

    • Virtual broadband network gateway support on virtual MX Series router (vMX)—Starting in Junos OS Release 16.1R4, vMX supports most of the subscriber management features available with Junos OS Release 16.1R4 on MX Series routers to provide a virtual broadband network gateway on x86 servers.

      Because vBNG runs on vMX, it has similar exceptions. The following subscriber management features available on MX Series routers are not supported for vBNG:

      • High availability features such as hot-standby backup for enhanced subscriber management and MX Series Virtual Chassis
      • CoS features such as shaping applied to an agent circuit identifier (ACI) interface set and its members

      To deploy a vBNG instance, you must purchase these licenses:

      • vMX PREMIUM application package license with 1 Gbps, 5 Gbps, 10 Gbps, or 40 Gbps bandwidth
      • vBNG subscriber scale license with 1000, 10 thousand, 100 thousand, or 1 million subscriber sessions for one of these tiers: Introductory, Preferred, or Elite

    Routing Protocols

    • Support for unique AS path count ( MX Series)—Starting with Junos OS Release 16.1R4, you can configure a routing policy to determine the number of unique autonomous systems (ASs) present in the AS path. The unique AS path count helps determine whether a given AS is present in the AS path multiple times, typically as prepended ASs. In earlier Junos releases it was not possible to implement this counting behavior using the as-path regular expression policy. This feature permits the user to configure a policy based on the number of AS hops between the route originator and receiver. This feature ignores ASs in the as-path that are confederation ASs, such as confed_seq and confed_set.

      To configure AS path count, include the as-path-unique-count count (equal | orhigher | orlower) configuration statement at the [edit policy-options policy-statement policy_name from] hierarchy level.

    Services Applications

    • Support for Inline-JFlow multiple collectors on MX Series routers—Starting in Junos OS Release 16.1R4, you can export flow records to four collectors under a family with the same source IP address for Inline-JFlow. The Packet Forwarding Engine (PFE) can export the flow record, flow record template, option data, and option data template packet to all configured collectors. You can configure the multiple collectors at the [edit forwarding-options sampling instance instance name] hierarchy level.

      Note: You cannot change the source IP address for collectors under the same family.

    Subscriber Management and Services

    • Support for parameterized filters for protocol-independent packets (MX Series)—Starting in Junos OS Release 16.1R4, you can use family any for parameterized firewall filters in dynamic service profiles. You can also specify a precedence order for family any filters when they are attached to a dynamic logical interface. Parameterization enables you to create basic or boilerplate filters under a dynamic profile and have specific values for certain attributes provided only when the dynamic session is activated.
    • Reporting of effective shaping rate and session rate limit from LAC to LNS in L2TP (MX Series)—Starting in Junos OS Release 16.1R4, Junos OS reports connect speed updates from the L2TP access concentrator (LAC) to the L2TP network server (LNS) for class -of-service (CoS) effective shaping rates. This includes both AVP 24 (the Tx speed) and AVP 38 (the Rx speed). These speed updates are reported in the L2TP CSUN message.

      A new Tx connect speed method, service-profile, is added to the tx-connect-speed-method configuration statement, replacing the actual Tx connect speed method. The service-profile method is also added to the RADIUS dictionary for the VSA attribute Tunnel-Tx-Speed-Method (26-94). You configure service-profile as the Tx connect speed method with the set tx-connect-speed method service-profile statement at the [edit services l2tp] hierarchy level.

      To provide the Rx connect speed for the new service-profile method, use the set report-ingress-shaping-rate statement at the [edit dynamic-profiles profile-name class-of-service interfaces interface-name unit logical-unit-number] hierarchy level.

      To display the configured Tx connect speed method, use the show services lt2p session extensive command.

    • Reporting of effective shaping rate and session rate limit from LAC to LNS in L2TP (MX Series)—Starting in Junos OS Release 16.1R4, Junos OS reports connect speed updates from the L2TP access concentrator (LAC) to the L2TP network server (LNS) for class -of-service (CoS) effective shaping rates. This includes both AVP 24 (the Tx speed) and AVP 38 (the Rx speed). These speed updates are reported in the L2TP CSUN message.

      A new Tx connect speed method, service-profile, is added to the tx-connect-speed-method configuration statement, replacing the actual Tx connect speed method. The service-profile method is also added to the RADIUS dictionary for the VSA attribute Tunnel-Tx-Speed-Method (26-94). You configure service-profile as the Tx connect speed method with the set tx-connect-speed method service-profile statement at the [edit services l2tp] hierarchy level.

      To provide the Rx connect speed for the new service-profile method, use the set report-ingress-shaping-rate statement at the [edit dynamic-profiles profile-name class-of-service interfaces interface-name unit logical-unit-number] hierarchy level.

      To display the configured Tx connect speed method, use the show services lt2p session extensive command.

    • Support for parameterized filters for protocol-independent packets (MX Series)—Starting in Junos OS Release 16.1R4, you can use family any for parameterized firewall filters in dynamic service profiles. You can also specify a precedence order for family any filters when they are attached to a dynamic logical interface. Parameterization enables you to create basic or boilerplate filters under a dynamic profile and have specific values for certain attributes provided only when the dynamic session is activated.
    • DHCP and DHCPv6 asymmetric lease support (MX Series)—Starting in Junos OS Release 16.1R4, you can configure a shorter lease for DHCP and DHCPv6 that overrides the original lease configuration. The shorter lease is also known as an asymmetric lease. When the client successfully requests a lease extension, the client renews the short lease for the same duration. The short lease continues until the original or long lease offered by DHCP or DHCPv6 expires. The short lease provides a means to force a lease renewal for particular hosts or clients before the original lease expires and a form of liveness detection. When the client is no longer using the lease, the client stops requesting a lease renewal; this is reported to the DHCP server or DHCP relay agent as an expiration of the short lease. In the absence of a short lease, client inactivity can be detected only when the long lease expires. The short lease enables earlier detection and frees up address resources earlier than is possible with the long lease.

      Configure the short lease duration for DHCP or DHCPv6 globally or by group with the following statement at any [edit...(dhcp-local-server | dhcp-relay)...overrides] hierarchy level:

      • asymmetric-lease-time seconds, where seconds is in the range 600 through 86,400

      Configure the short lease duration for DHCPv6 delegated prefix addresses globally or by group with the following statement at any [edit...(dhcp-local-server | dhcp-relay)...overrides] hierarchy level:

      • asymmetric-prefix-lease-time seconds, where seconds is in the range 600 through 86,400
    • Shared memory log supports filter-based debugging (MX Series)—Starting in Junos OS Release 16.1R4, Junos OS supports filter-based debugging using the shared memory log.

      Junos OS uses a shared memory space to store log entries for subscriber service daemons, such as jpppd, jdhcpd, jl2tpd, autoconfd, bbe-smgd, authd, cosd, and dfwd. The shared memory log, or shmlog, output can be displayed using the show shmlog entries logname (logname | all) <filter filter> <flag-name flag> command.

      By default, shared memory logging is enabled. To disable the shmlog, at the [edit system services subscriber-management] hierarchy level, enter the set overrides shmlog disable; configuration statement.

      By default, shmlog filtering is disabled. To enable shmlog filtering, at the [edit system services subscriber-management overrides] hierarchy level, enter the set shmlog filtering enable; configuration statement.

      To display shmlog output for all daemon logs, use the logname all option in the show shmlog entries command. To limit shmlog output to a specific daemon log, provide the daemon name after the logname option followed by an asterisk. For example, logname jpppd* or logname authd*.

      To filter shmlog output, use the filter filter option in the show shmlog entries logname all command. To display a list of valid filters, enter the command show shmlog entries logname all ?.

      Output can also be limited to shmlog entries with specific flags, such as transmit-packets, configuration, and sessionDb, using the flag-name flag option in the show shmlog entries logname all command. To display a list of valid flags, enter the command show shmlog entries logname all flag-name ?.

      To direct shmlog output to a file, at the [edit system services subscriber-management overrides] hierarchy level, enter the set shmlog file <filename>; configuration statement. To view shmlog output stored in a text file, use the command show shmlog entries filename filename.

    • Support for per-subscriber application-aware policy control (MX Series with MS-MPCs)—Starting in Junos OS Release 16.1R4, the MS-MPC supports per-subscriber policy control based on Layer 7 application identification information for the IP flow (for example, YouTube) or Layer 3 and Layer 4 information for the IP flow (for example, the source and destination IP address). Subscriber application-aware policy actions can include:
      • Redirecting HTTP traffic to another URL or IP address
      • Setting the forwarding class
      • Setting the maximum bit rate
      • Setting the gating status to blocked or allowed
      • Setting the allowed burst size
      • Logging and reporting application-aware data sessions

      To configure per-subscriber application-aware policy control or Layer 3 and Layer 4 policy control:

      1. Install the jservices-mss, jservices-jdpi, and jservices-pcef service packages at the [edit chassis fpc slot-number pic pic-number service-package extension-provider package] hierarchy level on any MS-MPC that performs policy control.
      2. Configure policy control with policy and charging control (PCC) rules and policy and charging enforcement function (PCEF) profiles. PCC rules define the Layer 7 or Layer 3 and Layer 4 conditions to match and the actions to take on packets that match. A PCEF profile points to a set of PCC rules to assign to a subscriber. To use Layer 7 matching conditions, you must either install predefined application identification signatures (see Downloading and Installing Predefined Junos OS Application Signature Packages) or configure custom application signatures (see Configuring Custom Application Signatures). To use Layer 3 and Layer 4 matching conditions, configure flow descriptions. Configure PCC action profiles to specify the actions for a PCC rule.

        Configure PCC rules, PCEF profiles, flow descriptions, and PCC action profiles at the [edit services pcef] hierarchy level.

        You can find details about configuring PCC rules and PCEF profiles in the Subscriber-Aware and Application-Aware Traffic Treatment Feature Guide. The guide shows the pcef objects at the [edit unified-edge pcef] hierarchy level, but for subscriber management, configure the pcef objects at the [edit services pcef] hierarchy level. See the following topics:

      3. Configure a service set to identify the service interface that handles application-aware policy control.
        service-set service-set-name {service-set-options {subscriber-awareness;}application-identification-profile appid-profile-name;pcef-profile pcef-profile-name;interface-service {service-interface interface-name;}}

        The application-identification-profile and pcef-profile statements must include names, but these names are dummy variables and are not used.

        The service-interface can be an aggregated multiservices (AMS) interface (see Configuring Aggregated Multiservices Interfaces).

      4. Configure one or more dynamic profiles that specify the PCEF profile and the service set to use.
        1. In the dynamic profile at the [edit dynamic-profile profile-name interfaces interface-name unit logical-unit-number service pcef] hierarchy level, point to the PCEF profile. In the client dynamic profile, you can identify the PCEF profile with the variable $junos-pcef-profile. All of a subscriber’s dynamic profiles that include a PCEF profile must point to the same PCEF profile.
        2. Activate one or more PCC rules in the dynamic profile at the [edit dynamic-profile profile-name interfaces interface-name unit logical-unit-number service pcef profile-name] hierarchy level. Activate a specific rule name with the activate rule-name statement or activate all the rules in the PCEF profile with the activate-all statement. In the client dynamic profile, you can identify a specific rule name with the variable $junos-pcef-rule.

          If you activate PCC rules in multiple dynamic profiles, all of those PCC rules are applied to the subscriber.

        3. In the dynamic profile at the [edit dynamic-profile profile-name interfaces interface-name unit logical-unit-number family family service (input | output) service-set] hierarchy level, point to the service set. In the client dynamic profile, you can identify the service set with a variable ($junos-input-service-set | $junos-output-service-set | $junos-input-ipv6-service-set | $junos-output-ipv6-service-set). You must use the same service set for both the input and output service.
        4. (Optional) In the dynamic profile at the [edit dynamic-profile profile-name interfaces interface-name unit logical-unit-number family family service (input | output) service-set service-set-name service-filter] hierarchy level, point to the service filter. In the client dynamic profile, you can identify the service filter with a variable ($junos-input-service-filter | $junos-output-service-filter | $junos-input-ipv6-service-filter | $junos-output-ipv6-service-filter).

        Table 1 provides a list of the new predefined variables for application-aware policy control in the dynamic profile.

      Table 1: Junos OS PCEF Predefined Variables

      Junos OS Predefined Variable

      RADIUS Attribute

      Description

      $junos-pcef-profile

      204

      PCEF profile name.

      $junos-pcef-rule

      205

      PCC rule name. The RADIUS server can provide multiple PCC rule names for a dynamic profile.

      The following commands have been added or modified to support application-aware policy control:

      • show services pcef subscribers—(New) Displays statistics for subscribers that are using PCEF profiles. You can include any of the options that are available for show subscribers (see show subscribers).
      • show services pcef pic <fpc-slot fpc-slot> <pic-slot pic-slot>—(New) Displays the number of subscribers on each service PIC. The output is zero when a service PIC is down or is coming up after a reboot because the information is taken from the service PIC, and this will not match the show services pcef subscribers count, which is taken from the Routing Engine.
      • show subscribers—(Modified) Displays additional fields that show the service set, service filter, PCEF profile, and PCC rules for the subscriber.

    System Management

      • Support for asynchronous batch commits (MX Series)—Starting in Junos OS Release 16.1R4, batch commit behavior is enhanced to allow asynchronous commits, scheduling of commit jobs, and fair scheduling among jobs with different priorities.

        By default, batch commit behavior is synchronous, meaning that the CLI waits until the commit completes before displaying the command prompt. By default, high-priority commit jobs are always processed before low-priority jobs, blocking the completion of low-priority jobs. This default behavior is not suitable for situations where there is a hard requirement to commit certain configurations in a predefined time period or to see the command-prompt within a predefined time limit, especially in a scaled environment.

        Now you can configure asynchronous batch commits, which allow the CLI to display the command prompt immediately following the commit request when the job is added to the commit queue. Two new CLI commands are introduced to commit the jobs asynchronously: commit asynchronous commits the low-priority jobs asynchronously, and commit priority asynchronous commits the high-priority jobs asynchronously. A new CLI configuration statement commit async/asynchronous is introduced that returns a job-id which can be used for status on these jobs. The CLI returns a job-id that you can use to monitor status with the show commit server queue id commit-id command.

        Use the commit async statement from batch configuration mode [edit batch] to batch an asynchronous job in the commit queue as a low-priority commit job. You can specify a high-priority asynchronous commit job with the commit priority async statement. The commit operation proceeds in the background, depending on priority and scheduling, and the CLI is available for further inputs.

        Best Practice: We recommend that you use the and-quit option for either asynchronous statement.

        There is a schedule attached to low-priority asynchronous commits. The schedule specifies the time duration and maximum load under which the commit server should process the low-priority jobs. If there is no schedule specified, no schedule is used, and the commit will proceed as a normal batch commit.

        You can use the new commit-schedule-profile profile-name statement at the [edit system commit server] hierarchy level to define one or more sets of scheduling parameters that can be attached to low-priority commit jobs. For example, you might configure different schedules for day versus night. An example schedule has the following attributes:

        • start-time hh:mm—Time when the schedule starts.
        • end-time hh:mm—Time when the schedule ends.
        • interruptible—Flag indicating that any commit job in the schedule can be interrupted by a high-priority job. If this attribute is not configured, a high-priority job must wait for an ongoing low-priority job to finish before it can be processed; the high-priority job is then processed ahead of any pending low-priority jobs.
        • load-average average—Preferred load-average before schedule kicks in. This is the maximum system utilization or load average that allows the schedule to start. For example, if you specify a load average of 0.66, the schedule is not applied unless the system utilization is less than or equal to 0.66 (66 percent).

          The commitd daemon determines when to remove from the queue and process a job based on the priority of the job and the schedule configured on the commit server. The schedule is checked every time a batch job is removed from the queue and committed.

          Apart from receiving system log messages, you can also use the redirect-completion-status url statement at the [edit system commit server] hierarchy level to post status for asynchronous commits to the URL configured. The status includes a job ID, job status, and job cookie for the specified URL.

    Release 16.1R3 New and Changed Features

    General Routing

    • Support for OpenConfig—Starting in Junos OS Release 16.1R3, you can configure your MX and PTX Series network devices by using OpenConfig data models. The data models are written in YANG, a data modeling language that can be used to model both configurational data as well as operational data and can be managed on the router by using the CLI or with NETCONF.

      Junos OS Release 16.1R3 supports the following OpenConfig data models:

      • Border Gateway Protocol
      • Routing Policy
      • Local Routing
      • Telemetry
      • Interface
      • MPLS

      [See OpenConfig Feature Guide.]

    High availability and Resiliency

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

      High availability for IPsec on MS-MPCs (MX Series)—Starting in Junos OS Release 16.1R3, 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 (1:1) redundancy 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.

    Layer 2 Features

    • Implicit maximum bandwidth for inline services for L2TP LNS (MX Series)—Starting in Junos OS Release 16.1R3, you are no longer required to explicitly specify a bandwidth for L2TP LNS tunnel traffic using inline services. If you do not specify a bandwidth, the maximum bandwidth supported on the PIC is automatically available for the inline services; inline services can use up to this maximum value. For example:
      user@host# set chassis fpc 3 pic 0 inline-servicesuser@host# set chassis fpc 3 pic 1 inline-services
      user@host> show interfaces si-3/0/0
      Physical interface: si-3/0/0, Enabled, Physical link is Up
        Interface index: 181, SNMP ifIndex: 561
        Type: Adaptive-Services, Link-level type: Adaptive-Services,  
         MTU: 9192, Speed: 100000mbps
        …
      
      user@host> show interfaces si-3/1/0
      Physical interface: si-3/1/0, Enabled, Physical link is Up
        Interface index: 182, SNMP ifIndex: 562
        Type: Adaptive-Services, Link-level type: Adaptive-Services, 
        MTU: 9192, Speed: 100000mbps
        …
      

      In earlier releases, you must specify a bandwidth to enable inline services by including the bandwidth statement with the inline-services statement.

    Management

    • Enhancements to the Junos Telemetry Interface (MX Series)—The Junos Telemetry Interface enables you to export telemetry data from supported interface hardware. Line-card sensor data, such as interface events, are sent directly to configured collection points without requiring polling.

      Starting with Junos OS Release 16.1R3, telemetry sensors for the following system resources are now also supported:

      • CPU memory
      • BGP peers (gRPC streaming only)
      • Memory utilization for routing protocol tasks (gRPC streaming only)
      • Network processing unit (NPU) memory and memory utilization
      • Optical interfaces
      • Inline flow sampling process (UDP streaming only)
      • Chassis components
      • Aggregated Ethernet interfaces configured with LACP (gRPC streaming only)
      • ARP (gRPC streaming only)
      • Ethernet interfaces configured with LLDP (gRPC streaming only)
      • RSVP interface events (gRPC streaming only)
      • Network Discovery Protocol table state (gRPC streaming only)
      • Routing Engine internal interfaces (gRPC streaming only)

      [See Junos Telemetry Interface Feature Guide.]

    • Support for adding nonnative YANG RPCs to the Junos OS schema (MX Series and T Series)—Starting with Junos OS Release 16.1R3, you can load custom YANG RPCs on devices running Junos OS. Creating custom RPCs enables you to precisely define the input parameters and operations and the output fields and formatting for your specific operational tasks on those devices. The ability to add custom RPCs to a device is also beneficial when you want to create RPCs that are device-agnostic and vendor-neutral. You can load YANG modules that add custom RPCs by using the request system yang add operational command.
    • gRPC support for the Junos Telemetry Interface (MX Series)—Starting with Junos OS Release 16.1R3, you can use a set of gRPC remote procedure call (gRPC) interfaces to provision sensors and to subscribe to and receive telemetry data. gRPC is based on an open source framework and provides for interoperability as well as the secure and reliable transport of data. Use the telemetrySubscribe RPC to specify telemetry parameters and stream data for a specified list of OpenConfig command paths. Telemetry data is generated as Google protocol buffers (gpb) messages in a universal key/value format. If your Juniper Networks device is running a version of Junos OS with the upgraded FreeBSD kernel, you must download the Network Agent package, which provides the interfaces to manage gRPC subscriptions. The package is available on the All Junos Platforms software download URL on the Juniper Networks webpage. On MX Series routers, supported hardware for gRPC telemetry data streaming is MPC1 through MPC9E. On PTX Series routers, supported hardware is FPC1, FPC2, and FPC3.

      [See Junos Telemetry Interface Feature Guide.]

    • Junos SDK is end of life (EOL)—Starting in Junos OS Release 16.1, the Juniper Extension Toolkit (JET) provides a rich set of APIs to program the Junos control plane. JET allows users to build applications on top of Junos OS and, hence, replaces the legacy Junos SDK. With the support of JET APIs in Junos OS Release 16.1R1, Junos SDK is now EOL. Junos SDK will be supported as long as the equivalent Junos OS Release is supported. So, a customer running Junos OS Release 14.2 can still download and use Junos SDK until Junos OS Release 14.2 is end of support (EOS).

      [For JET, see Juniper Extension Toolkit (JET). For, Junos SDK downloads, see https://www.juniper.net/support/csc/swdist-junos-sdk/.]

    MPLS

    • Enhancements to MPLS RSVP-TE LSP (T 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.1R2 and later releases.

      These enhancements make the RSVP-TE configuration easier by:

      • Ensuring 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 64000 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.

    Services Applications

    • IPsec multipath forwarding with UDP encapsulation (MX Series routers with MS-MPCs and MS-MICs)—Starting in Junos OS Release 16.1R3, 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.]

    Subscriber Management and Services

    • Enhanced DHCP dual-stack support (MX Series)—Starting in Junos OS Release 16.1R3, subscriber management supports a single-session DHCP dual-stack model that provides a more efficient configuration and management of dual-stack subscribers.

      The single-session dual-stack model addresses session-related inefficiencies that exist in the traditional dual-stack—for example, the new model requires single sessions for authentication and accounting, as opposed to multiple sessions that are often needed in a traditional dual-stack configuration. The single-session dual-stack model also simplifies router configuration, reduces RADIUS message load, and improves accounting session performance for subscriber households with dual-stack environments.

      See Single-Session DHCP Dual-Stack Overview.

    • Flat-file accounting (MX Series)—Starting in Junos OS Release 16.1R3, you can collect accounting statistics from the Packet Forwarding Engine to be reported in an XML flat file. Flat file accounting is typically used to record accounting statistics on logical interfaces for Extensible Subscriber Services Manager (ESSM) business subscribers. You can also use flat-file accounting to collect and archive accounting statistics for wholesaler and retailer subscriber activity in a Layer 2 wholesale environment by applying it to a core-facing physical interface. You can configure multiple accounting profiles with different combinations of fields for specific accounting requirements, and then assign the profiles as needed to provisioned interfaces to satisfy the accounting requirements for each interface depending on how it is used.

      Best Practice: We recommend that you use separate flat-file profiles for Layer 2 wholesale core-facing physical interfaces and ESSM business subscriber logical interfaces.

      You can create an accounting profile template to define the flat-file attributes, such as the statistics fields to collect, the name and format of the file, the frequency at which the Packet Forwarding Engine is polled for statistics, and the schema version.

      The file typically uses the IP Detail Record (IPDR) format; in this case, a file header includes information, such as the name of the host where the statistics are collected, a timestamp, a file identification number, and the name of the schema. The schema is associated with a specific XML format and output based on the flat-file configuration and defines the information conveyed in the file. The schema enables an external file processor to correctly interpret the file contents.

      [See Flat File Accounting Overview.]

    • Flat-file accounting options (MX Series)—Starting in Junos OS Release 16.1R3, you can configure accounting options for flat files, which are typically used to record accounting statistics on logical interfaces for Extensible Subscriber Services Manager (ESSM) business subscribers.

      Flat file accounting options include the size, number of files saved before overwriting, how long backed-up files are saved, archive sites, frequency, the location where files are saved in the event of a Routing Engine switchover, and more. You can configure the router to save a backup copy of the accounting files to the /var/log/pfedBackup directory.

      The accounting files are transferred at regular intervals; configuring multiple archive sites increases the likelihood of a successful transfer. If a transfer fails, all remaining sites are tried in order until the transfer is successful or all sites have failed. If backup-on-failure is configured, an attempt is made at the next scheduled interval to transfer any backed-up files from /var/log/pfedBackup.

      If you do not configure backup-on-failure, the file is saved on failure into the local directory that is specified as the last site in the list of archive sites. No further attempts are made to transfer the file. You must configure an event script or some other means to transfer files from the local directory to a remote site.

      [See Flat File Accounting Overview.]

    • Monitoring only ingress traffic for subscriber idle timeouts (MX Series)—Starting in Junos OS Release 16.1R3, you can specify that only ingress data traffic is monitored for subscriber idle timeout processing. If you Include the client-idle-timeout-ingress-only statement in addition to the client-idle-timeout statement at the [edit access-profile profile-name session-options] hierarchy level, subscribers are logged out or disconnected when no ingress traffic is received for the duration of the idle timeout period. Egress traffic is not monitored. If you do not include the client-idle-timeout-ingress-only statement, both ingress and egress data traffic are monitored during the timeout period to determine whether subscribers are logged out or disconnected.

      This configuration is useful in cases where the LNS sends traffic to the remote peer even when the peer is not up, such as when the LNS does not have PPP keepalives enabled and therefore is not aware that the peer is not up. In this situation, because by default the LAC monitors both ingress and egress traffic, it detects the egress traffic from the LNS and either does not log out the subscriber or delays detection of inactivity until the egress traffic ceases. When you specify that only ingress traffic be monitored, the LAC can detect that the peer is inactive and then initiate logout.

    • Support for maximum session limits on L2TP service interfaces (MX Series)—Starting in Junos OS Release 16.1R3, you can include the l2tp-maximum-session number statement at the [edit interfaces service-interface] hierarchy level to specify the maximum number of sessions that are allowed on an individual service interface (si) or aggregated service interface (asi). New session requests on an interface are accepted only when the session count is less than the maximum session limit. If the limit has been reached, subsequent requests are dropped and the LNS responds with a CDN message (Result Code 2, Error Code 4). If a pool of interfaces is configured, interfaces at the maximum limit are ignored in favor of an interface in the pool that has a lower session count. For an asi interface, the configuration applies to all member interfaces; you cannot configure the limit for individual member interfaces.
    • Enhanced load balancing on L2TP physical service interfaces (MX Series)—Starting in Junos OS Release 16.1R3, when a service interface in a service device pool is rebooted, sessions reconnect and new session requests are distributed based on the number of sessions on the available interfaces in the pool. The sessions are assigned to the interface with the fewest sessions. If more than one interface has the minimum number of sessions, then a random selection determines which interface gets the session.

      In earlier releases, session load balancing is a simple round-robin distribution among the interfaces. Consequently, fewer sessions are assigned to a newly rebooted interface than to the other interfaces. For example, consider a pool with two si interfaces, si-0/0/0 and si-1/0/0. Each has 100 sessions. If si-1/0/0 reboots, it drops all 100 sessions. As the sessions reconnect, they alternate between the two interfaces so that when all sessions have reconnected, si-0/0/0 has 150 sessions and the reconnected si-1/0/0 interface has only 50 sessions.

      Consider the same pool with the new behavior. As sessions reconnect, si-1/0/0 has fewer sessions (0 to start) than si-0/0/0 (100). Because the interface with the fewest sessions is selected, all sessions are assigned to si-1/0/0 until it reaches the same count as si-0/0/0.

      For asi interfaces, the interface with the lowest session count is selected from the pool for new or reconnect session requests. When the active si interface in the asi bundle goes down, all the active sessions on that primary interface fail over to the secondary interface.

    • DHCPv6 subscriber identification criteria and automatic logout(MX Series)—Starting in Junos OS Release 16.1R3, the DHCPv6 local server and the DHCPv6 relay agent can identify a DHCPv6 client by using the incoming-interface option in addition to the client identifier. The incoming interface allows only one client device to connect on the interface. If the client device changes—that is, if DHCPv6 receives a solicit message from a client whose incoming interface matches the existing interface—DHCPv6 automatically logs out the existing client without waiting for the normal lease expiration. It deletes the existing client binding and creates a binding for the newly connected device.

      See DHCPv6 Match Criteria for Identifying DHCPv6 Subscribers.

    • Changes to show ancp subscriber and clear ancp subscriber commands (MX Series)—Starting in Junos OS Release 16.1R3, multiple simultaneous filtering options are no longer allowed for the show ancp neighbor, show ancp subscriber, and clear ancp subscriber commands. In earlier releases, you can issue commands with both the identifier and neighbor options or both the ip-address and system-name options on the same line. Now you can enter only one of these options at a time.

      To improve consistency, the neighbor option has been replaced with ip-address for the show ancp subscriber command, to match the show ancp neighbor, clear ancp neighbor, and clear ancp subscriber commands. For example, to display information about subscribers connected to a specific access node identified by its address, use the show ancp subscriber ip-address ip-address command; in earlier releases, you use the show ancp subscriber neighbor ip-address command.

      The system-name mac-address option is now available for the show ancp subscriber and clear ancp subscriber commands.

    Release 16.1R2 New and Changed Features

    High Availability and Resiliency

    • Support for unified ISSU on MX Series routers with MPC3E-3D-NG, MPC3E-3D-NG-Q, MPC2E-3D-NG, and MPC2E-3D-NG-Q (MX240, MX480, MX960, MX2010, and MX2020)—Starting with Release 16.1R2, Junos OS supports unified in-service software upgrade (ISSU) on MX Series routers with MPC3E-3D-NG, MPC3E-3D-NG-Q, MPC2E-3D-NG, and MPC2E-3D-NG-Q.

      Unified ISSU enables you to upgrade between two different Junos OS releases with no disruption on the control plane and with minimal disruption of traffic.

      Note: Unified ISSU is not supported on MPC3E-3D-NG, MPC3E-3D-NG-Q, MPC2E-3D-NG, and MPC2E-3D-NG-Q with the following MICs:

      • MS-MIC-16G
      • MIC-3D-8DS3-E3
      • MIC-3D-1OC192-XFP

    IPv6

    • Forced IPv6 DNS server address insertion (MX Series)—Starting in Junos OS Release 16.1R2, MX Series devices can dynamically provision IPv6 DNS Server addresses for DHCPv6 clients. The IPv6 DNS Server addresses are provided in DHCPv6 Advertise and Reply messages, even if the Solicit message or Request message from the client does not request the IPv6 DNS Server address.

    Management

    • Support for Junos Telemetry Interface (MX Series)—Junos Telemetry Interface enables you to export telemetry data from supported interface hardware. Line card sensor data is sent directly to configured collection points without involving polling. Starting with Junos OS Release 16.1R2, you can export logical interface statistics and firewall filter statistics in addition to physical interface statistics. Junos Telemetry Interface is supported only on MPC1 through MPC9E. All parameters are configured at the [edit services analytics] hierarchy level.

    MPLS

    • Support for LDP signaling over native IPv6 (T Series)— IPv6 connectivity often relies on tunneling IPv6 over an IPv4 MPLS core with IPv4-signaled MPLS label-switched paths (LSPs). To enable such tunneling, you need to configure the IPv4-signaled LSPs statically or have them configured dynamically by provider edge routers. To overcome these challenges, and to meet the growing demand of IPv6, Junos OS supports LDP signaling for native IPv6.

      Starting in Junos OS Release 16.1R2, LDP is supported in:

      • IPv6 network only
      • IPv6 or IPv4 dual-stack network

      [ See Configuring LDP Native IPv6 Support and Example: Configuring LDP Native IPv6 Support.]

    Operation Administration and Management

    • Support for sender ID TLV—Starting with Junos OS Release 16.1R2, you can configure Junos OS to send the sender ID TLV along with the packets. The sender ID TLV is an optional TLV that is sent in continuity check messages (CCMs), loopback messages, and Link Trace Messages (LTMs), as specified in the IEEE 802.1ag standard. The sender ID TLV contains the chassis ID, which is the unique, CFM-based MAC address of the device, and the management IP address, which is an IPv4 or an IPv6 address.

      You can enable Junos OS to send the sender ID TLV at the global level by using the set protocols oam ethernet connectivity-fault-management sendid-tlv and the set protocols oam ethernet connectivity-fault-management sendid-tlv send-chassis-tlv commands. If the sender ID TLV is configured at the global level, then the default maintenance domain, maintenance association, and the maintenance association intermediate point (MIP) half function inherit this configuration.

      You can also configure the sender ID TLV at the following hierarchy levels:

      • Maintenance domain—At the [edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domain-name mip-half-function default] hierarchy level. Configuration performed at this level applies to all the maintenance associations under the maintenance domain.
      • Default maintenance domain and the MIP half function—At the [edit protocols oam ethernet connectivity-fault-management maintenance-domain default-maintenance-domain-name mip-half-function default] hierarchy level.
      • Maintenance association—At the [edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domain-name maintenance-association maintenance-association-name continuity-check] hierarchy level.

      The sender ID TLV, if configured at the hierarchy levels mentioned above, takes precedence over the global-level configuration.

      Note: Sender ID TLV is supported only for 802.1ag PDUs and is not supported for performance monitoring protocol data units (PDUs).

    Platform and Infrastructure

    • Virtual MX Series router (vMX)—Starting in Junos OS Release 16.1, you can deploy vMX routers on x86 servers. FreeBSD 10 is the underlying OS for Junos OS for vMX.

      vMX supports most of the features available on MX Series routers and allows you to leverage Junos OS to provide a quick and flexible deployment. vMX provides the following benefits:

      • Optimizes carrier-grade routing for the x86 environment
      • Simplifies operations by consistency with MX Series routers
      • Introduces new services without reconfiguration of current infrastructure

    Routing Protocols

    • Selective advertising of BGP multiple paths—Beginning with Junos OS Release 16.1R2, you can restrict BGP add-path to advertise contributor multiple paths only. Advertising all available multiple paths might result in a large overhead of processing on device memory and is a scaling consideration, too. You can limit and configure up to six prefixes that the BGP multipath algorithm selects. Selective advertising of multiple paths facilitates Internet service providers and data centers that use route reflector to build in-path diversity in IBGP.
    • Support for IS-IS Flooding Groups (PTX Series)—Starting with Junos OS Release 15.1F5 and 16.1R2, you can configure flooding groups with IS-IS. This feature is to limit the Link State PDU (LSP) flooding over IS-IS interfaces.

      A non self-originated LSP will be flooded only through the interface belonging to the flood group that has the configured area ID in the LSP. It helps to minimize the routes and topology information, thus ensuring optimal convergence. You can segregate both level 1 and level 2 networks into flood groups by using area IDs as tags to identify a flood group. Configure interfaces with specific area IDs to modify the flooding behavior as per your requirements.

      To enable IS-IS flooding group include the flood-group flood-group-area-ID statement at the [edit protocols isis interface] hierarchy level.

    • BGP advertises multiple add-paths based on community value—Beginning with Junos OS 16.1R2, you can define a policy to identify eligible multiple path prefixes based on community values. BGP advertises these community-tagged routes in addition to the active path to a given destination. If the community value of a route does not match the community value defined in the policy, then BGP does not advertise that route. This feature allows BGP to limit the number of multiple paths that are processed and not advertise more than 20 paths to a given destination. You can limit and configure the number of prefixes that BGP considers for multiple paths without actually knowing the prefixes in advance. Instead, a known BGP community value determines whether or not a prefix is advertised.

    Security

    • Global configuration for flow detection and tracking (MX Series)—Starting in Junos OS Release 16.1R2, you can configure the mode of operation for flow detection and tracking globally for all protocol groups and packet types. In earlier releases, although you enable flow detection and tracking globally, you can configure the behavior only at the individual flow aggregation levels: physical interface, logical interface, or subscriber; you cannot configure the behavior globally. The new the global configuration applies to all packet types in the traffic flow unless it is overridden by the configuration for a protocol group or packet type at the flow aggregation levels.

      To configure the global behavior for flow detection, include the flow-detection-mode statement at the [edit system ddos-protection global] hierarchy level and specify one of the following modes:

      • automatic—Detect flows only when the policer is being violated. This is the default mode.
      • on—Monitor and detect all flows even when no policer is being violated.
      • off—Disable flow detection.

      To configure the global behavior for how traffic in the detected flow is controlled, include the flow-level-control statement at the [edit system ddos-protection global] hierarchy level and specify one of the following control behaviors:

      • drop—Drop all traffic in the flow. This is the default behavior.
      • keep—Keep all traffic in the flow.
      • police—Police the traffic in the flow to within its allowed bandwidth.

      Use the show ddos-protection statistics command to display the current global configuration.

    Services Applications

    • Network attack protection for MS-MPCs (MX Series)—Starting in Junos OS Release 16.1R2, the MS-MPC can detect and prevent network probing attacks, network flooding attacks, suspicious packet pattern attacks, and header anomaly attacks. The configuration of IDS rules for MS-MPCs differs from the configuration of IDS rules for MS-DPCs.

      Network probing attacks and network flooding attacks—Use the following hierarchy to configure an intrusion detection service (IDS) rule and assign the IDS rule to a service set to protect against network probing attacks and network flooding attacks. The IDS rule has no from statement, and we recommend that you also configure a stateful firewall rule to limit the packets that the IDS rule processes. Only the first IDS input rule and the first IDS output rule for a service set are used, and only the first term of an IDS rule is used. If you configure an IDS rule to protect against suspicious packet pattern attacks (see Suspicious packet pattern attacks) in addition to network attacks, all configuration must be in the first term of the same rule.

      [edit services ids]
      rule rule-name {match-direction (input | input-output |output);term term-name {then {aggregation {destination-prefix prefix-value;destination-prefix-ipv6 prefix-value;source-prefix prefix-value;source-prefix-ipv6 prefix-value;}session-limit {by-destination {maximum number;packets number;rate number;by-protocol {tcp {maximum number;packets number;rate number;}udp {maximum number;packets number;rate number;}icmp {maximum number;packets number;rate number;}}}by-source {maximum number;packets number;rate number;by-protocol {tcp {maximum number;packets number;rate number;}udp {maximum number;packets number;rate number;}icmp {maximum number;packets number;rate number;}}}}}}}
      [edit services]
      service-set service-set-name {ids-rules rule-name;}

      You can configure the following IDS rule options for protecting against network probing attacks and network flooding attacks:

      • match-direction (input | input-output |output)—Specify whether the IDS rule is applied to input traffic, output traffic, or both.
      • aggregation—Specify a prefix length for source or destination packets for IPv4 or IPv6. This applies session limits to an aggregation of all attacks from within a subnet of the specified length. For example, if you configure a value of 24 for source-prefix, then attacks from 10.1.1.2 and 10.1.1.3 are counted as attacks from the 10.1.1/24 subnet. However, if a single host on a subnet generates a large number of network probing or flooding attacks, the flows for the entire subnet might be stopped. For IPv4, use a value from 1 through 32; for IPv6, use a value from 1 through 128.
      • maximum number—Specify the maximum number of concurrent sessions allowed for a destination or source address or subnet. You can configure this value for specific protocols for the destination or source or for the destination or source independent of a protocol.
      • packets number—Specify the maximum packets per second allowed for a destination or source address or subnet. You can configure this value for specific protocols for the destination or source or for the destination or source independent of a protocol. For TCP sessions, we recommend that you do not configure packets, or configure a very high value.
      • rate number—Specify the maximum number of connections per second allowed for a specific destination or source address or subnet. You can configure this value for specific protocols for the destination or source or for the destination or source independent of a protocol.

      Configure the maximum number, packets number, or rate number at the following hierarchies:

      • Configure the value for the destination, independent of the protocol, at the [edit services ids rule rule-name term term-name then session-limit by-destination] hierarchy level. This value overrides the value for a specific protocol.
      • Configure the value for the destination and for a specific protocol at the [edit services ids rule rule-name term term-name then session-limit by-destination by-protocol (tcp | udp | icmp)] hierarchy level.
      • Configure the value for the source, independent of the protocol, at the [edit services ids rule rule-name term term-name then session-limit by-source] hierarchy level. This value overrides the value for a specific protocol.
      • Configure the value for the source and for a specific protocol at the [edit services ids rule rule-name term term-name then session-limit by-source by-protocol (tcp | udp | icmp)] hierarchy level.

      If the service set is associated with an AMS interface, the limits you configure are applicable to each member interface.

      Suspicious packet pattern attacks—Use the following hierarchy to configure an IDS rule to protect against suspicious packet pattern attacks. The IDS rule has no from statement, and we recommend that you also configure a stateful firewall rule to limit the packets that the IDS rule processes. Only the first IDS input rule and the first IDS output rule for a service set are used, and only the first term of an IDS rule is used. If you configure an IDS rule to protect against network probing attacks and network flooding attacks (see Network probing attacks and network flooding attacks) in addition to suspicious pattern attacks, all configuration must be in the first term of the same rule.

      [edit services ids]
      rule rule-name {match-direction (input | input-output |output);term term-name {then {allow-ip-options {any;loose-source-route;route-record;route-alert;security;stream-id;strict-source-route;timestamp;}allow-ipv6-extension-header {any;ah;dstopts;esp;fragment;hop-by-hop;mobility;routing;}tcp-syn-defense;tcp-syn-fragment-check;tcp-winnuke-check; icmp-fragment-check; icmp-large-packet-check; land-attack-check {ip-only ;ip-port;}}}}

      You can configure the following IDS rule options for protecting against suspicious packet pattern attacks:

      • match-direction (input | input-output |output)—Specify whether the IDS rule is applied to input traffic, output traffic, or both.
      • allow-ip-options—Specify the type of IPv4 options that the packet can include. If the packet includes an option that is not configured, the packet is blocked. If the packet includes a configured option whose length is an illegal value, the packet is dropped. Specifying any allows all options.
      • allow-ipv6-extension-header—Specify the type of IPv6 extension headers that the packet can include. If the packet includes an extension header that is not configured, the packet is blocked. If the packet includes a configured extension header whose length is an illegal value, the packet is dropped. Specifying any allows all extension headers.
      • tcp-syn-defense—Use to close unestablished TCP connections when the open-timeout value at the [edit interfaces interface-name service-options] hierarchy level expires.
      • tcp-syn-fragment-check—Use to identify and drop TCP SYN packets that are IP fragments.
      • tcp-winnuke-check—Use to identify and drop TCP segments that are destined for port 139 and have the urgent (URG) flag set.
      • icmp-fragment-check—Use to identify and drop ICMP packets that are IP fragments.
      • icmp-large-packet-check—Use to identify and drop ICMP packets that are larger than 1024.
      • land-attack-check—Use to identify and drop SYN packets that have the same source and destination address or port.

      Header anomaly attacks—To protect against header anomaly attacks, use either of the following methods:

      • Configure a stateful firewall rule, a NAT rule, or an IDS rule and apply it to the service set. A header integrity check is automatically enabled.
      • If you do not apply a stateful firewall rule, NAT rule, or IDS rule to a service set, use the following hierarchy to configure a header integrity check:
        [edit services]
        service-set service-set-name {service-set-options {header-integrity-check {enable-all;}}}

      Header integrity checks now include;

      • ICMP ping of death
      • IP unknown protocol
      • TCP no flag
      • TCP SYN FIN
      • TCP FIN no ACK

      If you want to skip IDS rule processing for some traffic, configure a stateful-firewall rule that matches the traffic, and configure skip-ids at the [edit services stateful-firewall rule rule-name term term-name then accept] hierarchy level.

      If the service set is associated with an AMS interface, and a NAT rule and an IDS rule are assigned to the service set, we recommend that you configure source-ip at the [edit interfaces interface-name load-balancing-options hash-keys ingress-key] hierarchy level.

      You can enable logging of IDS events at the [edit services service-set service-set-name syslog host hostname] hierarchy level. To log header-integrity and suspicious packet pattern packet drops, configure packet-logs. To log limit-based packet drops, configure ids-logs.

      The show services service-set statistics ids drops <interface interface-name> <service-set service-set-name> <terse> command displays counters for IDS violations on service sets. The interface interface-name option lists the counters for the service sets hosted on the specified service interface. The service-set service-set-name option lists counters for the specified service set. The terse option displays only the nonzero values.

    • Service redundancy daemon support for redundancy across multiple gateways (MX Series with MPC)—Starting in Junos OS Release 16.1R2, you can configure redundancy across multiple service gateways. The redundancy actions are based on the results of monitoring system events, including:
      • Interface and link down events
      • FPC and PIC reboots
      • Routing protocol daemon (rpd) aborts and restarts
      • Peer gateway events, including requests to acquire or release mastership, or to broadcast warnings

      [See Service Redundancy Daemon Overview.]

    • Traffic Load Balancer (MX Series with MS-MPCs or MS-MICs)—Starting in Junos OS Release 16.1R2, traffic load balancing is supported on MS-MPCs and on MS-MICs. The Traffic Load Balancer (TLB) application distributes traffic among multiple servers in a server group, and performs health checks to determine whether any servers should not receive traffic. TLB supports multiple VRFs.

      [See Traffic Load Balancer Overview.]

    • Support for IKE and IPsec on NAPT-44 and NAT64 (MX Series with MS-MPCs and MS-MICs)—Starting in Junos OS Release 16.1R2, you can enable the passing of IKE and IPsec packets through NAPT-44 and NAT64 filters between IPsec peers that are not NAT-T compliant by using the IKE-ESP-TUNNEL-MODE-NAT-ALG application-level gateway (ALG) on MS-MPCs and MS-MICs.

      Use the following hierarchy to enable IKE-ESP-TUNNEL-MODE-NAT-ALG:

      [edit applications]
      application ike-esp-application-name {application-protocol ike-esp-nat;protocol udp;destination-port 500;inactivity-timeout 3600;}
      application-set ike-esp-application-set-name {application ike-esp-application-name;}
      [edit services nat]
      pool ike-isp-nat-pool-name {address ip-prefix;port automatic;}
      rule rule-name {match-direction input;term 0 {from {source-address address;application-sets ike-esp-application-set-name;}then {translated {source-pool ike-isp-nat-pool-name;translation-type napt-44;}}}}
    • Class-of-service (CoS) marking and reclassification for MS-MICs and MS-MPCs—Starting with Junos Release OS 16.1R2, MS-MICs and MS-MPCs support CoS configuration, which enables you to configure Differentiated Services code point (DSCP) marking and forwarding-class assignment for packets transiting the MS-MIC or MS-MPC. You can configure the CoS service alongside the stateful firewall and NAT services, using a similar rule structure.

      [See Configuring CoS Rules.]

    • New options to stop creating sessions for TCP non-SYN packets(MX Series with MS-MPC or MS-DPC)—On routers with MS-MPC and MS-DPC and with stateful firewall configured, a session is created when a packet hits the services set and matches the stateful firewall rule even if the packet is a non-SYN packet. However, in certain scenarios, a session must not be created if the first packet is a non-SYN packet even if it matches the stateful firewall rule.

      To ensure that a session is not created, include either the tcp-non-syn drop-flow or the tcp-non-syn drop-flow-send-rst statement at the [edit services service-set service-set-name service-set-options] hierarchy level. If either of the two options is configured, and if the first packet is a TCP non-SYN packet, the packet is dropped and a drop flow is created. If the tcp-non-syn drop-flow-send-rst statement is configured, in addition to the creation of a drop flow, the originator of the non-SYN packet receives a reset frame.

    • CLI command parity for carrier-grade NAT and stateful firewall (MX Series with MS-MPC)—Starting in Junos OS Release 16.1R2, new operational commands and configuration options provide information previously available only when using the MS-DPC as the services PIC.
      • To display information equivalent to that provided by show services stateful-firewall flow-analysis for the MS-DPC, use show services sessions analysis for the MS-MPC.
      • To display information equivalent to that provided by show services stateful-firewall subscriber-analysis for the MS-DPC, use show services subscriber analysis for the MS-MPC.
      • To drop sessions after a certain session setup rate is reached, include the new CLI option max-session-creation-rate at the [edit services service-set service-set-name] hierarchy level.
    • Enhancements to stateful synchronization (MS-MIC, MS-MPC)—Starting in Junos OS Release 16.1R2, stateful synchronization for long-running flows is available for MS-MPC services PICs. 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 configure the timeout for checkpointing, include the replication-threshold seconds statement at the [edit interfaces interface-name redundancy-options] hierarchy level.

      [See Configuring Inter-Chassis Stateful Synchronization for Long Lived Flows (MS-MPC, MS-MIC).]

    Subscriber Management and Services

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

    • Support for username stripping per routing instance (MX Series)—Starting in Junos OS Release 16.1R2, you can configure a subscriber access profile so that a portion of each subscriber login string is discarded and the remaining characters are used as a modified username by an external AAA server for session authentication and accounting. The modified username appears in RADIUS Access-Request, Acct-Start, and Acct-Stop messages; RADIUS-initiated disconnect requests; and change of authorization (CoA) requests. This username stripping configuration replaces a domain map configuration, but can be overridden by a AAA server.

      Use the following statements at the [edit access profile profile-name session-options strip-user-name] hierarchy level to configure username stripping:

      • delimiter delimiter—Specify up to eight characters that the router uses to determine the boundary between the new modified username and the part of the original username that is discarded. There is no default delimiter.
      • parse-direction (left-to-right | right-to-left)—Specify the direction in which the login string is examined until one of the configured delimiters is identified; left-to-right is the default. The delimiter and all characters to the right of the delimiter are discarded.

      For example, consider a login string of drgt21@example.com$84 with the delimiters configured to be /@$%#. If the parse direction is left-to-right, the @ delimiter is reached first and the modified username is drgt21. If the parse direction is right-to-left, then the $ delimiter is reached first and the modified username is drgt21@example.com.

      Best Practice: We recommend that you do not configure username stripping either when multiple user authentications are needed or when a global domain map is configured for the same subscribers covered by the AAA options configuration.

      The show network-access aaa subscribers session-id id-number detail command displays the modified username in the Session Authentication Username field. The clear network-access aaa subscriber username username command requires you to specify the original, unstripped username (login string). The output of the show subscribers command displays the unstripped username, and when you issue the show subscribers user-name username command, you must specify the unstripped username.

    • AAA option sets to authorize and configure subscribers per routing instance to support username stripping (MX Series)—Starting in Junos OS Release 16.1R2, you can include one or more of the following statements at the new [edit access aaa-options aaa-options-name] hierarchy level to define a set of AAA options for a subscriber or set of subscribers that username stripping is applied to:
      • access-profile profile-name—Specify the name of the access profile that includes the username stripping configuration.
      • aaa-context aaa-context-name—Specify the logical-system:routing-instance that the subscriber session uses for AAA (RADIUS) interactions like authenticating and accounting.
      • subscriber-context subscriber-context-name—Specify the logical-system:routing-instance in which the subscriber interface is placed.

      Note: Only the default (master) logical system is supported.

      Use the aaa-options aaa-options-name statement at the [edit dynamic-profiles profile-name interfaces pp0 unit $junos-interface-unit ppp-options] hierarchy level to apply the attributes to PPP subscribers tunneled from the LAC to the LNS inline service interface.

      Alternatively, use the aaa-options aaa-options-name statement at the [edit access group-profile profile-name ppp-options] hierarchy level to apply the attributes to PPP subscribers tunneled from LACs that are members of the user group.

      Usernames are examined and modified according to the subscriber and AAA contexts specified in the option set. In the event of a conflict between option sets configured in both a group profile and a dynamic profile, the dynamic profile takes precedence.

    Release 16.1R1 New and Changed Features

    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 MPC variants that support higher scale and bandwidth (MX Series)—Starting with Junos OS Release 16.1, MPC7E (Multi-Rate), MPC7E 10G, MPC8E, and MPC9E are supported on MX Series routers. Table 2 lists the platforms that support these MPCs.

      Table 2: Supported Platforms

      MPC

      Supported Platforms

      MPC7E (Multi-Rate)

      MX240, MX480, MX960, MX2010, and MX2020

      MPC7E 10G

      MX240, MX480, MX960, MX2010, and MX2020

      MPC8E

      MX2010 and MX2020

      MPC9E

      MX2010 and MX2020

      See MIC/MPC Compatibility for supported MICs on these MPCs.

      Note: MPC7E(Multi-Rate) MPC is also supported in Junos OS Release 15.1F4. MPC7E 10G, MPC8E, and MPC9E MPCs are also supported in Junos OS Release 15.1F5. To use these MPCs in these releases, you must install Junos Continuity software. See Junos Continuity Software for more details.

    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.

    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.]

    EVPNs

    • 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.]

    • Distribution of VXLAN VNIDs using EVPN (MX Series)—Starting in Release 16.2, Junos OS enables Ethernet VPN (EVPN) with Virtual Extensible LAN (VXLAN) encapsulation to provide Layer 2 connectivity for endpoints within a virtual network that Contrail virtualization software creates. Endpoints in this scheme include virtual machines (VMs) connected to a virtual server, and non-virtual bare-metal servers (BMSs) connected to a top-of-rack (ToR) platform. An MX Series router performs as a default gateway for non-virtual BMSs for the traffic among the endpoints that belong to different virtual networks.

      The virtual network uses two types of encapsulation:

      An MX Series router supports all-active L3 gateways for redundancy and load balancing to ensure failure protection for the default gateway.

    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.

    • Support for virtualization on RE-S-X6-64G (MX240, MX480, MX960, MX2010, and MX2020)—The Routing Engine RE-S-X6-64G supports virtualization for the following platforms:

      • MX240, MX480, and MX960—Junos OS Release 15.1F3, 16.1R1, and later
      • MX2010 and MX2020—Junos OS Release 15.1F5, 16.1R2, and later

      Virtualization enables the router to support multiple instances of Junos OS and other operating systems on the same Routing Engine. However, for Junos OS Release 15.1F3, one instance of Junos OS, which runs as a guest operating system, is launched by default. The user needs to log in to this instance for operations and management. For more information see, RE-MX-X6, RE-MX-X8, RE-PTX-X8 and RCBPTX with VM Host Support .

      With virtualization of the Routing Engine, Junos OS supports new request and show commands associated with host and hypervisor processes. The commands are related to:

      • Reboot, halt, and power management for the host
      • Software upgrade for the host
      • Disk snapshot for the host

    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:

      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.

    • 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:

      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.
    • 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 for higher MTU size on MX Series MPCs—Starting in Junos OS Release 16.1R1, the maximum transmission unit (MTU) size for a media or protocol is increased from 9192 to 9500 for Ethernet interfaces on the following MX Series MPCs:

      • MPC1
      • MPC2
      • MPC2E
      • MPC3E
      • MPC4E
      • MPC5E
      • MPC6E

      See http://www.juniper.net/techpubs/en_US/junos/topics/reference/configuration-statement/mtu-edit-interfaces-ni.html

    • 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 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 (MX Series and 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.]

    • Configuration support for multiple up MEPs for interfaces belonging to a single VPLS service or a bridge domain (MX Series with MPC)—Starting with Junos OS Release 16.1R1, you can configure multiple up maintenance association endpoints (MEP) for a single combination of maintenance association ID and maintenance domain ID for interfaces belonging to a particular VPLS service or a bridge domain.

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

    • 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

      See show pfe statistics traffic.

    • Enhancement to ambient-temperature statement (MX Series)—Starting in Junos OS Release 16.1R1, the default ambient temperature is set at 40° C on MX480, MX960, MX2010, and MX2020 3D Universal Edge Routers. You can override ambient temperature by setting the temperature at 55° C or 25° C.
      [edit]
      user@router# set chassis ambient-temperature ?
      Possible completions:
      25C                  25 degree celsius
      40C                  40 degree celsius
      55C                  55 degree celsius
      [edit]

      When a router restarts, the system adjusts the power allocation or the provisioned power for the line cards on the basis of the configured ambient temperature. If enough power is not available, a minor chassis alarm is raised. However, the chassis continues to run with the configured ambient temperature. You can configure a new higher ambient temperature only after you make more power available by adding new power supply modules or by taking a few line cards offline. By using the provisioned power that is saved by configuring a lower ambient temperature, you can bring more hardware components online.

    • Support for fabric black-hole detection and recovery in TX Matrix Plus routers—TX Matrix Plus routers can detect and recover from fabric faults that are not caused by hardware failure but might be a result of a fabric black-hole condition.

      To recover from a fabric black-hole condition, the routing matrix uses the following options:

      • SIB reboot
      • FPC reboot
      • Destination reprogramming
      • Related faults recovery

      You can disable the automatic recovery feature by using the auto-recovery-disable statement at the [edit chassis fabric degraded] hierarchy level. You can configure the FPCs to go offline when a traffic black-hole condition is detected in the routing matrix by using the fpc-offline-on-blackholing statement at the [edit chassis fabric degraded] hierarchy level.

      You can configure the FPCs to restart when a traffic black-hole condition is detected in the routing matrix by using the fpc-restart statement at the [edit chassis fabric degraded] hierarchy level.

      [See auto-recovery-disable and fpc-offline-on-blackholing.]

    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 and T 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 and T 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 and T 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 and T 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 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 configuration models that enable the same configuration to be used on different devices from one or more vendors. You can load YANG modules that add configuration hierarchies 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 Juniper Extension Toolkit, Release 1.0. For the JET Applications Guide, see Understanding JET Interaction with Junos OS.

    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.

      [See Pseudowire Termination: Explicit Notifications for Pseudowire Down Status.]

    • 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.

      [See show rsvp version.]

    • 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 and T 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 and T 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.
      • Enabling flexible view of LSP data-sets to facilitate LSP characteristic data visualization.
    • 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.

    • Subnet-match authentication for LDP sessions (MX Series)—Starting in Junos OS Release 16.1R1, support for Hashed Message Authentication Code (HMAC) and MD5 authentication for LDP sessions is extended from a per-session configuration to a subnet-match (that is, longest-prefix-match) configuration.

      This feature provides flexibility in configuring authentication for automatically targeted LDP (TLDP) sessions, making the deployment of remote loop-free alternate (LFA) and FEC 129 pseudowires easy.

      To enable this feature, configure the session-group option at the [edit protocols ldp] hierarchy level, and then enable the required authentication for the configured session group.

      [See Configuring the TCP MD5 Signature for LDP Sessions.]

    • 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.

      [See Pseudowire Subscriber Logical Interfaces Overview.]

    • 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.

      [See Pseudowire Subscriber Logical Interfaces Overview.]

    • 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 and T 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 and T 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
    • Support for RFC 5132, IP Multicast MIB (MX Series and T 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.

    Operation Administration and Management

    • Configuration support for multiple up MEPs for interfaces belonging to a single VPLS service or a bridge domain (MX Series with MPC)—Starting with Junos OS Release 16.1R1, you can configure multiple up maintenance association endpoints (MEP) for a single combination of maintenance association ID and maintenance domain ID for interfaces belonging to a particular VPLS service or a bridge domain.

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

    • Ethernet loss measurement counter support for each class in a multiclass environment—Junos OS supports Ethernet loss measurement (ETH-LM) for multiclass services. The ETH-LM feature is used by operators to collect frame loss counter values for ingress and egress service frames. Starting with Junos OS Release 16.1R1, the ETH-LM feature is extended to support the frame loss measurement counters for each class of packets in a multiclass environment. Counters for each class of packets are supported for point-to-point services only.

      Note: ETH-LM is currently supported for VPWS services only.

      ETH-LM maintains counters based on the forwarding class and loss priority of a packet. The loss priority determines the color of a packet—for example, green indicates loss priority low for committed information rate (CIR) and yellow indicates loss priority medium-high for excess information rate (EIR). The color (green and yellow) counters are maintained for each class of packets. Based on the counters supported on an interface, you can configure accounting modes with color or without color for Ethernet loss measurement:

      • Forwarding class-based accounting with color—In this mode, traffic is serviced based on packet loss priority and forwarding class. Two counters—green and yellow—are maintained for each forwarding class on each service interface. In this mode, an OAM (operation, accounting, and maintenance) packet collects counters based on the forwarding class.

        To configure this mode of loss measurement accounting, use the enable-multiclass-loss-measurement statement at the [set protocols oam ethernet connectivity-fault-management performance-monitoring] hierarchy level for global configuration or at the [set protocols oam ethernet connectivity-fault-management performance-monitoring interface interface-name] hierarchy level for interface-level configuration.

      • Forwarding class-based accounting without color—In this mode, traffic is serviced based on the forwarding class only. Only one counter is maintained for each forwarding class in each service interface.

        To configure this mode of loss measurement accounting, use the enable-multiclass-loss-measurement and colorless-loss-measurement statements at the [set protocols oam ethernet connectivity-fault-management performance-monitoring] hierarchy level for global configuration or at the [set protocols oam ethernet connectivity-fault-management performance-monitoring interface interface-name] hierarchy level for interface-level configuration.

      • Color-based accounting—In this mode, traffic is serviced based on the loss priority. Two counters—green and yellow—are maintained for each service interface. Color-based accounting is the default loss measurement mode and requires no configuration.
      • Code point-based accounting (without color)—In this mode, traffic is serviced based on the 802.1p priority bits. One counter is maintained for each code point (priority bit) on each service interface. If there are user virtual LAN or 802.1p rewrite rules configured, loss measurement accounting is done before applying the rewrite rules.

        To configure this mode, use the code-point-based-lm-accounting statement at the [set protocols oam ethernet connectivity-fault-management performance-monitoring] hierarchy level for global configuration or at the [set protocols oam ethernet connectivity-fault-management performance-monitoring interface interface-name] hierarchy level for interface-level configuration

        Note: Code point-based accounting mode does not work if virtual LAN pop or push is configured on the interface. If pop or push is configured, the 802.1p bits are removed from the data packets. Therefore in such cases, you can use forwarding class-based accounting if a one-to-one mapping exists between a forwarding class and the 802.1p bits value; else you can use the priority-based accounting mode.

      • Priority-based accounting—In this mode, four counters are maintained for each forwarding class for each interface, with each counter corresponding to either green or yellow colors. To configure this mode, use the priority-based-lm-accounting statement at the [set protocols oam ethernet connectivity-fault-management performance-monitoring] hierarchy level for global configuration or at the [set protocols oam ethernet connectivity-fault-management performance-monitoring interface interface-name] hierarchy level for interface-level configuration.
    • Support extended for IEEE 802.1ag Ethernet OAM (MX Series routers with MPC2E, MPC3E, MPC5E, and MPC6)—Support for the IEEE 802.1ag standard for Operation, Administration, and Maintenance (OAM) is now available on MX Series routers with MPC2E, MPC3E, MPC5E, and MPC6. The IEEE 802.1ag specification provides for Ethernet connectivity fault management (CFM), which monitors Ethernet networks that might comprise one or more service instances for network-compromising connectivity faults.
    • Support for MEF-36-compliant performance monitoring (MX Series)—Starting in Release 16.1R1, Junos OS supports performance monitoring that is compliant with Technical Specification MEF 36. You can enable MEF-36-compliant performance monitoring by configuring the measurement-interval statement at the [edit protocols oam ethernet cfm performance-monitoring] hierarchy level.

      Note: When MEF-36-compliant performance monitoring is enabled, an SNMP get next request for a variable might not fetch the current value unless an SNMP walk is performed before performing the get next request. This limitation applies only to the current statistics for delay measurement, loss measurement, and synthetic loss measurement.

      When MEF-36-compliant performance monitoring is enabled:

      • The output for the field Current delay measurement statistics might display a measurement interval of 0 (zero) and an incorrect timestamp until the first cycle time has expired.
      • Supported data TLV size for performance monitoring protocol data units (PDUs) is 1386 bytes when MEF-36-compliant performance monitoring is enabled. The TLV size is 1400 bytes in legacy mode.
      • The maximum configurable value for the lower threshold bin is 4,294,967,294.
      • Frame loss ratio (FLR) is excluded in loss measurements during period of unavailability for synthetic loss measurement only. In case of loss measurement, FLR is included even during period of unavailability.
      • During a period of loss of continuity (adjacency down), although SOAM PDUs are not sent, FLR and availability calculations are not stopped. These calculations are performed with the assumption of 100% loss.
      • The number of SOAM PDUs that are sent during the first measurement interval might be less than expected. This is because of a delay in detecting the adjacency state at the performance monitoring session level.
      • The number of SOAM PDUs transmitted during a measurement interval for a cycle time of 100 ms might not be accurate. For example, in a measurement interval of two minutes with a cycle time 100 ms, the SOAM PDUs transmitted might be in the range of 1198—2000.

    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 (MX Series)—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.

      [See Configuring the Accounting of Policer Overhead in Interface Statistics.]

    • 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.

      [See Understanding Route Filter and Source Address Filter Lists for Use in Routing Policy Match Conditions.]

    • 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.

      [See Example: Configuring the Priority for Route Prefixes in the rpd Infrastructure.]

    • 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 Packet Forwarding Engine 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 Packet Forwarding Engine for IP options packets for a given protocol. The queue-depth indicates the number of IP options packets which can be enqueued in the Packet Forwarding Engine 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 and T 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 and T 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 and T 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 and T 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.

    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.

      [See Supported IPv6 Standards.]

    • 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.

      [See Understanding Distributed Denial-of-Service Protection with IPv6 Neighbor Discovery Protocol.]

    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 MPC2E-NG, MPC3E-NG, MPC5E, and MPC6E (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 MPC2E-NG, MPC3E-NG, MPC5E, and MPC6E.

      [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.

      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
    • Exclude interfaces support in flowspec (rpd-infra) (MX Series)—Starting in Release 15.1, Junos OS excludes applying the flowspec filter to traffic received on specific interfaces. A new term is added at the beginning of the flowspec filter that accepts any packet received on these specific interfaces. The new term is a variable that creates an exclusion list of terms attached to the forwarding table filter as a part of the flow specification filter.

      To exclude the flowspec filter from being applied to traffic received on specific interfaces, you must first configure a group-id on such interfaces by including the family inet filter group group-id statement at the [edit interfaces] hierarchy level and then attach the flowspec filter with the interface group by including the flow interface-group group-id exclude statement at the [edit routing-options] hiearchy level. You can configure only one group-id per routing instance with the set routing-options flow interface-group group-id statement.

      [See Understanding BGP Flow Routes for Traffic Filtering.]

    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.]

    • Unified 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 and 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.

    Software Defined Networking

    • Support of Internet draft draft-ietf-pce-stateful-pce-07 for the stateful PCC implementation (MX Series and T Series)—The partial client-side implementation of the stateful Path Computation Element (PCE) architecture is currently based on version 2 of Internet draft draft-ietf-pce-stateful-pce. Starting with Junos OS Release 16.1, this implementation is upgraded to support version 7, as defined in Internet draft draft-ietf-pce-stateful-pce-07.

      Releases prior to 16.1 support the older version of the PCE draft, causing interoperability issues between a Path Computation Client (PCC) running a previous release and a stateful PCE server that adheres to Internet draft draft-ietf-pce-stateful-pce-07.

      [See Example: Configuring Path Computation Element Protocol for MPLS RSVP-TE.]

    • Support for PCEP-based reporting of point-to-multipoint LSPs (MX Series and T Series)—A stateful Path Computation Element (PCE) provides external path computation of traffic engineered (TE) label-switched paths (LSPs) for a Path Computation Client (PCC) in an MPLS network. After a PCEP session is established between a PCE and a PCC, the PCC reports all the LSPs in the system to the PCE for LSP state synchronization. Currently, this includes PCC-controlled, PCE-delegated, and PCE-initiated point-to-point RSVP-TE LSPs. Starting with Junos OS Release 15.1F6 and 16.1R1, this capability of a PCC is extended to report point-to-multipoint RSVP-TE LSPs as well.

      By default, a PCC does not support reporting of point-to-multipoint LSPs to a PCE. To add this capability, include the p2mp-lsp-report-capability statement at the [edit protocols pcep pce pce-name] or [edit protocols pcep pce-group group-id] hierarchy levels.

      A PCC configured with the capability of reporting point-to-multipoint LSPs to a PCE enables the PCE to have greater visibility of individual per-LSP, per-device bandwidth demands in the MPLS netwrok.

      [See Support of Path Computation Element Protocol for RSVP-TE Overview and Example: Configuring Path Computation Element Protocol with Support for PCE Controlled Point-to-Multipoint RSVP-TE LSPs.]

    • Support for securing PCEP sessions using MD5 authentication (MX Series and T Series)—Starting with Junos OS Release 16.1, you can secure a Path Computation Element Protocol (PCEP) session using TCP-MD5 authentication as per RFC 5440. To enable the MD5 security mechanism for a PCEP session, it is recommended that you define and bind the MD5 authentication key at the [edit protocols pcep pce pce-id] hierarchy level for a PCEP session. You can, however, also use a predefined keychain from the [edit security authentication-key-chains key-chain] hierarchy level to secure a PCEP session. In this case, you should bind the predefined keychain into the PCEP session at the [edit protocols pcep pce pce-id] hierarchy level.

      The following configuration is executed on the Path Computation Client (PCC) to establish a secure PCEP session with a Path Computation Element (PCE):

      • Using MD5 authentication key:
        [edit protocols pcep pce pce-id]user@PCC# set authentication-key key
      • Using predefined authentication keychain:
        [edit protocols pcep pce pce-id]user@PCC# set authentication-key-chain key-chainuser@PCC# set authentication-algorithm md5

      For secure PCEP sessions to be established successfully, the MD5 authentication should be configured with the pre-shared authentication key on both the PCE and the PCC. The PCE and PCC use the same key to verify the authenticity of each segment sent on the TCP connection of the PCEP session.

      This feature protects the communication between a PCE and PCC over a PCEP session, which might be subject to an attack, and can disrupt network services.

      You can view the authentication keychain used by a PCEP session by executing the show path-computation-client status and show protocols pcep commands.

      [See Support of Path Computation Element Protocol for RSVP-TE Overview.]

    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.1R1, 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
    • New predefined variables and Juniper Networks VSAs for family any interface filters (MX Series)—Starting in Junos OS Release 16.1R1, 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.]

    • 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 five-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 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.

    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
    • New configuration statement for filtering text substring in system log messages (MX Series and T 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.]

    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.

    Timing and Synchronization

    User Interface and Configuration

    • Support for JSON format for configuration data (MX Series and T 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.]

    • Extend the Junos CLI command set with custom scripts (MX Series)–Starting with Junos OS Release 16.1, you can configure devices running Junos OS to allow your custom scripts to be invoked in the Junos OS CLI or from within a NETCONF or Junos XML protocol session. The custom script can be written in either SLAX or Python. Configure your custom script to act as a native command using Yang’s RPC keyword extension. Its location in the command schema is specified in a Yang module.

      [See Junos Automation Scripting Overview,Using Juniper Networks YANG Modules.]

    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
    • MX Series Virtual Chassis Unified ISSU support for MPC6E line cards (MX Series Virtual Chassis)—Starting in Junos OS Release 16.1R2, MPC6E line cards support Unified ISSU in MX Series Virtual Chassis environments.

    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.
    • Support for common Public Key Infrastructure (PKI) functionality (MX Series)—Starting in Junos OS Release 16.1R3, 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.1R3, 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.

    Modified: 2017-06-07