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 the QFX Series

 

These release notes accompany Junos OS Release 20.3R1 for the QFX 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 the Junos OS main and maintenance releases for QFX Series switches.

Note

The following QFX Series platforms are supported in Release 20.3R1: QFX5100, QFX5110 (32Q and 48S), QFX5120, QFX5200, QFX5210, QFX10002, QFX10002-60C, QFX10008, and QFX10016.

Junos on White Box runs on Accton Edgecore AS7816-64X switches in this release. The software is based on Junos OS running on QFX5210 switches, so release-note items that apply to QFX5210 switches also apply to Junos on White Box.

Hardware

  • We’ve added the following features to the QFX5120-48T in Junos OS Release 20.3R1.

    Table 5: Features Supported by the QFX5120-48T

    Feature

    Description

    Firewall filters and policers

    Timing and synchronization

  • Support for QSFP-100G-DR transceivers (QFX5200, QFX5120-32C, QFX5120-48Y, QFX10002-72, and QFX10002-60C)—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

    The QSFP-100G-DR 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 the QSFPP-4X10GE-SR and JNP-QSFP-4X10GE-LR transceivers (QFX5120)—Starting in Junos OS Release 20.3R1, QFX5120 switches support the QSFPP-4X10GE-SR and JNP-QSFP-4X10GE-LR transceivers.

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

  • Support for QSFP-100G-FR transceivers (QFX5200 and QFX10002-72)—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. The QSFP-100G-FR transceivers are not compatible with earlier-generation 100-Gbps transceivers (for example, QSFP-100G-CWDM4 and QSFP-100G-LR4).

    Note

    The QSFP-100G-FR 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.]

EVPN

  • Support for creating remote VXLAN VTEP per underlay (QFX5100, QFX5110, QFX5120, QFX5200, QFX5210, QFX10002, QFX10002-60C, and QFX10016)—Starting in Junos OS Release 20.3R1, you can create one VTEP logical interface per remote provider edge (PE) device, regardless of the number of routing instances. For example, if there are X number of PE devices and Y number of routing instances, this would currently result in having (X – 1) * Y remote VTEPs. Starting in Junos OS Release 20.3R1, however, there are only X – 1 remote VTEPs. This change reduces the number of next hops and hardware tokens from the quadratic level to the linear level.

    For existing platforms that support EVPN-VXLAN, configure the shared-tunnels statement at the [edit forwarding-options evpn-vxlan] hierarchy level. For changes to take effect, reboot the device.

  • Seamless EVPN-VXLAN stitching (QFX10002-36Q, QFX10002-72Q, QFX10008, and QFX10016)—Starting in Junos OS Release 20.3R1, we support the seamless stitching of unicast and broadcast, unknown unicast, and multicast (BUM) routes in the following use cases:

    • Interconnected EVPN-VXLAN points of delivery (PODs) in a data center.

    • Interconnected EVPN-VXLAN data centers (data center interconnect [DCI]).

    Note

    We do not currently support the assisted replication of BUM traffic in the described use cases.

    In these use cases, the QFX10000 switches, either single-homed or multihomed in all-active mode, can serve as either a spine or super spine device that interconnects the PODs or data centers through an EVPN-VXLAN WAN network.

    When configuring the interconnection, you can set up a single routing instance of type virtual-switch or evpn on each spine or super spine device. Or, you can use the default switching instance. In this instance, you include elements described in interconnect.

    After you configure the interconnection, the EVPN control plane stitches the EVPN routes from the POD or data center network and from the WAN network into a single MAC forwarding table.

  • Enhancement in the number of supported VLANs and ports (QFX5110 and QFX5120)—Starting with Junos OS Release 20.3R1, we’ve increased the combined total number of VLANs and ports that can be supported on the QFX5110 and QFX5120 switches. The number of supported VLANs remains at 4093, but Junos OS no longer limits the number of ports that can be configured in conjunction with the number of configured VLANs on EVPN-VXLAN. This enhancement applies only when you use the enterprise style of configuration when configuring the interfaces.

    [See Understanding EVPN with VXLAN Data Plane Encapsulation.]

  • Filter-based forwarding in EVPN-VXLAN networks (QFX5110 and QFX5120)—Starting in Junos OS Release 20.3R1, QFX5110 and QFX5120 switches support the use of firewall filters along with routing instances to specify different routes for IPv4 VXLAN-encapsulated traffic in your EVPN-VXLAN network.

    To set up this feature:

    • Create an input filter.

    • Specify one or more of these match criteria:

      • Source or destination IP address

      • Source or destination Layer 4 port

      • Time to live (TTL)

      • IP protocol

    • For the action, specify the routing instance to which to send packets. (We also support the accept, count, and discard actions.)

    • Apply the filter to an IRB interface with or without a virtual gateway address or an anycast address.

    For example:

    When the Juniper Networks switch receives incoming traffic from the specified address on interface irb.10, it counts and then forwards the traffic to the FBF-1 routing table. According to the routing table, the packet is forwarded to the next hop that corresponds to the destination address entry in the table.

    [See Understanding Filter-Based Forwarding.]

  • Dynamic load balancing in an EVPN-VXLAN network (QFX5100, QFX5110, QFX5120, QFX5200, QFX5210, and QFX5220)—Starting with Junos OS Release 20.3R1, the listed QFX switches support dynamic load balancing in an EVPN-VXLAN network. When your EVPN-VXLAN network includes a multihomed device that can be reached through multiple virtual tunnel endpoints (VTEPs) that share a common Ethernet segment identifier (ESI), dynamic load balancing works as follows:

    • The EVPN control plane (overlay) identifies the common ESI as the next hop for a destination device with a particular MAC address.

    • Based on the parameters in a packet, the forwarding plane in the switch (hardware) dynamically chooses one of the VTEPs associated with the ESI. The VTEP then forwards the packet along the selected underlay path to the destination device.

    By default, the listed QFX switches have dynamic load balancing enabled.

    [See Dynamic Load Balancing in an EVPN-VXLAN Network.]

  • Increased number of ARP and neighbor discovery entries and token spaces for IRB and aggregated Ethernet interfaces (QFX10002-60C)—Starting in Junos OS Release 20.3R1, we’ve increased the number of token spaces to 96,000, and the number of ARP and neighbor discovery entries to 256,000. We’ve also enabled both 96,000 token spaces and 256,000 ARP and neighbor discovery entries by default for VXLAN Layer 3 gateway scenarios. The token spaces are also shared with the ARP and neighbor discovery entries, which helps with the default ARP scale as well as with multidimensional scale.

    To disable the sharing of token spaces with the ARP and ND entries, enable the no-arp-enhanced statement at the [edit system] hierarchy level. Reboot the device for changes to take effect.

    [See Increasing ARP and Network Discovery Protocol Entries for Enhanced MC-LAG and Layer 3 VXLAN Topologies.]

  • Layer 2 egress filtering on EVPN-VXLAN interfaces (QFX5110 and QFX5120)—Starting in Junos OS Release 20.3R1, QFX5110 and QFX5120 switches support the filtering of Layer 2 traffic exiting access interfaces on which EVPN-VXLAN is running.

    To set up this feature:

    • Create a Layer 2 egress filter.

    • In the filter, specify one or more of these match criteria:

      • Source or destination MAC address

      • Ethernet type

      • VLAN ID

    • Specify one or more of these actions:

      • Accept

      • Count

      • Discard

    • Apply the filter to a physical interface or an aggregated Ethernet interface.

    The following sample configuration creates a Layer 2 egress firewall filter named epacl, which you apply to interface xe-0/0/10.0. The first term specifies that the interface accepts and counts packets from source MAC address 00:00:5e:00:53:a1/48. The second term specifies that the interface discards all other packets and counts them.

    [See Overview of Firewall Filters (QFX Series).]

