Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

New and Changed Features

 

This section describes the new features and enhancements to existing features in the Junos OS main release and the maintenance releases for MX Series.

Release 17.1R2 New and Changed Features

Interfaces and Chassis

  • Enhancement to ambient-temperature statement (MX Series)—In Junos OS Release 17.1R2 and later, 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.

    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.

Routing Protocols

  • IGP cost calculation for next-hop-based dynamic tunnels(MX Series)—Starting in Junos OS Release 17.1R2, IGP cost calculation is supported for next-hop-based dynamic tunnels. In multihoming networks with next-hop-based GRE or UDP tunnel, rpd chooses the best path by calculating IGP metrics. However, in single-homed networks, rpd installs the tunnel composite next hop in the Packet Forwarding Engine without any IGP cost calculation.

    In earlier Junos OS releases, BGP preferred a path with the lowest router ID, which was not cost effective. When multiple PE devices advertise the same route, BGP did not take into account the IGP cost to those devices. This new feature allows BGP to choose an IGP path with the lowest metric and set up a tunnel to a PE device with the lowest cost. Note that in the absence of IGP connectivity, Junos OS does not install the advertised routes in the Packet Forwarding Engine or create a dynamic tunnel.

Subscriber Management and Services

  • Configurable grace period for unresponsive RADIUS servers (MX Series)—Starting in Junos OS Release 17.1R2, you can use the timeout-grace statement at the [edit access radius-options] hierarchy level to configure a grace period that determines when an unresponsive RADIUS authentication server is marked as down or unreachable. When the server fails to respond to any of the attempts made for an authentication request, it times out, the time is noted, and the grace period begins. If the server is unresponsive for subsequent authentication requests, the grace period is checked each time the server times out. When the check determines that the grace period has expired, the server is marked as down or unreachable.

    You can configure the grace period in the range 0 through 30 seconds; the default is 10 seconds. Use a short grace period to declare servers unavailable sooner and direct requests to available servers. Use a long grace period to give unresponsive servers more opportunities to respond.

    In earlier releases, the grace period is 10 seconds and is not configurable.

  • Support for excluding tunnel attributes from RADIUS Access-Request messages (MX Series)—Starting in Junos OS Release 17.1R2, you can use the exclude statement at the [edit access profile profile-name radius attribute] hierarchy level to exclude the following tunnel attributes from RADIUS Access-Request messages in addition to the previously supported Accounting-Start, and Accounting-Stop messages:

    • acct-tunnel-connection—RADIUS attribute 68, Acct-Tunnel-Connection

    • tunnel-assignment-id—RADIUS attribute 82, Tunnel-Assignment-Id

    • tunnel-client-auth-id—RADIUS attribute 90, Tunnel-Client-Auth-Id

    • tunnel-client-endpoint—RADIUS attribute 66, Tunnel-Client-Endpoint

    • tunnel-medium-type—RADIUS attribute 65, Tunnel-Medium-Type

    • tunnel-server-auth-id—RADIUS attribute 91, Tunnel-Server-Auth-Id

    • tunnel-server-endpoint—RADIUS attribute 67, Tunnel-Server-Endpoint

    • tunnel-type—RADIUS attribute 64, Tunnel-Type

Release 17.1R1 New and Changed Features

Hardware

  • Support for ODU path delay measurement for 100-Gigabit DWDM OTN MIC and 100-Gigabit DWDM OTN PIC (MX Series)—Starting in Junos OS Release 17.1R1, Junos OS supports ODU path delay measurement for the 100-Gigabit DWDM OTN MIC (MIC3-100G-DWDM) on MPC3E (MX-MPC3E-3D) and MPC3E-NG (MPC3E-3D-NG) on MX Series routers and for the 100-Gigabit Ethernet DWDM OTN PIC (PTX-5-100G-WDM) on PTX3000 and PTX5000 routers. Delay is measured by transmitting a known pattern (delay measurement pattern) in a selected bit of the delay measurement (DM) field and measuring the number of frames that are missed when the delay measurement pattern is received at the transmitting end (local interface).

    To enable delay measurement, first enable looping of the delay measurement pattern at the remote interface by including the remote-loop-enable statement at the [edit interfaces interfacename otn-options odu-delay-management] hierarchy level. Then, measure the delay by including the start-measurement statement at the [edit interfaces interfacename otn-options odu-delay-management] hierarchy level. Use the stop-measurement statement to stop measuring the delay. To disable looping of the delay measurement pattern at the remote interface, use the no-remote-loop-enable statement.

  • 1-port 100-Gigabit DWDM OTN MIC with CFP2 (MX240, MX480, MX960, MX2010, and MX2020)—Starting in Junos OS release 17.1R1, support is provided for the 1-port 100-Gigabit Ethernet dense wavelength division multiplexing (DWDM) optical transport network (OTN) MIC (MIC3-100G-DWDM) with CFP2 analog coherent optical (CFP2-ACO) pluggable optics on MPC3E (MX-MPC3E-3D) and MPC3E NG (MPC3E-3D-NG). The 100-Gigabit Ethernet DWDM OTN MIC supports the following features:

    • Transparent transport of 100-Gigabit Ethernet signals with optical channel transport unit, OTU4 (V) framing

    • Dual-polarization quadrature phase shift keying (DP-QPSK) modulation with coherent receiver and soft-decision forward error correction (SD-FEC) for long-haul and metro applications

    • International Telecommunication Union (ITU)-standard OTN performance monitoring and alarm management

    • Extensive optical, digital signal processing (DSP), and bit error ratio (BER) performance monitoring statistics for the optical link

    [See 100-Gigabit DWDM OTN MIC with CFP2-ACOand Configuring OTN Interfaces on MIC3-100G-DWDM MIC.]

Class of Service (CoS)

  • Copy ToS bits from incoming IP header to outer GRE IP header (MX Series with MPCs)—Starting in Junos OS Release 17.1R1, you can set GRE tunnel interfaces to copy the ToS bits (DSCP value) from the incoming IPv4 header to the outer GRE IP header for transit traffic. You can set this at the individual GRE interface level by including the copy-tos-to-outer-ip-header-transit statement at the [edit interfaces gr-fpc/pic/port unit logical-unit-number] hierarchy level, or globally by including the copy-tos-to-outer service-type ([ gre ] | [ mt ]) statement at the [edit chassis] hierarchy level.

    You can also now rewrite the DSCP/IP precedence value in both the inner and outer headers with the rewrite rules ([ dscp ] | [ inet-precedence ]) default protocol ([ inet-both ] | [ inet-outer ]) statement at the [edit class-of-service interfaces interface-name] hierarchy level.

    [See Configuring a GRE Tunnel to Copy ToS Bits to the Outer IP Header.]

