Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Junos OS Release Notes for PTX Series

 

These release notes accompany Junos OS Release 20.3R3 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.

What's New

Learn about new features introduced in Junos OS Release 20.3R3 for the PTX Series.

What’s New in Release 20.3R3

There are no new features or enhancements to existing features for PTX Series routers in Junos OS Release 20.3R3.

What’s New in Release 20.3R2

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

What’s New in Release 20.3R1

Hardware

  • Support for QSFP-100G-DR transceivers (PTX1000, PTX10002-60C, PTX10008, and PTX10016)—Starting in Junos OS Release 20.3R1, we provide support for the QSFP-100G-DR transceivers. These transceivers interoperate with 400-Gbps breakout optics. For example, the QDD-400G-DR4 interconnects with up to four QSFP-100G-DR transceivers. The QSFP-100G-DR transceivers interconnect in single links (QSFP-100G-DR to QSFP-100G-DR or to QSFP-100G-FR) and interoperate at the shortest link length.

    Note

    These transceivers are not compatible with earlier-generation 100-Gbps transceivers (for example, QSFP-100G-CWDM4 and QSFP-100G-LR4).

    [See the Hardware Compatibility Tool (HCT) for details.]

  • Support for QSFP-100G-FR transceivers (PTX1000, PTX10002-60C, PTX10008, and PTX10016)—Starting in Junos OS Release 20.3R1, we provide support for the QSFP-100G-FR transceivers. These transceivers interoperate with the QDD-4X100G breakout optics. For example, the QDD-4X100G-FR interconnects with up to four QSFP-100G-FR transceivers. The QSFP-100G-FR transceivers interconnect in single links (QSFP-100G-FR to QSFP-100G-FR or to QSFP-100G-DR) and interoperate at the shortest link length.

    Note

    These transceivers are not compatible with earlier-generation 100-Gbps transceivers (for example, QSFP-100G-CWDM4 and QSFP-100G-LR4).

    [See the Hardware Compatibility Tool (HCT) for details.]

Authentication, Authorization, and Accounting

  • Support for TCP authentication option (TCP-AO) for BGP and LDP connections (MX Series and PTX Series)—Starting in Junos OS Release 20.3R1, you can use TCP-AO to authenticate TCP segments exchanged during BGP and LDP sessions. It supports both IPv4 and IPv6 traffic. TCP-AO provides a framework to support multiple stronger algorithms, such as HMAC-SHA1 and AES-128, to create its message digest. TCP-AO supports up to 64 keys that can be used for a BGP or an LDP session. You can configure a new key for a BGP or LDP session during its lifetime without causing any session flap. Each key becomes active based on its configured start time.

    In earlier releases, you could use only the TCP MD5 authentication method. It supports only MD5 algorithm to create its message digest.

    [See TCP Authentication Option (TCP-AO) for BGP and LDP Sessions and authentication-key-chains (TCP-AO).]

IP Tunneling

  • IPIP encapsulation for flexible tunnel interfaces (FTIs) (MX Series, PTX Series, and QFX10002)—We've extended flexible tunnel interfaces (FTIs) and existing forwarding constructs to support configuring static IPv4 IP-in-IP tunnels and RIB APIs. To configure an IP-in-IP tunnel on a FTI, use the ipip option at the [edit interfaces interface-name unit logical-unit-number tunnel encapsulation] hierarchy level.

    [See Configuring Flexible Tunnel Interfaces and ipip.]

  • Support for IP over IP next hop based tunneling (MX Series, PTX1000, PTX10000, QFX10000, and QFX10002)—Starting in Junos OS Release 20.3R1, we support an IP-over-IP encapsulation to facilitate IP overlay construction over IP transport network. An IP network contains edge devices and core devices. To achieve higher scale and reliability among these devices, you need to logically isolate the core network from the external network that the edge devices interact with, by using an overlay encapsulation. Among the other overlay encapsulations supported, IP over IP encapsulation is the only kind where transit devices are able to parse the inner payload and use inner packet fields for hash computation and customer edge devices are able to route traffic into and out of the tunnel without any throughput reduction. IP over IP relies on a next hop-based infrastructure to support higher scale.

    On MX Series routers, routing protocol daemon(RPD) sends the encapsulation header with tunnel composite nexthop and the Packet Forwarding Engine finds the tunnel destination address and forwards the packet. On PTX Series routers and QFX10000 switches, RPD sends fully resolved next hop-based tunnel to PFE. You can either use static configuration or a BGP protocol configuration to distribute routes and signal dynamic tunnels. You can also configure Interface based firewall filters on any transit or egress device with an action to decapsulate IP-IP packets and forward it to main instance or to a routing-instance as required.

    [See Next-Hop-Based Dynamic Tunneling Using IP-Over-IP Encapsulation.]

  • Support for filter-based decapsulation of IPv4 and IPv6 unicast traffic encapsulated in IPv4 IP-in-IP tunnels (MX Series, PTX1000, PTX10002, and QFX10002)—Junos OS supports decapsulating IPv4 and IPv6 unicast traffic that has been encapsulated in IPv4 IP-in-IP tunnels using firewall filters. If the outer IPv4 header address matches the firewall configuration and the packet has ipip set as the protocol type, then the outer IPv4 header is removed and the packet is routed based on the inner IPv4 or IPv6 address. If the packet does not have the expected ipip header, the packet is dropped.

    Configure this feature using the following CLI statements at the [edit firewall family inet filter filter-name term term-name] hierarchy:

    • from protocol ipip: Set the protocol type as IP-IP.

    • then decapsulate ipip: Decapsulate the IP-IP packet. The inner IP destination address is routed using the inet.0 routing table by default.

    • then decapsulate ipip routing-instance routing-instance-name: Decapsulate the IP-IP packet and route the inner destination address using the specified routing instance.

    Use show firewall to view the configuration.

    [See filter (Firewall Filters) and Configuring IP Tunnel Interfaces.]

