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 Junos OS Release 17.4R2 for the MX Series routers.

Release 17.4R2 New and Changed Features

EVPNs

  • EVPN proxy ARP and ARP suppression without IRB interfaces (MX Series routers with MPCs, EX9200 switches)—MX Series routers and EX9200 switches that function as provider edge (PE) devices in an Ethernet VPN-MPLS (EVPN-MPLS) or Ethernet VPN-Virtual Extensible LAN (EVPN-VXLAN) environment support proxy Address Resolution Protocol (ARP) and ARP suppression. The proxy ARP and ARP suppression capabilities are enabled by default.

    Starting with Junos OS Release 17.4R2, these features no longer require the configuration of an integrated routing and bridging (IRB) interface on the PE device. Now, any interface configured on a PE device can deliver ARP requests from local remote customer edge (CE) devices. ARP proxy and ART suppression are not supported on remote CE’s.

    In addition, you can now control the following aspects of the media access control (MAC)-IP address bindings database on a PE device:

    • The maximum number of MAC-IP address entries in the database

    • The amount of time a locally learned MAC-IP address binding remains in the database

    [See EVPN Proxy ARP and ARP Suppression.]

Interfaces and Chassis

  • Enhancement to increase the threshold of corrected single-bit errors (MPC7E, MPC8E, MPC9E on MX Series)—In Junos OS Release 17.4R2, the threshold of corrected single-bit error is increased from 32 to 1024, and the alarm severity is changed from Major to Minor for those error messages. There is no operational impact upon corrected single bit errors. Also, a log message is added to display how many single-bit errors have been corrected between the reported events as follows:

    EA[0:0]: HMCIF Rx: Link0: Corrected single bit errordetected in HMC 0 - Total count 25

    EA[0:0]: HMCIF Rx: Link0: Corrected single bit errordetected in HMC 0 - Total count 26

    [See Alarm Overview.]

Restoration Procedures and Failure Handling

  • Device recovery mode introduced in Junos OS with upgraded FreeBSD (MX Series)—In Junos OS Release 17.4R2, for devices running Junos OS with upgraded FreeBSD, provided you have saved a rescue configuration on the device, there is an automatic device recovery mode that goes into action should the system go into amnesiac mode.The new process is for the system to automatically retry to boot with the saved rescue configuration. In this circumstance, the system displays a banner "Device is in recovery mode” in the CLI (in both the operational and configuration modes). Previously, there was no automatic process to recover from amnesiac mode. A user with load and commit permission had to log in using the console and fix the issue in the configuration before the system would reboot.

    [See Saving a Rescue Configuration File.]

Software Installation and Upgrade

  • ZTP support is added for MX VM host platforms (MX Series)—In Junos OS Release 17.3R3, ZTP, which automates the provisioning of the device configuration and software image with minimal manual intervention, is supported on MX Series VM hosts. When you physically connect a supported device to the network and boot it with a factory configuration, the device attempts to upgrade the Junos OS software image automatically and autoinstall a configuration provided on the DHCP server.

    [See Understanding Zero Touch Provisioning.]

Release 17.4R1 New and Changed Features

Hardware

  • Support for the CFP2-DCO-T-WDM-1 transceiver on the MPC5E-100G10G MPC and the MIC6-100G-CFP2 MIC (MX Series)—Starting in Junos OS Release 17.4R1, you can install the CFP2-DCO-T-WDM-1 transceiver on the MPC5E-100G10G MPC and the MIC6-100G-CFP2 MIC (installed on the MX2K-MPC6E MPC). The CFP2-DCO-T-WDM-1 transceiver is a 100-Gigabit digital pluggable CFP2 digital coherent optical module.

    The CFP2-DCO-T-WDM-1 transceiver supports the following:

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

    • 100-Gigabit quadrature phase shift keying (QPSK) with differential encoding mode and soft-decision forward error correction (SD-FEC)

    • proNX Service Manager (PSM)

    • Junos OS YANG extensions

    • Firmware upgrade

    [See 2x100GE + 4x10GE MPC5E and 100-Gigabit Ethernet MIC with CFP2.]

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

  • Periodic refresh of authorization profile on TACACS+ server (MX Series)—Starting with Junos OS Release 17.4R1, periodic refresh of the authorization profile that is received from the TACACS server is supported. The authorization profile that is configured for the user on the TACACS server is sent to the Junos OS device after the user is successfully authenticated. The authorization profile is stored locally on the Junos OS device. With the periodic refresh feature, the authorization profile is periodically fetched from the TACACS server to refresh the authorization profile that is stored locally. User authorization is reevaluated using the refreshed authorization profile.

    [See Configuring Periodic Refresh of the TACACS+ Authorization Profile.]

  • Enhanced TACACS+ support for the dedicated management instance (MX Series and vMX)—Starting in Junos OS Release 17.4R1, TACACS+ behavior is enhanced to support the management interface in a non-default virtual routing and forwarding (VRF) instance. For supported platforms, TACACS+ packets can now be sent to the server successfully even with the management-instance configuration statement enabled. The dedicated management instance was released in Junos OS Release 17.3R1.

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

Class of Service (CoS)

  • New criteria introduced for when to throttle logins based on CoS queues (MX Series)—Starting in Junos OS Release 17.4R1, new criteria are incorporated into the throttling decision for subscriber access. CoS resources (queues) are taken into account when deciding whether to avoid accepting new subscriber logins when there are insufficient CoS resources. To support this behavior, a new CLI configuration statement (high-cos-queue-threshold) is introduced to enable usage of CoS resource monitoring in throttling decisions and to set the threshold of CoS resource usage above which new logins are not permitted. A new show command (show system resource-monitor ifd-cos-queue-mapping fpc) is also introduced.

    [See “Throttling Subscriber Load Based on CoS Resource Capacity” in Resource Monitoring for Subscriber Management and Services Overview, high-cos-queue-threshold, and show system resource-monitor ifd-cos-queue-mapping fpc].

  • Support for static Type of Service (ToS)/Traffic Class on GRE tunnels (MX Series)—Starting in Junos OS Release 17.4R1, MPCs on MX Series routers support the setting of a static ToS/Traffic Class value in the IPv4/IPv6 header, respectively, of a GRE tunnel. You can set a traffic-class value at the interfaces gre-interface-name unit logical-unit-number tunnel hierarchy level. The value represents the entire 8-bit differentiated services (DS) field in the IP header, ranging from 0-255, and should be chosen based on the desired DSCP/IP precedence value. For example, if a DSCP value of 111000 is desired, then configure the traffic-class value to be 224 (corresponding to 111000 00).

    [See traffic-class (Tunnels).]

Dynamic Host Configuration Protocol (DHCP)

  • Support for RADIUS reauthentication of DHCPv4 and DHCPv6 clients (MX Series)—Starting in Junos OS Release 17.4R1, reissue of the RADIUS authentication request [access-request] is supported as an alternative to RADIUS Change of Authorization (CoA) to change subscriber session characteristics.

    Reauthentication is enabled by the following triggers:

    • The reauthenticate remote-id-mismatch command specifies reauthentication when there is a remote-id change in the option of the control packet (for example, RENEW, REBIND, DISCOVER, or SOLICIT) for the DHCPv4 or DHCPv6 client.

    • The reauthenticate lease-renewal command specifies reauthentication for a renew or rebind.

    • The reauthentication-on-renew command indicates to reauthentication on every renew or rebind from the DHCPv4 or DHCPv6 client.

    • If both reauthenticate lease-renewal and the Reauthentication-on-renew are specified for a given subscriber, the Junos DHCPD (DHCP daemon) requests reauthentication from the RADIUS server every time the DHCP client sends a DHCP renew request. If the reauthentication-on-renew vendor-specific attribute (VSA) is disabled, then behavior reverts to reauthenticate lease-renewal configuration.

    • If both reauthenticate lease-renewal and the reauthentication-on-renew VSA are enabled for a given subscriber

      • Junos OS DHCPD requests reauthentication from the RADIUS server every time the DHCP client sends a DHCP renew request (as reauthentication-on-renew VSA is enabled).

      • If the client sends a discover or solicit with DHCP options indicating a service plan change (different remote-id), Junos DHCPD will request reauthentication (as Junos OS DHCPD configuration reauthenticates on remote-id mismatch).

      • If the client sends a discover or solicit with DHCP options indicating No service plan change (same remote-id), Junos OS DHCPD will not request reauthentication (as the discover or solicit are not renews, and there is no remote-id mismatch).

      • If the reauthentication-on-renew VSA is disabled, then Junos OS DHCPD only reauthenticates when there is a renew, discover or solicit with a remote-id change (service plan change).

    [See RADIUS Reauthentication As an Alternative to RADIUS CoA for DHCPv4 and DHCPv6 Subscribers Overview.]

  • Support for forward-only action for DHCP relayed traffic with unknown DHCP server address (MX Series)—Starting in Junos OS Release 17.4R1, forward-only action for DHCP relayed traffic is supported with unknown DHCP server address. Administrator is able to configure for which servers (clients are binding) they need to have relay subscriber entry, apply dynamic profile, policies and more, and for whom they want to forward only. This feature also introduces configuration for processing destination address, option-54 and option-2 on DHCP relay.

    DHCP relay agent entry will be useful for authentication, authorization, accounting, applying filtering, QoS to client, processing of options specified in the packet. Customer networks can contain non-customer controlled bindings for which the customer does not want these relay agent entry functionalities. Hence relay agent subscriber entries are not created for non-customer controlled bindings.

    Prior to 17.4R1 Release, subscriber entry creation constituted of Junos OS DHCPD (DHCP daemon) memory resources, session database resources, authentication procedure, accounting, dynamic profile instantiation, dynamic interface creation, firewall, CoS association, and more. if a customer network has some non-customer controlled traffic for which a relay agent entry is created then it would be an unnecessary utilization of resources, and an incorrect association of profiles.

    [See Forward-only Action for DHCPv4 and DHCPv6 Relay Traffic with Unknown DHCP Server Address Overview.]