EVPNs

  • Support for multihoming in an MSAN scenario with EVPN (MX Series routers with MPCs)—Starting in Junos OS Release 17.1R1, the EVPN multihoming feature enables you to connect a customer site to two or more provider edge (PE) devices to provide redundant connectivity. A customer edge (CE) device can be multihomed to different PE devices or the same PE device. A redundant PE device can provide network service to the customer site as soon as a failure is detected. Thus, EVPN multihoming helps maintain EVPN service and traffic forwarding to and from the multihomed site in case of network failures such as:

    • Failure of the link between PE device to CE device

    • PE device failure

    • MPLS-reachability failure between the local PE device and a remote PE device

    [See EVPN Multihoming Overview.]

  • Support for VPWS with EVPN signaling mechanisms (MX Series)—The Ethernet VPN (EVPN)-virtual private wire service (VPWS) network provides a framework for delivering the VPWS with EVPN signaling mechanisms. The VPWS with EVPN signaling mechanisms supports single-active or all-active multihoming capabilities and inter-autonomous system (AS) options associated with BGP-signaled VPNs. Starting with Junos OS Release 17.1R1, the vpws-service-id statement identifies the endpoints of the EVPN-VPWS network based on the local and remote identifiers configured on the provider edge (PE) routers in the network. These endpoints are autodiscovered by BGP and are used to exchange the service labels (learned from the respective PE routers) that are used by autodiscovered routes per EVPN instance (EVI).

    Use the show evpn vpws-instance command to verify the routes and interfaces of the VPWS instance of the EVPN.

    [See Overview of VPWS Service with EVPN Signaling Mechanisms.]

  • Support for inter-data center connectivity over pure Layer 3 network with EVPN (MX Series routers with MPCs)—Starting in Junos OS Release 17.1R1, the control plane EVPN Type-5 supports IP prefix for inter-subnet connectivity across data centers. The data packet is sent as the L2 Ethernet frame encapsulated in the VXLAN header over the IP network across the data centers to reach the tenant through the connectivity provided by the EVPN Type-5 IP prefix route.

    [See EVPN Type-5 Route with VXLAN encapsulation for EVPN/VXLAN.]

  • Support for LACP in EVPN active-active multihoming (MX Series routers with MPCs)—Starting with Junos OS Release 17.1R1, an extra level of redundancy can be achieved in an Ethernet VPN (EVPN) active-active multihoming network by configuring the Link Aggregation Control Protocol (LACP) on both the endpoints of the link between the multihomed customer edge (CE) and provider edge (PE) devices. The link aggregation group (LAG) interface of the multihomed CE-PE link can either be in the active or in the standby state. The interface state is monitored and operated by LACP to ensure fast convergence on isolation of a multihomed PE device from the core.

    When there is a core failure, a traffic black hole can occur at the isolated PE device. With the support for LACP on the CE-PE link, at the time of core isolation, the CE-facing interface of the multihomed PE device is set to the standby state, thereby blocking data traffic transmission from and toward the multihomed CE device. After the core recovers from the failure, the interface state is switched back from standby to active.

    To configure LACP in an EVPN active-active multihoming network:

    • On the multihomed CE device

      • Include the lacp active statement at the [edit interfaces aex aggregated-ether-options] hierarchy.

    • On the multihomed PE device

      • Include the lacp active statement at the [edit interfaces aex aggregated-ether-options] hierarchy.

      • Include the service-id number statement at the [edit switch-options] hierarchy.

    [See Example: Configuring LACP for EVPN Active-Active Multihoming.]

  • Support for IPv6 over IRB interfaces with EVPN (MX Series routers with MPCs)—Starting in Junos OS Release 17.1R1, IPv6 addresses are supported on IRB interfaces with EVPN using the Neighbor Discovery Protocol (NDP). The following capabilities are introduced for IPv6 support with EVPN:

    • IPv6 addresses on IRB interfaces in master routing instances

    • Learning IPv6 neighborhood from solicited NA message

    • NS and NA packets on the IRB interfaces are disabled from network core

    • Virtual gateway addresses are used as Layer 3 addresses

    • Host MAC-IP synchronization for IPv6

    You can configure the IPv6 addresses in the IRB interface at the [edit interfaces irb] hierarchy level.

    [See EVPN with IRB Solution Overview.]

  • Support for VLAN bundle service for EVPN (MX Series)—Starting in Junos OS Release 17.1R1, Junos OS supports the VLAN bundle service for EVPN. The VLAN bundle service maps multiple VLAN IDs to one EVPN instance. Because a separate instance for each VLAN ID is not needed, this feature lowers the control plane overhead on the router by reducing the number of EVPN instances.

    [See VLAN Bundle Service for EVPN.]

General Routing

  • PHY timestamping support for MIC-3D-20GE-SFP-EH, MIC-3D-20GE-SFP-E, and built-in 10-Gigabit Ethernet ports (MX104)—Starting with Junos OS Release 17.1R1, timestamping at the physical layer, also known as PHY timestamping, is supported on MIC-3D-20GE-SFP-EH, MIC-3D-20GE-SFP-E, and the built-in 10-Gigabit Ethernet ports on MX104 routers. PHY timestamping is the timestamping of the IEEE 1588 event packets at the physical layer. Timestamping the packet at the physical layer eliminates the noise or the packet delay variation (PDV) that is introduced by the Packet Forwarding Engine.

    To enable PHY timestamping on MX104 routers, include the phy-timestamping statement at the edit [protocols ptp] hierarchy level.

    [See PHY Timestamping.]

  • Support for PTP over Ethernet, hybrid mode, and G.8275.1 profile (MPC5E and MX104)—Starting in Junos OS Release 17.1R1, MPC5E and MX104 support the following features:

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

    • Hybrid mode—In hybrid mode, the synchronous Ethernet equipment clock (EEC) derives the frequency from Synchronous Ethernet and the phase and time of day from PTP.

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

      [See Profile Type.]