High Availability (HA) and Resiliency

  • Higher scale and performance in RIFT (QFX2000, QFX5100, QFX5110, QFX10000, MX960, and vMX)— Starting in Junos OS Release 20.3R1, we’ve made the following improvements to increase the scalability and performance in Routing in Fat Tree (RIFT):

    • Prefixes in RIFT

    • Peers in RIFT

    • Convergence improvement with RIFT

    • BFD sessions with RIFT

    [See RIFT Overview.]

IP Tunneling

  • Support for IP over IP next hop based tunneling (MX Series, PTX1000, PTX10000, and QFX10000)—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. BGP protocol is used to distribute routes and signal dynamic tunnels.

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

  • 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 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, PTX10003, PTX10008, PTX10016, QFX3500, QFX3600, QFX5100, QFX5110, QFX5120, QFX5130, QFX5200, QFX5210, QFX5220, 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 system 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.]

  • Remote port mirroring to an IP address (using GRE) with ToS and DSCP (QFX10002, QFX10008, and QFX10016)—You use port mirroring to send traffic to applications that analyze traffic to monitor compliance, enforce policies, detect intrusions, and so on. Starting in Junos OS Release 20.3R1, you can configure remote port mirroring to send sampled packets to a remote IP address. You send the packets using GRE. You can set type-of-service (ToS) and DiffServ code point (DSCP) values to provide the necessary priorities in the network for these packets. You can also apply policing to sampled packets that are leaving the interface where the GRE destination was learned. Configure the settings you need in the [edit forwarding-options port-mirroring instance instance-name output] hierarchy.

    [See instance (Port Mirroring) and traffic-class (Tunnels).]

  • Enhancements to sessions over outbound HTTPS (EX Series, MX Series, PTX Series, QFX Series, and SRX Series)—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.]

Routing Policy and Firewall Filters

  • Loopback firewall filter scale optimization (EX4650 and QFX5120-48Y)—Starting with Junos OS Release 20.3R1, you can configure up to 768 loopback filter terms for IPv6, and up to 1152 terms for IPv4. To do so, you configure an ingress firewall filter, apply it to the loopback interface, and then enable the loopback-firewall-optimization statement at the [edit chassis] hierarchy level (this triggers the Packet Forwarding Engine to restart).

    The switches do not support terms that include a reserved multicast destination, for example 224.0.0.x/24, and terms with a time-to-live (TTL) of 0/1. You need to configure a separate filter for these terms. So, for example, to count OSPF packets on the loopback interface, you would create a separate filter with terms for the protocol (OSPF) to count packets destined to a reserved multicast address (such as 224.0. 0.6).

    [See Planning the Number of Firewall Filters to Create.]

Routing Protocols

  • PTP over IRB (QFX-5110-48s and QFX-5200-32q)—Starting in Junos OS Release 20.3R1, we support PTP boundary clock to IRB interfaces for PTP over multicast for broadcast profiles.

    [See Understanding IEEE 1588 Precision Timing Protocol (PTP) over IRB for Broadcast profiles.]

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

Security

  • Source MAC filtering on aggregated Ethernet interfaces (QFX5100, QFX5120-32C, and QFX5120-48Y switches)—Starting in Junos OS Release 20.3R1, you can configure source media access control (MAC) filtering on an aggregated Ethernet interface on QFX5100, QFX5120-32C, and QFX5120-48Y switches. Ingress packets are matched on the source MAC address list you have configured under the accept-source-mac mac-address hierarchy level on the logical interface of the aggregated Ethernet interface.

    [See Understanding MAC Limiting on Layer 3 Routing Interfaces and accept-source-mac.]

Services Applications

  • Support for IPv4 and IPv6 inline active flow monitoring (QFX10002-60C)—Starting in Junos OS Release 20.3R1, you can configure inline active flow monitoring for IPv4 and IPv6 traffic. We support both the IPFIX and the version 9 formats of the IPv4 and IPv6 templates. To configure the template properties for inline active flow monitoring, configure the options for the flow-monitoring (version-ipfix | version9) template template-name statement at the [edit services] hierarchy level.

    [See Configuring Inline Active Flow Monitoring Using Routers, Switches or NFX250.]

