Junos OS Release Notes for PTX Series Packet Transport Routers

 

These release notes accompany Junos OS Release 17.4R2 for the PTX Series. They describe new and changed features, limitations, and known and resolved problems in the hardware and software.

You can also find these release notes on the Juniper Networks Junos OS Documentation webpage, located at https://www.juniper.net/documentation/product/en_US/junos-os.

New and Changed Features

This section describes the new features and enhancements to existing features in Junos OS Release 17.4R2 for the PTX Series.

Release 17.4R2 New and Changed Features

There are no new features or enhancements to existing features for PTX Series in Junos OS Release 17.4R2.

Release 17.4R1 New and Changed Features

Hardware

  • PTX10016 Packet Transport Router—Starting in Junos OS Release 17.4R1, the PTX10016 Packet Transport Router provides 3.0 Tbps per slot forwarding capacity for the service providers and cloud operators. The router provides an opportunity for the cloud, telco, and data center operators for a smooth transition from 10-Gigabit Ethernet and 40-Gigabit networks to 100-Gigabit Ethernet high-performance networks. This high-performance, 21 rack unit (21RU) modular chassis provides 48 Tbps of throughput and 32 Bpps of forwarding capacity. The PTX10016 router has 16 slots for the line cards that can support a maximum of 2304 10-Gigabit Ethernet ports, 576 40-Gigabit Ethernet ports, or 480 100-Gigabit Ethernet ports.

    You can deploy the PTX10016 router in the core of the network for the following functions:

    • Label switching routing

    • IP core routing

    • Internet peering

    PTX10016 Packet Transport Router supports two PTX10K line cards, LC1101 and LC1102. The LC1101 line card consists of thirty QSFP+ Pluggable Solution (QSFP28) cages that support 40-Gigabit Ethernet or 100-Gigabit Ethernet optical transceivers. The line card supports speed of either 40-Gbps or 100-Gbps. It also supports 10-Gigabit Ethernet by channelizing the 40-Gigabit Ethernet ports. The default port speed is 100-Gbps. The default port speed is 100-Gbps. If the user plugs in 40Gigabit or 4x10Gigabit optic, the appropriate port speed has to be configured manually.

    The LC1102 line card consists of 36 quad small form-factor pluggable plus (QSFP+) ports that support 40-Gigabit Ethernet optical transceivers. The QSFP+ ports support 40-Gigabit or 100-Gigabit Ethernet optical transceivers in selected ports. The default port speed on the LC1102 line card is channelized 10-Gbps. Out of these 36 ports, 12 ports are QSFP28 capable for supporting 100-Gigabit Ethernet. The line card supports 10-Gigabit Ethernet by channelizing the 40-Gigabit ports. Channelization is supported on fiber breakout cable using standard structured cabling techniques.

    For more information, see PTX10016 Packet Transport Router Hardware Guide .

  • Support for the CFP2-DCO-T-WDM-1 transceiver on the P2-100GE-OTN PIC (PTX)—Starting in Junos OS Release 17.4R1, you can install the CFP2-DCO-T-WDM-1 transceiver on the P2-100GE-OTN PIC. 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 Standardization(ITU-T) OTN performance monitoring and alarm management

    • 100-Gigabit Ethernet 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 100-Gigabit Ethernet OTN PIC with CFP2 (PTX Series) .]

High Availability (HA) and Resiliency

  • Resiliency Support for PTX10K-LC1101 and PTX10K-LC1102 (PTX10016)—Starting with Junos OS Release 17.4R1, resiliency support is enabled for the following components:

    • PTX10K-LC1101 and PTX10K-LC1102

    • Routing and Control Boards

    • Switch Interface Boards

Interfaces and Chassis

  • Fabric Management Support (PTX100016)—Starting in Junos OS Release 17.4R1, you can set up and manage the fabric connections between the Packet Forwarding Engines in the PTX100016 routers. Fabric management includes collecting fabric status and statistics, monitoring health of the hardware, and responding to CLI queries. It also tracks addition and removal of FRUs from the router and monitors faults in the data plane. It is enabled by default and can be monitored by using the following commands:

    • show chassis fabric summary

    • show chassis fabric fpcs fpc fpc-slot

    • show chassis fabric sibs

    • show chassis fabric errors

    • show chassis fabric reachability

    [See Fabric Management Overview.]

  • Support for large-scale packet-forwarding features (PTX10000)—Starting with Junos OS Release 17.4R1, PTX10000 router supports large scaling IPv4 and IPv6 forwarding information base (FIB). A maximum of 4 million routes are supported.

  • Support for pre-FEC BER monitoring when using the CFP2-DCO-T-WDM-1 transceiver (PTX 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.]

  • Support for a 16 Slot Chassis (PTX10016)—Starting with Junos OS Release 17.4R1, the PTX10016 has 16 slots and supports core and edge profiles.

IPv6

  • Support for IPv6 statistics on PTX Series routers—Starting in Junos OS Release 17.4R1, you can obtain the transit IPv6 statistics at both the physical interface and logical interface levels on third-generation FPCs (FPC3-PTX-U2 and FPC3-PTX-U3 on PTX5000 and FPC3-SFF-PTX-U0 and FPC3-SFF-PTX-U1 on PTX3000), PTX1000, and PTX10008 by using both a CLI command and SNMP MIB counters. Use the show interfaces statistics command to display both physical interface and logical interface statistics. You can view only logical interface statistics if you use SNMP MIB counters. However, for aggregated Ethernet interfaces, the accounting is not done at the level of the child links and, thus, IPv6 statistics for child links are not displayed.

    To start getting IPv6 statistics on third-generation FPCs, use the route-accounting statement at the [edit forwarding-options family inet6] hierarchy level. PTX Series routers with first-generation and second-generation FPCs do not display IPv6 statistics for physical interfaces or logical interfaces, and transit statistics on child links in aggregated Ethernet interfaces are also not taken into account.

    Note

    Egress accounting for IPV6 traffic is not performed for cases where MPLS packets arrives on TCC interface and egress out of the router as IPV6 packets.

    [See route-accounting and show interfaces extensive.]