High Availability (HA) and Resiliency

  • ISSU Feature Explorer—The unified ISSU Feature Explorer is an interactive tool that you can use to verify your device’s unified ISSU compatibility with different Junos OS releases.

    [See ISSU Feature Explorer.]

  • 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 Junos OS Release 17.1R1, unified in-service software upgrade (ISSU) is supported 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-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.

    [See Protocols and Applications Supported by MX240, MX480, MX960, MX2010, and MX2020 MPC2E, Protocols and Applications Supported by the MX240, MX480, MX960, MX2010, and MX2020 MPC3E, and Protocols and Applications Supported by the MX240, MX480, MX960, MX2010, and MX2020 MPC5Es.]

  • Unified in-service software upgrade support for 100-Gigabit DWDM OTN MIC (MX960)—Starting with Junos OS Release 17.1R1, unified in-service software upgrade (unified ISSU) is supported for the 1-port 100-Gigabit Ethernet dense wavelength division multiplexing (DWDM) OTN MIC (MIC3-100G-DWDM) on MX960 routers with MPC3E (MX-MPC3E-3D) and MPC3E-NG (MX-MPC3E-NG).

    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.

    [See Unified ISSU System Requirements.]

  • New options for the show vrrp track command (MX Series)—Starting with Junos OS Release 17.1R1, the show vrrp track routes command gives you the option to view all tracked routes. Another new option for the show vrrp track command, all, is equivalent to the already existing command show vrrp track.

    [See show vrrp track.]

Interfaces and Chassis

  • Getting load-balancing hash result information (MX Series)—Starting in Junos OS Release 17.1R1, you can get the details for load-balancing hash results. You can get information for up to three levels of load balancing.

    To get load-balancing results for routed IPv4, IPv6, and other L3 traffic, use the show forwarding-options load-balance ingress-interface <interface-name> family <family-type> source-address <src-IP> destination-address <dest-IP> transport-protocol <transport-protocol> source-port <src-port> destination-port <dest-port> tos <TOS> command. To get load-balancing results for raw packet dumps, use the show forwarding-options load-balance ingress-interface <interface-name> family <family-type> packet-dump <pkt-dump> command.

    [See show forwarding-options load-balance.]

  • Support for PPP-TCC encapsulation on MIC-3D-16CHE1-T1-CE (MX Series)—Starting in Junos OS Release 17.1R1, Junos OS supports PPP-TCC encapsulation on channelized E1/T1 Circuit Emulation MIC (MIC-3D-16CHE1-T1-CE). PPP-TCC encapsulation is used for circuits with different media on either sides of the connection.

  • Removing the native VLAN ID from untagged traffic (MX Series)—Starting in Junos OS Release 17.1R1, you can send untagged traffic without a native VLAN ID to the remote end of the network. To do this, remove the native VLAN ID from the untagged traffic configuration by setting the no-native-vlan-insert statement. If you do not configure this statement, the native VLAN ID is added to the untagged traffic.

    [See Sending Untagged Traffic Without VLAN ID to Remote End.]

  • Inline MultilinkPPP, Multilink FrameRelay, and Multilink FrameRelay End-to-End for time-division multiplexing WAN interfaces (MX Series)—The ability to provide bundling services through the Packet Forwarding Engine without requiring a PIC or DPC by using inline Multilink PPP (MLPPP), Multilink Frame Relay (MLFR) FRF.16, and MLFR end-to-end FRF.15 for time-division multiplexing (TDM) WAN interfaces was first rolled out in Junos OS Release 14.1. Starting in Junos OS Release 17.1R1, this feature is also supported on the following MPCs: MPC5E (MX240, MX480, MX960, MX2010, and MX2020 routers) and MPC6E (MX2010 and MX2020 routers). Support includes multiple links on the same bundle as well as multiclass extensions for MLPPP. You can enable bundling services without additional DPC slots, freeing the slots for other MICs.

    [See Inline MLPPP for WAN Interfaces Overview, Example: Configuring Inline MLPPP and Multilink Frame Relay End-to-End (FRF.15) for WAN Interfaces,] and [Example: Configuring Inline Multilink Frame Relay (FRF.16) for WAN Interfaces.]

  • Enhancement to policer configuration (MX Series)—Starting in Junos OS Release 17.1R1, 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 up to 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.

  • Support for inline Two-Way Active Measurement Protocol (TWAMP) server and client on MPC7E (MX240, MX480, MX960)—Starting in Junos OS Release 17.1R1, MX Series routers with MPC7E cards support the inline Two-Way Active Measurement Protocol (TWAMP) control-client and server for transmission of TWAMP IPv4 UDP probes between the session-sender (control-client) and the session-reflector (server). The TWAMP control-client and server can also work with a third-party server and control-client implementation.

    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 rpm] hierarchy level. To configure the TWAMP client, include the twamp-client statement at the:[edit interfaces si-fpc/pic/ port unit logical-unit-number rpm] hierarchy level.

    [See Two-Way Active Measurement Protocol Overview.]

  • Support for frame relay inverse ARP on MIC-3D-16CHE1-T1-CE (MX Series)—Starting in Junos OS Release 17.1R1, Junos OS supports frame relay inverse ARP requests on channelized E1/T1 Circuit Emulation MIC (MIC-3D-16CHE1-T1-CE). You can configure MIC-3D-16CHE1-T1-CE to operate in either T1 or E1 mode. By default, all the ports operate in T1 mode.

    [See Configuring Inverse Frame Relay ARP.]

Layer 2 Features

  • Enhancement to MAC limit function (MX Series with MPCs)—Starting in Junos OS Release 17.1R1, the handling of a burst of packets with new source MAC addresses is improved to reduce resource use and processing time. In earlier releases, new source MAC addresses are learned and placed in the MAC table even after the limit is exceeded. The Routing Engine later deletes the MAC address entries that are over the limit.

    Now, the learning limit configured with the interface-mac-limit statement for new source MAC addresses is enforced at all levels: global, bridge domain, and VPLS. The MAC table is not updated with any new addresses after the limit has been reached. When any static MAC addresses are configured, the learning limit is the configured limit minus the number of static addresses.

    [See Limiting MAC Addresses Learned from an Interface in a Bridge Domain and Limiting the Number of MAC Addresses Learned from Each Logical Interface.]

Layer 2 VPN

  • Support for ETH-SLM and ETH-DM on aggregated Ethernet interfaces and LAG members on MPCs (MX Series)—Starting in Junos OS Release 17.1R1, you can configure ITU-T Y.1731 standard-compliant Ethernet synthetic loss measurement (ETH-SLM) and Ethernet delay measurement (ETH-DM) capabilities on aggregated Ethernet interfaces and LAG members on all MX Series MPCs. These ITU-T Y.1731 OAM services or performance-monitoring techniques can be measured in on-demand mode (triggered through the CLI) or proactive mode (triggered by the iterator application).

    ETH-SLM is an application that enables the calculation of frame loss by using synthetic frames instead of data traffic. ETH-DM provides fine control to operators for triggering delay measurement on a given service and can be used to monitor service-level agreements (SLAs).