Software Defined Networking (SDN)

  • Support for static FTI backup paths with IP-in-IP tunnel encapsulation and provisioning APIs (MX Series, PTX Series, and QFX10002)—Starting in Junos OS Release 20.3R1, we've enhanced Juniper Extension Toolkit (JET) APIs to enable a controller to implement underlay network backup paths that use IP-in-IP tunnels with IPv4 encapsulation on flexible tunnel interfaces (FTIs). Use this feature to engineer effective, loop-free backup paths for core transport networks built with only IP protocols for fast restoration after failures.

    We've extended FTIs and existing forwarding constructs to support configuring static IPv4 IP-in-IP tunnels. You can also allow policy matches for routes injected by JET APIs.

    [See policy-statement, tunnel, ipip, show interfaces, show route, Configuring Flexible Tunnel Interfaces, and JET APIs on the Juniper Engineering Network website.]

Software Licensing

  • Juniper Agile Licensing (QFX5120 and QFX5200) —Starting in Junos OS Release 20.3R1, we’re moving toward license-based software features. We now use Juniper Agile Licensing to support soft enforcement for software features on the listed devices.

    Juniper Agile Licensing provides simplified and centralized license administration and deployment. You can install and manage licenses for hardware and software features using Juniper Agile Licensing.

    From this release onwards, you can now opt to use the Juniper Agile License Manager to significantly improve the ease of license management for an entire network of supported devices.

    If you are upgrading to this release, you need new license keys to use the features on the listed devices. Contact Customer Care to exchange license keys for Junos OS releases earlier than Junos OS Release 20.3R1.

    Table 6 describes the licensing support on the QFX5120 and QFX5200 devices.

    Table 6: Licensed Features on the QFX5120 and QFX5200 Devices

    QFX Switch License Model

    Detailed Features

    Standard license for integrated SKUs (standard hardware and software platform)

    Filters (Layer 2 and Layer 3), Layer 2 (xSTP, 802.1Q, LAG), Layer 3 (static), QoS (Layer 2 and Layer 3), and SNMP

    Advanced license for integrated and advanced SKUs

    Advanced 1: BGP, FBF, GRE, IS-IS, JTI, MC-LAG, OSPF, sFlow, VRF, and VRRP

    Advanced 2: Includes Advanced 1 features + CFM, Layer 2 and Layer 3 multicast, OAM, Packet Timestamping, PTP, and Q-in-Q

    PTP is supported only on QFX5120-48Y and QFX5200-32C.

    Premium license for integrated and premium SKUs

    Includes Advanced 2 features + EVPN-MPLS, MPLS, Layer 2 circuit, Layer 3 VPN, LDP, RSVP, segment routing, and SR-TE

    [See Supported Features on QFX5120 and QFX5200 Devices, Juniper Agile Licensing Guide, Configuring Licenses in Junos OS, and Managing Licenses.]

Virtual Chassis

  • Support for Virtual Chassis (QFX5120-32C)—Starting in Junos OS Release 20.3R1, you can interconnect two QFX5120-32C switches into a Virtual Chassis managed as a single device. The Virtual Chassis:

    • Contains only QFX5120-32C switches.

    • Has two member switches in the Routing Engine role (one master and one backup).

    • Supports any of the 32 network ports installed with 100-Gbps QSFP28 or 40-Gbps QSFP+ transceivers as Virtual Chassis ports (VCPs) to connect the member switches.

    • Supports NSSU.

    A QFX5120-32C Virtual Chassis supports the same protocols and features as the standalone switches in Junos OS Release 20.3R1, except for the following:

    • EVPN-VXLAN

    • Junos telemetry interface (JTI)

    • Multichassis link aggregation (MC-LAG)

    Configuration and operation are the same as for other QFX Series Virtual Chassis.

    [See Virtual Chassis Overview for Switches.]

What's Changed

Learn about what changed in Junos OS main and maintenance releases for QFX Series Switches.

General Routing

  • Priority-based flow control (PFC) support (QFX5120-32C)—Starting with Junos OS Release 20.3R1, QFX-5120-32C switches support priority-based flow control (PFC) using Differentiated Services code points (DSCP) at Layer 3 for untagged traffic.

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

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.

  • IGMP snooping in EVPN-VXLAN multihoming environments (QFX5110)—In an EVPN-VXLAN multihoming environment on QFX5110 switches, you can now selectively enable IGMP snooping only on those VLANs that might have interested listeners. In earlier releases, you must enable IGMP snooping on all VLANs associated with any configured VXLANs because all the VXLANs share VXLAN tunnel endpoints (VTEPs) between the same multihoming peers and require the same settings. This is no longer a configuration limitation.

Known Limitations

Learn about known limitations in Junos OS Release 20.3R1 for QFX Series Switches. For the most complete and latest information about known Junos OS defects, use the Juniper Networks online Junos Problem Report Search application.