EVPNs

  • Support for duplicate MAC address detection and suppression (MX Series)—When a MAC address relocates, PE devices can converged on the latest location by using sequence numbers in the extended community field. Misconfigurations in the network can lead to duplicate MAC addresses. Starting in Junos OS Release 17.4R1, Juniper supports duplicate MAC address detection and suppression.

    You can modify the duplicate MAC address detection settings on the router by configuring the detection window for identifying duplicate MAC address and the number of MAC address moves detected within the detection window before duplicate MAC detection is triggered and the MAC address is suppressed. In addition, you can also configure an optional recovery time that the router waits before the duplicate MAC address is automatically unsupressed.

    To configure duplicate MAC detection parameters, use the detection-window, detection-threshold, and auto-recovery-time statements at the [edit routing instance routing-instance-name protocols evpn duplicate-mac-detection] hierarchy level.

    To clear duplicate MAC suppression manually, use the clear evpn duplicate-mac-suppression command.

    [See Overview of MAC Mobility. ]

  • Enhancements to composite next hops (MX Series)—Starting in Junos OS Release 17.4R1, you can enable dynamic list next hop. By enabling this feature, when the link fails between the CE device and a multihomed PE device in EVPN active-active multihoming, the routing process daemon (rpd) dynamically modifies the next-hop list without first removing the next-hop entry and creating a new entry. This reduces mass MAC route withdrawals and improves convergence and performance.

    To enable dynamic list next hop, include the dynamic-list-next-hop statement at the [edit routing-options forwarding-table] hierarchy level. If you perform a unified ISSU to upgrade your device from an OS release prior to Junos OS Release 17.4R1, you must upgrade both the Routing engine and the backup Routing Engine before enabling dynamic list next hop.

    [See Configuring Dynamic List Next Hop.]

  • EVPN active standby multihoming to a single PE device (MX Series)—Starting in Junos OS Release 17.4R1, Juniper supports EVPN active-standby multihoming. When you configure a protect (backup) interface for a primary interface on the same PE router, the protect interface becomes active when the primary interface fails and network traffic is switched to the protect interface.

    To configure a protect interface, include the protect-interface statement at the [edit interfaces hierarchy level for a routing instance, EVPN bridge domain, and the EVPN protocol under EVPN VPWS routing instance.

    [See Configuring EVPN Active-Standby Multihoming to a Single PE.]

  • SPRING support for EVPN (MX Series)—-Starting in Junos OS Release 17.4R1, Junos OS supports using Source Packet Routing in Networking (SPRING) as the underlay transport in EVPN. SPRING tunnels enable routers to steer a packet through a specific set of nodes and links in the network.

    To configure SPRING, use the source-packet-routing statement at the [edit protocols isis] hierarchy level.

    [See Understanding Source Packet Routing in Networking (SPRING).]

  • EVPN-MPLS interworking with MC-LAG (MX Series routers)—Starting with Junos OS Release 17.4R1, you can use Ethernet VPN (EVPN) to extend your MC-LAG network over an MPLS network. Typically, an MC-LAG network is extended to a data center network or geographically distributed campus or enterprise network.

    The EVPN-MPLS interworking feature offers the following benefits:

    • Ability to use separate virtual routing and forwarding (VRF) instances to control inter-VLAN routing.

    • VLAN translation.

    • Default Layer 3 virtual gateway support, which eliminates the need to run such protocols as Virtual Router Redundancy Protocol (VRRP).

    • Load balancing to better utilize both links when using EVPN multihoming.

    • The use of EVPN type 2 advertisement routes (MAC+IP) reduces the need for flooding domains with ARP packets.

    [See Understanding EVPN-MPLS Interworking with Junos Fusion Enterprise and MC-LAG.]

General Routing

  • Support for PTP over IPv4 and hybrid mode on 10GE, 40G, and 100GE WAN ports (MX10003, MX204)—Starting in Junos OS Release 17.4R1, the 10GE, 40G, and 100GE WAN ports support the following features:

    • PTP over IPV4 Encapsulation—In PTP over IPv4, the nodes (master and slave devices) participate in unicast negotiation in which the slave node is provisioned with the IP address of the master node and requests unicast messages to be sent to it from the master node.

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

      [See Understanding Hybrid Mode]

    • PHY timestamping support—PHY timestamping is the timestamping of the 1588 event packets at the PHY. Timestamping the packet in the PHY eliminates the noise or the Packet Delay Variation (PDV) that is introduced by the Packet Forwarding Engine (PFE).

      [See phy-timestamping]

  • Support for PTP over Ethernet, hybrid mode, and G.8275.1 profile (MPC7E-10G, MPC7E-MRATE, MPC8E, MPC9E)—Starting in Junos OS Release 17.4R1, MPC7E-10G, MPC7E-MRATE, MPC8E, and MPC9E 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. The IEEE 1588 standard defines two types of multicast MAC addresses 01-80-C2-00-00-0E (link local multicast) and 01-1B-19-00-00-00 (standard Ethernet multicast) for PTP over Ethernet operations.

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

      [See Understanding Hybrid Mode]

    • G.8275.1 profile— The G.8275.1 is a PTP profile for applications requiring 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 Precision Time Protocol Overview]

High Availability (HA) and Resiliency

  • Hardware resiliency support (MX204)—Starting in Junos OS Release 17.4R1, MX204 routers support the resiliency feature, which includes hardware failure and fault handling. Resiliency on an MX204 enhances its debugging capability in the case of hardware failure of any of its components. For example, the resiliency feature enables the router to recover from inter-integrated circuit (I2C) failure, and improves its voltage monitoring, temperature monitoring, PCI Express error handling and reporting. DRAM single-bit and multibit error checking and correction (ECC), and SSD SMART attribute monitoring capabilities.

  • L2VPN connection last uptime preserved after switchover (MX Series)—Starting in Junos OS Release 17.4R1, the show l2vpn connections command displays the last time that the L2VPN connection was in the Up condition, and this value persists after a switchover or unified ISSU.

    [See show l2vpn connections]

Interfaces and Chassis

  • Support for JNP-MIC-100G MIC with MACsec support on MPC8E and MPC9E (MX2000 line of routers)—Starting in Junos OS Release 17.4R1, the JNP-MIC-100G MIC extends Media Access Control Security (MACsec) capabilities on MPC8E and MPC9E MPCs installed in MX2010, MX2020, and MX2008 routers. Each MPC supports two JNP-MIC-100G MICs. On an MPC8E, each MIC supports 48 10-Gigabit Ethernet, 12 40-Gigabit Ethernet, or 4 100-Gigabit Ethernet MACsec-capable interfaces, or a combination. On an MPC9E, each MIC supports 48 10-Gigabit Ethernet, 12 40-Gigabit Ethernet, or 8 100-Gigabit Ethernet MACsec-capable interfaces, or a combination. Support for MACsec increases security within a data center and also provides secured connectivity between data centers.

    [See Understanding Media Access Control Security (MACsec) on MX Series Routers on basic information about MACsec.]

  • MX204 Universal Routing Platform—Starting in Junos OS Release 17.4R1, the MX204 Universal Routing Platform is added to the MX Series family of routers. The MX204 is a highly dense 1 rack unit (1 U) chassis that offers speeds of up to 400 Gbps and can be used as a preaggregation chassis and in mobile backhaul scenarios.

    The MX204 router is a fixed-configuration router, and supports one fixed Routing Engine. The MX204 has four rate-selectable ports that can be configured as 100-Gigabit Ethernet ports or 40-Gigabit Ethernet ports, or each port can be configured as four 10-Gigabit Ethernet ports (by using a breakout cable). The MX204 also has eight 10-Gigabit Ethernet ports. The four rate-selectable ports support QSFP28 and QSFP+ transceivers, whereas the eight 10-Gigabit Ethernet ports support SFP+ transceivers.

    [See MX204 Router Rate-Selectability Overview and Supported Active Physical Rate-Selectable Ports to Prevent Oversubscription on MX204 Router.]

    MX204 router supports port LED for 4xQSFPP ports—Starting in Junos OS Release 17.4R1, port LED is supported on MX204 routers. LEDs on the interface cards display the status of the ports. In MX204 router, there are four port LEDs per port. Each port provides an individual status LED with four states signaled by the color/LED state: OFF, GREEN, AMBER, RED

    [See MX204 LED Scheme Overview.]

  • Support for power management and environmental monitoring in MX204 routers—Starting with Junos OS Release 17.4R1, Junos OS chassis management software for the MX204 routers provides enhanced environmental monitoring and power management. MX204 routers have one Routing Engine and MPC. The MPC has one Packet Forwarding Engine that supports a bandwidth up to 400 Gbps. The MPC supports two fixed Physical Interface Card (PIC) where PIC0 comprises four QFP28 ports and PIC1 comprises 8 XSFPP ports. The power supply and the fan trays are upgradable. The cooling system contains three fan assemblies with two fans in each assembly. The chassis has two redundant power supply modules (PSM): DC PSM and AC PSM. Each of these PSMs deliver 650 W of power.

  • Software feature support on MX204 routers— Starting with Junos OS Release 17.4R1, Junos OS supports the MX204 Universal Routing Platform (model number: JNP204 [MX204]). The MX204 chassis is a monolithic system containing in-built MPC with one EA ASICs (operating in 400G mode) and supports 2 fixed port PICs (4xQSFP28 PIC and 8xSFPP PIC). All the devices including Packet Forwarding Engines, WAN interfaces are managed by the CPU subsystem (8 core Broadwell CPU). There are no fabric ASICs in the MX204 router.

    The MX204 router is a 400G capable monolithic platform having a single board with 8 Core Intel Broadwell CPU with 1 EA Packet Forwarding Engine ASICs connected to each other back to back.

    The following features are supported on MX204 platform:

    • Basic Layer 2 features including Layer 2 Ethernet OAM and virtual private LAN service (VPLS)

    • Class of service (CoS)

    • Firewall filters and policers

    • Integrated routing and bridging (IRB)

    • Layer 2 protocols

    • Layer 2 VPNs, Layer 2 circuits, and Layer 3 VPNs

    • Layer 3 routing protocols and MPLS

    • Layer 3 inline services

    • Multicast forwarding

    • Port mirroring

    • Spanning-tree protocols, such as STP, MSTP, RSTP, and VSTP

    • Synchronous Ethernet and Precision Time Protocol (IEEE 1588)

    • Tunneling

  • Support for MACsec PSK keychain (MX2010, MX2020)—Starting in Junos OS Release 17.4R1, MX2020 and MX2010 supports Key Agreement Protocol Fail Open mode. The MACsec PSK chains hitless rollover feature is documented in Junos OS Release 17.4R1, but not supported.

  • Strong encryption for configuration secrets (MX2020, MX2010, and MX2008 routers)—Starting in Junos OS Release 17.4R1, the MX2020, MX2010 and MX2008 routers support strong encryption for configuration secrets. To use strong encryption for your configuration secrets, you need to configure a master password. The master password enables you to derive an encryption key that you use with the AES256-GCM standard to encrypt configuration secrets. This new encryption method uses the $8$ formatted strings.

    [See Hardening Shared Secrets in Junos OS.]

  • Enhanced TACACS+ support for the dedicated management instance (MX Series and vMX)—Starting in Junos OS Release 17.4R1, TACACS+ behavior is enhanced to support the management interface in a non-default virtual routing and forwarding (VRF) instance. For supported platforms, TACACS+ packets can now be sent to the server successfully even with the management-instance configuration statement enabled. The dedicated management instance was released in Junos OS Release 17.3R1.

    [See Management Interface in a Non-Default Instance, and management-instance]

  • Support for pre-FEC BER monitoring when using the CFP2-DCO-T-WDM-1 transceiver (MX Series)—Starting in Junos OS Release 17.4R1, you can monitor the condition of an OTN link by using the pre-forward error correction (pre-FEC) bit error rate (BER) when using the CFP2-DCO-T-WDM-1 transceiver.

    [See Understanding Pre-FEC BER Monitoring and BER Thresholds.]