Juniper Extension Toolkit (JET)

  • Support for static backup paths with IP-in-IP tunnel encapsulation and provisioning APIs (MX Series, PTX Series, and QFX10002)—We’ve enhanced Juniper Extension Toolkit (JET) APIs to enable a controller to set up underlay network backup paths that use IP-in-IP tunnels with IPv4 encapsulation. JET APIs notify the controller of active paths, interfaces, and changes to the interface state. The loop-free backup paths help quickly restore failed core transport networks built with only IP protocols.

    [See JET APIs on Juniper EngNet.]

  • Support for policy match condition to match programmed routes (MX Series, PTX Series, and QFX10002)—We’ve introduced a new option programmed that allows policy matches for routes injected by JET APIs. To allow policy matches for routes injected by JET APIs, use the programmed option at the [edit policy-options policy-statement policy-name term term-name from] hierarchy level. To view details about programmed routes, use the show route programmed (detail | extensive) command.

    [See policy-statement and show route.]

  • RIB service API option to control route distribution (MX Series, PTX Series, and QFX10002)—We’ve added a no-advertise flag to the RIB service API per-route RouteAttributes object to limit re-advertisement of the provisioned route. You can set this flag to TRUE to prevent the route from being redistributed to routing protocols and advertised to peers.

    [See JET APIs on Juniper EngNet.]

  • Juniper Extension Toolkit (JET) supports BFD Service APIs for routing protocol process (rpd) programmability (MX Series, PTX Series, QFX Series, and vMX)—Starting in Junos OS Release 20.3R1, you can use programmable rpd (prpd) BFD APIs to add, update, and delete BFD sessions and subscribe to BFD events from outside applications. These APIs enable the integration of rpd with software-defined networking (SDN) controllers and increase the flexibility of your network. The prpd BFD APIs support BFD Echo-Lite sessions in single-hop IPv4 and IPv6 modes.

    The following BFD Service APIs are supported:

    • Initialize

    • SessionAdd

    • SessionUpdate

    • SessionDelete

    • SessionDeleteAll

    • Subscribe

    • Unsubscribe

    Use the show bfd session extensive command to view BFD sessions. BFD sessions added through prpd BFD APIs are labeled with PRPD:<session-id> in the client field. The <session-id> is 1 for the first BFD session that is added, 2 for the second, and so on.

    [See show bfd session extensive and JET APIs on Juniper EngNet.]

Junos OS XML, API, and Scripting

  • Support for REST API over nondefault virtual routing and forwarding (VRF) instance (EX Series, MX Series, PTX Series, QFX Series, and SRX Series)—Starting in Junos OS Release 20.3R1, you can execute Junos OS operational commands using the REST API over a nondefault VRF instance. The nondefault VRF instance can be a user-defined instance or the management instance, mgmt_junos.

    The REST API allows you to execute Junos OS operational commands over HTTP(S). If you don’t specify a routing instance, REST API requests are sent over the default routing instance. Use a nondefault VRF instance to improve security and make it easier to troubleshoot.

    Use the routing-instance routing-instance statement at the [edit system services rest] hierarchy level to specify a nondefault VRF instance for REST API requests.

    [See Management Interface in a Nondefault Instance and rest.]

Junos Telemetry Interface

  • Support for forwarding information base (FIB) sensor on JTI (MX Series and PTX Series)—Starting in Junos OS Release 20.3R1, you can use the Junos telemetry interface (JTI) and remote procedure calls (gRPC) services to stream or export ON_CHANGE FIB, also known as forwarding table, statistics to outside collectors. This feature supports the OpenConfig YANG model OC-AFT.

    To enable and manage FIB streaming, include the following statements on the client device:

    • set system fib-streaming and delete system fib-streaming statements at the [edit] hierarchy level to launch or terminate the process.

    • set system fib-streaming traceoptions file file-name statement at the [edit] hierarchy level to configure a logging file.

    • set system fib-streaming traceoptions flag flag-name statement at the [edit] hierarchy level to configure various trace parameters.

    • set system fib-streaming traceoptions level level-name statement at the [edit] hierarchy level to configure log levels.

    Use the restart fib-streaming command to restart the process.

    To show information about FIB streaming, use the following operational mode commands on the client device:

    • show fib-streaming

    • show fib-streaming next-hop-groups

    • show fib-streaming next-hops

    • show fib-streaming routes ipv4-unicast

    • show fib-streaming routes ipv6-unicast

    • show fib-streaming routes mpls

    The following table shows supported sensors:

    Table 6: Supported Sensors

    Supported Sensors

    /network-instances/network-instance/afts/next-hop-groups/next-hop-group/conditional/condition/

    /network-instances/network-instance/afts/next-hop-groups/next-hop-group/conditional/condition/id

    /network-instances/network-instance/afts/next-hop-groups/next-hop-group/conditional/condition/state/id

    /network-instances/network-instance/afts/next-hop-groups/next-hop-group/conditional/condition/state/dscp[]

    /network-instances/network-instance/afts/next-hop-groups/next-hop-group/conditional/condition/state/next-hop-group

    /network-instances/network-instance/afts/next-hop-groups/next-hop-group/conditional/condition/input-interfaces/input-interface

    /network-instances/network-instance/afts/next-hop-groups/next-hop-group/conditional/condition/input-interfaces/input-interface/id

    /network-instances/network-instance/afts/next-hop-groups/next-hop-group/conditional/condition/input-interfaces/input-interface/state/id

    /network-instances/network-instance/afts/next-hop-groups/next-hop-group/conditional/condition/input-interfaces/input-interface/state/interface

    /network-instances/network-instance/afts/next-hop-groups/next-hop-group/conditional/condition/input-interfaces/input-interface/state/subinterface

    /network-instances/network-instance/afts/ipv4-unicast/ipv4-entry/prefix

    /network-instances/network-instance/afts/ipv4-unicast/ipv4-entry/state/prefix

    /network-instances/network-instance/afts/ipv4-unicast/ipv4-entry/state/next-hop-group

    /network-instances/network-instance/afts/ipv6-unicast/ipv6-entry/prefix

    /network-instances/network-instance/afts/ipv6-unicast/ipv6-entry/state/prefix

    /network-instances/network-instance/afts/ipv6-unicast/ipv6-entry/state/next-hop-group

    /network-instances/network-instance/afts/mpls/label-entry/label

    /network-instances/network-instance/afts/mpls/label-entry/state/label

    /network-instances/network-instance/afts/mpls/label-entry/state/next-hop-group

    /network-instances/network-instance/afts/mpls/label-entry/state/popped-mpls-label-stack

    This leaf reports the same label value in case of pop or swap.

    /network-instances/network-instance/afts/next-hop-groups/next-hop-group/id

    /network-instances/network-instance/afts/next-hop-groups/next-hop-group/next-hops/nexthop/index

    /network-instances/network-instance/afts/next-hop-groups/next-hop-group/next-hops/nexthop/state/weight

    /network-instances/network-instance/afts/nexthops/nexthop/index

    /network-instances/network-instance/afts/next-hops/next-hop/juniper/state/lsp-id

    This leaf is a new augmentation.

    /network-instances/network-instance/afts/next-hops/next-hop/state/ip-address

    /network-instances/network-instance/afts/next-hops/next-hop/state/mac-address

    /network-instances/network-instance/afts/next-hops/next-hop/state/pushed-mpls-label-stack

    /network-instances/network-instance/afts/next-hops/next-hop/interface-ref/state/interface

    /network-instances/network-instance/afts/next-hops/next-hop/interface-ref/state/subinterface

    /network-instances/network-instance/afts/next-hops/next-hop/juniper/state/mapped-next-hop-index

    This leaf is a new augmentation.

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

  • Support for aggregated Ethernet interface ON_CHANGE with JTI (MX5, MX10, MX40, MX80, MX104, MX150, MX204, MX240, MX480, MX960, MX2008, MX2010, MX2020, MX10003, MX10008, MX10016, PTX1000, PTX3000, PTX5000, PTX10001-36MR, PTX10002, PTX10008, PTX10016, QFX5100, QFX5110, QFX5120, QFX5200, QFX5210, QFX10002, QFX10008, and QFX10016)—Starting in Junos OS Release 20.3R1, Junos telemetry interface (JTI) supports ON-CHANGE statistics for aggregated Ethernet interfaces for minimum links and member interfaces.

    To export these statistics to an outside collector using remote procedure call (gRPC) services and JTI, include the following resource paths in a subscription:

    • /interfaces/interface/aggregation/state/min-links/

    • /interfaces/interface/aggregation/state/member/

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