Management

  • Support for Junos Telemetry Interface sensor for queue depth statistics (MX Series)—Starting with Junos OS Release 17.1R1 , you can configure a Junos Telemetry Interface sensor that exports queue depth statistics for ingress and egress queue traffic. Telemetry data is exported directly from the line card. You can also apply one or more regular expressions to filter data. Include the resource /junos/system/linecard/qmon/ statement at the [edit system services analytics sensor sensor-name] hierarchy level. Only UDP streaming of data is supported. gRPC streaming of queue depth statistics is not currently supported. Only MPC7E, MPC8E, and MPC9E are supported.

    [See sensor (Junos Telemetry Interface).]

  • gRPC support for the Junos Telemetry Interface (MX Series)–The Junos Telemetry Interface supports using a set of gRPC remote procedure call interfaces to provision sensors, subscribe to, and receive telemetry data. gRPC is based on an open source framework and provides secure and reliable transport of data. Use the telemetrySubscribe RPC to specify telemetry parameters and stream data for a specified list of OpenConfig commands 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 an 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. Support for gRPC for Junos Telemetry Interface was introduced in Junos OS Release 16.1R3.

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

  • Support for Junos Telemetry Interface (MX Series)—The Junos Telemetry Interface enables you to export telemetry data from supported interface hardware. Sensor data, such as interface events, are sent directly to configured collection points without involving polling. On MX Series routers, only MPC1 through MPC9E are supported. For sensors that stream data through the User Datagram Protocol, all parameters are configured at the [edit services analytics] hierarchy level. For sensors that stream data through gRPC, use the telemetrySubscribe RPC to specify telemetry parameters. Support for Junos Telemetry Interface was introduced in Junos OS Releases 15.1F3, 15.1F5, 15.1F6, and 16.1R3. Not all hardware and sensors are supported in those previous releases.

    [See Overview of the Junos Telemetry Interface.]

MPLS

  • Support for subscriber management over MPLS pseudowire logical interface on virtual chassis (MX Series)—Starting with Junos OS Release 17.1R1, MPLS pseudowire logical interface for subscriber management is supported on virtual chassis. The functionality of Ethernet interface types such as ae/ge/xe, works on virtual chassis.

  • Support for Layer 2 services provisioning on the services side of the pseudowire service logical interface (MX Series)—Starting with Junos OS Release 17.1R1, Layer 2 services provisioning such as bridge domain or VPLS instance is possible on the services side of the pseudowire service logical interface anchored to logical tunnel interface.

    Prior to Junos OS Release 17.1R1, Layer 2 encapsulations and features such as Spanning Tree Protocol (STP), VLAN and many more could not be configured on pseudowire service on the service logical interface.

    [See Layer 2 Services Provisioning on Services Side of Pseudowire Service Interface Overview.]

  • Support for port mirroring on pseudowire subscriber logical interface (MX Series)—Starting with Junos OS Release 17.1R1, port mirroring is supported on the services side of an MPLS pseudowire subscriber logical interface.

    You can configure pseudowire service interface in the same way as the logical interface or physical interface. The main purpose of port mirroring on pseudowire service interface is to allow configurations of pseudowire service interface as a mirrored interface at Layer 2 and Layer 3 levels as supported by firewall filters.

  • Support for LDP pseudowire auto-sensing (MX Series)—Starting with Junos OS Release 17.1R1, Label Distribution Protocol (LDP) pseudowire auto-sensing addresses zero-touch provisioning. LDP pseudowire auto-sensing enables pseudowire headend termination to be dynamically provisioned rather than statically configured. Hence, it is referred to as zero-touch provisioning.

    In Junos OS, pseudowire headend termination on service nodes is supported through the use of pseudowire service logical interfaces and physical interfaces. This approach is considered as superior in scalability to the old logical tunnel interface based approach, due to its capability of multiplexing and demultiplexing subscribers or customers over a single pseudowire. Currently, the creation and deletion of the pseudowire service logical interfaces, pseudowire service physical interfaces, Layer 2 circuits, and Layer 2 VPNs for pseudowire headend termination rely on static configuration. This is not considered as ideal from the perspective of scalability, efficiency, and flexibility, especially in a network where each service node might potentially host a large number of pseudowires.

    [See LDP Pseudowire Auto-Sensing Overview.]

  • Order-aware abstract hops for MPLS LSPs (MX Series)—Junos OS Release 17.1R1 introduces abstract hops, which are user-defined router clusters or groups that can be sequenced and used for setting up a label-switched path (LSP), similar to real-hop constraints.

    The router groups are created using constituent lists that include constituent attributes, which is a logical combination of the existing traffic engineering constraints, such as administrative groups, extended administrative groups, and Shared Risk Link Groups (SRLGs). Ordering among the router groups that satisfy the specified constituent attributes is achieved by using operational qualifiers in the abstract-hop definition.

    A path can use a combination of real and abstract hops as constraints. To configure abstract hops, you need to create constituent lists with traffic engineering attributes, include the lists in the abstract-hop definition, and define path constraints that use the abstract hops.

    [See Abstract Hops For MPLS LSPs Overview and Example: Configuring Abstract Hops for MPLS LSPs.]

  • Support for extension of pseudowire redundancy condition to logical Interfaces (MX Series)—Starting with Junos OS Release 17.1R1, pseudowire redundancy condition is supported on MPLS pseudowire subscriber logical interface. This is similar to the pseudowire redundancy feature for mobile backhaul by using the logical tunnel paired (lt-) interfaces.

    The primary or backup pseudowire is terminated at the provider edge routers (ps0.0) and the corresponding pseudowire (ps0.1 to ps0.n) service logical interfaces connected to Layer 3 domain by configuring those service logical interfaces in the Layer 3VPN routing instances. There is a Layer 2 circuit across MLPS access node and provider edge with the pseudowire service on transport logical interface (ps0.0) as the local interface of Layer 2 circuit terminating at the provider edge device.

    [See Extension of Pseudowire Redundancy Condition Logic to Pseudowire Subscriber Logical Interface Overview.]

  • Increased scaling values for MPLS-over-UDP tunnels (MX Series routers with MPCs/MICs)—The next-hop-based dynamic UDP tunnels are referred to as MPLS-over-UDP tunnels, and support the creation of a tunnel composite next hop for every dynamic tunnel created. Starting in Junos OS Release 17.1, the limit for the maximum number of next-hop-based dynamic MPLS-over-UDP tunnels that can be created on an MX series router with MPCs or MICs is increased. This provides additional scaling advantage for the total number of IP tunnels that can be created on the router.

    [See Example: Configuring Next-Hop-Based MPLS-Over-UDP Dynamic Tunnels.]