Junos OS XML API and Scripting

  • Automation script library additions and upgrades (PTX 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 Layer 2 protocols (PTX 10016)—Starting in Junos OS Release 17.4R1, Layer 2 protocols are supported on PTX10016 routers that have third-generation FPCs installed. Layer 2 protocols include Spanning Tree Protocol (STP), Rapid Spanning Tree Protocol (RSTP), Multiple Spanning Tree Protocol (MSTP), VLAN Spanning Tree Protocol (VSTP), Link Layer Discovery Protocol (LLDP), and so on.

Layer 3 Features

  • Support for Layer 3 protocols (PTX 10016)—Starting in Junos OS Release 17.4R1, Layer 3 protocols are supported on PTX10016 routers that have third-generation FPCs installed. Layer 3 protocols include the Multiprotocol Label Switching (MPLS), Layer 3 Virtual Private Network (L3VPN), Bidirectional Forwarding Detection (BFD), Layer 2 Virtual Private Network (L2VPN), Point-to-multipoint (P2MP), Fast ReRoute (FRR), Operations, Administration and Maintenance (OAM), Protocol Independent Multicast (PIM), Internet Group Management Protocol (IGMP), Adaptive Load Balancing (ALB), and so on.

Management

  • Support for multiple, smaller configuration YANG modules (PTX 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.]

  • Support for IS-IS sensor for Junos Telemetry Interface (PTX 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 (PTX 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 (PTX 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 (PTX 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.]

  • Support for bypass LSP statistics for Junos Telemetry Interface (PTX 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 BGP routing table sensors for Junos Telemetry Interface (PTX 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 ipv6-unicast in any of the paths.

    [See Guidelines for gRPC Sensors].

  • Support for bidirectional authentication for gRPC for Junos Telemetry Interface (PTX 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, 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.

    [See gRPC Services for Junos Telemetry Interface.]

  • Enhancements to MPLS sensor for Junos Telemetry Interface (PTX 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.]

  • FPC1 and FPC2 support for CPU and NPU sensors for Junos Telemetry Interface (PTX Series)—Starting with Junos OS Release 17.4R1, you can export data for CPU memory and NPU memory and utilization for FPC1 and FPC2 on PTX Series routers through the Junos Telemetry Interface. Previously, only FPC3 was supported on these sensors. 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 sensor (Junos Telemetry Interface) and Guidelines for gRPC sensors.]

MPLS

  • Support for static adjacency segment identifier for aggregate Ethernet member links using single-hop static LSP (PTX 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 aggregate 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 static adjacency segment identifier for IS-IS (PTX 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 adjusting the threshold of autobandwidth based on the absolute value for LSP (MX Series)—Current autobandwidth threshold adjustment is done based on the configured percentage, which is hard to tune to work well for both small and large bandwidth reservations. For a given threshold percentage, when the bandwidth reservation is small there can be multiple LSP resignalling events. This is because the LSP is responsive to even minor increase or decrease in the utilization when current reservation is small. For example, a small threshold adjustment of 5 percent allows large LSPs of say 1G to respond to changes in bandwidth of the order of 50M. However, that same threshold adjustment results in too many LSP resignalling events for small LSPs of say 10M reservation. Increasing the adjust threshold percentage by for example 40 percent minimizes LSP resignaling for small LSPs. However, large LSPs do not react to bandwidth usage changes unless they are huge, for example, 400M. Starting in Junos OS Release 17.4R1, you can configure an absolute value based threshold along with the percentage based threshold that helps avoid the bandwidth getting triggered for LSPs of both small and large bandwidth reservations. Configure adjust-threshold-absolute value option at the [edit protocols mpls label-switched-path lsp-name auto-bandwidth] hierarchy level.

  • Support for default time-out duration for self-ping on an LSP instance (PTX Series)—Starting in Junos OS 17.4R1, the default time out duration for which the self-ping runs on an LSP instance is reduced from 65535 (runs until success) to 1800 seconds. You can also configure the self ping duration value between 1 to 65,535 (runs until success) seconds using the self-ping-duration value command at the [edit protocols mpls label-switched-path label-switched-path] hierarchy level. By default, self-ping is enabled. The LSP types like CCC, P2MP, VLAN-based, and non-default instances do not support self-ping . You can configure no-self-ping command at the [edit protocols mpls label-switched-path label-switched-path] hierarchy level to override the behavior of self-ping running by default.

  • Support for flap and MBB counter for LSP (PTX Series)—Starting in Junos OS Release 17.4R1, the show mpls lsp extensive command introduces the following two counters for LSP on master routing engine only:

    • Flap counter–- Counts the number of times an LSP flaps down or up.

    • MBB counter— Counts the number of times an LSP incurs MBB.

    The clear mpls lsp counters command resets the flap and the MBB counter to zero.

  • Display of labels in received record route for unprotected LSPs by show mpls lsp extensive command (PTX Series)—The show mpls lsp extensive command displays the labels in received record route (RRO) for protected LSPs. Starting in Junos OS Release 17.4R1, the command also displays the labels associated with the hops in RRO for unprotected LSPs as well. The label recording in RRO is enabled by default.

  • Support for label history for MPLS protocol (PTX Series)—Starting in Junos OS Release 17.4R1, configure max-entries number option at [edit protocols mpls label-history] hierarchy level to display label allocation, release history, and associated information such as RSVP session that helps debug label related error such as stale label route and deleted label route. You can configure the limit for the maximum number of MPLS history entry per label . By default, label history is off and there is no maximum limit for the number of entries for each label. The show mpls label history label-value command displays the label history for a given label value and the show mpls label history label-range start-label end-label command displays the history of labels between the given label range.

    The clear mpls label history command clears the label history details.

Routing Protocols

  • Support for importing IGP topology information into BGP-LS (PTX 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 (PTX Series)—Starting in Junos OS Release 17.4R1, a BGP speaker supports traffic steering based on a segment routing policy. The controller can specify a segment routing policy consisting of multiple paths to steer labeled or IP traffic. This feature enables BGP to support a segment routing policy for traffic engineering at ingress routers. 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.]

  • Topology-independent loop-free alternate for IS-IS (PTX 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 network instance-based BGP configuration (PTX 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.]

  • DDoS protection support (PTX3000, PTX-5000, PTX1000, PTX10000)—Starting with Junos OS Release 17.4R1, protection from DDoS attack is provided on PTX3000, PTX 5000, PTX1000, and PTX10000 routers only if they have PE-based FPCs installed.

    If the total amount of traffic that a Routing Engine can handle exceeds its limit, the Routing Engine becomes overloaded and is unable to handle the routing protocol messages and other important control plane packets. This results in an inconsistent control plane protocol state and that is termed as DDoS attack.

    With the support for DDoS protection, the firewall filters and policers available in Junos OS are used to discard or rate-limit control plane traffic so that such malicious traffic does not overwhelm and bring down the Routing Engine. The Packet Forwarding Engine does not support rate-based policers; therefore, DDoS protection works based on bandwidth.

    DDoS protection is supported with the following protocols:

    • L3 protocols— IGMP v4/v6, OSPF-Hello, OSPF, LDP-Hello, LDP, PIM-Ctrl, PIM-Data, RSVP, RIP, BFD, MHOP BFD, MSDP, BGP, TELNET, FTP, SSH, SNMP, NTP, TACACS, DNS, GRE, ICMP, MLD, NDP, and EGPv6

    • L2 protocols— STP, LACP, LLDP, OAM-CFM, OAM-LFM, ISIS, ISO-TCC, ETH-TCC, and PVST

    Exceptions to DDoS protection support include the following:

    • L3 protocols are per protocol level and not at packet type level.

    • Unsupported L3 protocols— DHCP v4/v6, PTP, VRRP, DTCP, RADIUS-SERVER, RADIUS-ACCT, RADIUS-AUTH, DIAMETER, DIAMETER-TCP, DIAMETER-SCTP, L2TP, LMP, BFDv6, Martian-address, and PIM-REGISTER

    • Unsupported L2 protocols— STP, DOT1X, GARP, FC, Bridge control, and PVST

    • FPC1 and FPC2 on PTX5000 router are not supported.

    For more information, see Distributed Denial-of-Service (DDoS) Protection Overview.

  • Support for EBGP route server (PTX 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.]

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

Security

  • Support for Layer 2 circuit pass-through (PTX Series)—Starting in Junos OS Release 17.4R1, you can configure PTX Series routers to allow LACP, LLDP, OAM LFM, and OAM CFM packets to cross the Layer 2 circuit. To configure Layer 2 circuit pass-through, include the l2circuit-control-passthrough statement at the [set forwarding-options] hierarchy level.

    Note

    LACP can be configured only when the aggregated interface is configured with the ethernet-ccc encapsulation.

    [See l2circuit-control-passthrough.]

Services Applications

  • Reporting of true outgoing interface packets for inline flow monitoring (PTX Series)—Starting in Junos OS Release 17.4R1, you can configure inline flow monitoring to report true packets for the outgoing interface. For ECMP, the actual outgoing interface used for a given flow is the true outgoing interface.

    To enable a true outgoing interface, include the nexthop-learning enable statement at the [set services flow-monitoring (version9 | version-ipfix) template template-name] hierarchy level.

    [See template (Flow Monitoring IPFIX Version) or version9 (Flow Monitoring).]

  • Reporting of the true incoming interface for the sampled packets for inline flow monitoring (PTX Series)—Starting in Junos OS Release 17.4R1, inline flow monitoring reports the true incoming interface for the GRE-encapsulated packets entering the router for the configured inline flow monitoring filter criteria.

    [See Configuring Flow Aggregation to Use IPFIX Flow Templates on PTX Series Routers.]

  • Support for inline JFlow version 9 flow templates (PTX 10016)—Starting in Junos OS Release 17.4R1, you can use inline-J-Flow export capabilities with version 9 flow templates to define a flow record template suitable for IPv4 or IPv6 traffic.

Software Installation and Upgrade

  • Device serial number added to DHCP option 60 (PTX1000)—Starting in Junos OS Release 17.4R1, DHCP option 60 (Vendor Class Identifier) includes the serial number of the device when you use zero touch provisioning to automate provisioning of the device configuration and software image. The serial number can uniquely identify the device in a broadcast network. The serial number appears in the format Juniper-model-number. For example, a PTX1000 router numbered DA000 appears as Juniper-ptx1000-DA000.

Changes in Behavior and Syntax

This section lists the changes in behavior of Junos OS features and changes in the syntax of Junos OS statements and commands in Junos OS Release 17.4R2 for the PTX Series.

Class of Service (CoS)

  • Changes in configuration of hardware-based queue priority (PTX Series)—Starting in Junos OS Release 17.4R1, the mapping of output queue priority values in the Junos OS to the output queue priorities supported by physical interfaces on PTX Series routers has changed. For shared scheduling, when strict-high is not configured, setting the priority to high maps to the hardware priority high. And for strict-priority scheduling, setting the priority to high maps to the hardware priority high. For the full mapping of output queue priorities, see Understanding Scheduling on PTX Series Routers.

Interfaces and Chassis

  • Secondary interface (em2) raises an alarm when the link is down (PTX1000)—Starting in Junos OS Release 17.4R1, secondary interface (em2) raises alarm when the link goes down. Earlier, no alarm was raised when an em2 (secondary interface) went down. Currently, the behavior is changed and an alarm will be raised when the interface link goes down as shown below:

  • Modified output of the request vmhost zeroize command—Starting with Junos OS Release 17.2, the command request vmhost zeroize, upon execution, prompts the user for confirmation to proceed. The following line is displayed:

  • Power supply alarm is not raised when the input switch status is OFF or power not connected (PTX10008, PTX10016)—Starting in Junos OS Release 17.4R2, the power supply alarm A power supply input has failed will not be raised if the INP1/INP2 switch status if off and the power is not connected. Earlier, an alarm was raised for the power entry module (PEM) that it was not powered on as Not Powered irrespective of the switch state. For the power supply status, execute the show chassis power or show chassis power detail CLI command. The DC input is the new output parameter that provides information about the status of the input feed.

    Previous behavior:

    user@host> show chassis power

    Current behavior:

    user@host> show chassis power

    [See show chassis power.]

Management

  • Changes to Junos OS YANG module naming conventions (PTX Series)—Starting in Junos OS Release 17.4R1, the native Junos OS YANG modules use a new naming convention for the module's name, filename, and namespace. The module name and filename include the device family and the area of the configuration or command hierarchy to which the schema in the module belongs. In addition, the module filename includes a revision date. The module namespace is simplified to include the device family, the module type, and an identifier that is unique to each module and that differentiates the namespace of the module from that of other modules.

    [See Understanding Junos OS YANG Modules.]

MPLS

  • Support for adjusting the threshold of autobandwidth based on the absolute value for LSP (PTX Series)—Current autobandwidth threshold adjustment is done based on the configured percentage which is hard to tune to work well for both small and large bandwidth reservations. For a given threshold percentage, when the bandwidth reservation is small there can be multiple LSP resignaling events. This is because the LSP is responsive to even minor increases or decreases in the utilization when current reservation is small. For example, a small threshold adjustment of 5 percent allows large LSPs of around 1G to respond to changes in bandwidth of the order of 50M. However, that same threshold adjustment results in too many LSP resignalling events for small LSPs of around 10M reservation. Increasing the adjust threshold percentage by for example 40 percent minimizes LSP resignaling for small LSPs. However, large LSPs do not react to bandwidth usage changes unless they are huge, for example, 400M. Starting in Junos OS Release 17.4R1, you can configure an absolute value-based threshold along with the percentage-based threshold that helps avoid the bandwidth getting triggered for LSPs of both small and large bandwidth reservations. Configure adjust-threshold-absolute value option at the [edit protocols mpls label-switched-path lsp-name auto-bandwidth] hierarchy level.

  • Support for label history for MPLS protocol (PTX Series)—Starting in Junos OS Release 17.4R1, configure max-entries number option at the [edit protocols mpls label-history] hierarchy level to display label allocation, release history, and associated information such as RSVP session that helps debug label related error such as stale label route and deleted label route. You can configure the limit for the maximum number of MPLS history entries per label . By default, label history is off and there is no maximum limit for the number of entries for each label. The show mpls label history label-value command displays the label history for a given label value and the show mpls label history label-range start-label end-label command displays the history of labels between the given label range.

    The clear mpls label history command clears the label history details.

  • Support for default time out duration for self-ping on an LSP instance (PTX Series)—Starting in Junos OS 17.4R1, the default time out duration for which the self-ping runs on an LSP instance is reduced from 65,535 (runs until success) to 1800 seconds. You can also configure the self ping duration value between 1 to 65,535 (runs until success) seconds using the self-ping-duration value command at the [edit protocols mpls label-switched-path label-switched-path] hierarchy level. By default, self-ping is enabled. The LSP types like CCC, P2MP, VLAN-based, and non-default instances do not support self-ping . You can configure no-self-ping command at the [edit protocols mpls label-switched-path label-switched-path] hierarchy level to override the behavior of self-ping running by default.

  • Display of labels in received record route for unprotected LSPs by show mpls lsp extensive command (PTX Series)—The show mpls lsp extensive command displays the labels in received record route (RRO) for protected LSPs. Starting in Junos OS Release 17.4R1, the command also displays the labels associated with the hops in RRO for unprotected LSPs as well. The label recording in RRO is enabled by default.

  • Support for flap and MBB counter for LSP (PTX Series)—Starting in Junos OS Release 17.4R1, the show mpls lsp extensive command introduces the following two counters for LSP on the master routing engine only:

    • Flap counter–- Counts the number of times an LSP flaps down or up.

    • MBB counter— Counts the number of times an LSP incurs MBB.

    The clear mpls lsp counters command resets the flap and the MBB counter to zero.

Multicast

  • Support for rpf-selection statement for PIM protocol at global instance level (PTX Series)—Starting in Junos OS 17.4R1, the rpf-selection statement for the PIM protocol is available at global instance level. You can configure group and source statements at the [edit protocols pim rpf-selection] hierarchy level.

Network Management and Monitoring

  • Change in default log level setting (PTX Series)—In Junos OS Release, 17.4R1, the following changes were made in default logging levels:

    Before this change:

    • SNMP_TRAP_LINK_UP was LOG_INFO for both the physical (IFD) and logical (IFL) interfaces.

    • SNMP_TRAP_LINK_DOWN was LOG_WARNING for both the physical (IFD) and logical (IFL) interfaces.

    After this change:

    • IFD LinkUp -> LOG_NOTICE (because this is an important message but less frequent)

    • IFL LinkUp -> LOG_INFO (no change)

    • IFD and IFL LinkDown -> LOG_WARNING (no change)

    [See the MIB Explorer.]

  • SNMP syslog messages changed (PTX Series)—In Junos OS Release 17.4R1, two misleading SNMP syslog messages have been rewritten to accurately describe the event:

    • OLD --AgentX master agent failed to respond to ping. Attempting to re-register

      NEW –- AgentX master agent failed to respond to ping, triggering cleanup!

    • OLD –- NET-SNMP version %s AgentX subagent connected

      NEW --- NET-SNMP version %s AgentX subagent Open-Sent!

    [See the SNMP MIB Explorer.]

  • New context-oid option for trap-options configuration statement to distinguish the traps that come from a non-default routing instance with a non-default logical system (PTX Series)—Starting in Junos OS Release 17.4R2, a new option, context-oid, for the trap-options statement allows you to handle prefixes such as <routing-instance name>@<trap-group> or <logical-system name>/<routing-instance name>@<trap-group> as an additional varbind.

    [See trap-options.]

Security

  • Support for logging SSH key changes—Starting with Junos OS Release 17.4R1, the configuration statement log-key-changes is introduced at the [edit system services ssh ] hierarchy level. When the log-key-changes is enabled and committed (with the commit command in configuration mode), Junos OS logs the changes to the set of authorized SSH keys for each user (including the keys that were added or removed). Junos OS logs the differences since the last time log-key-changes was enabled. If log-key-changes was never enabled, then Junos OS logs all the authorized SSH keys.

Software Licensing

  • Key generator adds one day to make the duration of license show as 365 days (PTX Series)—Starting in Junos OS Release 17.4R1, the duration of subscription licenses as generated by the show system license command and shown in the output duration is correct to the numbers of days. Before this fix, for example, for a 1-year subscription license, the duration was generated as 364 days. After the fix, the duration of the 1-year subscription now shows as 365 days.

    [See show system license.]

Subscriber Management and Services

  • DHCPv6 lease renewal for separate IA renew requests (PTX Series)—Starting in Junos OS Release 17.4R2, the jdhcpd process handles the second renew request differently if the DHCPv6 client CPE device does both of the following:

    • Initiates negotiation for both the IA_NA and IA_PD address types in a single solicit message.

    • Sends separate lease renew requests for the IA_NA and the IA_PD and the renew requests are received back-to-back.

    The new behavior is as follows:

    1. When the reply is received for the first renew request, if a renew request is pending for the second address type, the client stays in the renewing state, the lease is extended for the first IA, and the client entry is updated.

    2. When the reply is received for the second renew request, the lease is extended for the second IA and the client entry is updated again.

    In earlier releases:

    1. The client transitions to the bound state instead of staying in the renewing state. The lease is extended for the first IA and the client entry is updated.

    2. When the reply is received for the second renew request, the lease is not renewed for the second address type and the reply is forwarded to the client. Consequently, when that lease ages out, the binding for that address type is cleared, the access route is removed, and subsequent traffic is dropped for that address or address prefix.

    [See Using DHCPv6 IA_NA with DHCPv6 Prefix Delegation Overview.]

Known Behavior

This section contains the known behavior, system maximums, and limitations in hardware and software in Junos OS Release 17.4R2 for PTX Series.

For the most complete and latest information about known Junos OS defects, use the Juniper Networks online Junos Problem Report Search application.

General Routing

  • For CFP2-DCO-T-WDM-1 pluggable, Rx payload type is shown incorrectly. PR1300423

  • On PTX (GingerAle PIC on Gladiator FPC), when backward frr is enabled on far end the convergence time is higher as extra delay (average 500 msec) incurred in triggering FRR, due to software based polling. PR1303820

  • Forwarding-option filter (FTF) with DSCP action is not supported on PTX1000 and other PE chipset platforms. PR1310747

  • In the specific case of semi-graceful RCB reboot initiated by the internal shell command: 'vhclient init 0', GRES takes longer to complete i.r 3 minutes as opposed to 21 seconds. The regular cli command: 'request vmhost reboot' (graceful) and a jack-out-jack-in of the RE (ungraceful) do not exhibit this delay. PR1312065

Interfaces and Chassis

  • On PTX10008 and PTX10016 routers, if you remove the redundant Switch Interface Board (SIB) after upgrading Junos OS from Release 17.4R1 or Release 17.2X75-D90 to a later release, then an alarm is not generated. This is a known behavior and has no impact on the performance of the router.

Known Issues

This section lists the known issues in hardware and software in Junos OS Release 17.4R2 for the PTX Series.

For the most complete and latest information about known Junos OS defects, use the Juniper Networks online Junos Problem Report Search application.

General Routing

  • While upgrading from Junos OS Release 15.1F based images to Junos OS 16.x and later releases or downgrading from Junos OS Release 16.x to Junos OS Release 15.1F images, if the "validate" option is enabled, chassisd might crash and upgrade or downgrade will fail. This issue should not be seen if both base and target images are from Junos OS Release 15.1F or Junos OS Release 16.x and later. PR1171652

  • PTX Series FPC3 might receive noise on the FPC console port and interpret it as valid signals. This might cause a login failure on the console port and generate core files, or even reloads. PR1224820

  • On PTX platforms with FPC3, PTX1000 with build-in chassis and QFX10000 platforms, an FPC major alarm might be seen if the system detects parity error, and the error messages DLU: ilp memory cache error and DLU: ilp prot1 detected_imem_even error might appear. The alarm might be cleared without intervention. This error might also be accompanied by traffic loss. PR1251154

  • When an FPC goes offline or restarts, FPC 'x' sends traffic to FPC 'y'. The following error messages are seen on the destination FPC. A corresponding alarm is set on the destination FPC. Specific to PTX10000, the transient alarm gets set when this condition occurs. The alarm clears later because the source FPC goes offline. Apr 09 10:31:24 [TRACE] [asta] Apr 9 10:19:59 asta fpc4 Error (0x210613), module: PE Chip, type: Apr 09 10:31:24 [TRACE] [asta] Apr 9 10:19:59 asta fpc4 Cmerror Op Set: PE Chip: PE1[1]: FO:core intr: 0x00000010: Grant spray drop due to unspray-able condition error Apr 09 10:31:24 [TRACE] [asta] Apr 9 10:19:59 asta fpc4 Error (0x210614), module: PE Chip, type: Apr 09 10:31:24 [TRACE] [asta] Apr 9 10:19:59 asta fpc4 Cmerror Op Set: PE Chip: PE1[1]: FO:core intr: 0x00000008: Request spray drop due to unspray-able condition error. PR1268678

  • On PTX 5000 with FPC type 3 in rare condition FPC might crash during lo0.0 inet6 input filter. PR1268875

  • Sometimes l2cpd core files are generated when LLDP neighbors are cleared. PR1270180

  • When msata installation fails in Linux-based linecards msata is removed from the boot list thinking its bad hardware. Linecard continues to pxie boot from network. There will be alarm on Routing Engine side indicating this failure. If msata installation is successful, then it can be manually added back. PR1279344

  • The FPC state is displayed incorrectly. PR1300795

  • When CFP2-DCO-T-WDM-1 plugged in PTX PIC, after repeated configuration rollback, link sometime might take longtime to come-up. PR1301462

  • When CFP2-DCO-T-WDM-1 plugged in PTX PIC, after FPC restart sometimes carrier frequency offset tca is raised even when tca not enabled. PR1301471

  • iLatency (calculated by differing producer timestamp and gRPC server timestamp) might sometimes be negative for Packet Forwarding Engine related telemetry packets due to drift in Routing Engine and Packet Forwarding Engine NTP servers. PR1303376

  • The crash indicates simultaneous operation on an ephemeral instance. When a process wants to open ephemeral configuration in merge view, other activities (like purging, deletion/recreation) are being carried out on this ephemeral instance. The occurrence of this core is rare. PR1305424

  • When the command set forwarding-options l2circuit-control-passthrough is configured on a working LACP bundle, the interface goes down and no traffic will pass. PR1320407

  • When DCO hot-plug is done *before* link is UP, the FPC might crash. PR1322260

  • On PTX Series platform with FPC type 3, the error message could be observed when FPC card goes online or off-line. PR1322491

  • On PTX Series platform with broadway cards (for example, FPC1, FPC2) and class of service (CoS) used, a high priority queue might not get the entire configured bandwidth. PR1324853

  • In streaming telemetry scenario, when commit full command is executed, na-grpd daemon might disconnect streaming telemetry. PR1326366

  • In the event of Routing Engine switchover, if there are existing sensor subscriptions, they will continue to show in show agent sensors output after the switchover. These stale sensors will be cleared when the device becomes master again. PR1347779

  • This issue applies to PTX3000 FPC-SFF-PTX-P1-A/FPC-SFF-PTX-T. When BFD is configured for BGP, any L3 packet injects from linecard might lead to the result that BFD sessions does not come up on PTX3000. PR1352112

  • If output firewall filter is configured with "syslog" option, the host interface might be wedged on a PTX1000, or a PTX Series platform with FPC type 3. PR1354580

  • In case of link flap with LDP adjacencies, there is a possibility that the traffic drop is up to 1-2 seconds. PR1357925

  • When a Routing Engine reboots and comes up again, it sends gratuitous ARP packets to the internal interfaces in order to advertise its MAC address. These packets get in to the UKERN running on the FPC, which drops these packets. The messages seen here are printed just before dropping these packets. These error messages are harmless and do not disrupt working of any feature. PR1374372

Interfaces and Chassis

  • Junos OS upgrade involving Junos OS Release 14.2R5 and later maintenance releases, and Junos OS Release 16.1 later mainline releases with CFM configuration might cause cfmd crash after upgrade. This is due the old version of /var/db/cfm.db. PR1281073

MPLS

  • LDP to BGP stitching with eBGP indirect next hop having an implicit null label does not work. It does work when BGP indirect next hop has a real label. As a workaround, ensure the peer advertises a real label by adding another router between the egress and ingress PE devices. Use IBGP that gets resolved over LDP or RSVP-TE LSPs. This ensures that the BGP indirect next hop has a real label. PR1254702

Platform and Infrastructure

  • Execution of Python scripts through enhanced automation is only supported on non-veriexec images. PR1334425

Resolved Issues

This section lists the issues fixed in the Junos OS main release and the maintenance releases for the PTX Series.

For the most complete and latest information about known Junos OS defects, use the Juniper Networks online Junos Problem Report Search application.

Resolved Issues: 17.4R2

General Routing

  • The commands restart na-grpc-server and restart na-mqtt for MTRE does not work. PR1284121

  • PTX1000s routers are periodically exporting IPFIX flow packets with high octet values. PR1286427

  • On a PTX1000, upgrade from Junos OS Release 16.1X65D45 to Junos OS Release 17.3-20170721 fails frequently on enabling sampling. PR1296533

  • Interfaces might go down when Packet Forwarding Engine encounters TOE::FATAL ERROR. PR1300716

  • On a PTX3000 platform, powering on a FPC (PTX-IPLC-B-32) card might cause the other FPC cards to reboot. PR1302304

  • Internal latency is high during the initial subscription of sensors. PR1303393

  • Repeated log message %PFE-3 fpcX expr_nh_index_tree_ifl_get and expr_nh_index_tree_ipaddr_get is observed when the sampling packet is discarded with a log(or syslog) configuration statement under the firewall filter. PR1304022

  • The “interface hold-time down" timer does not take effect on a PTX5000 with an optical interface. PR1307302

  • Packet Forwarding Engine error messages are flooding as expr_sensor_update_cntr_to_sid_tree after a deletion and rollback as protocols isis source-packet-routing node-segment . PR1309288

  • On a PTX10000, a suppress chassis alarm for switched off PEM is seen. PR1311574

  • The SIB LED on the FPD comes to GREEN-STEADY state even before an SIB comes online. PR1311632

  • PTX10000 router does not bounce FPC without warning or alarm for different port speed settings. PR1311875

  • The rpd process generates a core file after multiple session flaps on a scale setup. PR1312169

  • Many logs are generated after executing many VHclient related commands. PR1315128

  • Memory leak in chassisd daemon is noticed while streaming active telemetry subscriptions. PR1315672

  • The Packet Forwarding Engine on a PTX FPC3 or PTX10000 line card might be disabled if the interface connecting to the Packet Forwarding Engine goes down. PR1315823

  • The physical interfaces might generate framing errors when ports are connected to an odd interface. PR1317827

  • On MX0016 router, after Jack-out/Jack-in, FPCs shows up as "No-Power" for some time; FPC, however, comes up. PR1319156

  • There is no traffic flowing with IPv6 payload prefixes on PTX Series platform. PR1319273

  • PTX10000 routers for 100G LR4 optics with part number 740-061409 changes the display of the show chassis hardware command to QSFP-100G-LR4-T2. PR1322082

  • The rpd process might crash when the OpenConfig package is upgraded with JTI streaming data in the background. PR1322553

  • On Junos OS MPC7, MPC8, and MPC9, PTX-FPC3 (FPC-P1, FPC-P2), PTX3000-FPC3, and PTX1000 line cards might crash upon receipt of specific MPLS packet (CVE-2018-0030). PR1323069

  • On a PTX1000, the local time on an FPC might be different from the local time on a Junos-VM or VM-host. PR1325048

  • The GRE traffic is not decapsulated by the firewall filter. PR1325104

  • PTX Series routers MKA sessions are not coming up after changing CA parameters such as transmit-interval, and key-server-priority. PR1325392

  • MPLS traceroute fails across the PTX Series platform. PR1327609

  • On a PTX5000 with FPC3 line cards, on a PTX10000, and on PTX1000 platforms, output firewall filters that are configured with "syslog" and "discard" actions do not perform the "syslog" action. PR1328426

  • PTX10000 line card might reboot continuously after upgrading to Junos OS Release 17.2R1 or later if HMC BIST fails. PR1330618

  • There is a link instability after a link-down event on PTX Series routers. PR1330708

  • A PTX5000 FPC might reboot in certain rare scenarios when interface-specific policer is configured. PR1335161

  • The directory where the init and configuration files are stored are removed when request system zeroize is executed. Hence, the telemetry process does not start after the zeroize is done. PR1336004

  • A member of an IPv4 unilist next hop might get stuck in "Replaced" state after an interface flap. PR1336201

  • Disabling a breakout 10G port on interface et-0/0/5 will unexpectedly disable another breakout 10G port on interface et-0/0/5. PR1337975

  • FPC/FPC2/FPC E on a PTX Series does not forward traffic. PR1339524

  • The link goes down on a PTX3000. The PTX5000 with an FPC3 is inserted after the router reboots or the link flaps. PR1340612

  • The interface might flap continuously after reboot on PTX5000 and PTX3000 platform with P3-24-U-QSFP28 PIC. PR1342681

  • On a PTX1008, the 30-port coherent line card (DWDM-lC) does not come up. PR1344732

  • The FPC was rebooted a few minutes after loading the configuration. PR1346467

  • Sensors are not getting cleared up after doing Routing Engine switchover. PR1347779

  • MPLS traceroute for P2MP LSPs configured with link-protection causes FPC crash.PR1348314

  • The interface of 15 100G ports PIC might delay 60 seconds to come up. PR1357410

  • P2MP LSP replication traffic loss on an aggregated Ethernet bundle after a member link is down on PTX Series routers.PR1359974

  • The route stuck might be seen after BGP neighbor and route flapping. PR1362560

  • The traffic is still forwarded through the member link of an aggregated Ethernet bundle interface even with Link-Layer-Down flag set. PR1365263

  • On a PTX Series IPLC (OPT3-SFF-PTX FPC), a first J-UKERN crash triggers multiple secondary J-UKERN crashes. PR1365791

  • The commit or commit check might fail due to the error of cannot have lsp-cleanup-timer without lsp-provisioning. PR1368992

Infrastructure

  • The ixlv interface statistics are not accounting properly. PR1313364

  • PTX Series routers might get to abnormal state because of the malfunction of the protection mechanism for the F-Label. PR1336207

MPLS

  • Traffic drops during NSR switchover for RSVP P2MP provider tunnels used by MVPN. PR1293014

  • Traffic loss for static LSP configured with the stitch configuration statement. PR1307938

  • The rpd process might crash on the backup Routing Engine due to memory exhaustion. PR1328974

  • The rpd might crash with MPLS traceoption configured. PR1329459

  • MPLS LSP statistics are not shown in the CLI command. show mpls lsp ingress statistics. PR1344039

  • On PTX1000, PTX10000, or QFX10000 platform, when hybrid memory cube (HMC) error occurs, label switched paths (LSPs) might go down because of the incorrect bandwidth requested for auto-bandwidth adjustment. PR1374102

Platform and Infrastructure

  • Continuous log messages occur. For example, you see tftpd[23724]: Timeout #35593 on DATA block 85. PR1315682

  • Traffic black hole seen along with JPRDS_NH:jprds_nh_alloc(),651: JNH[0] failed to grab new region for NH messages. PR1349332

  • Traffic black hole seen along with JPRDS_NH:jprds_nh_alloc(),651: JNH[0] failed to grab new region for NH messages. PR1357707

Routing Protocols

  • With BGP LU FRR in an inter-AS scenario, a very high FRR time is visible once the link is up. PR1307258

  • The rpd process might constantly consume high CPU in a BGP setup. PR1315066

  • The primary path of an MPLS LSP might switch to another address. PR1316861

  • The rpd process might crash after deactivating the passive interface under IS-IS. PR1318180

  • The rpd process might crash continuously on both Routing Engines when backup-spf-options remote-backup-calculation is configured in an IS-IS protocol. PR1326899

  • The rpd process generates a core file at ispfc_incrementally_mend_one_postf_sp_tree (postf_spf_res=<optimized-out>, topo=<optimized-out>) at ../../../../../../../../src/junos/usr.sbin/rpd/lib/igp-spf-compute/igp_spf_compute_ti_lfa.c:3364" PTX1K. PR1339296

  • A protocol churn might lead the rpd process to crash. PR1341466

  • The rpd process generates a core file while running a streaming telemetry test. PR1347431

VPNs

  • In a specific CE device environment in which asynchronous notification is used, after the link between the PE and CE devices goes up, the L2 circuit flaps repeatedly.PR1282875

Resolved Issues: 17.4R1

General Routing

  • PTX1000 : ch_get_product_attribute.324: Cannot find chassisd error message appears while loading image. PR1217505

  • The rpd might crash on platforms with 64-bit X86 RE if IPv6 is configured. PR1224376

  • On PTX Series platforms, chassisd thread is not getting CPU resources for 200 seconds and multiple chassisd core files are continuously generated. PR1226992

  • The "validation-state:unverified" routing entry might not be displayed with proper location when using the show route command. PR1254675

  • The routing protocol process (rpd) might crash after flapping BGP sessions and routes. PR1269327

  • 100Base-ER4 (740-045420) is displayed as “UNKNOWN” in show chassis hardware in Junos OS Release 15.1R5.5. PR1280089

  • FPC cards might go offline due to fabric healing in PTX3000 with SIB-SFF-PTX-240-S platform. PR1282983

  • “Host 0 RTC Battery failure" error messages are seen on PTX1000, QFX10000-series after upgrade to Junos version 16.1.PR1287128

  • The MPLS TTL might be reset to 255 on third-generation PTX Series FPCs if mpls no-propagate-ttl protocols configuration statement is configured. PR1287473

  • LSP traffic gets silently dropped or discarded after link goes down in bypass path. PR1291036

  • The rpd core file might be generated when restarting the process through CLI. PR1291110

  • Incorrect SNMP OID values are sent in SNMP traps for removal or insertion of front panel display on PTX Series routers. PR1294741

  • LINK LED is “RED” when the port is disabled on PTX Series routers.PR1294871

  • The rpd core might be generated after interface or BGP flapping.PR1294957

  • The chassisd process might run out of memory and restart on PTX1000 platform. PR1295691

  • PTX5K/SyncE (ESMC): clock is not getting locked if the source interface is a member link of an ae bundle. PR1296015

  • CoS escalation: Alarms and syslog errors are seen with priority strict-high on AF4 queue, on the oversubscription cases (1X100G egress to 1X10G egress setup). PR1297343

  • PE Chip: FATAL ERROR!! from pe0[0]: HMCIF: might trigger FPC crash or slow route/next-hop installation processing. PR1300180

  • PTX Series FPC3 will drop MPLS packets if its oif has inet MTU that is less than the MPLS packet size. PR1302256

  • Heap memory leak might be observed on PTX Series FPCs during a multicast route installation into the Packet Forwarding Engine. PR1302303

  • The third-generation FPC (FPC3-SFF-PTX) is not booting up on Control Board/Routing Engine systems. PR1303295

  • On PTX3000 and PTX5000 platforms, the 100G interfaces might not come up. PR1303324

  • If MPLS LSP self-ping is enabled (self-ping is enabled by default), kernel might panic with the error message Fatal trap 12: page fault while in kernel mode.PR1303798

  • PTX3000 with RCB-PTX Routing Engine might not be online or recognize IPLCs. PR1304124

  • The 10g interface might flap if it is set to 100g speed.PR1315079

  • The physical interfaces might generate framing errors when ports are connecting odd interfaces. PR1317827

  • The physical interfaces might generate framing errors when ports are connecting to odd interface. PR1317827

  • No traffic is flowing with IPV6 payload prefixes on PTX platform. PR1319273

  • PFT : RCB restarts continuously after executing request system reboot.PR1320977

Infrastructure

  • The show system users CLI command output displays a larger number of users than that are actually using the router. PR1247546

Interfaces and Chassis

  • The interface might flap when performing Routing Engine switchover if the member link of an ae interface is configured with framing settings. PR1287547

  • 100-Gigabit Ethernet interfaces might not come up if otn-options laser-enable is configured on PTX Series platforms. PR1297164

  • LFM discovery state appears as Fault for aggregate Ethernet interface after GRES. PR1299534

Multiprotocol Label Switching (MPLS)

  • Stale RSVP LSP entry after NSR switchover and session is not refreshed. PR1292526

  • The rpd might crash if the MPLS LSP path change occurs. PR1295817

Platform and Infrastructure

  • Mgd generates core file when downgrading from Junos OS Release17.3-20170721 to 16.1X65D40.2. The mgd core is also overwritten if attempted multiple times. PR1296504

Routing Protocols

  • A few BFD sessions are flapping while coming up after FPC restart/reboot.PR1274941

  • The rpd generated core files multiple times when it received an “OPEN” message from an existing BGP peer. PR1299054

  • With BGP LU FRR in Inter-As scenario, a very high FRR time is seen once link is up. PR1307258

  • Assignment of SUB-TLV values for Segment routing TE policy SUB-TLVs. PR1315486

Documentation Updates

There are no errata or changes in Junos OS Release 17.4R2 documentation for PTX Series.

Migration, Upgrade, and Downgrade Instructions

This section contains the procedure to upgrade Junos OS, and the upgrade and downgrade policies for Junos OS for the PTX Series. Upgrading or downgrading Junos OS might take several hours, depending on the size and configuration of the network.

Upgrade and Downgrade Support Policy for Junos OS Releases

Support for upgrades and downgrades that span more than three Junos OS releases at a time is not provided, except for releases that are designated as Extended End-of-Life (EEOL) releases. EEOL releases provide direct upgrade and downgrade paths—you can upgrade directly from one EEOL release to the next EEOL release even though EEOL releases generally occur in increments beyond three releases.

You can upgrade or downgrade to the EEOL release that occurs directly before or after the currently installed EEOL release, or to two EEOL releases before or after. For example, Junos OS Releases 17.1, 17.2, and 17.3 are EEOL releases. You can upgrade from Junos OS Release 17.1 to Release 17.2 or from Junos OS Release 17.1 to Release 17.3. However, you cannot upgrade directly from a non-EEOL release that is more than three releases ahead or behind.

To upgrade or downgrade from a non-EEOL release to a release more than three releases before or after, first upgrade to the next EEOL release and then upgrade or downgrade from that EEOL release to your target release.

For more information about EEOL releases and to review a list of EEOL releases, see https://www.juniper.net/support/eol/junos.html.

Upgrading a Router with Redundant Routing Engines

If the router has two Routing Engines, perform a Junos OS installation on each Routing Engine separately to avoid disrupting network operation as follows:

  1. Disable graceful Routing Engine switchover (GRES) on the master Routing Engine and save the configuration change to both Routing Engines.

  2. Install the new Junos OS release on the backup Routing Engine while keeping the currently running software version on the master Routing Engine.

  3. After making sure that the new software version is running correctly on the backup Routing Engine, switch over to the backup Routing Engine to activate the new software.

  4. Install the new software on the original master Routing Engine that is now active as the backup Routing Engine.

For the detailed procedure, see the Installation and Upgrade Guide.

Basic Procedure for Upgrading to Release 17.4

When upgrading or downgrading Junos OS, use the jinstall package. For information about the contents of the jinstall package and details of the installation process, see the Installation and Upgrade Guide. Use other packages, such as the jbundle package, only when so instructed by a Juniper Networks support representative.

Note

Back up the file system and the currently active Junos OS configuration before upgrading Junos OS. This allows you to recover to a known, stable environment if the upgrade is unsuccessful. Issue the following command:

Note

The installation process rebuilds the file system and completely reinstalls Junos OS. Configuration information from the previous software installation is retained, but the contents of log files might be erased. Stored files on the router, such as configuration templates and shell scripts (the only exceptions are the juniper.conf and ssh files), might be removed. To preserve the stored files, copy them to another system before upgrading or downgrading the routing platform. For more information, see the Junos OS Administration Library.

Note

We recommend that you upgrade all software packages out of band using the console because in-band connections are lost during the upgrade process.

To download and install Junos OS Release 17.4R2:

  1. Using a Web browser, navigate to the All Junos Platforms software download URL on the Juniper Networks webpage:

    https://www.juniper.net/support/downloads/

  2. Select the name of the Junos OS platform for the software that you want to download.
  3. Select the release number (the number of the software version that you want to download) from the Release drop-down list to the right of the Download Software page.
  4. Select the Software tab.
  5. In the Install Package section of the Software tab, select the software package for the release.
  6. Log in to the Juniper Networks authentication system using the username (generally your e-mail address) and password supplied by Juniper Networks representatives.
  7. Review and accept the End User License Agreement.
  8. Download the software to a local host.
  9. Copy the software to the routing platform or to your internal software distribution site.
  10. Install the new jinstall package on the router.Note

    After you install a Junos OS Release 17.4R2 jinstall package, you cannot return to the previously installed software by issuing the request system software rollback command. Instead, you must issue the request system software add validate command and specify the jinstall package that corresponds to the previously installed software.

    The validate option validates the software package against the current configuration as a prerequisite to adding the software package to ensure that the router reboots successfully. This is the default behavior when the software package being added is for a different release. Adding the reboot command reboots the router after the upgrade is validated and installed. When the reboot is complete, the router displays the login prompt. The loading process might take 5 to 10 minutes. Rebooting occurs only if the upgrade is successful.

    Customers in the United States and Canada, use the following command:

    user@host> request system software add validate reboot source/jinstall-17.4R2.SPIN-domestic-signed.tgz

    All other customers, use the following command:

    user@host> request system software add validate reboot source/jinstall-17.4R2.SPIN-export-signed.tgz

    Replace the source with one of the following values:

    • /pathname—For a software package that is installed from a local directory on the router.

    • For software packages that are downloaded and installed from a remote location:

      • ftp://hostname/pathname

      • http://hostname/pathname

      • scp://hostname/pathname (available only for Canada and U.S. version)

    The validate option validates the software package against the current configuration as a prerequisite to adding the software package to ensure that the router reboots successfully. This is the default behavior when the software package being added is a different release.

    Adding the reboot command reboots the router after the upgrade is validated and installed. When the reboot is complete, the router displays the login prompt. The loading process might take 5 to 10 minutes.

    Rebooting occurs only if the upgrade is successful.

Note

You need to install the Junos OS software package and host software package on the routers with the RE-PTX-X8 Routing Engine. For upgrading the host OS on this router with VM Host support, use the junos-vmhost-install-x.tgz image and specify the name of the regular package in the request vmhost software add command. For more information, see the VM Host Installation topic in the Installation and Upgrade Guide.

Note

After you install a Junos OS Release 17.4 jinstall package, you cannot return to the previously installed software by issuing the request system software rollback command. Instead, you must issue the request system software add validate command and specify the jinstall package that corresponds to the previously installed software.

Note

Most of the existing request system commands are not supported on routers with RE-PTX-X8 Routing Engines. See the VM Host Software administrative commands in the Installation and Upgrade Guide.

Product Compatibility

Hardware Compatibility

To obtain information about the components that are supported on the devices, and special compatibility guidelines with the release, see the Hardware Guide and the Interface Module Reference for the product.

To determine the features supported on PTX Series devices in this release, use the Juniper Networks Feature Explorer, a Web-based application that helps you to explore and compare Junos OS feature information to find the right software release and hardware platform for your network. Find Feature Explorer at: https://pathfinder.juniper.net/feature-explorer/.

Hardware Compatibility Tool

For a hardware compatibility matrix for optical interfaces and transceivers supported across all platforms, see the Hardware Compatibility tool.