Layer 3 Features

  • Support for BGP Layer 3 VPN over IP-IP Tunnel (MX Series, PTX1000, QFX10002, and QFX10008)—Starting in Junos OS Release 20.3R1, we support BGP Layer 3 VPN over IP over IP (IP-IP) tunnels to create a new transport service. IP-IP tunnels terminate into service-layer VRF, so you do not need to use a service label. This feature allows interoperability between the new VRF and traditional VRF, so both types of overlays can coexist in your network. You can use this feature to transition from an MPLS network to an IP fabric core network and to protect your network from distributed denial-of-service (DDoS) attacks.

    To use VPN over an IP-IP tunnel, configure the tunnel-attribute statement at the [edit policy-options policy-statement policy-name term term-name then] or [edit policy-options policy-statement policy-name then] hierarchy level.

    To configure the receiver to program the dynamic tunnel using the tunnel attribute, use the extended-nexthop-tunnel statement at the [edit routing-instances routing-instance-name protocols bgp group group-name family (inet-vpn | inet6-vpn) unicast] hierarchy level.

    [See BGP Layer 3 VPN over IP-IP Tunnels Overview, family (Protocols BGP), policy-statement, vrf-export, and Configuring IP Tunnel Interfaces.]

MPLS

  • New output fields added in the show path-computation-client lsp extensive command (MX Series, PTX Series, and QFX Series)—Starting in Junos OS Release 20.3R1, you’ll see association details such as Association type, ID, and source in the output of the show path-computation-client lsp command when you use the command with the extensive option.

    [See show path-computation-client lsp.]

Network Management and Monitoring

  • Probe command to query the status of the probed interfaces (ACX Series, EX Series, MX Series, PTX Series, QFX Series, and SRX Series)—Starting in Junos OS Release 20.3R1, you can use the probe command to query the status of the probed interface. The proxy interface resides on the same node as the probed interface, or it can reside on a node to which the probed interface is directly connected.

    The Probe command helps to capture the interface details such as probe packet statistics, and interface state (active/inactive), irrespective of whether the network family address configured is IPv4 or IPv6 on the probed interfaces.

    To enable the probe command, configure the extended-echo statement under the [edit system] hierarchy.

    [See Using the Probe command.]

  • Enhanced sFlow (PTX5000)—Starting in Junos OS Release 20.3R1, you can use sFlow to detect and sample MPLS and GRE traffic flows on PTX5000 routers. sFlow technology is a monitoring technology for high-speed switched or routed networks.

    [See Overview of sFlow Technology.]

  • Enhancements to sessions over outbound HTTPS (EX Series, MX Series, PTX1000, PTX3000, PTX5000, PTX10001, PTX10002, PTX10008, PTX10016, QFX Series, SRX1500, SRX4100, SRX4200, SRX4600, SRX5600, SRX5800, and vSRX)—Starting in Junos OS Release 20.3R1, devices running Junos OS with upgraded FreeBSD support the following enhancements to sessions over outbound HTTPS:

    • Connecting to multiple outbound HTTPS clients by configuring one or more clients at the [edit system services outbound-https] hierarchy level

    • Configuring multiple backup gRPC servers for a given outbound HTTPS client

    • Establishing a csh session

    • Establishing multiple, concurrent NETCONF and csh sessions between the device running Junos OS and an outbound HTTPS client

    • Configuring a shared secret that the outbound HTTPS client uses to authenticate the device running Junos OS

    • Authenticating the client using certificate chains in addition to self-signed certificates

    [See NETCONF and Shell Sessions over Outbound HTTPS.]

Port Security

  • MACsec preshared key hitless rollover (PTX10008 and PTX10016)—Starting in Junos OS Release 20.3R1, we support preshared key (PSK) hitless rollover for Media Access Control Security (MACsec) on the PTX10K-LC1104 and PTX10K-LC1105 line cards. PSK hitless rollover uses a keychain of multiple security keys to prevent session drops when the connectivity association key (CAK) configuration changes.

    [See Configuring Media Access Control Security (MACsec) on Routers.]

  • Timer-based MACsec SAK refresh (MX10003, PTX10001, PTX10003, PTX10008, and PTX10016)—Starting in Junos OS Release 20.3R1, you can configure a time-based refresh of the secure association key (SAK) on a Media Access Control Security (MACsec)-secured link. The key server generates the SAK and refreshes it periodically. The key server also sets a refresh interval, by default, based on packet counter movement. If the refresh does not occur frequently, this can leave the SAK vulnerable to attack. You can enhance security of the SAK by configuring a shorter time-based refresh interval.

    [See Understanding Media Access Control Security (MACsec).]