Multicast

  • Rate sensitive upstream multicast hop (UMH) selection for multicast VPN source-active routes (MX Series)—Starting in Junos OS Release 17.1R1, you can use the traffic rate on the ingress PE to trigger the egress PE to use an alternative UHM. Two new commands are introduced to support this feature, min-rate and dampen.

    Use this feature, for example, to ensure that egress PEs only receive Source-Active A-D route advertisements from ingress PEs that are receiving traffic at or above a specified rate. Rather than advertising the Source-Active A-D route immediately upon learning of the S,G, the ingress PE waits the time specified in the dampen command for the traffic rate to remain above the min-rate before it sends Source-Active A-D route advertisements. If the rate drops below the threshold, the Source-Active A-D route is withdrawn. These new commands can be found at the [edit routing-instancesinstance-name protocols mvpn mvpn-mode spt-only source-active-advertisement] hierarchy level.

    [See min-rate and dampen.]

Network Management and Monitoring

  • Support for hrProcessorTable object (MX Series)—Starting in Junos OS Release 17.1R1, support is provided for the hrProcessorTable object (object id: 1.3.6.1.2.1.25.3.3) described in the RFC2790, Host Resources MIB. The hrProcessorTable object provides the load statistics information per CPU for multi-core devices.

    [See SNMP MIB Explorer.]

  • Get and walk support for SNMP Timing MIB objects (MX104)—Starting in Junos OS Release 17.1R1, the get and walk functionality is supported for the following SNMP timing MIB objects:

    • jnxPtpClass

    • jnxPtpGmId

    • jnxPtpAdvClockClass

    • jnxPtpUtcOffset

    • jnxPtpUtcValid

    • jnxPtpOperationalSlaves

    • jnxPtpOperationalMaster

    • jnxPtpServoState

    • jnxPtpSlaveOffset

    • jnxTimingFrequencyTraceability

    • jnxTimingTimeTraceability

    • jnxClksyncQualityCode

    • jnxClksyncQualityCodeStr

    • jnxClksyncIfIndex

    • jnxClksyncIntfName

    • jnxClksyncSynceQualityTable

    • jnxClksyncSynceQualityIntfIndex

    • jnxClksyncSynceQualityValue

    • jnxClksyncSynceQualityIntfName

    [See SNMP MIB Explorer.]

  • Support for mplsL3VpnIfConfTable object (MX Series)— Starting in Junos OS Release 17.1R1, support is provided for the mplsL3VpnIfConfTable object (object id: 1.3.6.1.2.1.10.166.11.1.2.1) 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.]

  • Port mirroring enhancements (MX Series)—Starting in Junos OS Release 17.1R1, the port mirroring feature supports several new enhancements:

    • Packet mirroring for both ingress and egress directions on subscriber IFLs

    • Support for the encapsulation of mirrored packets onto per-subscriber L2TP tunnels

    • Support for the removal of S-VLAN tags from mirrored packets

    [See Configuring Protocol-Independent Firewall Filter for Port Mirroring.]

OpenFlow

  • Destination MAC address rewrites for OpenFlow (MX80, MX240, MX480, and MX960)—Some types of network equipment that function as routers accept and handle packets only if the destination MAC address in the packet is the same as the MAC address of the Layer 3 interface on which the packet is received. To interoperate with these routers, connected devices must also be able to rewrite the destination MAC address of an incoming packet. Starting with Junos OS Release 17.1R1, an OpenFlow controller can configure an MX Series router that supports OpenFlow to rewrite the destination MAC address of an incoming packet.

    [See Understanding How the OpenFlow Destination MAC Address Rewrite Action Works.]

Operation, Administration, and Maintenance (OAM)

  • Enhanced scale support for MIPs per chassis (MXSeries with MPCs)—Starting in Junos OS Release 17.1R1, Junos OS supports 8000 maintenance association intermediate points (MIPs) per chassis for bridge domain and VPLS domain interfaces. Increasing the number of MIPs per chassis for specific domains enables effective Ethernet OAM deployment in scaling networks. To support the increased number of MIPs, configure the network services mode on the router as enhanced-ip. If you do not configure the network services mode, then Junos OS supports only 4000 MIPs.

    [See Configuring Maintenance Intermediate Points (MIPs).]

  • Support for sender ID TLV—Starting with Junos OS Release 17.1R1, 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.

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

    Note

    The sender ID TLV is supported only for 802.1ag PDUs and is not supported for performance monitoring protocol data units (PDUs).

    [See Junos OS Support for Chassis ID TLV.]

  • CFM enhancement for interoperability during unified ISSU (MX Series on MPC1, MPC2, MPC2-NG, MPC3-NG, MPC5, and MPC6 cards)—Starting in Junos OS Release 17.1R1, Junos OS CFM works during a unified ISSU when the peer device is not a Juniper Networks router. Interoperating with the router of another vendor, the Juniper Networks router retains session information and continues to transmit CCM PDU (continuity check messages) during the unified ISSU upgrade.

    To provide this interoperability, enable inline (Packet Forwarding Engine) keepalives with the hardware-assisted-keepalives statement at the [edit protocols oam ethernet connectivity-fault-management performance-monitoring] hierarchy level. You must also configure the continuity-check interval to 1 second with the interval statement at the [edit protocols oam ethernet connectivity-fault-management maintenance-domain domain-name maintenance-association ma-name continuity-check] hierarchy level. Interoperability during unified ISSU is not supported for any other interval value.

    [See Configuring Connectivity Fault Management for interoperability during Unified In-Service Software Upgrades.]