Junos OS XML API and Scripting

  • Automation script library additions and upgrades (MX Series)—Starting in Junos OS Release 17.4R1, devices running Junos OS include new and upgraded Python modules as well as upgraded versions of Junos PyEZ and libslax. On-box Python automation scripts can use features supported in Junos PyEZ Release 2.1.4 and earlier releases to perform operational and configuration tasks on devices running Junos OS. Python automation scripts can also leverage new on-box Python modules including ipaddress, jxmlease, pyang, serial, and six, as well as upgraded versions of existing modules. In addition, SLAX automation scripts can include features supported in libslax release 0.22.0 and earlier releases.

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

Layer 2 Features

  • Support for new configuration statements to perform qualified MAC learning on inner VLAN tags (MX Series) —Starting with Junos OS Release 17.4R1, MX series routers support the following new configuration statements:

    • deep-vlan-qualified-learning vlan_tag_number at the [edit interfaces unit logical_unit_number] hierarchy level to enable qualified mac-learning on the third VLAN tag (innermost) of an ingress 3-tagged packet, without any kind of implicit VLAN manipulation. If the packet has two tags, MAC learning happens on the second VLAN. If the ingress packet has more than three tags, all tags beyond the third tag are treated as part of data. For bidirectional traffic flow, input-vlan-map pop has to be configured.

    • vlan-id inner-all at the [edit routing instances instance_name] to enable qualified MAC learning on the second (inner) VLAN tag of an ingress double tagged packet, without removing the first (outer) tag implicitly. For a single-tagged packet, qualified MAC learning happens on VLAN 4096. If the ingress packet has more than two tags, all tags beyond the second tag are treated as part of data.

Logical Systems

  • Storm control In logical systems (MX Series)—Starting in Junos OS Release 17.4R1, support for storm control has been added for logical systems running on MX Series devices. With storm control, you can set a traffic threshold and enable traffic monitoring so that whenever the threshold is reached, the router automatically starts dropping broadcast, unknown unicast, and/or multicast (BUM) packets in order to prevent a “storm” of packets from proliferating on the network.

    To use this feature with a given logical system, create a storm control profile at the [edit logical-systems name forwarding-options storm-control-profiles name] hierarchy level.

    [See Understanding Storm Control for Managing Traffic Levels.]

  • EVPNs on logical systems (MX Series)—Starting with Junos OS Release 17.4R1, support for Ethernet Virtual Private Network (EVPN) has been added for logical systems running on MX Series devices. Running EVPN in a logical system provides the same options and performance as running EVPN on a physical system, which adheres to the standards described in RFC 7432. Note that Graceful Restart, Graceful Routing Engine switchover (GRES), and nonstop active routing (NSR) are not supported.

    Configure EVPN on a logical system at the [edit logical-systems logical-system-name routing-instances routing-instance-name protocols evpn] level.

    [See EVPN Overview .]