Routing Protocols

  • Support for Implicit filter for default EBGP route propagation behavior without policies (ACX Series, JRR200, MX204, vRR and PTX5000)—Starting in Junos OS Release 20.3R1, we’ve introduced a new configuration hierarchy, defaults ebgp no-policy at the existing [edit protocols bgp] hierarchy level. The configuration option separates the default policy for receive and advertise, into separate clauses (accept, reject, or reject-always) to allow the route propagation behavior of EBGP speakers to vary independently from its default behavior.

    In earlier releases, the default behavior of BGP was to receive and advertise all routes. With the introduction of this feature, the default behavior still remains to “accept” all routes for both receive and advertise, but you also have an option to reject routes by default.

    With the reject configuration, you can reject routes of type inet unicast and inet6 unicast in instance types master, vrf, virtual-router, and non-forwarding. With the reject-always configuration, you can reject all routes from being received or getting advertised, irrespective of address family or instance type. By using this feature, you can control traffic in leaf autonomous systems (AS) and thereby, prevent them from having to accidentally function as transit autonomous systems.

    Note

    The introduction of this implicit filter does not affect the existing deployments that rely on the default behavior.

    [See Implicit Filter for Default EBGP route propagation behavior without policies and defaults.]

  • TI-LFA SRLG protection and fate-sharing protection for OSPFv2 (MX Series and PTX Series)—Starting in Junos OS Release 20.3R1, you can configure Shared Risk Link Group (SRLG) protection and fate-sharing protection for segment routing to choose a fast reroute path that does not include SRLG links and fate-sharing groups in the topology-independent loop-free alternate (TI-LFA) backup paths to avoid fate-sharing and SRLG failures. This is in addition to existing fast reroute options such as link-protection and node protection for segment routing.

    To enable TI-LFA SRLG protection and fate-sharing protection with segment routing for OSPFv2, include the srlg-protection statement and the fate-sharing-protection statement respectively at the [edit protocols ospf area area-id interface name post-convergence-lfa] hierarchy level.

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

  • BGP sharding for IPv4 and Ipv6 L3VPN, BGP-LU (MX Series, PTX-Series and vRR)—Starting in Release 20.3R1, Junos OS supports BGP sharding and update IO features for these IPv4 and Ipv6 address families:

    • inet-vpn unicast

    • inet-vpn multicast (vrf.inet.2)

    • inet6-vpn unicast

    • inet6-vpn multicast (vrf.inet.2)

    • inet labeled-unicast

    • inet6 labeled-unicast

    To enable BGP sharding, configure rib-sharding at the [edit system processes routing bgp] hierarchy level. Sharding is dependent on the update I/O thread feature. To enable update I/O, configure update-threading at the [edit system processes routing bgp] hierarchy level.

    BGP Sharding is supported only on 64-bit routing protocol process (rpd) where the Routing Engine has at least 4 CPU cores and 16 GB of memory. To enable your device to always use 64-bit mode, use set force-64-bit at [edit system processes routing] hierarchy level. If you configure rib-sharding on a routing engine, RPD creates sharding threads. By default, the number of sharding threads created is the same as the number of CPU cores on the routing engine. Optionally, you can specify the number-of-shards you want to create. To set the number of sharding threads, use set number-of-shards <number-of-shards> at [edit system processes routing bgp rib-sharding] hierarchy level. To set the number of update threads, use set number-of-threads <number-of-threads> at the [edit system processes routing bgp update-threading] hierarchy level. To enable your device to always use 64-bit mode, use set force-64-bit at [edit system processes routing] hierarchy level.

    [See rib-sharding and update-threading.]

  • ECMP nexthop update rate throttling (MX Series, PTX Series, and QFX Series)—Starting in Junos OS Release 20.3R1, you can choose to defer multipath computation for all families during a BGP peering churn. In very large-scale network deployments during BGP peering churn there is a temporary spike in multipath computation, which takes a toll on the Packet Forwarding Engine resources. This feature allows you to pause the multipath computation and to resume after the peering churn settles down. Note that if there is no BGP peering churn, then multipath computation is not paused.

    To enable the pause option for BGP multipath computation during BGP peering churn, include the pause computation statement at the [edit protocols BGP multipath] hierarchy level.

    [See pause-computation-during-churn.]

Segment Routing

  • Support for LDP Tunneling over Segment Routing Traffic Engineering (MX Series, PTX Series, and ACX5448)—Starting in Junos OS Release 20.3R1, you can tunnel LDP LSPs over Segment Routing Traffic Engineering (SR-TE) in your network. Tunneling LDP over SR-TE provides consistency and co-existence of both LDP LSPs and SR-TE LSPs.

    [See Tunneling LDP over SR-TE.]

Services Applications

  • Support for hardware timestamping of Two-Way Active Measurement Protocol (TWAMP) and real-time performance monitoring (RPM) probe messages (MX10008, MX10016, PTX10008, and PTX10016)—Starting in Junos OS Release 20.3R1, we’ve extended support for hardware timestamping of TWAMP and RPM probe messages. Hardware timestamping is enabled by default for TWAMP, but you must configure it for RPM. You use TWAMP and RPM to measure IP performance between two devices in a network. By configuring hardware timestamping for RPM, you can account for the latency in the communication of probe messages and generate more accurate timers in the Packet Forwarding Engine. To configure hardware timestamping for RPM, include the hardware-timestamping statement at the [edit services rpm probe probe-owner test test-name] hierarchy level.

    [See Understanding Two-Way Active Measurement Protocol on Routers, Understanding Using Probes for Real-Time Performance Monitoring on M, T, PTX and MX Series Routers, and Configuring RPM Timestamping on MX, M, T, and PTX Series Routers and EX Series Switches.]

  • IPFIX IPv4 and IPv6 template support for forwarding class and PLP (PTX1000, PTX10008 (without the JNP10008-SF3), and PTX10016)—Starting in Junos OS Release 20.3R1, two more information elements have been added to the IPFIX IPv4 and IPv6 templates. These elements carry the packet loss priority (PLP) values and the first two characters of the configured forwarding class name that the sampled packet carries. The collector uses these elements to derive the DiffServ code point (DSCP) bits that the packet would contain while exiting the router. To use these elements, you must configure the next-hop-learning enable statement at the [edit services flow-monitoring version-ipfix template name] hierarchy level.

    [See nexthop-learning.]

What's Changed

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 20.3R3 for the PTX Series.

What's Changed in Release 20.3R3

General Routing

  • Change in OID ifHighSpeed—Now, the object identifier (OID) ifHighSpeed displays the negotiated speed once negotiation is completed. If the speed is not negotiated, ifHighSpeed displays the actual maximum speed of the interface. In earlier releases, ifHighSpeed always displayed the actual speed of the interface.

    [See SNMP MIBs and Traps Supported by Junos OS.].

Interfaces and Chassis

  • Warning message when taking an FPC offline—PTX10003-80C and PTX10003-160C devices do not support the request chassis fpc slot slot-number online command. The only way to bring up an FPC (MPC) that is offline is by rebooting the chassis. So, when you take an FPC offline by using the request chassis fpc slot slot-number online command, the screen displays the following message. 'Warning : FPC <slot> cannot be made online using a CLI command. You need to perform router reboot using "request system reboot" to online the FPC <slot>. Do you wish to continue ? [yes,no] (no).

    [See request chassis fpc].

  • Blocking duplicate IP detection in the same routing instance (ACX Series, EX Series, MX Series, NFX Series, PTX Series, QFX Series, and SRX Series)—Junos will no longer accept duplicate IPs between different logical interfaces in the same routing instance. Refer to the table mentioned in the topic inet (interfaces). When you try to configure same IP on two logical interfaces inside same routing instance, the commit will be blocked with the error displayed as shown below: [edit] user@host# set interfaces ge-0/0/1 unit 0 family inet address 2.2.2.2/24 [edit] user@host# commit commit complete [edit] user@host# set interfaces ge-0/0/2 unit 0 family inet address 2.2.2.2/24 [edit] user@host# commit [edit interfaces ge-0/0/2 unit 0 family inet] 'address 2.2.2.2/24' identical local address found on rt_inst [default], intfs [ge-0/0/2.0 and ge-0/0/1.0], family [inet]. error: configuration check-out failed

    [See inet(interfaces).]