Platform and Infrastructure

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

    vBNG runs on vMX, so 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.

    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

  • Virtual MX Series router (vMX)—Starting in Junos OS Release 17.1R1, you can deploy vMX routers on x86 servers. FreeBSD 10 is the underlying OS for Junos OS for vMX. vMX uses DPDK 2.2 to support improved performance.

    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

  • IS-IS import policy and route prioritization ( MX Series)—Beginning with Junos OS Release 17.1R1, you can prioritize IS-IS routes that are installed in the routing table for better convergence. In a network with a large number of interior gateway protocol prefixes with BGP Layer 3 VPN or label-based pseudowire service established on top of some interior gateway protocol prefixes, it is important to control the order in which routes get updated in the forwarding table.

    In previous releases, Junos OS installed IS-IS routes lexicographically in the routing table. Starting with Junos OS Release 17.1R1, you can configure an import policy to prioritize IS-IS routes as per your network requirements. Use a route tag, or filter the routes based on their prefix before setting a priority of high, medium, or low. Use the reject policy option to reject routes from a specific prefix or routes marked with a particular tag. The IS-IS protocol downloads routes to the rpd routing table based on the configured priority. If you do not configure an import policy, all routes are set to a medium priority by default.

    [See Example: Configuring a Routing Policy to Prioritize IS-IS Routes.]

  • Adjustable TCP MSS values (MX Series)—Starting in Junos OS Release 17.1R1, you can use the tcp-mss statement to configure the maximum segment size (MSS) for transient TCP packets that traverse a router. Adjusting the TCP MSS value helps reduce the likelihood of fragmentation and packet loss. The tcp-mss statement can be enabled on dynamic interfaces and supports protocols families inet and inet6.

    [See tcp-mss.]

  • BGP advertises multiple add-paths based on community value (MX Series)—Beginning with Junos OS 17.1R1, 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 advertise not 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.

    [See Example: Configuring a Routing Policy to Select and Advertise Multipaths Based on BGP Community Value.]

  • Selective advertising of BGP multiple paths (MX Series)—Beginning with Junos OS Release 17.1R1, 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.

    [See Example: Configuring Selective Advertising of BGP Multiple Paths for Load Balancing.]

  • System performance enhancements for rpd, Packet Forwarding Engine, and kernel (MX Series)—Beginning with Junos OS Release 17.1R1, performance of the routing protocol process (rpd), the Packet Forwarding Engine, and the kernel is enhanced to speed up the process with which the rpd learns the route states and changes, and reflects these changes in the ASIC-based Packet Forwarding Engine residing in the line cards. The key enhancements are faster route download rates when a router comes up after a reboot, or when you add a new line card, and faster update of the data plane in convergence scenarios. We recommend disabling daemons, such as Layer 2 address learning process (l2ald) and connectivity-fault management process (cfmd) —if they are not required— to improve system performance. Though these enhancements are mainly for the MX Series, other platforms might see some performance improvements as well.