Management

  • Support for IS-IS sensor for Junos Telemetry Interface (MX Series)—Starting with Junos OS Release 17.4R1, you can export data for the IS-IS routing protocol through the Junos Telemetry Interface. Only gRPC streaming is supported. To export statistics for IS-IS, include the /network-instances/network-instance[name_'instance-name']/protocols/protocol/isis/levels/level/ and /network-instances/network-instance[name_'instance-name']/protocols/protocol/isis/interfaces/interface/levels/level/ set of paths. Use the telemetrySubscribe RPC to specify telemetry parameters and provision the sensor. Streaming telemetry data through gRPC also requires you to download the OpenConfig for Junos OS module.

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

  • Support for Packet Forwarding Engine traffic sensor for Junos Telemetry Interface (MX Series)—Starting with Junos OS Release 17.4R1, you can export Packet Forwarding Engine traffic statistics through the Junos Telemetry Interface. Both UDP and gRPC are supported. This sensor tracks reporting of Packet Forwarding Engine statistics counters and provides visibility into Packet Forwarding Engine error and drop statistics. The resource name for the sensor is /junos/system/linecard/packet/usage/. The OpenConfig path is /components/component/subcomponents/subcomponent[name='FPC<id>:NPU<id>']/properties/property/, where NPU refers to the Packet Forwarding Engine. To provision the sensor to export data through gRPC, use the telemetrySubcribe RPC to specify telemetry parameters. For streaming through UDP, all parameters are configured at the [edit services analytics] hierarchy level.

    [See Overview of the Junos Telemetry Interface.]

  • Enhancements to LSP events sensor for Junos Telemetry Interface (MX Series) —Starting with Junos OS Release 17.4R1, telemetry data streamed through gRPC for LSP events and properties is reported separately for each routing instance. To export data for LSP events and properties, you must now include /network-instances/network-instance/[name_'instance-name']/ in front of all supported paths. For example, to export LSP events for RSVP signaling protocol attributes, use the following path: /network-instances/network-instance[name_'instance-name']/mpls/signaling-protocols/rsvp-te/. Use the telemetrySubscribe RPC to specify telemetry parameters and provision the sensor. If your device is running a version of Junos OS with an upgraded FreeBSD kernel, you must download the Junos Network Agent software package, which provides the interfaces to manage gRPC subscriptions.

    [See Guidelines for gRPC Sensors.]

  • Enhancement to BGP sensor for Junos Telemetry Interface (MX Series)—Starting with Junos OS Release 17.4R1, you can specify to export the number of BGP peers in a BGP group for telemetry data exported through gRPC. To export the number of BGP peers for a group, use the following OpenConfig path: /network-instances/network-instance[name_'instance-name']/protocols/protocol/

    bgp/peer-groups/peer-group[name_'peer-group-name]/state/peer-count/
    . The BGP peer count value exported reflects the number of peering sessions in a group. For example, for a BGP group with two devices, the peer count reported is 1 (one) because each group member has one peer. To provision the sensor to export data through gRPC, use the telemetrySubcribe RPC to specify telemetry parameters.

    [See Guidelines for gRPC Sensors.]

  • Broadband edge (BBE) telemetry sensors (MX Series routers)—In Junos OS Release 17.4R1, support is expanded for BBE telemetry sensors. These sensors are used to proactively manage a broadband network gateway (BNG) and are configured using both Junos Telemetry Interface (JTI) and gRPC streaming. The new sensors are grouped in the following functional areas:

    • Chassis and system extensions

    • Authentication, authorization, and accounting (AAA)

    • Dynamic Host Configuration Protocol (DHCP)

    • Packet Forwarding Engine resource monitoring

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

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

  • Enhancements to MPLS sensor for Junos Telemetry Interface (MX Series)—Starting with Junos OS Release 17.4R1, you can export statistics for MPLS through the Junos Telemetry Interface in the following categories:

    • Shared Risk Link Groups (SRLGs)

    • Traffic engineering global attributes

    • Traffic engineering interface attributes

    Additional RSVP signaling protocol attributes, such as counters and interfaces, that were not previously available are also supported. Only gRPC streaming is supported.

    [See Guidelines for gRPC Sensors.]

  • Support for bidirectional authentication for gRPC for Junos Telemetry Interface (MX Series)—Starting with Junos OS Release 17.4R1, you can configure gRPC to require client authentication as well as server authentication. Previously, only the client initiating an RPC request was able to authenticate the server;, that is, a Juniper device using SSL certificates. To enable bidirectional authentication, include the mutual-authentication statement at the [edit system-services extension-service request-response grpc ssl] hierarchy level. You must also configure and reference a certificate-authority profile. Include the certificate-authority profile name statement at the [edit system services extension-service request-response grpc ssl] hierarchy level. For profile-name, include the name of certificate-authority profile configured at the [edit security pki ca-profile] hierarchy level. This profile is used to validate the certificate provided by the client.

    Note

    MX80 and M104 routers do not support gRPC.

    [See gRPC Services for Junos Telemetry Interface.]

  • Support for BGP routing table sensors for Junos Telemetry Interface (MX Series)—Starting with Junos OS Release 17.4R1, you can provision Junos Telemetry Interface sensors to export data for BGP routing tables (RIBs) for IPv4 and IPv6 routes. Each address family supports exporting data for five different tables. Only gRPC streaming is supported.

    The tables are:

    • local-rib—Main BGP routing table for the main routing instance.

    • adj-rib-in-pre—NLRI updates received from the neighbor before any local input policy filters have been applied.

    • adj-rib-in-post—Routes received from the neighbor eligible for best-path selection after local input policy filters have been applied.

    • adj-rib-out-pre—Routes eligible for advertising to the neighbor before output policy filters have been applied.

    • adj-rib-out-post—Routes eligible for advertising to the neighbor after output policy filters have been applied.

    To stream data for the main BGP routing table for IPv4 routes, include the /bgp-rib/afi-safis/afi-safi/ipv4-unicast/loc-rib/ set of paths. To stream data for the main BGP routing table for IPv6 routes, include the /bgp-rib/afi-safis/afi-safi/ipv6-unicast/loc-rib/ set of paths.

    For the neighbor BGP routing tables for IPv4 routes, include the following sets of paths:

    • /bgp-rib/afi-safis/afi-safi/ipv4-unicast/neighbors/neighbor/adj-rib-in-pre/

    • /bgp-rib/afi-safis/afi-safi/ipv4-unicast/neighbors/neighbor/adj-rib-in-post/

    • /bgp-rib/afi-safis/afi-safi/ipv4-unicast/neighbors/neighbor/adj-rib-out-pre/

    • /bgp-rib/afi-safis/afi-safi/ipv4-unicast/neighbors/neighbor/adj-rib-out-post/

    To stream data for IPv6 routes, change ipv4-unicast to ipv6-unicast in any of the paths.

    [See Guidelines for gRPC Sensors.]

  • Junos Telemetry Interface support for virtual MX Series routers (vMX)—Starting with Junos OS Release 17.4R1, the Junos Telemetry Interface is supported on vMX routers. The Junos Telemetry Interface enables you to provision sensors to stream telemetry data for network elements without involving polling. All sensors supported on MX Series routers are supported on vMX routers, except for the following: fabric statistics and high queue-scale statistics. To provision a sensor to export data through gRPC, use the telemetrySubscribe RPC to specify telemetry parameters. For UDP streaming, all parameters are configured at the [edit services analytics] hierarchy level. Streaming telemetry data through gRPC also requires you to download the OpenConfig for Junos OS module.

    [See Overview of the Junos Telemetry Interface.]

  • Multiservices MPC (MS-MPC) support for Junos Telemetry Interface (MX Series)—Starting with Junos OS Release 17.4R1, interfaces configured on MS-MPCs support the Junos Telemetry Interface, which enables you to provision sensors to stream telemetry data for network elements without involving polling. Only streaming through UDP is supported. gRPC streaming is not supported. To provision sensors to stream data through UDP, all parameters are configured at the [edit services analytics] hierarchy level.

    Only the following sensors are supported on MS-MPCs:

    • Firewall filters

    • CPU memory

    • NPU memory

    • NPU memory utilization

    • Physical interfaces

    [See Configuring a Junos Telemetry Interface Sensor.]

  • Junos Telemetry Interface support on MX2008 routers (MX Series)—Starting with Junos OS Release 17.4R1, the Junos Telemetry Interface, which enables you to provision sensors to stream telemetry data for network elements without involving polling, is supported on MX2008 routers. Both UDP and gRPC streaming are supported. To provision the sensor to export data through gRPC, use the telemetrySubscribe RPC to specify telemetry parameters. For streaming through UDP, all parameters are configured at the [edit services analytics] hierarchy level. Streaming telemetry data through gRPC also requires you to download the OpenConfig for Junos OS module.

    [See Overview of the Junos Telemetry Interface.]

  • Support for dynamic tunnel statistics for Junos Telemetry Interface (MX Series)—Starting with Junos OS Release 17.4R1, you can export counter statistics for Packet Forwarding Engine dynamic tunnels. Both UDP and gRPC streaming are supported. The resource string to export statistics is /junos/services/ip-tunnel/usage/. The OpenConfig path is /junos/services/ip-tunnel[name='tunnel-name']/usage/counters[name='counter-name']/. All parameters for UDP sensors are configured at the [edit services analytics] hierarchy level. To export data through gRPC, use the telemetrySubscribe RPC. To stream data through gRPC, you must also download the OpenConfig for Junos OS module. MX80 and MX104 routers only support UDP streaming. They do not support gRPC.

    [See Overview of the Junos Telemetry Interface.]

  • Support for bypass LSP statistics for Junos Telemetry Interface (MX Series)—Starting with Junos OS Release 17.4R1, you can export statistics for bypass label-switched paths (LSPs). Previously, only statistics for the primary LSP path were exported. The ability to export bypass LSP statistics helps to monitor the efficiency of global convergence when the bypass LSP is used to carry traffic during a link or node failure.

    Statistics are exported for the following:

    • Bypass LSP originating at the ingress router of the protected LSP

    • Bypass LSP originating at the transit router of the protected LSP

    • Bypass LSP protecting the transit LSP as well as the locally originated LSP

    When the bypass LSP is active, traffic is exported both on the bypass LSP and the ingress (protected) LSP. To provision the sensor to export data through gRPC, use the telemetrySubcribe RPC to specify telemetry parameters. For streaming through UDP, all parameters are configured at the [edit services analytics] hierarchy level. Streaming telemetry data through gRPC also requires you to download the OpenConfig for Junos OS module. You must also include the sensor-based-stats statement at the [edit protocols mpls] hierarchy level.

    [See sensor and Guidelines for gRPC Sensors.]

  • Support for multiple, smaller configuration YANG modules (MX Series)—Starting in Junos OS Release 17.4R1, the YANG module for the Junos OS configuration schema is split into a root configuration module that is augmented by multiple, smaller modules. The root configuration module comprises the top-level configuration node and any nodes that are not emitted as separate modules. Separate, smaller modules augment the root configuration module for the different configuration statement hierarchies. Smaller configuration modules enable YANG tools and utilities to more quickly and efficiently compile and work with the modules, because they only need to import the modules required for the current operation.

    [See Understanding the YANG Modules That Define the Junos OS Configuration.]

MPLS

  • Interoperability of segment routing with LDP (MX Series)—In an LDP network with gradual deployment of segment routing, some devices may not support segment routing, which can cause interoperability issues in the network. Starting in Junos OS Release 18.2R1, and 17.4R2, you can use OSPF or ISIS to enable segment routing devices to operate with the LDP devices that are not segment routing capable.

    To implement this feature using OSPF, an extended prefix link-state advertisement (LSA) with Range type, length, and value (TLV) for all the LDP prefixes is generated, and mapping routes corresponding to the prefix is installed in the inet.3 and mpls.0 routing tables.

    To implement this feature using ISIS, a server-client configuration is required under protocols ISIS and LDP, respectively, and routes from the inet.3 or inet.0 routing tables are used for stitching of segment routing LSP with an LDP LSP and vice-versa.

    [See LDP Mapping Server for Interoperability of Segment Routing with LDP Overview .]

  • Support for Ethernet CCC encapsulation on pseudowire subscriber transport and services logical interfaces (MX Series)—Starting in Junos OS Release 17.4R1, you can configure the same Ethernet circuit cross-connect (CCC) encapsulation (also known as VLAN-ID) on pseudowire subscriber transport and service logical interface. The primary reason for Ethernet CCC encapsulation on the pseudowire subscriber transport is for interoperability between the existing access node and aggregation node in the network.

    Prior to Release 17.4R1, Junos OS does not allow the same VLAN-ID to be configured on more than one logical interface under the same pseudowire subscriber physical interface. To establish a pseudowire connection from an access node or aggregation node to a Multi-Service Edge (MSE) node, ignore-encapsulation-mismatch configuration statement is used. This statement is a Junos OS feature and the access or aggregation device may not support this feature. To overcome this restriction, you can configure same VLAN-ID on transport and service logical interface.

    [See VLAN CCC Encapsulation on Transport Side of Pseudowire Subscriber Logical Interfaces Overview.]

  • Support for static adjacency segment identifier for IS-IS (MX Series)—Starting with Junos OS Release 17.4R1, you can configure static adjacency segment ID (SID) labels for an interface. You can configure two IPv4 adjacency SIDs (protected and unprotected), IPv6 adjacency SIDs (protected and unprotected) per level per interface. You can use the same adjacent SID for multiple interfaces by grouping a set of interfaces under an interface-group and configuring the adjacency-segment for that interface-group. For static adjacency SIDs, the labels are picked from either a static reserved label pool or from segment routing global block (SRGB).

    [See Static Adjacency Segment Identifier for ISIS.]

  • Support for static adjacency segment identifier for aggregate Ethernet member links using single-hop static LSP (MX Series)—Starting with Junos OS Release 17.4R1, you can configure a transit single-hop static label switched path (LSP) for a specific member link of an aggregated Ethernet (AE) interface. A static labeled route is added with next-hop pointing to the AE member link of an aggregate interface. Label for these routes is picked from the segment routing local block (SRLB) pool of the configured static label range. This feature is supported for AE interfaces only.

    A new member-interface CLI command is added under the next-hop configuration at the [edit protocols mpls static-label-switched-path lsp-name transit] hierarchy to configure the AE member interface name. The static LSP label is configured from a defined static label range.

    [See Configuring Static Adjacency Segment Identifier for Aggregate Ethernet Member Links Using Single-hop Static LSP.]

  • Support for segment routing statistics (MX Series Routers with MPCs and MICs)—Starting in Junos OS Release 17.4R1, the traffic statistics in a segment routing (SR) network can be recorded in an OpenConfig compliant format for Layer 3 interfaces. The statistics is recorded for the Source Packet Routing in Networking (SPRING) traffic only, excluding RSVP and LDP-signaled traffic, and the family MPLS statistics per interface is accounted for separately. The SR statistics also includes SPRING traffic statistics per link aggregation group (LAG) member, and per service identifier (SID).

    To enable recording of SR statistics, include the sensor-based-stats (per-interface-per-member-link <ingress | egress> | per-sid ingress statement at the [edit protocol isis source-packet-routing] hierarchy level.

    [See Understanding Source Packet Routing in Networking (SPRING).]

  • IPv6 next-hop support for static egress LSPs (MX Series)—Starting in Junos OS Release 17.4R1, static LSPs on the egress router can be configured with IPv6 as the next-hop address for forwarding IPv6 traffic. Previously, only IPv4 static LSPs were supported. The IPv6 static LSPs share the same transit, bypass, and static LSP features of IPv4 static LSPs.

    A commit failure occurs when the next-hop address and destination address of the static LSP do not belong to the same address family (IPv4 or IPv6).

    [See next-hop (Protocols MPLS).]

Operation, Administration, and Maintenance (OAM)

  • Support for Inline performance monitoring (MX Series Routers)—Starting in Junos OS Release 17.4R1, Junos OS supports inline mode for MEF 35 compliant service OAM performance monitoring on MX Series routers. Performance monitoring functions include measurement of Ethernet frame delay, frame delay variations, frame loss, and availability of service. By default, performance monitoring packets are handled by the CPU of a line-card, such as Modular Port Concentrator (MPC). Enabling inline mode of performance monitoring delegates the processing of the protocol data units (PDUs) to the forwarding ASIC (that is, to the hardware). By enabling inline mode of performance monitoring, the load on the CPU of the line-card is reduced and you can configure an increased number of performance monitoring sessions and achieve maximum scaling for service OAM performance monitoring sessions.

    Inline mode of performance monitoring is supported only for proactive mode of frame delay measurement (Two-way Delay Measurements) and synthetic loss measurements (SLM) sessions. Performance monitoring functions configured using the iterator profile (CFM) are referred to as proactive performance monitoring. Inline mode of performance monitoring for frame loss measurement using service frames (LM) is not supported.

    Note

    MPC3E (MX-MPC3E-3D) and MPC4E (MPC4E-3D-32XGE-SFPP and MPC4E-3D-2CGE-8XGE) do not support inline performance monitoring. User-defined Data TLV is not supported if you have configured inline mode of performance monitoring. Also, only 12 history records per PM sessions are supported.

  • Support for CFM monitoring on pseudowire services interfaces(MX Series Routers)—Starting in Junos OS Release 17.4R1, Junos OS supports IEEE 802.1ag connectivity fault management (CFM) on pseudowire service interfaces. Pseudowire service interfaces support configuring of subscriber interfaces over MPLS pseudowire termination. Termination of subscriber interfaces over PW enables network operators to extend their MPLS domain from the Access/Aggregation network to the service edge and use uniform MPLS label provisioning for a larger portion of their network. ​

    To enable support for CFM on pseudowire service interfaces, configure maintenance intermediate points (MIPs) on the pseudowire service interfaces. The CFM MIP session is supported only on the pseudowire services interface and not on the pseudowire services tunnel interface.

Routing Protocols

  • Support for timing and synchronization on MX204 Routers—Starting in Junos OS Release 17.4R1, MX204 routers support the following timing and synchronization features:

    • SyncE support with ESMC—Synchronized Ethernet with Ethernet Synchronization Message Channel (ESMC) is supported as per the ITU G.8264 specification. ESMC is a logical communication channel. It transmits synchronization status message information, which is the quality level of the transmitting Synchronous Ethernet equipment clock, by using ESMC protocol data units.

    • PTP support—Precision Time Protocol (PTP), also known as IEEE 1588v2, is a packet-based technology that enables the operator to deliver synchronization services on packet-based mobile backhaul networks. IEEE 1588 PTP (Version 2) clock synchronization standard is a highly precise protocol for time synchronization that synchronizes clocks in a distributed system. The time synchronization is achieved through packets that are transmitted and received in a session between a master clock and a slave clock. One-step clock mode operation for the master clock is supported.

    • BITS (T1/E1) Interface support—BITS support for input and output on T1/E1 framed and 2.048MHz unframed clock input.

    • GPS external clock interface and TOD support—GPS input and output support for 1 MHz/5 MHz/10 MHz and PPS signal

  • Support for importing IGP topology information into BGP-LS (MX Series)—Starting in Junos OS Release 17.4R1, you can import interior gateway protocol (IGP) topology information into BGP-Link State (BGP-LS) in addition to RSVP-traffic engineering (RSVP-TE) topology information through the lsdist.0 routing table. This allows you to monitor both IGP and traffic engineering topology information.

    To install IGP topology information into the traffic engineering database, use the set igp-topology configuration statement at the [edit protocols isis traffic-engineering] and [edit protocols ospf traffic-engineering] hierarchy levels. To import IGP topology information into BGP-LS from lsdist.0, use the set bgp-ls configuration statement at the [edit protocols mpls traffic-engineering database import igp-topology] hierarchy level.

    [See Link-State Distribution Using BGP Overview.]

  • BGP supports segment routing policy for traffic engineering (MX Series)—Starting in Junos OS Release 17.4R1, a BGP speaker supports traffic steering based on a segment routing policy at ingress routers. The controller can specify a segment routing policy consisting of multiple paths to steer labeled or IP traffic. The segment routing policy adds an ordered list of segments to the header of a packet for traffic steering. Static policies can be configured at ingress routers to allow routing of traffic even when the link to the controller fails.

    To enable BGP IPv4 segment routing traffic engineering capability for an address family, include the segment-routing-te statement at the [edit protocols bgp family inet] hierarchy level.

    [See Understanding Ingress Peer Traffic Engineering for BGP SPRING.]

  • Support for EVPN control plane with VXLAN data plane encapsulation (MX150)—Starting in Junos OS Release 17.4R1, MX150 routers, powered with vMX, decouples an underlay network from the tenant overlay network with VXLAN. By using a Layer 3 IP-based underlay coupled with a VXLAN-EVPN overlay, you can deploy larger networks than those possible with traditional Layer 2-based networks. With overlays, end-points (servers and virtual machines) can be placed anywhere in the network and remain connected to the same logical Layer 2 network. One of the key benefits is that virtual topology can be decoupled from the physical topology.

  • Support for Layer 2 VXLAN gateway (MX150)—Starting in Junos OS Release 17.4R1, MX150 routers, powered with vMX, that support a Virtual Extensible LAN (VXLAN) can function as a hardware virtual tunnel endpoint (VTEP ). In this role, the Juniper Networks device encapsulates in VXLAN packets Layer 2 Ethernet frames received from software applications that run directly on a physical server. The VXLAN packets are tunneled over a Layer 3 fabric. Upon receipt of the VXLAN packets, software VTEPs in the virtual network de-encapsulate the packets and forward the packets to virtual machines (VMs).

  • Support for BGP advertising aggregate bandwidth across external BGP links for load balancing (MX Series)—Starting in Junos OS Release 17.4R1, BGP uses a new link bandwidth extended community, aggregate-bandwidth, to advertise aggregated bandwidth of multipath routes across external links. BGP calculates the aggregate of multipaths that have unequal bandwidth allocation and advertises the aggregated bandwidth to external BGP peers. A threshold to the aggregate bandwidth can be configured to restrict the bandwidth usage of a BGP group. In earlier Junos OS releases, a BGP speaker receiving multipaths from its internal peers advertised the link bandwidth associated with the active route. To advertise aggregated bandwidth of multipath routes and to set a maximum threshold, configure a policy with aggregate-bandwidth and limit bandwidth actions at the [edit policy-options policy-statement name then] hierarchy level.

    [See Advertising Aggregate Bandwidth Across External BGP Links for Load Balancing Overview.]

  • Topology-independent loop-free alternate for IS-IS (MX Series)—Starting in Junos OS Release 17.4R1, topology-independent loop-free alternate (TI-LFA) with segment routing provides MPLS fast reroute (FRR) backup paths corresponding to the post-convergence path for a given failure. You can enable TI-LFA for IS-IS by configuring the use-post-convergence-lfa statement at the [edit protocols isis backup-spf-options] hierarchy level. TI-LFA provides protection against link failure, node failure, and failures of fate-sharing groups.

    You can enable the creation of post-convergence backup paths for a given interface by configuring the post-convergence-lfa statement at the [edit protocols isis interface interface-name level level] hierarchy level. The post-convergence-lfa statement enables link-protection mode.

    You can enable node-protection and/or fate-sharing-protection mode for a given interface at the [edit protocols isis interface interface-name level level post-convergence-lfa] hierarchy level. To use a particular fate-sharing group as a constraint for the fate-sharing-aware post-convergence path, you need to configure the use-for-post-convergence-lfa statement at the [edit routing-options fate-sharing group group-name] hierarchy level.

    [See Understanding Topology-Independent Loop-Free Alternate with Segment Routing for IS-IS.]

  • Support for trace route through an interface through the inactive routes (MX Series)—Starting in Junos OS Release 17.4R1, you can configure traceroute to send out packets through an inactive next hop by specifying the traceroute next-hop address to a destination through an inactive next hop.

    [See Traceroute for Inactive Interface.]

  • Support for network instance based BGP configuration (MX Series)—Starting in Junos OS Release 17.4R1, you can configure BGP in a specific network instance. After the network instance is configured, you will be prompted with options for BGP configuration such as global bgp, neighbor bgp, and so on. See Mapping OpenConfig Network Instance Commands to Junos Operation.

  • Support for EBGP route server (MX Series)—Starting in Junos OS Release 17.4R1, BGP feature is enhanced to support EBGP route server functionality. A BGP route server is the external BGP (EBGP) equivalent of an internal IBGP (IBGP) route reflector that simplifies the number of direct point-to-point EBGP sessions required in a network. EBGP route server propagates unmodified BGP routing information between external BGP peers to facilitate high scale exchange of routes in peering points such as Internet Exchange Points (IXPs). When BGP is configured as a route server, EBGP routes are propagated between peers unmodified, with full attribute transparency (NEXT_HOP, AS_PATH, MULTI_EXIT_DISC, AIGP, and Communities).

    The BGP JET bgp_route_service.proto API has been enhanced to support route server functionality as follows:

    • Program the EBGP route server.

    • Inject routes to the specific route server RIB for selectively advertising it to the client groups in client-specific RIBs.

    The BGP JET bgp_route_service.proto API includes a peer-type object that identifies individual routes as either EBGP or IBGP (default).

    [See BGP Route Server Overview.]

Services Applications

  • Inline video monitoring for IPv4-over-MPLS flows on M10003 and MX204 routers—Starting in Junos OS Release 17.4R1, MX10003 and MX204 routers support the inline video monitoring of IPv4-over-MPLS flows to measure media delivery index (MDI) metrics. MDI information enables you to identify devices that are causing excessive jitter or packet loss for streaming video applications.

    [See Configuring Inline Video Monitoring]

  • Port Control Protocol support (MX Series routers with MS-MPCs and MS-MICs)—Starting in Junos OS Release 17.4R1, the Port Control Protocol (PCP) feature is supported on MS-MPCs and MS-MICs. Before Junos OS Release 17.4R1, PCP was supported only on MS-DPC service cards. PCP provides a mechanism to control the forwarding of incoming packets by upstream devices such as NAT44 and firewall devices, and a mechanism to reduce application keepalive traffic. Use PCP in the context of both carrier-grade NATs and small NATs (for example, residential NATs). PCP allows hosts to operate servers for a long time (for example, a webcam) or a short time (for example, while playing a game or on a phone call) when behind a NAT device, including when behind a carrier-grade NAT operated by their Internet service provider. PCP allows applications to create mappings from an external IP address and port to an internal IP address and port.

    PCP on the MS-MPC and MS-MIC supports only NAPT44. PCP with DS-Lite is not supported on the MS-MPC and MS-MIC.

    [See Port Control Protocol Overview, Configuring Port Control Protocol, and Example: Configuring Port Control Protocol with NAPT44.]

  • Increased sampling rate for inline Junos Traffic Vision (MX Series)—Starting in Junos OS Release 17.4R1, the sampling rate that you can configure for inline Junos Traffic Vision (inline active flow monitoring) using the rate number statement at the [edit forwarding-options sampling instance instance-name family (inet |inet6)] and [edit forwarding-options sampling input] hierarchy levels is increased from 65,535 to 16,000,000. This functionality is supported for Inline Active Flow Monitoring on MX Series and vMX routers. This feature is also supported for PIC-based flow monitoring on MX Series routers with certain MPCs. If a line card does not support a sampling rate higher than 65,535, such as an I-chip-based DPC, the maximum sampling rate is limited to 65,535.

    [See Example: Configuring Flow Monitoring on MS-MIC and MS-MPC.]

  • Support for Diffie-Hellman group15, group16, and group24 for IKE SAs and IPsec policies (MX Series)—Starting in Junos OS Release 17.4R1, Diffie-Hellman group15, group16, and group24 for IKE security associations (SAs) and IPsec policies are supported.

    [See Configuring IKE Proposals and Configuring IPsec Policies.]

  • Port forwarding (MX Series routers with MS-MPCs and MS-MICs)—Starting in Junos OS Release 17.4R1, support for port forwarding is extended to the MS-MPC and MS-MIC. Port forwarding allows the destination address and port of a packet to be changed to reach the correct host in a Network Address Translation (NAT) gateway. The translation facilitates reaching a host within a masqueraded, typically private, network based on the port number on which the packet was received from the originating host. Port forwarding allows remote computers, such as public machines on the Internet, to connect to a nonstandard port (port other than 80) of a specific computer within a private network. An example of this type of destination is the host of a public HTTP server within a private network. You can also configure port forwarding without translating a destination address.

    [See Port Forwarding Overview.]

  • Support for 100,000 simultaneous RPM probes from RPM clients for offload RPM (MX Series)—Starting in Junos OS Release 17.4R1, you can enable the application of optimized CLI configuration in the offload-RPM scale configuration and the existing legacy RPM clients supported on MS-MIC and MS-MPC by entering the rpm-scale statement at the [edit services rpm probe probe-owner] hierarchy level and at the [edit groups group-name services rpm] hierarchy level.

    [See Configuring RPM Probes.]

  • Support for CoS revert and direction awareness on services interfaces (MX Series routers with MS-MPCs and MS-MICs)—Starting in Junos OS Release 17.4R1, you can configure a services interface CoS rule to store the DSCP and forwarding class of a packet that is received in the match direction of the rule; this stored DSCP and forwarding class are then applied to packets that are received in the reverse direction of the same session. You can also configure a service set to create a CoS session when a packet is first received in the wrong match direction for a CoS rule; this results in the CoS rule values being applied as soon as a packet in the correct match direction is received.

    [See Configuring CoS Rules.]

  • DS-Lite support on MS-MPCs and MS-MICs (MX Series routers)—Starting in Junos OS Release 17.4R1, the MS-MPC and MS-MIC support dual-stack lite (DS-Lite). DS-Lite employs IPv4-over-IPv6 tunnels to cross an IPv6 access network to reach a carrier-grade IPv4-IPv4 NAT. This facilitates the phased introduction of IPv6 on the Internet by providing backward compatibility with IPv4.

    Prior to Junos OS Release 17.4R1, DS-Lite was supported on the MX Series only on MS-DPCs.

    DS-Lite running on MS-MPCs or MS-MICs does not support the following features, which are supported on MS-DPCs:

    • ALGs

    • Limitations per subnet

    • Clearing NAT mappings and flows for a specific subscriber, for a basic bridging broadband device (B4), or for a specific service set

    • Port Control Protocol

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

  • IPsec NAT-T Support (MX Series)—Starting in Junos OS Release 17.4R1, NAT-T is supported for IKEv1 and IKEv2. Junos OS Release 17.4R1 also supports UDP encapsulation and decapsulation for IKE and ESP packets by specifying disable-natt at the [edit services ipsec-vpn] hierarchy levels. NAT-T is enabled by default.

    [See disable-natt (Services IPsec VPN).]

  • Multiple syslog servers support (MX Series routers with MS-MPCs and MS-MICs)—Starting in Junos OS Release 17.4R1, you can commit multiple syslog hosts (up to four) under the [edit services service-set service-set-name] hierarchy level.

    [See Configuring System Logging for Service Sets.]

  • Support for inline NAT and FlowTapLite on MPC7E, MPC8E, and MPC9E (MX Series)—Starting in Junos OS Release 17.4R1, you can configure inline NAT and FlowTapLite on the following Modular Port Concentrators: MPC7E, MPC8E, and MPC9E.

    [See Inline Network Address Translation Overview for MPCs and Configuring FlowTapLite.]

  • Support for NAT64 with deterministic IP address and port mapping (MX Series routers with MS-MPCs and MS-MICs)—Starting in Junos OS Release 17.4R1, there is support for deterministic NAT64 mapping on the MS-MPC and MS-MIC. Deterministic NAT mapping ensures that a given internal IP address and port are always mapped to the same external IP address and port range, and the reverse mapping of a given translated external IP address and port are always mapped to the same internal IP address. Deterministic NAT mapping eliminates the need for logging address translations.

    [See Configuring Deterministic NAPT.]

  • Support for inline video monitoring for IPv6 flows (MX Series)—Starting in Junos OS Release 17.4R1, MX Series routers support the inline video monitoring of IPv6 flows and IPv6-over-MPLS flows to measure media delivery index (MDI) metrics. MDI information enables you to identify devices that are causing excessive jitter or packet loss for streaming video applications.

    [See Configuring Inline Video Monitoring.]

  • Support for disabling the filtering of HTTP traffic with an embedded IP address belonging to a blacklisted domain (MX Series)—Starting in Junos OS Release 17.4R1, you can disable the filtering of HTTP traffic that contains an embedded IP address (for example, http:/10.1.1.1) belonging to a blacklisted domain name in the URL filter database. To disable the filtering, include the disable-url-filtering statement at the [edit services url-filter profile profile-name template template-name] hierarchy level when you are configuring URL filtering. However, if the embedded IP address is explicitly identified in the blacklisted URL filter database, then the traffic is still filtered.

    [See Configuring URL Filtering.]

Software Defined Networking (SDN)

  • Support for YANG-based abstraction to orchestrate GNFs (MX480, MX960, MX2010, MX2020)—Starting with Junos OS Release 17.4R1, Junos supports YANG-based abstraction to orchestrate guest network functions (GNFs), using single touchpoint. In the single touchpoint method, the SDN controller (for example, OpenDaylight or ODL) communicates only with the base system (BSYS). The BSYS receives the RPC requests from the ODL controller, parses the RPC, and then forwards the adequate RPC to the JDM (based on scripts available at the BSYS). After receiving the response from the JDM, the BSYS parses and forwards the response back to the ODL.

    Note

    Junos Node Slicing also supports management of GNF life cycle using the dual touchpoint method. In this method, ODL sends RPCs to, and receive responses from, JDM and BSYS separately. To enable dual touch point, you just need to mount both BSYS and Juniper Device Manager (JDM) on ODL.

    [See Setting Up YANG-Based Abstraction to Orchestrate GNFs.]

  • Unified ISSU support for Junos Node Slicing (MX480, MX960, MX2010, MX2020)—Starting with Junos OS Release 17.4R1, Junos Node Slicing supports unified ISSU. ISSU enables you to upgrade between two different Junos OS releases with no disruption on the control plane and with minimal disruption of traffic. Now, users with administrator rights can perform unified ISSU on the BSYS, (the base system in a Junos Node Slicing setup) and the guest network functions (GNF) separately. Also, users can run unified ISSU on each GNF independently, without affecting other GNFs.

    Note

    The multi-version software support limitations (such as version difference limits) are also applicable to unified ISSU upgrade.

    [See Understanding the Unified ISSU Process.]

  • Multi-Version software support for Junos Node Slicing (MX480, MX960, MX2010, MX2020)—Starting from Junos OS Release 17.4R1, Junos Node Slicing supports multi-version software compatibility, enabling the BSYS to interoperate with a guest network function (GNF), which runs a Junos OS version that is higher than the software version on the BSYS. This feature supports a deviation of up to two versions between GNF and BSYS. That is, the GNF software can be up to two versions higher than the BSYS software. However, for this feature to work, both BSYS and GNF must meet a minimum version requirement of Junos OS Release 17.4R1.

    Note

    The multi-version software compatibility support is limited to major releases only.

    [See Understanding Multi-Version Software Compatibility.]

  • Improved debugging ability and serviceability for JDM (MX480, MX960, MX2010, MX2020)—Starting with Junos OS release 17.4R1, improved debugging ability and serviceability are provided for Juniper Device Manager (JDM). The following are the key capabilities supported:

    • JDM-JDM keepalive to monitor reachability of the peer JDM, and to provide failover in case one of the JDM instances (running on server 0 and server 1) goes down.

    • A new force option under the CLI command request virtual-network-functions to overwrite a VNF image. Example: request virtual-network-functions vnf-name add-image image-name force

    • New CLI command, show version vnf vnf-name, to show the version details of the guest network functions (GNFs).

    • Dedicated interfaces for JDM and VNF management.

    Configuring JDM on the x86 Servers

  • Abstracted Fabric interface for Junos Node Slicing (MX480, MX960, MX2010, MX2020)—Starting with Junos OS Release 17.4R1, Junos Node Slicing supports Abstracted Fabric (AF) interface, a pseudointerface that represents the behavior of a first class Ethernet interface. An AF interface is created on a GNF to enable it to communicate with the peer GNF when the two GNFs are configured to be connected to each other. The AF interface facilitates routing control and management traffic between GNFs. You can create or delete AF interface from the BSYS. AF interfaces support the following protocol families: inet, inet6, mpls, ccc, and iso.

    Note

    Most of the Layer 1 features and a few of the Layer 2 and Layer 3 features are disabled on AF interfaces.

    [See Abstracted Fabric Interface]

  • Software Support for Junos Node Slicing (MX480, MX960, MX2010, MX2020)—Starting from Junos OS Release 17.4R1, Junos Node Slicing supports the following software features:

    • BNG

    • Business PE router

    • L2VPN or EVPN PE router

    • Multicast

    • Junos Telemetry Interface—An MX Series router in the BSYS mode provides full-fledged JTI support. However, guest network functions (GNFs) provide limited support for JTI (only physical and logical interfaces statistics for FPCs owned by GNFs are available through gRPC).

  • Support for OpenDaylight (ODL) controller on MX Series routers—Starting with Junos OS Release 17.4R1, MX Series routers support OpenDaylight (ODL) controller (Carbon release). The ODL controller, or ODL platform, provides a southbound Network Configuration Protocol (NETCONF) connector API, which uses NETCONF and YANG models to interact with a network device. You can use the ODL controller to carry out configuration changes in MX Series routers, and orchestrate and provision the routers. Also, ODL controller enables you to execute Remote Procedure Calls (RPCs) to MX Series routers to get state information.

    [See Configuring Interoperability Between MX Series Routers and OpenDaylight

Software Installation and Upgrade

  • Support for unified ISSU on MX Series routers with MPC7E-MRATE, MPC7E-10G, MX2K-MPC8E, and MX2K-MPC9E (MX240, MX480, MX960, MX2010, and MX2020)—Starting with Release 17.4R1, Junos OS supports unified in-service software upgrade (ISSU) on MX Series routers with MPC7E-MRATE, MPC7E-10G, MX2K-MPC8E, and MX2K-MPC9E.

    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 Getting Started with Unified In-Service Software Upgrade]

  • Support for Zero Touch Provisioning (ZTP) (MX150)—Starting in Junos OS Release 17.4R1, MX150 routers, powered with vMX, support zero touch provisioning. Zero touch provisioning enables 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. When you physically connect the MX150 router to the network and boot it with a default configuration, it attempts to upgrade the Junos OS Software automatically using information detected on the DHCP server. If you do not configure the DHCP server to provide this information, the MX150 router boots with the pre-installed software and default configuration.

  • Support for unified ISSU on the CFP2-DCO-T-WDM-1 transceiver (MX Series)—Starting in Junos OS Release 17.4R1, unified in-service software upgrade (unified ISSU) is supported on the CFP2-DCO-T-WDM-1 transceiver when the transceiver is installed on the MPC5E-100G10G MPC or the MIC6-100G-CFP2 MIC (installed on the MX2K-MPC6E MPC).

    [See Getting Started with Unified In-Service Software Upgrade.]

Subscriber Management and Services

  • Support for static subscriber daemon gaps for Gx/Gy support (MX Series)—Starting in Junos OS Release 17.4R1, support for usage based billing are added using the Gy interface for static subscribers. The service-profile is added to the static-subscribers to apply services for all static subscribers at the hierarchy level [edit system services static-subscribers group group-name].

    [See Subscribers on Static Interfaces Overview.]

  • DHCP session liveness detection based on ARP and neighbor discovery packets (MX Series)—Starting in Junos OS Release 17.4R1, you can configure bidirectional Layer 2 liveness detection for directly connected DHCPv4 and DHCPv6 subscribers using ARP packets for v4 and neighbor discovery (ND) packets for v6. You can configure Layer 2 liveness detection for both DHCP local server and DHCP relay clients. This method of liveness detection enables the host and the broadband network gateway (BNG) separately to determine the validity and state of the DHCP client session and to clean up inactive sessions. The liveness detection send functionality enables the BNG to determine client session state based on the host response to request packets the BNG sends at a configurable interval. The liveness detection receive functionality enables the client host to determine session state based on the BNG response to ARP or ND packets sent by the client to the BNG.

    Layer 2 liveness detection (AR/ND) and Bidirectional Forwarding Detection (BFD) are mutually exclusive.

    [See DHCP Liveness Detection Overview.]

  • RADIUS-sourced DHCPv4 and DHCPv6 Options support for single and dual-stack sessions (MX Series)—Starting in Junos OS Release 17.4R1, for DHCP dual-stack session subscribers, the DHCPv4 option values are saved in the SDB_DHCP_OPTIONS session database (SDB) attribute. Likewise, for DHCPv6 subscribers, option values are saved in the SDB_DHCPV6_OPTIONS SDB attribute. However, for single-stack sessions (DHCP or DHCPv6), the DHCP option values for both IPv4 and IPv6 subscribers will be saved in SDB_DHCP_OPTIONS SDB attribute.

    For both single and dual-stack sessions, DHCPv4 header is saved in the SDB_DHCP_HEADER and DHCPv6 header in the SDB_DHCPV6_HEADER SDB attributes.

    The option values and header values received in DHCPv4 discover and DHCPv6 solicit messages are stored in respective SDBs and thus get populated in the new vendor specific attributes (VSAs). These VSAs are then sent to RADIUS server for authentication. The RADIUS server decodes the options, authenticates the client, and sends the RADIUS-sourced DHCP options back to the DHCP server. The DHCP server copies the RADIUS-sourced DHCP options, and also adds the DHCP server-sourced options to the packet and sends the response back to the client.

    [See Dedicated Session Database and Vendor-Specific Attributes for DHCPv4 and DHCPv6 Subscribers Overview.]

  • Appending subscriber information to redirect URLs (MX Series)—Starting in Junos OS Release 17.4R1, you can append information about the subscriber retrieved from the subscriber session database when the redirect URL is returned to the HTTP client. You can configure the attributes at the [edit services captive-portal-content-delivery] hierarchy. Only the following attributes are supported: subscriber IP or IPv6 address, NAS IP address, requested URL, NAS port ID, MAC address, subscriber session ID, and username.

    Note

    This feature is already supported for Routing Engine based and Multiservices Modular PIC Concentrator (MS-MPC) based converged captive-portal-content-delivery (CPCD). From 17.4R1 onward, it is supported for Routing Engine based and MS-MPC based static CPCD.

    [See HTTP Redirect Service Overview.]

  • Enhancements to share CPE parameters between broadband network gateway (BNG) and RADIUS server (MX Series)—Starting in Junos OS Release 17.4R1, the following enhancements are made to facilitate better communication between the broadband network gateway (BNG) and the RADIUS server:

    • CPE parameters such as DHCPv4 (VSA 26-208) and DHCPv6 (VSA 26-209) packet headers are shared between the broadband network gateway (BNG) and the RADIUS server.

    • A new VSA 26-207 is introduced that facilitates the exchange of DHCPv6 options with the RADIUS server, thereby ensuring that VSA 26-55 is dedicated to the exchange of DHCPv4 options.

    • A new statement, family-state-change-immediate-update. When configured at the [edit access profile] hierarchy level, the DHCP (both DHCPv4 and DHCPv6) server sends an immediate interim accounting report to the RADIUS server when the second family (IPv4 or IPv6) is activated or the first family gets deactivated.

    • A new VSA 26-210 is added to convey the reason for the accounting-request message in the start and interim accounting request packets sent to the RADIUS server. This helps the RADIUS server to determine the reason of the start and interim accounting that is being sent.

    [See Exchange of DHCPv4 and DHCPv6 Parameters with the RADIUS Server Overview.]

  • Virtual broadband network gateway support (MX150)—Starting in Junos OS Release 17.4R1, MX150 routers, powered with vMX, support most of the subscriber management features available with Junos OS Release 17.4 on vMX to provide a virtual broadband network gateway on MX150 routers. vBNG runs on vMX, so it has similar exceptions; the following subscriber management features available on vMX 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 the following vBNG license:

    • vBNG subscriber scale license for one of these tiers: Introductory, Preferred, or Elite.

  • Support for Broadband Edge on MX204 router—Starting in Junos OS Release 17.4R1, MX204 supports the next-generation broadband edge software architecture for wireline subscriber management. With enhanced subscriber management, you can take advantage of optimized scaling and performance for configuration and management of dynamic interfaces and services for subscriber management.

  • New criteria introduced for when to throttle logins based on CoS queues (MX Series)—Starting in Junos OS Release 17.4R1, new criteria are incorporated into the throttling decision for subscriber access. CoS resources (queues) are taken into account when deciding whether to avoid accepting new subscriber logins when there are insufficient CoS resources. To support this behavior, a new CLI configuration statement (high-cos-queue-threshold) is introduced to enable usage of CoS resource monitoring in throttling decisions and to set the threshold of CoS resource usage above which new logins are not permitted. A new show command (show system resource-monitor ifd-cos-queue-mapping fpc) is also introduced.

  • Improved multicast performance with distributed IGMP (MX Series)—Starting in Junos OS Release 17.4R1, both dynamic and static interfaces support distributed Internet Group Management Protocol (IGMP). Distributed IGMP moves IGMP processing from the Routing Engine and distributes it across multiple Modular Port Concentrators (MPCs) on the Packet Forwarding Engine for improved performance and decreases join and leave latency.

    To enable distributed IGMP on static interfaces, include the distributed statement at the [edit protocols igmp interface interface-name] hierarchy level.

    To enable it on dynamic interfaces, include the distributed statement at the [edit dynamic-profiles profile-name protocols igmp interface $junos-interface-name] hierarchy level.

    You must also enable enhanced IP networking services at the [edit chassis network-services enhanced-ip] hierarchy level.

    You can optionally configure specific multicast groups to join statically by including the distributed option at one of the following hierarchy levels:

    • [edit protocols pim static]

    • [edit protocols pim static group multicast-group-address]

    • [edit protocols pim static group multicast-group-address source source-address]

    [See Understanding Distributed IGMP .]

  • Support for expanded traffic rate adjustment for DSL access lines (MX Series)—Starting in Junos OS Release 17.4R1, the traffic rate adjustment feature is expanded to support PPPoE intermediate agent (PPPoE-IA) tags by processing the Vendor-Specific-Tags TLV in PADI and PADO packets received from the access node. Now both PPPoE subscriber connections (terminated and tunneled) and ANCP-triggered Layer 2 wholesale service connections are subject to the same class and quality-of-service management transformations.

    Configuration for traffic rate adjustment and reporting for both AAA and CoS is moved to the new [edit system access-line] hierarchy level. In earlier releases, DSL line traffic rate adjustment is available only for the ANCP agent and uses statements at the [edit protocols ancp] and [edit protocols ancp qos-adjust] hierarchy levels.

    [See Traffic Rate Reporting and Adjustment by the ANCP Agent and Setting a Global Adjustment Factor per DSL Subscriber Line for ANCP Agent-Reported Traffic Rates.]

  • Displaying accurate subscriber accounting statistics (MX Series)—Starting in Junos OS Release 17.4R1, you can enable the router to display accurate subscriber accounting statistics for dynamic interfaces by including the actual-transit-statistics statement in the dynamic profile that creates the interface. The aggregate statistics counters show the subscriber traffic bytes and packets arriving on and leaving from the interface; these are the same traffic values reported to RADIUS. The counters exclude overhead byte adjustments, dropped or discarded packets, and control packets. When enabled, use the show subscribers id accounting-statistics command to display counts for the specified subscriber session and the show subscribers interface accounting-statistics command to display counts for all subscriber sessions on the specified interface.

    [See Enabling the Reporting of Accurate Subscriber Accounting Statistics to the CLI.]

  • Automatic 64-bit mode and maximum configuration database size (MX Series)—Starting in Junos OS Release 17.4R1, when enhanced IP network services and enhanced subscriber management are enabled and a Routing Engine in the system has at least 32 GB of RAM, subscriber management daemons on that Routing Engine run in 64-bit mode. For consistent operation, all Routing Engines in the system must have the same amount of memory.

    [See Configuring Junos OS Enhanced Subscriber Management.]

  • DSL line attributes support for L2TP LNS (MX Series)—Starting in Junos OS Release 17.4R1, an MX Series router configured as an LNS can process subscriber access line information that it receives from the LAC. This information includes access line attributes conveyed in ICRQ messages, initial Tx/Rx connect speeds (AVP 24/38) in ICCN messages, and connect speed updates in CSUN messages. The rate information enables CoS shaping on the subscriber session to be more accurate, but updates are subject to CoS adjustment control profiles. You can configure processing for information received from all LACs, or for only LACs you specify by address.

    [See Subscriber Access Line Information Handling by the LAC and LNS Overview.]

  • Enhancement to Gx-Plus Application (MX Series)—Starting in Junos OS Release 17.4R1, the following enhancements to the Gx-Plus client application on the BNG are available:

    • When a monitored service is deactivated separate from a subscriber logout, the CCR-U indicates that the service is no longer active and includes the service’s usage data.

    • The router updates the monitoring key and threshold values when they are received in a RAR message from the PCRF.

    • A CCR-U is sent to the PCRF after the router sends an RAA message in response to an RAR message that requests service activations or deactivations.

    • When the PCRF returns threshold values that are lower than the current values, the new threshold becomes the sum of the current value and the returned value.

    • The PCEF has default minimum threshold values. If the change between the current value and the value returned by the PCRF is less than the minimum value, then the new value is adjusted to the minimum.

    • The CCR-I message includes the Diameter AVP Subscription-Id attribute (443) with the Subscription-Id-Type Diameter AVP sub-attribute (450) set to 4 (END_USER_PRIVATE) and the Subscription-Id-Data Diameter AVP sub-attribute (444) set to reserved.

    [See Understanding Gx-Plus Interactions Between the Router and the PCRF and Messages Used by Diameter Applications.]

  • RADIUS attributes added to LNS messages (MX Series)—Starting in Junos OS Release 17.4R1, the LNS includes the following RADIUS attributes when it sends an Access-Request message to the RADIUS server:

    • Tunnel-Type (64)

    • Tunnel-Medium-Type (65)

    • Tunnel-Client-Endpoint (66)

    • Tunnel-Server-Endpoint (67)

    • Acct-Tunnel-Connection (68)

    • Tunnel-Assignment-Id (82)

    • Tunnel-Client-Auth-Id (90)

    • Tunnel-Server-Auth-Id (91)

System Logging

    • Debugging firewall ukern-trace log toggle persisting across FPC reboot (MX Series)—Starting in Junos OS Release 17.4R1, you can enable or disable ukern-trace logging for the debugging firewall (DFW) on a specific FPC slot by using the set chassis fpc slot ukern-trace log app-type dfw logging (off | on) command. The new logging value of each DFW log takes effect immediately and persists if the FPC slot reboots.

      [See ukern-trace]

User interface and Configuration

  • Monitoring, detecting, and taking action on degraded physical 10-Gigabit, 40-Gigabit, and 100-Gigabit Ethernet links to minimize packet loss (MX Series routers with MPC5E, MPC6E, and 2x10GE MIC on MPC3E)—Starting with Junos OS Release 17.4R1, you can monitor physical link degradation (indicated by bit error rate (BER) threshold levels) on Ethernet interfaces, and take corrective actions if the BER threshold value drops to a value in the range of 10-13 to 10-5.

    Layer 2 and Layer 3 protocols support the monitoring of physical link degradation. An Ethernet link also supports monitoring of physical link degradation through the Link Fault Signaling (LFS) protocol. However, for both of these monitoring mechanisms, the BER threshold value range of 10-13 to 10-5 is very low. Because of the low BER threshold value, the physical link degradation goes undetected, causing disruption and packet loss on an Ethernet link.

    The following new configurations have been introduced at the [edit interfaces interface-name] hierarchy level to support the physical link degrade monitoring and recovery feature on 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 must be triggered on or cleared from an interface, use the link-degrade-monitor thresholds (set value | clear value) statement.

      The supported exponent range is 1 through 16, and the default value is 7 for the set configuration and 12 for the clear configuration.

    • To configure the link degrade interval value, use the link-degrade-monitor thresholds interval value statement. The configured interval value determines the number of consecutive link degrade events that are considered before any corrective action is taken.

    • To configure link degrade warning thresholds, use the link-degrade-monitor thresholds (warning-set value | warning-clear value) statement.

    • To configure the link degrade action that is taken when the configured BER threshold level is reached, use the link-degrade action media-based statement.

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

    You can view the link recovery status and the BER threshold values by using the show interfaces interface-name command.

VPNs

  • Support of BGP signaling for next-hop-based dynamic tunnels (MX Series)—Starting in Junos OS Release 17.4R1, the next-hop-based dynamic GRE and UDP tunnels are signaled using BGP encapsulation extended community. BGP export policy is used to specify the tunnel types, advertise the sender side tunnel information, and parse and convey the receiver side tunnel information. A tunnel is created according to the received type tunnel community.

    Multiple tunnel encapsulations are supported by BGP. On receiving multiple capability, the next-hop-based dynamic tunnel is created based on the configured BGP policy and tunnel preference. The tunnel preference should be consistent across both the tunnel ends for the tunnel to be set up, and by default, MPLS-over-UDP (MPLSoUDP) tunnel is preferred over GRE tunnels.

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