Layer 2 Ethernet Services

  • Link selection support for DHCP—We have introduced the link-selection statement at the [edit forwarding-options dhcp-relay relay-option-82] hierarchy level, which allows DHCP relay to add suboption 5 to option 82. Suboption 5 allows DHCP proxy clients and relay agents to request an IP address for a specific subnet from a specific IP address range and scope. Prior to this release, the DHCP relay dropped packets during the renewal DHCP process and the DHCP server used the leaf's address as a destination to acknowledge the DHCP renewal message.

    [See relay-option-82.]

Network Management and Monitoring

  • Change in OID ifHighSpeed—Now, the object identifier (OID) ifHighSpeed displays the negotiated speed once negotiation is completed. If the speed is not negotiated, ifHighSpeed displays the actual maximum speed of the interface. In earlier releases, ifHighSpeed always displayed the actual speed of the interface.

    [See SNMP MIBs and Traps Supported by Junos OS.]

What's Changed in Release 20.3R2

General Routing

  • Control plane DDoS protection packet type option for ARP traffic (PTX Series and QFX Series)—Starting in this release, we've renamed the arp-snoop packet type option in the [edit system ddos-protection protocols] arp protocol group to arp. This packet type option enables you to change the default control plane distributed denial of service (DDoS) protection policer parameters for ARP traffic.

    [See protocols (DDoS) (PTX Series and QFX Series).]

  • Loading of the default configurations in a RIFT package causes the following changes:

    1. Output of the show rift node status command displays the node ID in hexadecimal number even though the node ID is configured in decimal, hexadecimal, or octal number.

    2. Some of the DDoS default configurations change because of the DDoS protection interferes with the RIFT BFD operation.

  • New commit check for MC-LAG (MX Series, PTX Series, QFX Series)—We've introduced a new commit check to check the values assigned to the redundancy group identification number on the MC-AE interface ( redundancy-group-id ) and ICCP peer (redundancy-group-id-list ) when you configure multichassis aggregation groups (MC-LAGs). If the values are different, the system reports a commit check error. In previous releases, if the configured values were different, the l2ald process would crash.

    [See iccp and mc-ae.]

Junos OS XML API and Scripting

  • The jcs:invoke() function supports suppressing root login and logout events in system log files for SLAX commit scripts (ACX Series, EX Series, MX Series, PTX Series, QFX Series, and SRX Series)—The jcs:invoke() extension function supports the no-login-logout parameter in SLAX commit scripts. If you include the parameter, the function does not generate and log UI_LOGIN_EVENT and UI_LOGOUT_EVENT messages when the script logs in as root to execute the specified RPC. If you omit the parameter, the function behaves as in earlier releases in which the root UI_LOGIN_EVENT and UI_LOGOUT_EVENT messages are logged in system log files.

    [See invoke() Function (SLAX and XSLT).]

  • The jcs:invoke() function supports suppressing root login and logout events in system log files for SLAX event scripts (ACX Series, EX Series, MX Series, PTX Series, QFX Series, and SRX Series)—The jcs:invoke() extension function supports the no-login-logout parameter in SLAX event scripts. If you include the parameter, the function does not generate and log UI_LOGIN_EVENT and UI_LOGOUT_EVENT messages when the script logs in as root to execute the specified RPC. If you omit the parameter, the function behaves as in earlier releases in which the root UI_LOGIN_EVENT and UI_LOGOUT_EVENT messages are logged in system log files.

    [See invoke() Function (SLAX and XSLT).]

MPLS

  • The show mpls lsp extensive and show mpls lsp detail commands display next-hop gateway LSPid—When you use the show mpls lsp extensive and show mpls lsp detail commands, you'll see next-hop gateway LSPid in the output.

User Interface and Configuration

  • Verbose format option to export JSON configuration data (ACX Series, EX Series, MX Series, PTX Series, QFX Series, and SRX Series)—The Junos OS CLI exposes the verbose statement at the [edit system export-format json] hierarchy level. The default format to export configuration data in JSON changed from verbose format to ietf format starting in Junos OS Release 16.1R1. You can explicitly specify the default export format for JSON configuration data by configuring the appropriate statement at the [edit system export-format json] hierarchy level. Although the verbose statement is exposed in the Junos OS CLI as of the current release, you can configure this statement starting in Junos OS Release 16.1R1.

    [See export-format.]

What's Changed in Release 20.3R1

Class of Service (CoS)

  • We’ve corrected the output of the show class-of-service interface | display xml command. Output of the following sort: <container> <leaf-1> data </leaf-1><leaf-2>data </leaf-2> <leaf-3> data</leaf-3> <leaf-1> data </leaf-1> <leaf-2> data </leaf-2> <leaf-3> data </leaf-3> </container> will now appear correctly as <container> <leaf-1> data </leaf-1><leaf-2>data </leaf-2> <leaf-3> data</leaf-3></container> <container> <leaf-1> data </leaf-1> <leaf-2> data </leaf-2> <leaf-3> data </leaf-3> </container>.