Services Applications

  • Support for inline 6rd and 6to4 (MX Series routers with MPC5Es and MPC6Es)—Starting in Junos OS Release 17.1R1, you can configure inline 6rd or 6to4 on MPC5Es and MPC6Es. You can use the inline capability to avoid the cost of using MS-DPCs for required tunneling, encapsulation, and decapsulation processes. Anycast is supported for 6 to 4 using next-hop service interfaces. Hairpinning is also supported for traffic between 6rd domains.

    [See Tunneling Services for IPv4-to-IPv6 Transition Overview, show services inline softwire statistics, and clear services inline softwire statistics.]

  • Support for IP reassembly on GRE tunnel interfaces (MX Series routers with MPCs)—Starting in Junos OS Release 17.1R1, you can configure fragmentation and reasssembly of generic routing encapsulation (GRE) packets on GRE tunnel interfaces on MX Series routers with the following Modular Port Concentrators: MPC2E-NGs, MPC3E-NGs, MPC5Es, and MPC6Es.

    [See Configuring Unicast Tunnels.]

  • Support for 464XLAT PLAT on MS-MPCs and MS-MICs (MX Series)—Starting in Junos OS Release 17.1R1, the XLAT464 provider-side translater (PLAT) is supported on MS-MICs and MS-MPCs. The 464XLAT architecture provides a simple and scalable technique to provide IPv4 client-server connectivity across an IPv6-only network without having to maintain an IPv4 network and assign additional public IPv4 addresses on the customer side.

    [See 464XLAT Overview.]

  • Logging and reporting framework (MX Series with MS-MPC and MS-MIC)—Starting in Junos OS Release 17.1R1, the logging and reporting framework (LRF) enables you to log data for subscriber application-aware data sessions and send that data in an IP flow information export (IPFIX) format to an external log collector, using UDP-based transport. These data session logs can include subscriber information, application information, HTTP metadata, data volume, time-of-day information, and source and destination details. An external collector, which is not a Juniper Networks product, can then use this data to perform analytics that provide you with insights about subscriber and application usage.

    [See Logging and Reporting Function for Subscribers.]

  • Network attack protection for MS-MPCs and MS-MICs (MX Series)—Starting in Junos OS Release 17.1R1, the MS-MPC and MS-MIC can detect and prevent network probing attacks, network flooding attacks, header anomaly attacks, and suspicious packet pattern attacks.

    [See Configuring Protection Against Network Attacks (MS-MPCs and MS-MICs).]

  • Support for inline video monitoring on MPC7E, MPC8E, and MCP9E (MX Series)—Starting in Junos OS Release 17.1R1, support for video monitoring using media delivery indexing (MDI) criteria is expanded to include the following Modular Port Concentrators: MPC7E, MPC8E, and MCP9E.

    [See Inline Video Monitoring Overview.]

  • CLI command parity for carrier-grade NAT and stateful firewall (MX Series with MS-MPC)—Starting in Junos OS Release 17.1R1, 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.

    [See max-session-creation-rate (Service Set), show services subscriber analysis, and show services sessions analysis.]

  • Enhancements to stateful synchronization (MS-MIC, MS-MPC)—Starting in Junos OS Release 17.1R1, stateful synchronization for long-running flows is enhanced 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.

    • Checkpointing of IPv4 and IPv6 stateful firewall flows and NAPT-44 with address pooling paired (APP), with configurable timeout for checkpointing.

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

  • Subscriber-aware and application-aware traffic treatment (MX Series with MS-MPC)—Starting in Junos OS Release 17.1R1, Junos OS can perform subscriber-aware and application-aware policy enforcement for mobile or fixed-line subscribers. Junos OS determines the subscriber identity of traffic flow and applies the subscriber’s policy rules to the flow. Application identification is performed through deep packet inspection (DPI) at Layer 7 and Layer 4. Subscriber policy actions can include:

    • Redirecting HTTP traffic to another URL or IP address

    • Forwarding packets to a routing instance to direct packets to external service chains

    • Setting the forwarding class

    • Setting the maximum bit rate

    • Performing HTTP header enrichment

    • Setting the gating status to blocked or allowed

    [See Subscriber-Aware and Application-Aware Traffic Treatment Feature Guide.]

  • Usage monitoring for subscribers (MX Series with MS-MPC)—Starting in Junos OS Release 17.1R1, Junos OS can monitor the volume of traffic and the amount of time that a subscriber uses during a session if that subscriber’s policy control rules are controlled by a policy and charging rules function (PCRF) server. The PCRF initiates this monitoring, and the MX Series sends the reports to the PCRF. Monitoring can take place for the entire subscriber session or for only specific data flows and applications. The PCRF provides threshold values to indicate when the Service Control Gateway sends a report to the PCRF, or the PCRF can request a report at any time.

    [See Understanding Usage Monitoring for TDF Subscribers.]

  • Traffic Load Balancer (MX Series with MS-MPCs)—Starting in Junos OS Release 17.1R1, traffic load balancing is supported on MS-MPCs. 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 H.323 gatekeeper mode for NAT on MS-MPC and MS-MIC (MX Series routers)—Starting in Junos OS Release 17.1R1, H.323 gatekeeper mode is supported in NAPT44 and NAT64 rules and IPv4 stateful-firewall rules on the MX Series. H.323 is a legacy VoIP protocol.

    [See ALG Descriptions.]

  • Support for IKE and IPsec pass-through on NAPT44 and NAT64 (MX Series routers with MS-MPCs and MS-MICs)—Starting in Junos OS Release 17.1R1, you can enable the passing of IKE and IPsec packets through NAPT44 and NAT64 rules between IPsec peers that are not NAT-T compliant by using the IKE-ESP-TUNNEL-MODE-NAT-ALG Application Layer Gateway (ALG) on MS-MPCs and MS-MICs. This ALG supports only ESP tunnel mode.

    [See ALG Descriptions.]

  • Class-of-service (Cos) marking and reclassification for the MS-MICs and MS-MPCs—Starting with Junos Release 17.1R1, the MS-MIC and MS-MPC 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.]

  • Services support for MPC7E (MX Series)—Starting in Junos OS Release 17.1R1, the MPC7E (Multi-Rate) MPC supports the redirection of packets to the MS-MPC for the following services: carrier-grade NAT and stateful firewalls.

  • Support for distributing dynamic endpoint IPsec tunnels among AMS interfaces (MX Series routers with MS-MPCs)—Starting in Junos OS Release 17.1R1, you can distribute IPsec tunnels with dynamic endpoints among aggregated multiservices (AMS) interfaces.

    [See Configuring Dynamic Endpoints for IPsec Tunnels.]

  • Enhancements to the RFC2544-based benchmarking tests (MX Series)—Junos OS Release 17.1R1 extends support for the RFC2544 on MX Series routers with MPC3E (MX-MPC3E-3D), MPC3E-NG (MX-MPC3E-3D-NG), MPC4E (MPC4E-3D-32XGE-SFPP and MPC4E-3D-2CGE-8XGE), MPC5E (MPC5E-40G10G, MPC5EQ-40G10G, MPC5E-100G10G, and MPC5EQ-100G10G) and the MPC6E (MX2K-MPC6E).

    The RFC2544 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. Starting from Junos OS Release 17.1R1, RFC2544-based benchmarking tests on MX Series routers supports the following reflection function:

    • Layer 2 reflection (ingress direction) for family bridge, vpls

    To run the benchmarking tests on the MX Series routers, you must enable reflection feature on the corresponding MPC slot. To configure the reflector function on the MPC, use the chassis fpc fpc-slot-no slamon-services rfc2544 statement at the [edit] hierarchy level.

    [See RFC2544-Based Benchmarking Tests Overview.]

  • Service redundancy daemon support for redundancy across multiple gateways (MX Series routers with MS-MPCs)—Starting in Junos OS Release 17.1R1, 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.]