Layer 2 Ethernet Services

  • If a configuration or image filename has nonallowed special characters (such as #, %, and @) in it, ZTP over HTTP/HTTPS might not work. When HTTP/HTTPS URL is formed to download the file, the URL contains the filename in it. HTTP/HTTPS does not expect any special characters in the URL. If special characters are present, the HTTP/HTTPS protocol returns "Bad request". In order to avoid the issue, do not use any nonallowed special characters in the filename. PR1503588

  • If you configure image and script on the DHCP server as part of the ZTP, DHCPv6 client binding does not happen after image upgrade and reboot of image and script. PR1532304

Platform and Infrastructure

  • The 100-Gigabit Ethernet interface goes down after you configure and delete the Ethernet loopback configuration. PR1353734

  • On QFX10000 line of devices, if the analyzer is configured to a mirror traffic of an input aggregated Ethernet interface and a new member is added to the same aggregated Ethernet interface, then the analyzer might not provide sample packets that flow through the newly added child interface. PR1417694

  • TCAM calculation issue is found in Junos OS Release 18 and Junos OS Release 19 codes after introducing the IPACL VXLAN filters. PR1469515

  • On QFX 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

  • On a fully scaled system where all the slices are utilized by different families of CLI filters, if you try to delete one family and change another family with higher number of filter terms that requires expansion of the filter, the Packet Forwarding Engine fails to add the new changed filter as out of sequence messages are generated, that is, change of filter is called earlier than deletion of another filter. PR1512242

Routing Protocols

  • Higher than expected loss and traffic drops and discards silently during node failures with node protection on FTI interfaces for RSVP LSPs. PR1456350

  • Third party vendor SDK does not support variable mask for destination IP address in tunnel termination table, so firewall terms for de-encapsulation action should always have destination address as /32 address. Source IP address can be variable mask or optional. PR1511893

  • On the QFX5200 switch, hierarchical ECMP supports only two levels of ECMP. If a BGP route is resolved over multiple PRPD routes, we’ve unilist 1 (BGP route), unilist 2 (PRPD route), ucast1, ucast 2 (FTI underlay can be unilist). There will be three unilist in the hierarchy. Because of this, we’ve flattened the unilist paths for FTI NHs as well. Traffic distribution behavior is the same across QFX5100 and QFX5200. Hierarchal ECMP is not supported on QFX5100, even for routes pointing to non-FTI. For unilist of unilist, QFX5100 flattens all the unicast paths, so traffic will be equally distributed to the final list of unicast NHs, not at top-level unilist. PR1517519

Open Issues

Learn about open issues in Junos OS Release 20.3R1 for QFX Series Switches. For the most complete and latest information about known Junos OS defects, use the Juniper Networks online Junos Problem Report Search application.

High Availability (HA) and Resiliency

  • The QFX5200-32C reboot time is degraded. A flush cache issue is seen because of the reliable SSD disk input/output change made for this platform. PR1511607

Layer 2 Features

  • In case of QFX5000 Virtual Chassis or Virtual Chassis Fabric setups, when IGMP snooping is enabled, multicast traffic is forwarded based on IGMP joins or reports. But when the IGMP report times out, traffic should be dropped; instead it floods in the VLAN. This happens only in case of QFX5000 Virtual Chassis or Virtual Chassis Fabric; this issue is not seen on stand-alone QFX5000 switches. PR1431893

  • On QFX5110 and QFX5120 platforms, changing lo0 IP address might sometimes result either in stale entry of IP in mpls_entry table or in a missing IP entry, which results in traffic drop for VXLAN traffic. PR1472333

  • QFX5100 switches that send routed traffic (either transit or locally originated) out to an interface configured for Q-in-Q traffic fail to correctly add the two VLAN tags. PR1481648

Platform and Infrastructure

  • The QFX10000 line of devices drop the wireless access point (WAP) heartbeat packets; as a result, the WAP cannot work. PR1352805

  • USB upgrade of NOS image is not supported. PR1373900

  • On QFX5110 and QFX5120 platforms, unicast RPF check in strict mode might not work properly. PR1417546

  • The issue occurs because of a PECHIP limitation when underlay is tagged. After de-encapsulation, when the inner packet is recirculated, it retains the VLAN tag property from outer header because the outer header was tagged. Thus 4 bytes of inner tag is overwritten in the inner packet and the packet got corrupted, which results in EGP chksum trap seen in PECHIP. Fixing PECHIP limitation in software has high risk. As a workaround, enable encapsulate-inner-vlan configuration. PR1435864

  • The unified ISSU is not supported on QFX5200 switches and fails from Junos OS Release 17.2X75-D43.2 to some target versions. Also, dcpfe crash might be seen. PR1438690

  • On the QFX10000 line of devices, in an EVPN-VXLAN (spine-leaf) scenario, the QFX10000 spine switches are configured with VXLAN Layer 3 gateway (utilizing the virtual gateway) on an IRB interface. If you enable and then subsequently remove the VXLAN Layer 3 gateway on this IRB interface on one or some of these spine switches, traffic drop might be observed. As a workaround, configure all virtual gateways with unique IPv4 or IPv6 MAC address. PR1446291

  • After changing the VLAN name on the trunk interface, while port is receiving continuous traffic for that VLAN, local host MAC learning holds for more than 30 seconds. In case of trunk port, when VLAN name is changed, bridge domain entry is deleted from hardware and a new entry is installed in the hardware. When the new entry is yet to be installed in hardware, port keeps receiving traffic for that VLAN and learn source MAC and notifies to Packet Forwarding Engine with old bridge domain ID. When Packet Forwarding Engine software receives this MAC drops it as bridge domain and port mapping will not be present in software which is a must criteria for a source MAC received on a bridge domain. Once Packet Forwarding Engine drops the MAC, upper layers (L2ALD) does not get this MAC info and aging thread marks the hash index in hardware as stale. Until that hash index is not cleared in the hardware, same source MAC cannot be learnt on the same hash index. Ageing thread periodically scans one MAC table out of 4 tables at a time in intervals of 10 seconds and checks for stale entries and clear the hardware hash stale entry, and this time is almost 40-50 seconds based on the number of Packet Forwarding Engine chips in an FPC. In case of access port, default bridge domain is installed in the hardware to receive untagged traffic and does not get deleted while changing VLAN name associated to that access port. So this issue is not seen for access port. PR1454274

  • On QFX5110 switches, VXLAN VNI (mcast) scaling traffic issue from VXLAN tunnel to Layer 2 interface is observed. PR1462548

  • BGP route addition and deletion time and BGP, OSPF, and IS-IS link flap convergence time are increased. PR1464572

  • Dynamic IP-over-IP tunnels and filter-based IP-over-IP de-encapsulation filter on loopback interface cannot coexist together. If dynamic IP-over-IP tunnels were configured earlier, then FPC needs a reboot before it can be used for loopback IP-over-IP de-encapsulation filter. Also, the loopback interface might contain implicit filter. If these implicit filters get hit, the de-encapsulation filter might not get hit. PR1479613

  • On QFX Series platforms running Junos VM instance (excluding QFX10000 Series platforms), the laser signal might be transmitted on the disabled interfaces with QSFP and QSFP28 optics after device reboot. PR1487554

  • If the interface is newly added as a CE interface, the existing broadcast, unicast, and multicast (BUM) traffic can be looped. The loop prevention feature is designed to start working whenever a new CE interface is added by configuration. But the existing BUM traffic can be distributed to a new CE interface earlier, before enabling the loop prevention feature. PR1493650

  • Storage full message is displayed for the /var/tmp directory when the file is copied. The file copy command uses a default staging-directory (a temporary directory) and this staging directory is /var/tmp for the root user and /var/home/<user-dir> for all non-root users. If you face storage system full issues while coping the file, you can use the staging-directory command line option to choose a different staging directory (other than the default). PR1494489

  • On the QFX5210 switches, unexpected behavior for port LEDs lights is observed after the upgrade. PR1498175

  • In the l2circuit termination scenario with input-vlan-map/output-vlan-map and family ccc, the output-vlan-map push operation might not work. It has a traffic impact. PR1510629

  • In an EVPN-VXLAN scenario, multicast traffic might not reach to spine to form (S,G) in PIM enabled spines. Issue might happen due to various triggers including multiple rollback of configurations on spine, interface flap, and clear BGP. PR1510794

  • On QFX5100 Virtual Chassis, degradation is observed at the time of system reboot and FPC online. PR1513540

  • Disruptive switchover (no GRES or NSR configured) can lead to stale PPM entries programmed on the new master Routing Engine. If both GRES and NSR are activated after disruptive switchover, and then a GRES is performed, BFD sessions might flap continuously. PR1518106

  • Some inter VLAN traffic flows do not converge after rebooting spine device (QFX10002) in EVPN VXLAN non-collapsed scaled scenario when traffic is already flowing. PR1522585

  • If the Layer 3 filter is applied on a VXLAN IRB, then VXLANs and IRBs are deactivated in a separate commits, IRB filters attached does not go away. PR1537108

  • With an EVPN VXLAN configuration, when restart of l2-learning command is executed, BFD sessions on IRB interface might not come up. PR1538600

Routing Protocols

  • If DDoS protection is disabled on QFX5100 Virtual Chassis and multicast traffic is being sent, the Virtual Chassis might become unstable, with high CPU usage and it might crash eventually, creating FXPC core files. Disabling DDoS protection will disable rate limiting for all host-bound traffic. We do not recommend disabling DDoS protection on the device, because a high amount of control traffic can overwhelm the system, causing system instability. PR1238875

  • On QFX5100 Virtual Chassis or Virtual Chassis Fabric, when the mini-PDT-base configuration is issued, the following error message is seen in the hardware: BRCM_NH-,brcm_nh_bdvlan_ucast_uninstall(), 128:l3 nh 6594 uninstall failed. There is no functionality impact because of this error message. PR1407175

  • IPv6 routes pointing to the BGP LU path are not programmed in hardware with the preserve-nexthop-hierarchy statement. This results in traffic drop for IPv6 routes. The preserve-nexthop-hierarchy statement is required for IP-in-IP, in this case, the IPv6 route pointing to an IP tunnel has no issues. PR1510053

  • On the QFX10000 line of devices, if multiple sub-interfaces of the same aggregated Ethernet interface belong to different routing instances, and these sub-interfaces are configured with the same IP address and separate BFD sessions, the remaining BFD sessions flap continuously if one of these BFD sessions is deleted. PR1516556

Virtual Chassis

  • The QFX5110-48S reports false parity error messages like soc_mem_array_sbusdma_read and SDK can raise false alarms for such parity error messages. This is a false positive error message. PR1276970

  • On QFX5000 Virtual Chassis, DDoS violations that happen on the backup are not reported to Routing Engine. PR1490552

Resolved Issues

Learn which issues were resolved in Junos OS main and maintenance releases for QFX Series Switches.

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

Class of Service (CoS)

  • On QFX5120 switches, the priority-based flow control (PFC) feature is not supported on 2-member Virtual Chassis currently because of the hardware limitation. PR1431895

  • Traffic might be forwarded to an incorrect queue when fixed classifier is used. PR1510365

EVPN

  • On QFX10002-60C EVPN/VXLAN multicast, the show command issued for the VTEP interface does not show the mesh-group ID. PR1498052

  • The VXLAN function might be broken due to a timing issue. PR1502357

  • Unable to create a new VTEP interface. PR1520078

Infrastructure

  • The OID ifOutDiscards reports zero and sometimes shows valid value. PR1522561

Interfaces and Chassis

  • Traffic over MC-LAG drops because the next-hop points ICL link instead of MC-LAG. PR1486919

  • MC-LAG consistency check fails if multiple IRB units are configured with the same VRRP group. PR1488681

  • Error message is not generated while verifying the GRE limitation. PR1495543

Layer 2 Features

  • MAC learning might not work correctly on QFX5120 switches. PR1441186

  • On QFX5120 switches Q-in-Q, the third VLAN tag is not pushed onto the stack and SWAP is being done instead. PR1469149

  • On QFX5200 switches, MAC learning rate is degraded by 88 percent. PR1494072

  • Traffic imbalance might be observed on QFX5000 switches if ash-params is not configured. PR1514793

  • MAC address in hardware table might become out of sync between master and member in Virtual Chassis after MAC flap. PR1521324

Layer 2 Ethernet Services

  • Issues with DHCPv6 relay processing confirm and reply packets. PR1496220

  • The MC-LAG might become down after disabling and then enabling the force-up. PR1500758

  • The aggregated Ethernet interface might not come up after switch is rebooted. PR1505523

MPLS

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

Platform and Infrastructure

  • Port LEDs do not work on the QFX5100 switch in a QFX5110-QFX5100 mixed mode Virtual Chassis. PR1317750

  • A VM core is seen on QFX Series Virtual Chassis. PR1421250

  • SFP-LX10 stays down until autonegotiation is disabled. PR1423201

  • The PMTUD might not work for both IPv4 and IPv6 if the ingress Layer 3 interface is an IRB. PR1442587

  • In the EVPN-VXLAN scenario, changing the VLAN name associated with the access ports might prevent the MAC addresses from being learned. PR1454095

  • On the QFX5100 switch, the interface output counter is double counted for self-generated traffic. PR1462748

  • On the QFX5100 switch, traffic loss might be seen with framing errors or runts if MACsec is configured. PR1469663

  • On the QFX5000 switch, the DSCP marking might not work as expected if the fixed classifiers are applied to interfaces. PR1472771

  • The sFlow could not work correctly if the received traffic goes out of more than one interface. PR1475082

  • The dcpfe process might generate core file with the non-oversubscribed mode after SDK upgrade. PR1485854

  • The 10 GbE VCP ports do not become active in a QFX5100 Virtual Chassis scenario. PR1486002

  • On QFX5100 switches, If more than one UDF filter or term is configured, then only the first filter or term will be programmed in the hardware because of SDK 6.5.16 upgrade. PR1487679

  • The queue statistics are not as expected after configuring the IFD and logical-interface shaping with the transmit rate and scheduler map PR1488935

  • Traffic loss could be observed in mixed Virtual Chassis setup of QFX5100 and EX4300 switches. PR1493258

  • Traceroute monitor with MTR version v.69 shows a false 10 percent loss. PR1493824

  • On the QFX5120 switch, traffic loss might be seen in a MC-LAG scenario. PR1494507

  • On the QFX5120 switch, SNMP polling for CPU utilization and CPU state of backup Routing Engine do not show in a two-member Virtual Chassis. PR1495384

  • ARP does not get refreshed after timeout on QFX10002-60C. PR1497209

  • Extra carrier transitions are seen on the peer when negative triggers are performed on QFX5100 and QFX5110 switches. PR1497380

  • Virtual Chassis is not stable with 100-Gigabit Ethernet and 40-Gigabit Ethernet interfaces. PR1497563

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

  • Traffic might get dropped if the aggregated Ethernet member interface is deleted or added, or an SFP of the aggregated Ethernet member interface is unplugged or plugged. PR1497993

  • Firewall filter might not get applied on QFX5100 and QFX5110 switches. PR1499647

  • BFD sessions flap after deactivating or activating the aggregated Ethernet interface or executing GRES. PR1500798

  • On QFX5000 switches, ERPS might not work correctly. PR1500825

  • The interface becomes physically down after changing to FEC none mode. PR1502959

  • LLDP packets are not acquired when native-vlan-id and tagged VLAN-ID are the same on a port. PR1504354

  • The l2cpd might crash if the ERP configuration is added or removed, and l2cpd is restarted. PR1505710

  • The archival function might fail in certain conditions. PR1507044

  • On QFX5100 switches, the fxpc process might crash while installing image through ZTP. PR1508611

  • Traffic might be affected on QFX10002, QFX10008, and QFX10016 platforms because of PECHIP wedge caused by deactivating CoS ETS configuration. PR1509220

  • ARP replies might be flooded through the EVPN-VXLAN network as unknown unicast ARP reply. PR1510329

  • The QFX10000-36Q line card used on QFX10008 and QFX10016 switches might fail to detect any QSFP. PR1511155

  • In VXLAN configuration, the firewall filters might not be loaded into the TCAM with the message DFWE ERROR DFW: Cannot program filter .. because of the TCAM overflow after upgrading to Junos OS Release 18.1R3-S1, 18.2R1 and later. PR1514710

  • The routes update might fail upon HMC memory issue and affects the traffic. PR1515092

  • The MAC learning might not work properly after multiple MTU changes on the access port in a VXLAN scenario. PR1516653

  • The VGD core file might be generated when the OVSDB server restarts. PR1518807

  • Traffic forwarding might be affected when adding or removing or modifying the VLAN and VNI configurations such as VLAN-ID, VNI-ID and ingress-replication statement. PR1519019

  • On QFX10002, QFX10008, and QFX10016 switches, PRDS_SLU_SAL:jprds_slu_sal_update_lrncnt(),1379: jprds_slu_sal_update_lrncnt call failed syslog error messages might be seen when clearing and loading the scaled configuration again. PR1522852

  • On QFX10002-60C switches, sFlow adaptive-sampling with the rate limiter statement enabled crosses sample rate 65535. PR1525589

  • Packet loss is seen while validating the policer after restarting chassis control. PR1531095

Routing Protocols

  • The FPC process goes to the NotPrsnt state after upgrading the QFX5100 Virtual Chassis/Virtual Chassis Fabric. PR1485612

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

  • The rpd process generates core file at rt_nh_resolve_add_gen in ../../../../../../../../src/junos/usr.sbin/rpd/lib/rt/rt_resolve_ind.c: with the EVPN-DHCP configurations. PR1494005

  • Firewall filter might not work in certain conditions in a Virtual Chassis. PR1497133

  • Traffic drop might be observed after modifying the FBF firewall filter. PR1499918

  • With the egress-to-ingress configuration statement, you cannot configure 2000 scale and the scale is reduced to 1000. PR1514570

  • Enabling IPv6 flow-based Packet Forwarding Engine hashing gives commit error. PR1519018

  • Firewall sample configuration gives the warning as unsupported on QFX10002-36Q switches and does not work. PR1521763

  • On QFX5000, the fxpc process might crash if VXLAN interface flaps. PR1528490

User Interface and Configuration

  • The version information under the configuration is changed starting in Junos OS Release 19.1. PR1457602

Documentation Updates

There are no errata or changes in Junos OS Release 20.3R1 documentation for the QFX Series Switches.

Migration, Upgrade, and Downgrade Instructions

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

Upgrading Software on QFX Series Switches

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

If you are not familiar with the download and installation process, follow these steps:

  1. In a browser, go to https://www.juniper.net/support/downloads/junos.html.

    The Junos Platforms Download Software page appears.

  2. In the QFX Series section of the Junos Platforms Download Software page, select the QFX Series platform for which you want to download the software.
  3. Select 20.3 in the Release pull-down list to the right of the Software tab on the Download Software page.
  4. In the Install Package section of the Software tab, select the QFX Series Install Package for the 20.3 release.

    An Alert box appears.

  5. In the Alert box, click the link to the PSN document for details about the software, and click the link to download it.

    A login screen appears.

  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. Download the software to a local host.
  8. Copy the software to the device or to your internal software distribution site.
  9. Install the new jinstall package on the device.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.

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

    user@host> request system software add source/jinstall-host-qfx-5-x86-64-20.3-R1.n-secure-signed.tgz reboot

    Replace source with one of the following values:

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

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

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

    Rebooting occurs only if the upgrade is successful.

Note

After you install a Junos OS Release 20.3 jinstall package, you can issue the request system software rollback command to return to the previously installed software.

Installing the Software on QFX10002-60C Switches

This section explains how to upgrade the software, which includes both the host OS and the Junos OS. This upgrade requires that you use a VM host package—for example, a junos-vmhost-install-x.tgz .

During a software upgrade, the alternate partition of the SSD is upgraded, which will become primary partition after a reboot .If there is a boot failure on the primary SSD, the switch can boot using the snapshot available on the alternate SSD.

Note

The QFX10002-60C switch supports only the 64-bit version of Junos OS.

Note

If you have important files in directories other than /config and /var, copy the files to a secure location before upgrading. The files under /config and /var (except /var/etc) are preserved after the upgrade.

To upgrade the software, you can use the following methods:

If the installation package resides locally on the switch, execute the request vmhost software add <pathname><source> command.

For example:

user@switch> request vmhost software add /var/tmp/junos-vmhost-install-qfx-x86-64-20.3R1.9.tgz

If the Install Package resides remotely from the switch, execute the request vmhost software add <pathname><source> command.

For example:

user@switch> request vmhost software add ftp://ftpserver/directory/junos-vmhost-install-qfx-x86-64-20.3R1.9.tgz

After the reboot has finished, verify that the new version of software has been properly installed by executing the show version command.

user@switch> show version

Installing the Software on QFX10002 Switches

Note

If you are upgrading from a version of software that does not have the FreeBSD 10 kernel (15.1X53-D30, for example), you will need to upgrade from Junos OS Release 15.1X53-D30 to Junos OS Release 15.1X53-D32. After you have installed Junos OS Release 15.1X53-D32, you can upgrade to Junos OS Release 15.1X53-D60 or Junos OS Release 18.3R1.

Note

On the switch, use the force-host option to force-install the latest version of the Host OS. However, by default, if the Host OS version is different from the one that is already installed on the switch, the latest version is installed without using the force-host option.

If the installation package resides locally on the switch, execute the request system software add <pathname><source> reboot command.

For example:

user@switch> request system software add /var/tmp/jinstall-host-qfx-10-f-x86-64-20.3R1.n-secure-signed.tgz reboot

If the Install Package resides remotely from the switch, execute the request system software add <pathname><source> reboot command.

For example:

user@switch> request system software add ftp://ftpserver/directory/jinstall-host-qfx-10-f-x86-64-20.3R1.n-secure-signed.tgz reboot

After the reboot has finished, verify that the new version of software has been properly installed by executing the show version command.

user@switch> show version

Upgrading Software from Junos OS Release 15.1X53-D3X to Junos OS Release 15.1X53-D60, 15.1X53-D61.7, 15.1X53-D62, and 15.1X53-D63 on QFX10008 and QFX10016 Switches

Note

Before you install the software, back up any critical files in /var/home. For more information regarding how to back up critical files, contact Customer Support at https://www.juniper.net/support.

The switch contains two Routing Engines, so you will need to install the software on each Routing Engine (re0 and re1).

If the installation package resides locally on the switch, execute the request system software add <pathname><source> command.

To install the software on re0:

user@switch> request system software add /var/tmp/jinstall-host-qfx-10-m-15.1X53-D60.n-secure-domestic-signed.tgz re0

If the Install Package resides remotely from the switch, execute the request system software add <pathname><source> re0 command.

For example:

user@switch> request system software add ftp://ftpserver/directory/jinstall-host-qfx-10-m-15.1X53-D60.n-secure-domestic-signed.tgz re0

To install the software on re1:

user@switch> request system software add /var/tmp/jinstall-host-qfx-10-m-15.1X53-D60.n-secure-domestic-signed.tgz re1

If the Install Package resides remotely from the switch, execute the request system software add <pathname><source> re1 command.

For example:

user@switch> request system software add ftp://ftpserver/directory/jinstall-host-qfx-10-m-15.1X53-D60.n-secure-domestic-signed.tgz re1

Reboot both Routing Engines.

For example:

user@switch> request system reboot both-routing-engines

After the reboot has finished, verify that the new version of software has been properly installed by executing the show version command.

user@switch> show version

Installing the Software on QFX10008 and QFX10016 Switches

Because the switch has two Routing Engines, perform a Junos OS installation on each Routing Engine separately to avoid disrupting network operation.

Note

Before you install the software, back up any critical files in /var/home. For more information regarding how to back up critical files, contact Customer Support at https://www.juniper.net/support.

Warning

If graceful Routing Engine switchover (GRES), nonstop bridging (NSB), or nonstop active routing (NSR) is enabled when you initiate a software installation, the software does not install properly. Make sure you issue the CLI delete chassis redundancy command when prompted. If GRES is enabled, it will be removed with the redundancy command. By default, NSR is disabled. If NSR is enabled, remove the nonstop-routing statement from the [edit routing-options] hierarchy level to disable it.

  1. Log in to the master Routing Engine’s console.

    For more information about logging in to the Routing Engine through the console port, see the specific hardware guide for your switch.

  2. From the command line, enter configuration mode:

    user@switch> configure
  3. Disable Routing Engine redundancy:

    user@switch# delete chassis redundancy
  4. Disable nonstop-bridging:

    user@switch# delete protocols layer2-control nonstop-bridging
  5. Save the configuration change on both Routing Engines:

    user@switch# commit synchronize
  6. Exit the CLI configuration mode:

    user@switch# exit

    After the switch has been prepared, you first install the new Junos OS release on the backup Routing Engine, while keeping the currently running software version on the master Routing Engine. This enables the master Routing Engine to continue operations, minimizing disruption to your network.

    After making sure that the new software version is running correctly on the backup Routing Engine, you are ready to switch routing control to the backup Routing Engine, and then upgrade or downgrade the software version on the other Routing Engine.

  7. Log in to the console port on the other Routing Engine (currently the backup).

    For more information about logging in to the Routing Engine through the console port, see the specific hardware guide for your switch.

  8. Install the new software package using the request system software add command:

    user@switch> request system software add validate /var/tmp/jinstall-host-qfx-10-f-x86-64-20.3R1.n-secure-signed.tgz

    For more information about the request system software add command, see the CLI Explorer.

  9. Reboot the switch to start the new software using the request system reboot command:

    user@switch> request system reboot
    Note

    You must reboot the switch to load the new installation of Junos OS on the switch.

    To abort the installation, do not reboot your switch. Instead, finish the installation and then issue the request system software delete <package-name> command. This is your last chance to stop the installation.

    All the software is loaded when you reboot the switch. Installation can take between 5 and 10 minutes. The switch then reboots from the boot device on which the software was just installed. When the reboot is complete, the switch displays the login prompt.

    While the software is being upgraded, the Routing Engine on which you are performing the installation is not sending traffic.

  10. Log in and issue the show version command to verify the version of the software installed.

    user@switch> show version

    Once the software is installed on the backup Routing Engine, you are ready to switch routing control to the backup Routing Engine, and then upgrade or downgrade the master Routing Engine software.

  11. Log in to the master Routing Engine console port.

    For more information about logging in to the Routing Engine through the console port, see the specific hardware guide for your switch.

  12. Transfer routing control to the backup Routing Engine:

    user@switch> request chassis routing-engine master switch

    For more information about the request chassis routing-engine master command, see the CLI Explorer.

  13. Verify that the backup Routing Engine (slot 1) is the master Routing Engine:

    user@switch> show chassis routing-engine
  14. Install the new software package using the request system software add command:

    user@switch> request system software add validate /var/tmp/jinstall-host-qfx-10-f-x86-64-20.3R1.n-secure-signed.tgz

    For more information about the request system software add command, see the CLI Explorer.

  15. Reboot the Routing Engine using the request system reboot command:

    user@switch> request system reboot
    Note

    You must reboot to load the new installation of Junos OS on the switch.

    To abort the installation, do not reboot your system. Instead, finish the installation and then issue the request system software delete jinstall <package-name> command. This is your last chance to stop the installation.

    The software is loaded when you reboot the system. Installation can take between 5 and 10 minutes. The switch then reboots from the boot device on which the software was just installed. When the reboot is complete, the switch displays the login prompt.

    While the software is being upgraded, the Routing Engine on which you are performing the installation does not send traffic.

  16. Log in and issue the show version command to verify the version of the software installed.

  17. Transfer routing control back to the master Routing Engine:

    user@switch> request chassis routing-engine master switch

    For more information about the request chassis routing-engine master command, see the CLI Explorer.

  18. Verify that the master Routing Engine (slot 0) is indeed the master Routing Engine:

    user@switch> show chassis routing-engine

Performing a Unified ISSU

You can use unified ISSU to upgrade the software running on the switch with minimal traffic disruption during the upgrade.

Note

Unified ISSU is supported in Junos OS Release 13.2X51-D15 and later.

Perform the following tasks:

Preparing the Switch for Software Installation

Before you begin software installation using unified ISSU:

  • Ensure that nonstop active routing (NSR), nonstop bridging (NSB), and graceful Routing Engine switchover (GRES) are enabled. NSB and GRES enable NSB-supported Layer 2 protocols to synchronize protocol information between the master and backup Routing Engines.

    To verify that nonstop active routing is enabled:

    Note

    If nonstop active routing is enabled, then graceful Routing Engine switchover is enabled.

    If nonstop active routing is not enabled (Stateful Replication is Disabled), see Configuring Nonstop Active Routing on Switches for information about how to enable it.

  • Enable nonstop bridging (NSB). See Configuring Nonstop Bridging on Switches (CLI Procedure) for information on how to enable it.

  • (Optional) Back up the system software—Junos OS, the active configuration, and log files—on the switch to an external storage device with the request system snapshot command.

Upgrading the Software Using Unified ISSU

This procedure describes how to upgrade the software running on a standalone switch.

To upgrade the switch using unified ISSU:

  1. Download the software package by following the procedure in the Downloading Software Files with a Browser section in Installing Software Packages on QFX Series Devices.

  2. Copy the software package or packages to the switch. We recommend that you copy the file to the /var/tmp directory.

  3. Log in to the console connection. Using a console connection allows you to monitor the progress of the upgrade.

  4. Start the ISSU:

    • On the switch, enter:

      where package-name.tgz is, for example, jinstall-host-qfx-10-f-x86-64-20.3R1.n-secure-signed.tgz.

    Note

    During the upgrade, you cannot access the Junos OS CLI.

    The switch displays status messages similar to the following messages as the upgrade executes:

    Note

    A unified ISSU might stop, instead of abort, if the FPC is at the warm boot stage. Also, any links that go down and up will not be detected during a warm boot of the Packet Forwarding Engine (PFE).

    Note

    If the unified ISSU process stops, you can look at the log files to diagnose the problem. The log files are located at /var/log/vjunos-log.tgz.

  5. Log in after the reboot of the switch completes. To verify that the software has been upgraded, enter the following command:

  6. Ensure that the resilient dual-root partitions feature operates correctly, by copying the new Junos OS image into the alternate root partitions of all of the switches:

    Resilient dual-root partitions allow the switch to boot transparently from the alternate root partition if the system fails to boot from the primary root partition.

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.3, 19.4, and 20.1 are EEOL releases. You can upgrade from Junos OS Release 19.3 to Release 19.4 or from Junos OS Release 19.3 to Release 20.1.

You cannot upgrade directly from a non-EEOL release to a 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.