General Routing

  • Trigger alarms when a PTX10008 or PTX10016 router has a mix of AC and DC power supplies—If you insert a mix of AC and DC power supply units (PSU) into a PTX10008 or PTX10016 router, Junos OS raises an alarm to indicate that there is a mix of AC and DC power supplies in the router. To fix this alarm, you need to ensure that the router has the same type of power supplies.

    [See Understanding Chassis Alarms.]

  • The show chassis power command displays the power supply state (PTX10008 and PTX10004)—The show chassis power command displays the information regarding the state of the power supply (for instance, Online or Empty). This enhancement makes the show chassis power command output in Junos OS Evolved software consistent with that in Junos OS software.

    [See show chassis power.]

  • Control plane DDoS protection packet type option for ARP traffic (PTX Series and QFX Series)—Starting in this release, we've renamed the arp-snoop packet type option in the [edit system ddos-protection protocols] arp protocol group to arp. This packet type option enables you to change the default control plane distributed denial of service (DDoS) protection policer parameters for ARP traffic.

    [See protocols (DDoS) (PTX Series and QFX Series]

  • IPv6 address in the prefix TIEs displayed correctly—The IPv6 address in the prefix TIEs are displayed correctly in the show rift tie output.

  • Warning changed for configuration statements that correspond to deviate not-supported nodes in YANG data models (ACX Series, EX Series, MX Series, PTX Series, QFX Series, and SRX Series)—If you configure a statement corresponding to a YANG data model node that defines the deviate not-supported statement, the Junos OS configuration annotates that statement with the comment Warning: statement ignored: unsupported platform. In earlier releases, the warning is Warning: 'statement' is deprecated.

  • Python 3 add-on modules (PTX Series)—Junos OS Evolved includes additional Python 3 libraries and modules, which Python scripts can import and use.

    [See Overview of Python Modules on Devices Running Junos OS.]

High Availability (HA) and Resiliency

  • IPv6 address in the prefix TIEs displayed correctly—The IPv6 address in the prefix TIEs are displayed correctly in the show rift tie output.

Junos OS XML, API, and Scripting

  • Changes to Junos XML RPC request tag names (ACX Series, EX Series, MX Series, PTX Series, QFX Series, and SRX Series)—We've updated the Junos XML request tag name for some operational RPCs to ensure consistency across the Junos XML API. Devices running Junos OS still accept the old request tag names, but we recommend that you use the new names going forward. The changes include:

    • Most, but not all, request tag names that start with show replace show with get in the name.

    • Uppercase characters are converted to lowercase.

    [See Junos XML API Explorer - Operational Tags.]

Juniper Extension Toolkit (JET)

  • Set the trace log to only show error messages (ACX Series, EX Series, MX Series, PTX Series, QFX Series, SRX Series)— You can set the verbosity of the trace log to only show error messages using the error option at the edit system services extension-service traceoptions level hierarchy.

    See traceoptions (Services).

MPLS

  • Change in auto bandwidth adjustment (PTX5000)—If auto bandwidth adjustment fails because of bandwidth unavailable error, the router tries to bring up the LSP with the same bandwidth during the subsequent reoptimization. In earlier releases, when the auto bandwidth adjustment fails, the current bandwidth is reset to the bandwidth that was already active.

    See rsvp-error-hold-time.

  • Disable back-off behavior on PSB2 (ACX Series, EX Series, MX Series, PTX Series, QFX Series, and SRX Series)— We've introduced the cspf-backoff-time statement globally for MPLS and LSP to delay the CSPF by configured number of seconds, on receiving bandwidth unavailable PathErr on PSB2. If the configured value is zero, then the CSPF starts immediately for PSB2, when bandwidth-unavailable PathErr is received. If the statement is not configured, the default exponential back-off occurs.

    [ See cspf-backoff-time.]

Routing Protocols

  • Advertising /32 secondary loopback addresses to Traffic Engineering Database (TED) as prefixes (ACX Series, EX Series, MX Series, PTX Series, QFX Series, and SRX Series)—In Junos OS Release, multiple loopback addresses export into lsdist.0 and lsdist.1 routing tables as prefixes. This eliminates the issue of advertising secondary loopback addresses as router-ids instead of prefixes. In earlier Junos OS releases, multiple secondary loopback addresses in TED were added into lsdist.0 and lsdist.1 routing tables as part of node characteristics and advertised them as the router-id.

Known Limitations

Learn about known limitations in Junos OS Release 20.3R3 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

  • When an FPC goes offline or restarts, FPC x sends traffic to FPC y. The following error messages are seen and 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

  • During reconfiguration and link events at the physical interface level, the PECHIP[4]:pe.ipw.misc_int.status:iq_disabled(0): (Count:3561)err_pkt(0) error message can be seen. This does not impact traffic. PR1476553

  • On the PTX1000 routers, the following error message is observed when the sampling MPLS+IPv4/IPv6 traffic is forwarded over the IP-IP tunnel: dlu.ucode.jflow_not_routable pechip. If an entropy label is present in the packet, then the packet has to be recirculated in the ASIC to do IPv4 or IPv6 lookup after stripping the outer entropy labels. If only an explicit NULL label is present, the ASIC has the capability to do the stripping of the NULL label and do IPv4 or IPv6 lookup without doing recirculation. In this case, because the packet has entropy labels, the packet gets recirculated and in the second pass processing, the inet sampling takes effect. J-Flow sampling is not designed to work after MPLS recirculation. This results in offset errors and a corrupted packet is being fed to the J-Flow pipeline in the ASIC. Enable MPLS-IPvx J-Flow on these interfaces and disable the inet filter on these logical interfaces. In this way, the packets will be sampled in first pass itself and not in the second pass. In this case, the exported flow record is MPLS-IPv4 or MPLS-IPv6 and not IPv4 or IPv6. The flow records include explicit NULL and entropy labels in addition to IP. PR1485770

  • Filter based GRE tunneling is supported only in enhance-mode on PTX3000 routers. PR1497819

  • On PTX Series platform with set routing-options resolution preserve-nexthop-hierarchy statement configured, reaching tunnel destination out-going route via BGP-over-BGP route recursive resolution is not supported. PR1498085

  • In a tunnel termination scenario, packets with NULL, EL, and ELI labels followed by IPv4 or IPv6 header are treated as MPLS labeled packets and MPLS flows are created for these packets. Because these packets are treated as MPLS flows, the explicit NULL/EL labels are used for lookup, which results in failing the OIF getting reported as 0 for J-Flow records. PR1502423

  • sFlow for IPoIP traffic is not supported in this release. PR1508919

  • when counter sample is enabled, it attempts to fetch the physical interface statistics for sFlow enabled interfaces using rtsock messages to kernel. This blocks call and wait for the reply of earlier request and sends a new request only after receiving the reply of first one. So, FPC is occupied when this request is made and could not reply on time and hence the scheduler slip occurs. PR1517076

MPLS

  • Increasing ECMP from 64 to 128 might cause the ingress LSP setup rate to be lower because of increased number of next hop changes for the IGP routes using shortcut. PR1421976

  • LDP session might drop during the FRR if the maxecmp is configured to 128 and LDP/IGP has more than 64 RSVP LSP next hops and ldp-tunneling is configured on those next hops. PR1430361

Routing Protocols

  • Commit check fails when rib-sharding is configured with these statements:

    • routing-instances <name> routing-options multipath

    • routing-instances <name> routing-options policy-multipath

    • routing-instances <name> protocols mvpn.

  • Because of a race between route re-converge and the BGP-PIC version up message to the Packet Forwarding Engine, after a remote transit router reboot, certain BGP routes might reuse stale LDP next hops and cause packet discard at the transit router during the route re-convergence window. PR1495435

Open Issues

Learn about open issues in the Junos OS Release 20.3R3 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

  • On PTX Series platforms, some non-fatal interrupts (for example, CM cache or AQD interrupts) are logged as fatal interrupts. The following log messages will be shown on CM parity interrupt: fpc0 TQCHIP 0: CM parity Fatal interrupt,Interrupt status:0x10 fpc0 CMSNG: Fatal ASIC error, chip TQ fpc0 TQCHIP 0: CM cache parity Fatal interrupt has occurred 181 time(s) in 180010 msecs TQCHIP 0: CM cache parity Fatal interrupt has occurred 181 time(s) in 180005 msecs. PR1089955

  • On the PTX Series platforms with FPC-PTX-P1-A or FPC2-PTX-P1A line card might encounter a single event upset (SEU) event that might cause a linked-list corruption of the TQCHIP. The following syslog message is reported: Jan 9 08:16:47.295 router fpc0 TQCHIP1: Fatal error pqt_min_free_cnt is zero Jan 9 08:16:47.295 router fpc0 CMSNG: Fatal ASIC error, chip TQ Jan 9 08:16:47.295 router fpc0 TQ Chip::FATAL ERROR!! from PQT free count is zero jan 9 08:16:47.380 router alarmd[2427]: Alarm set: FPC color=RED, class=CHASSIS, reason=FPC 0 Fatal Errors - TQ Chip Error code: 0x50002 Jan 9 08:16:47.380 router craftd[2051]: Fatal alarm set, FPC 0 Fatal Errors - TQ Chip Error code: 0x50002. The Junos OS chassis management error handling detects such a condition, raises an alarm, and disables the affected Packet Forwarding Engine entity. To recover this Packet Forwarding Engine entity, restart the FPC. Contact your Juniper support representative if the issue persists even after the FPC restart. PR1254415

  • When CFP2-DCO-T-WDM-1 is plugged into a PTX Series PIC, after FPC restarts, the carrier frequency offset TCA is raised even when TCA is not enabled. PR1301471

  • On 30-port MACsec-enabled line card (LC1101-M-30C, LC1101-M-30Q, and LC1101-M-96X) of the PTX10008 chassis, when the exclude-protocol lacp statement is configured at the [edit security macsec connectivity-association connectivity-association-name] hierarchy level is deleted or deactivated, the LACP protocol's Mux State shown under the output of show lacp interface CLI command, might remain as attached or detached and might not change to distributing state. PR1331412

  • Alarm action does not work for minor errors after the threshold is changed to 1. PR1345154

  • The PTX Series platform drops the wireless access point (WAP) heartbeat packets; as a result, the WAP cannot work. PR1352805

  • Due to transient hardware condition, single-bit error (SBE) events are corrected and have no operational impact. Reporting of those events had been disabled to prevent alarms and possibly unnecessary hardware replacements. This change applies to all platforms using Hybrid Memory Controller (HMC). PR1384435

  • On the PTX3000 routers, the firewall counter for lo0 does not increment. PR1420560

  • When the firewall filter has Port-Mirror as an action along with discard action, the mirrored packet will have two Layer 2 headers. The first Layer 2 header will be the original Layer 2 header and the second Layer 2 header will be egress interface Layer 2 header. This causes packet corruption and packets get discarded. PR1437546

  • Memory leaks are expected in this release. PR1438358

  • On PTX1000 and PTX10001 routers, the port mirror does not work when the port-mirroring is configured with the firewall filter. PR1491789

  • The show chassis fpc command reports high CPU utilization in steady state. PR1492731

  • IPv4 traffic verification of interface statistics at logical interfaces level aggregated Ethernet bundle is failed. PR1531358

  • Flapping might be observed on channelized ports of PTX Series routers during ZTP, when one of the port is disabled on the supporting device. PR1534614

  • When we run continuous sync (show interfaces aex extensive) and async (SNMP polling) queries on aggregated Ethernet interface in parallel, we might observe spikes in aggregated Ethernet interface framing error counter in between correct values. PR1539537

  • IS-IS over Layer 2 circuit will not come up if the encapsulation is TCC. PR1590387

Layer 2 Ethernet Services

  • The copying of files to the RCB over WAN ports is slow. PR1496895

MPLS

  • At high scale, LSP setup rate will be relatively slower in IP-in-IP networks. PR1457992

Routing Protocols

  • In a Layer 3 VPN scenario, the rpd process on the backup Routing Engine might crash when BGP (standby) received a VPN route from the peer that is rejected due to invalid target community, because the BGP standby peer synchronization is not complete yet. PR1508888

Resolved Issues

Learn which issues were resolved in the Junos OS Release 20.3R3 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: 20.3R3

General Routing

  • On PTX10008 router, FPC UKERN core file is not transferred to Routing Engine in a scaled setup. PR1500418

  • The following error message might be seen after link flap: t6e_dfe_tuning_state:et-6/0/0 - Failed to dfe tuning count 10. PR1512919

  • Traffic might get dropped when the set routing-options forwarding-table no-ecmp-fast-reroute configuration is changed to 128 ECMP entries. PR1547457

  • The interface filter with source-port 0 matches everything instead of port 0. PR1551305

  • An enhancement to enable watchdog petting log on PTX10K line cards. PR1561980

  • Upgrading PTX1000 with unified SSDs (2x32G SSD) might result in boot loop in certain scenario. PR1571275

  • Traffic loss might be observed on the PTX5000 platform. PR1578511

  • TACACS traffic might get dropped on PTX platforms. PR1578579

  • When rpf-check is configured on PE chip based PTX platforms, the traffic might be dropped. PR1580211

  • On PTX5000 and PTX3000 routers, configuring and deleting the FEC mode disables the auto-FEC91 on an interface that uses QSFP28-SR4. PR1582200

  • Node locked license addition fails. PR1582704

  • The following error message is seen during bring up: Failed to get pechip handle for chip 0" and "prds_encap_sample_flood_lpbk_desc_install: Egress NH descriptor install OK for Flabel 7808. PR1585594

Infrastructure

  • The kernel crash with core file might be seen if churn happens for a flood composite next hop. PR1548545

Multicast

  • FPC might crash in a multicast scenario. PR1569957

Network Management and Monitoring

  • The mib2d process crashes and generates a core file on backup Routing Engine. PR1557384

Platform and Infrastructure

  • The BGP session replication might fail to start after the session crashes on the backup Routing Engine. PR1552603

  • FPC crash might be observed in a scaled firewall configuration on PTX Series platforms. PR1586817

Routing Policy and Firewall Filters

  • Generated route goes to the hidden state when the protect core command is enabled. PR1562867

Routing Protocols

  • Traffic might be silently discarded when the BGP route gets deleted, which is part of multipath. PR1514966

  • BGP LU session flap might be seen with the AIGP used scenario. PR1558102

Resolved Issues: 20.3R2

General Routing

  • On PTX10016 routers, if aggregated Ethernet member or interface flow control is in disabled state, then it does not enable its own. PR1478715

  • SNMP index in the Packet Forwarding Engine reports as 0. This causes the sFlow records to have either IIF (Input interface value) or OIF (Output interface value) as 0 value in sFlow record data at collector. PR1484322

  • On PTX5000 and PTX3000 routers, the FPC E might get stuck. PR1519673

  • The chassisd memory leak might cause traffic loss. PR1537194

  • The error message expr_dfw_action_topo_connect_anh:1434 expr_dfw_action_topo_connect_anh:eda_anh_discard is FALSE for nh-id 568 - return is observed in PTX1000 routers. PR1540064

  • The Packet Forwarding Engine might crash in MPLS IPv6-tunneling scenario when the next hop changes. PR1540793

  • Traffic might be silently dropped and discarded after swapping an FPC type 3 card with an FPC type 1 card in the same slot on a PTX3000 router. PR1547790

  • RPD crash might be seen when BGP service route is resolved over color-only SR-TE policy. PR1550736

  • Interface filter with source-port 0 is matching everything instead of just port 0. PR1551305

  • An enhancement to enable watchdog petting log on the PTX10000 line cards. PR1561980

Forwarding and Sampling

  • The l2ald process might crash due to next hop issue in the EVPN-MPLS. PR1548124

Infrastructure

  • Output might display 0 temporarily during a race condition for show interfaces extensive command when SNMP query for JnxCos is issued. PR1533314

  • Interface drop counters might display 0 during a race condition and voq statistics are also polled simultaneously. PR1537960

  • The kernel crashes and core file generates if churn happens for a flood composite next hop. PR1548545

Interfaces and Chassis

  • EOAM IEEE802.3ah link discovery state is Down instead of Active Send Local after deactivating interfaces on routers. PR1532979

  • Logs not being written in /var/log/messages on certain PTX platforms. PR1551374

Network Management and Monitoring

  • The syslog messages might not be sent with correct port. PR1545829

Platform and Infrastructure

  • The BGP session replication might fail to start after the session crashes on the backup Routing Engine. PR1552603

Routing Policy and Firewall Filters

  • Generate route goes to hidden state when protect core statement is enabled. PR1562867

Routing Protocols

  • The rpd process generates the core file at gp_rtarget_tsi_update,bgp_rtarget_flash_rt,bgp_rtarget_flash. PR1541768

  • BGP LU session might flap with AIGP scenario. PR1558102

Resolved Issues: 20.3R1

General Routing

  • On PTX5000 and PTX10008 routers, the show filter index < number> counter vty command displays values as zero at 28-02-HOSTBOUND_NDP_DISCARD_TERM. PR1420057

  • The show snmp mib walk jnxContentsDescr command does not show fan controllers. PR1455640

  • PHP device has NH mis-programming for members of ECMP for SR label route used for reaching IPv6 destinations. PR1457230

  • The PTX1000 and PTX10002 routers might discard traffic silently after the transient SIB or FPC voltage alarms. PR1460406

  • Optics-options syslog and link-down do not work as expected on PTX5000 with FPC3. PR1461404

  • The router might become nonresponsive and bring traffic down when the disk space becomes full. PR1470217

  • On PTX10016 routers, after device reboot, the FPC takes a long time to come up and hence MKA sessions establishment is delayed. The error message Frame 08: sp = 0x48d222b8, pc = 0x10fad3bc , blaze fpc2 SCHED: Thread 59 (PFE Manager) ran for 2177 ms without yielding is observed. PR1477585

  • Disk usage might keep increasing on PTX1000 platforms. PR1480217

  • LSP auto-bandwidth adjust-interval change does not get detected on commit in some cases. PR1484801

  • The Layer 2 VPN might flap and the CE-facing interface cannot restore the TX optical laser power even if the Layer 2 VPN is up under asynchronous-notification. PR1486181

  • Dynamic tunnels trace options do not offer state tracing and cause JTASK_SCHED_SLIP with single underlay route bounce. PR1493236

  • Kernel routing table queue become nonresponsive after J-Flow sampling of a malformed packet. PR1495788

  • Outbound SSH connection flaps or a memory leak issue during push configuration to ephemeral database with high rate. PR1497575

  • Packet drop is observed following an RSVP load-balance configuration on PTX10003 routers. PR1500711

  • Routes are being installed in the Packet Forwarding Engine even when the interface is down or disabled. PR1501321

  • An error message PFE_ERROR_FAIL_OPERATION: IFD et-1/0/8: RS credits failed to return: init=192 curr=193 chip=5 is observed. PR1502716

  • When you want to delete a YANG package, event-options (if configured) hierarchy has to be deactivated before issuing the request system yang delete command. PR1502939

  • On a dual Routing Engine GRES or NSR enabled PTX10008 or PTX10016 router, a few TCP-based application sessions such as BGP or LDP might flap upon Routing Engine mastership switch. PR1503169

  • Unable to bring the ports up when plugging the optic QSFP-100G-LR4-T2 (740-061409) into PTX3000 or PTX5000 routers. PR1511492

  • The routes update might fail because of an HMC memory issue, and traffic impact might be seen. PR1515092

  • On PTX10002-60C and PTX1000 routers, sFlow adaptive-sampling with rate limiter statement enabled, crosses the sample rate 65535. PR1525589

Interfaces and Chassis

  • When multiple CFM sessions are configured on a physical interface, SNMP walk of ieee8021CFMStack table fails. PR1517046

MPLS

  • BGP session might keep flapping between two directly connected BGP peers because of the incorrect TCP-MSS in use. PR1493431

  • The rpd process might crash in a rare condition in an SR-TE scenario. PR1493721

  • If the automatic bandwidth adjustment fails due to bandwidth unavailability, during the subsequent retries, it tries to bring up the LSP with the same bandwidth that was last requested. PR1504916

  • SNMP trap is sent with incorrect OID jnxSpSvcSetZoneEntered. PR1517667

Network Management and Monitoring

  • SNMP response packets have Don't Fragment (DF) flag set by default. PR1514156

Routing Protocols

  • The show dynamic-tunnels database command does not reflect the current value of traffic statistics. It shows the cached value of traffic statistics, which might not be equal to the current value. PR1445705

  • On PTX3000 and PTX5000 routers, the ppmd process generates a core file after configuring the sbfd responder on the RE-DUO-2600. PR1477525

  • The BGP route-target family might prevent the route reflector from reflecting Layer 2 VPN and Layer 3 VPN routes. PR1492743

Documentation Updates

There are no errata or changes in Junos OS Release 20.3R3 documentation for PTX Series routers.

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.

Basic Procedure for Upgrading to Release 20.3

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 Installation and Upgrade Guide.

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 20.3R3:

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

    https://support.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 by 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

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

    All customers except the customers in the Eurasian Customs Union (currently composed of Armenia, Belarus, Kazakhstan, Kyrgyzstan, and Russia) can use the following package:

    user@host> request system software add validate reboot source/junos-install-ptx-x86-64-20.3R3.9.tgz

    Customers in the Eurasian Customs Union (currently composed of Armenia, Belarus, Kazakhstan, Kyrgyzstan, and Russia) can use the following package (limited encryption Junos OS package):

    user@host> request system software add validate reboot source/junos-install-ptx-x86-64-20.3R3.9-limited.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

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

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 19.2, 19.3, and 19.4 are EEOL releases. You can upgrade from Junos OS Release 19.2 to Release 19.3 or from Junos OS Release 19.2 to Release 19.4. 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://support.juniper.net/support/eol/software/junos/.

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.