Subscriber Management and Services

  • Support for access-line-identifier interface sets based on the Agent Circuit ID (ACI), the Agent Remote ID (ARI), or both (MX Series)—Starting in Junos OS Release 17.1R1, you can configure interface sets for dynamic subscriber VLANs based on the access-line identifiers (ALI) that are received in a DHCPv4, DHCPv6, or PPPoE discovery packet. The set can be created when the identifier received is the ACI, the ARI, both the ACI and the ARI, or when neither the ACI nor the ARI is received. These interface sets model subscriber identities in a 1:N S-VLAN access model, where a single VLAN exists per service, but more than one subscriber might be using the service. In earlier releases, only the ACI could create the interface sets (ACI sets); when it was not present, the discovery packet was dropped.

    You can configure the creation of either ALI sets using this method or ACI interface sets using the legacy method, but not both. A CLI check prevents you from configuring both of these methods. The legacy ACI method might be deprecated in a future release.

    [See Access-Line-Identifier-Based Dynamic VLANs Overview.]

  • Static provisioning of unique subscriber ID including interface description (MX Series)—Starting in Junos OS Release 17.1R1, you can configure DHCP local server and DHCP relay agent to concatenate the interface description with the username during the subscriber or client authentication process. Use the interface-description statement to include either the logical interface description or the device interface description. The interface description is separated from the other username fields by the specified delimiter, or by the default delimiter “.” when you do not specify a delimiter. The specified delimiter must not be part of the interface description.

    [See Creating Unique Usernames for DHCP Clients.]

  • Flat file output for service filter-based accounting (MX Series)—Starting in Junos OS Release 17.1R1, you can configure service accounting statistics to be collected and reported in a local flat file as an alternative to being collected and automatically reported to a RADIUS server. Statistics collection is initiated when the service profile is attached to the subscriber interface.

    To configure local flat-file reporting:

    1. Create a flat-file profile and specify the service-accounting option at the [edit accounting-options flat-file-profile flat-file-profile-name fields] hierarchy level.
    2. Specify this profile with the local statement in the subscriber access profile.
    3. Configure the access profile for local reporting by setting the accounting-order either to local or—if you plan to activate the service with a CLI configuration or command—to activation-protocol at the [edit access profile profile-name service accounting-order] hierarchy level.

    [See Configuring Service Accounting in Local Flat Files.]

  • Support for asymmetric DHCP leasing (MX Series)—Starting in Junos OS Release 17.1R1, you can configure an override to the DHCP configuration—typically on the relay agent—to send a shorter (asymmetric) lease to a DHCP client than the lease granted by the DHCP local server. When the local server sends a client an acknowledgment packet in response to the client’s offer, the relay agent generates a new acknowledgment packet with the shorter time that you configured. When the client requests a lease renewal, the relay agent re-creates the short lease based on the original lease, rather than passing the request back to the local server. The relay agent continues to renew the shorter lease until the long lease renew time expires, at which time the asymmetric lease is no longer valid. Subsequent renewal requests from the client are forwarded to the server for consideration. If the client does not renew the lease before the short lease renew time expires, then the lease is considered to be abandoned by the client. The address is freed earlier than it would be if the granted lease was used. This feature is available for both DHCPv4 and DHCPv6 configurations.

    [See Configuring DHCP Asymmetric Leasing.]

  • shmlog support for CoS and firewall filter plug-ins (MX Series)—Starting in Junos OS Release 17.1R1, you can use the svc-sdb-id filter option with the show shmlog command to display only the shmlog filter table entries associated with a service session identifier. For example, the following command displays only shmlog entries that include service session 3:

    user@host> show shmlog entries logname all svc-sdb-id 3

    Any client session can have multiple associated service sessions. When you specify only the client session ID, the output includes the entries for the client session in addition to entries for all the service sessions related to that client session:

    user@host> show shmlog entries logname all sdb-id 2

    Although you can specify multiple shmlog filters at the same time, inaccurate results are returned when you combine svc-sdb-id with any filter other than sdb-id. For example, if you combine svc-sdb-id with vlan, the output does not display entries for the VLAN and service session. Instead, it displays no entries or only service session entries.

    Note

    The svc-sdb-id filter applies only to subscriber-based entries, because non-subscriber-based entries cannot be filtered. You can display those entries with the existing global commands. For example, for non-subscriber-based CoS and firewall entries, you can use the following commands:

    user@host> show shmlog entries logname all
    user@host> show shmlog entries logname *cos*
    user@host> show shmlog entries logname *dfw*
  • LAC support for IPv6 address family and firewalls (MX Series)—Starting in Junos OS Release 17.1R1, you can configure the LAC to create the IPv6 address family (inet6) when tunneling the subscriber to the LNS. By default, the LAC requires only family inet to enable forwarding into an IP tunnel. It can apply IPv4 firewall filters to the session. Even when family inet6 is included in the dynamic profile, by default it is not created and IPv6 firewall filters cannot be applied.

    Include the enable-ipv6-services-for-lac statement at the [edit services l2tp] hierarchy level to allow the IPv6 family to be created and IPv6 filters to be applied.

    Use the show services l2tp summary command to display the current state, Disabled or Enabled, in the IPv6 Ssrvices for LAC sessions field.

    [See enable-ipv6-services-for-lac.]

  • Dynamic subscriber and service management on statically configured interfaces (MX Series)—Starting in Junos OS Release 17.1R1, enhanced subscriber management supports dynamic service activation and deactivation for static subscribers. These static subscribers work with the native Juniper Networks Session and Resource Control (SRC), or you can configure RADIUS to activate and deactivate the services with change of authorization (CoA) messages.

    Note

    However, with RADIUS, authentication failure does not prevent the underlying interface from coming up and forwarding traffic. Instead, it prevents the subscriber from coming up, and thus service activation or deactivation. Authorization parameters such as IP addresses, net masks, policy lists, and QoS are also not imposed when using RADIUS.

    Use the following commands to provide administrative control of static subscribers:

    • request services static-subscribers login interface interface-name

    • request services static-subscribers logout interface interface-name

    • request services static-subscribers login group group-name

    • request services static-subscribers logout group group-name

    Use the following commands to monitor static subscribers:

    • show static-subscribers

    • show static-subscribers interface interface-name

    • show static-subscribers group group-name

  • Subscriber management and services feature parity (MX240, MX480, MX960)—Starting in Junos OS Release 17.1R1, the MX240, MX480, and MX960 routers with the Routing Engine RE-S-X6-64G support all subscriber management and services features. These services include DHCP, PPP, L2TP, VLAN, and pseudowire.

  • Packet injection enhancements (MX Series)—Starting in Junos OS Release 17.1R1, you can configure packet injection by using the packet-inject-enable option and a reserved policy map named packed-inject-flow. When a packet marked with the packet-inject-flow policy map egresses out of a logical interface that has the packet-inject-enable option enabled, it is sent for packet injection.

    The show interfaces statistics command output includes additional information about packet injection.

    [See packet-inject-enable.]

VPNs

  • Anti-spoofing protection for next-hop-based dynamic tunnels (MX Series Routers with MPCs)—Starting in Junos OS Release 17.1R1, anti-spoofing capabilities are added to next-hop-based dynamic IP tunnels, where checks are implemented for the traffic coming through the tunnel to the routing instance using reverse path forwarding in the Packet Forwarding Engine.

    Currently, when traffic is received from a tunnel, the gateway router does a destination address lookup before forwarding. With anti-spoofing protection, the gateway router does a source address lookup of the encapsulation packet IP header in the VPN to ensure that only legitimate sources are injecting traffic through their designated IP tunnels (strict mode). When a packet comes from a nondesignated tunnel, the reverse path forwarding check passes only in the loose mode. Traffic coming from nonexistent sources fails the reverse path forwarding check.

    This feature is supported on virtual routing and forwarding (VRF) routing instances with strict mode as the default.

    To enable anti-spoofing for dynamic tunnels, include the ip-tunnel-rpf-check statement at the [edit routing-instances routing-instance-name routing-options forwarding-table] hierarchy level.

    [See Anti-Spoofing Protection for Next-Hop-Based Dynamic Tunnels and Example: Configuring Anti-Spoofing Protection for Next-Hop-Based Dynamic Tunnels.]

  • Increased scaling values for next-hop-based dynamic GRE tunnels (MX Series routers with MPCs/MICs)—Starting in Junos OS Release 17.1R1, the limit for the maximum number of next-hop-based dynamic generic routing encapsulation (GRE) tunnels that can be created on an MX Series router with MPCs or MICs is increased. This provides additional scaling advantage for the total number of IP tunnels that can be created on the router.

    The increased scaling values of next-hop-based dynamic GRE tunnels benefits data center networks, where a gateway router is required to communicate with a number of servers over an IP infrastructure; for example, in Contrail networking.

    [See Example: Configuring a Next-Hop-Based Dynamic GRE Tunnels.]