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 19.4R1 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 19.4R1: QFX5100, QFX5110 (32Q and 48S), QFX5120, QFX5200, QFX5200-32CD, 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

  • Support for 40-Gbps ports to operate at 10-Gbps or 1-Gbps speed (QFX5200 and QFX5110 switches)—Starting in Junos OS Release 19.4R1, you can use the Mellanox 10-Gbps pluggable adapter (QSFP+ to SFP+ adapter— model number: MAM1Q00A-QSA) to convert quad-lane based ports to a single-lane based SFP+ port. The QSA adapter has the QSFP+ form factor with a receptacle for the SFP+ module. Use the QSA adapter to convert a 40-gigabit port to a 10-Gbps port or a 1-Gbps port .You can then plug-in a 10-Gbps SFP+ transceiver or a 1–Gbps SFP transceiver into the QSA adapter which is inserted into the QSFP or QSFP+ ports of the QFX5200 and QFX5110 switches. [See supported QFX5110 Transceivers and QFX5200 Tranceivers].

EVPN

  • EVPN pure type-5 route support (QFX5120-32C switches)—Starting with Junos OS Release 19.4R1, you can configure pure type-5 routing in an EVPN-VXLAN environment. Pure type-5 routing is used when the Layer 2 domain does not exist at the remote data centers. A pure type-5 route advertises the summary IP prefix and includes a BGP extended community called a router MAC, which carries the MAC address of the sending switch and provides next-hop reachability for the prefix. To configure pure type-5 routing, include the ip-prefix-routes advertise direct-nexthop statement at the [edit routing-instances routing-instance-name protocols evpn] hierarchy level. To enable two-level equal-cost multipath (ECMP) next hops in an EVPN-VXLAN overlay network, you must also include the overlay-ecmp statement at the [edit forwarding-options vxlan-routing] hierarchy level.

    [See ip-prefix-routes.]

  • EVPN control plane and VXLAN data plane support (QFX5120-32C switches)—Starting with Junos OS Release 19.4R1, QFX5120-32C switches support EVPN-VXLAN. By using a Layer 3 IP-based underlay network coupled with an EVPN-VXLAN overlay network, you can place endpoints anywhere in the network and remain connected to the same logical Layer 2 network.

    EVPN-VXLAN is commonly deployed over the following physical underlay architectures:

    • A two-layer IP fabric that includes spine devices (Layer 3 VXLAN gateways) and leaf devices (Layer 2 VXLAN gateways). You can deploy EX4650 and QFX5120 switches as spine or leaf devices in this fabric.

    • A one-layer IP fabric that includes leaf devices that function as both Layer 2 and Layer 3 VXLAN gateways. You can deploy EX4650 and QFX5120 switches as leaf nodes in this fabric.

    [See Understanding EVPN with VXLAN Data Encapsulation.]

  • Dynamic load balancing in an EVPN-VXLAN overlay network (QFX5200 and QFX5210)—In Junos OS Releases before Release 19.4R1, QFX5200 and QFX5210 switches support a static load-balancing scheme based on destination MAC addresses. This scheme distributes traffic on a round-robin basis among virtual tunnel endpoints (VTEPs) in an EVPN-VXLAN overlay network.

    Starting in Junos OS Release 19.4R1, QFX5200 and QFX5210 switches that function as leaf or spine devices in an EVPN-VXLAN overlay network (centrally-routed and edge-routed bridging overlays) support dynamic load balancing among different equal-cost VTEPs. When enabled, the dynamic load-balancing feature supersedes the static load-balancing feature. With the dynamic feature, traffic is hashed among equal-cost paths based on packet fields. We support this feature in the following use cases:

    • A leaf device is multihomed to multiple spine devices.

    • A host is multihomed to multiple leaf devices.

    In both use cases, each multihomed physical, aggregated Ethernet, or logical interface is configured with an Ethernet segment identifier (ESI). Dynamic load balancing supports a maximum of 255 ESIs. If you exceed this maximum (for example, you configure 256 ESIs), traffic destined for the 256th ESI is flooded to the VLAN associated with the ESI.

    The hashing takes place before a packet undergoes VXLAN encapsulation. We use these fields to load-balance traffic:

    • Packets with an IP header:

      • IP header fields:

        • Source IP address

        • Destination IP address

        • Protocol

      • VLAN ID

      • Layer 4 (TCP and UDP) source and destination ports

    • Packets with an MPLS/IP header:

      • Up to three top labels

      • IP header fields:

        • Source IP address

        • Destination IP address

      • Layer 4 (TCP and UDP) source and destination ports

    • Packets with a Layer 2 header only:

      • Source MAC address

      • Destination MAC address

      • VLAN ID

    To enable dynamic load balancing, include the vxlan-overlay-load-balance configuration statement at the [edit forwarding-options] hierarchy level and restart your switch.

    To further control the hashing input used by this feature, include the enhanced-hash-key configuration statement at the [edit forwarding-options] hierarchy level.

  • Assisted replication in data centers with EVPN-VXLAN overlay networks (QFX Series switches)—Starting in Junos OS Release 19.4R1, QFX Series switches support assisted replication (AR) in data centers with EVPN-VXLAN networks to optimize replication of BUM traffic being forwarded into the EVPN core. Instead of flooding BUM traffic using ingress replication, devices configured as AR leaf devices (also known as AR client devices) forward the traffic to an AR replicator device that can better handle the replication load, and only the AR replicator device replicates and forwards the traffic to the overlay tunnels. You can configure switches in the QFX10000 line as AR replicator devices and any QFX Series devices that support EVPN-VXLAN as AR leaf devices.

    AR devices advertise EVPN Type 3 (Inclusive Multicast Ethernet Tag) routes that include special AR Type and Flags fields indicating AR device roles. The network can also include devices that do not support AR (regular network virtualization edge devices), which ignore AR routes and use ingress replication to forward BUM traffic toward the EVPN core.

    You can configure AR with IGMP snooping to further optimize BUM traffic replication and forwarding.

    To enable assisted replication and configure devices into AR replicator or AR leaf roles, use the assisted-replication configuration statement at the [edit protocols evpn] hierarchy level.

  • Support for EVPN routing policies (ACX5448, EX4600, EX4650, EX9200, MX Series, QFX Series, and vMX)—Starting in Junos OS Release 19.4R1, Junos OS has expanded routing policy support to include the creation and application of policy filters specific to EVPN routes. You can create policies and apply policy filters to import and export EVPN routes at the routing-instance level or at the BGP level. Junos OS supports the following matching criteria for EVPN routes:

    • Route distinguisher ID

    • NLRI route type

    • EVPN Ethernet tag

    • BGP path attributes

    • Ethernet Segment Identifier

    • MAC Address on EVPN route type 2 routes

    • IP address on EVPN route type 2 and EVPN route type 5 routes

    • Extended community

    [See Routing policies for EVPN.]

  • Features supported on EX4650 and QFX5120 switches—Starting with Junos OS Release 19.4R1, the following Junos OS features are supported on EX4650 and QFX5120 switches:

General Routing

  • Optimized BGP peer reestablishment (MX Series, PTX Series, and QFX Series)—Starting with Junos OS Release 19.4R1, BGP peers in different groups can close in parallel. The connect/retry algorithm makes 16 attempts instead of 5 to reestablish BGP peers in the first 256 seconds after they go down. Peers can reestablish while cleanup of the Adj-RIB-In routes is in progress. If a peer comes back up before its route has been deleted from the routing table, that route is not deleted. The DeletePending flag in the show route detail and show route extensive command output indicates that a BGP route needs to be processed. PurgePending, PurgeInProgress, and PurgeImpatient flags in the show bgp neighbor command output show the status of the purge of routing table entries.

    [See Understanding External BGP Peering Sessions, show bgp neighbor, show route detail, and show route extensive.]

Interfaces and Chassis

  • QFX5120 supports JNP-SFPP-10GE-T—Starting in Junos OS Release 19.4R1, the QFX5120 switches support JNP-SFPP-10GE-T transceivers. The JNP-SFPP-10GE-T transceiver supports only 10 Gbps speed.

    Note

    In case a device with a different interface speed (that is, 1 Gbps or 100 Mbps) is connected on the other side of the wire, the interface on the Juniper device does not come up.

    [See QFX5120 System Overview.]

  • Support for dynamic load balancing (QFX5120-32C and QFX5120-48Y)—Starting in Junos OS Release 19.4R1, QFX5120-32C and QFX5120-48Y switches support dynamic load balancing (DLB) for ECMP and LAG. DLB is an enhancement to static load balancing. DLB considers member bandwidth utilization along with packet content for member selection.

    You can use the following DLB modes to load-balance traffic:

    • Flowlet

    • Assigned flow

    • Per-packet

    To configure DLB for ECMP, include the ecmp-dlb statement at the [edit forwarding-options enhanced-hash-key] hierarchy level.

    To configure DLB for LAG, include the dlb statement at the [edit interfaces aex aggregated-ether-options] hierarchy level.

    Note

    You cannot configure both DLB and resilient hashing at the same time. Otherwise, commit error will be thrown.

    [See Understanding Dynamic Load Balancing and Configuring Dynamic Load Balancing.]

  • Support for 10-Gbps speed using JNP-SFP-25G-DAC (QFX5120-48Y)—Starting in Junos OS Release 19.4R1, you can use any of the following JNP-SFP-25G-DAC cables to set 10-Gbps speed on the SFP28 ports of a QFX5120-48Y switch:

    • JNP-SFP-25G-DAC-1M

    • JNP-SFP-25G-DAC-3M

    • JNP-SFP-25G-DAC-5M

    If you've plugged a JNP-SFP-25G-DAC cable into a QFX5120-48Y switch, then the SFP28 ports come up with 10-Gbps speed by default. To configure the SFP28 ports to operate at 25-Gbps speed, you must explicitly configure the speed of the first port in the port group using the set chassis fpc 0 pic 0 port port-num speed 25g command.

    [See Channelizing Interfaces on QFX5120-48Y Switches.]

  • Support for 10-Gbps speed on 10GBASE-T SFP+ transceiver (QFX5100-48S)—Starting in Junos OS Release 19.4R1, QFX5100-48S switches support 10GBASE-T SFP+ transceiver. This transceiver supports 10-Gbps speed by default.

Junos OS XML API and Scripting

  • Automation script library upgrades (ACX Series, EX Series, MX Series, PTX Series, QFX Series, and SRX Series)—Starting in Junos OS Release 19.4R1, devices running Junos OS that support the Python extensions package include upgraded Python modules. Python scripts can leverage the upgraded versions of the following modules:

    • idna (2.8)

    • jinja2 (2.10.1)

    • jnpr.junos (Junos PyEZ) (2.2.0)

    • lxml (4.3.3)

    • markupsafe (1.1.1)

    • ncclient (0.6.4)

    • packaging (19.0)

    • paho.mqtt (1.4.0)

    • pyasn1 (0.4.5)

    • yaml (PyYAML package) (5.1)

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

  • Python 3 support for commit, event, op, and SNMP scripts (ACX Series, EX Series, MX Series, PTX Series, QFX Series, and SRX Series)—Starting in Junos OS Release 19.4R1, you can use Python 3 to execute commit, event, op, and SNMP scripts on devices running Junos OS. To use Python 3, configure the language python3 statement at the [edit system scripts] hierarchy level. When you configure the language python3 statement, the device uses Python 3 to execute scripts that support this Python version and uses Python 2.7 to execute scripts that do not support Python 3 in the given release.

    The Python 2.7 end-of-support date is January 1, 2020, and Python 2.7 will be EOL in 2020. The official upgrade path for Python 2.7 is to Python 3. As support for Python 3 is added to devices running Junos OS for the different types of onbox scripts, we recommend that you migrate supported script types from Python 2 to Python 3, because support for Python 2.7 might be removed from devices running Junos OS in the future.

    [See Understanding Python Automation Scripts for Devices Running Junos OS.]

Junos Telemetry Interface

  • JTI and OpenConfig support for VLAN sensors (EX4650, QFX5120)—Junos OS Release 19.4R1 supports the export of VLAN statistics using either Junos telemetry interface (JTI) services or remote procedure call (gRPC) services. You can export statistics at configurable intervals to an outside collector.

    This feature includes OpenConfig support for the data model openconfig-vlan.yang for VLAN configuration version 1.0.2.

    Use the following resource paths in a gRPC or gNMI subscription:

    • /vlans/

    • /vlans/vlan/state/name

    • /vlans/vlan/state/vlan-id

    • /vlans/vlan/state/status

    • /vlans/vlan/members/

    • /vlans/vlan/members/member/interface-ref/state/interface/

    • /vlans/vlan/members/member/interface-ref/state/interface/switched-vlan/state/interface-mode

    • /vlans/vlan/members/member/interface-ref/state/interface/switched-vlan/state/native-vlan

    • /vlans/vlan/members/member/interface-ref/state/interface/switched-vlan/state/access-vlan

    • /vlans/vlan/members/member/interface-ref/state/interface/switched-vlan/state/trunk-vlan

    • /vlans/vlan/members/member/interface-ref/state/interface/vlan/state/vlan-id

    Streaming telemetry data through gRPC or gNMI also requires the OpenConfig for Junos OS module.

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

Layer 2 Features

  • Ethernet ring protection switching (ERPS)(EX4650 and QFX5120)—Starting in Junos OS Release 19.4R1, the EX4650 and QFX5120 support ERPS to reliably achieve carrier-class network requirements for Ethernet topologies forming a closed loop. The ITU-T Recommendation is G.8032 version 1.

    ERPS version 1 comprises the following features:

    • Revertive mode of operation of the Ethernet ring

    • Multiple ring instances on the same interfaces

    • Multiple ring instances on different interfaces

    • Interworking with Spanning Tree Protocol, Multiple Spanning Tree Protocol, and redundant trunk groups

    [See Ethernet Ring Protection Switching Overview.]

  • Redundant Trunk Group support (EX4650 and QFX5120)—Starting with Junos OS Release 19.4R1, EX4650 and QFX5120 switches support redundant trunk group (RTG) links.

    [See Redundant Trunk Groups.]

MPLS

  • MPLS scaling enhancements (EX4650 and QFX5120)—Starting in Junos OS Release 19.4R1, MPLS scaling is enhanced on EX4650 and QFX5120 switches. For instance, you can increase the scale from its default 1024 to 8192 on QFX5120 switches. This enhancement optimizes and increases the ingress tunnel scale to address the current needs of data center networks either in IP-CLOS or IP over MPLS application spaces.

    [See Supported MPLS Scaling Values.]

Routing Protocols

  • Integrating RIFT protocol into Junos OS (MX Series, QFX Series, and VMX virtual routers)—Starting in Junos OS Release 19.4R1, you can integrate a new IGP protocol, Routing in Fat Tree (RIFT), into Junos OS to route packets in variants of CLOS-based and fat tree network topologies (also called the spine and leaf model).

    The RIFT protocol is capable of automatic construction of fat-tree topologies, providing you the benefit of having a close to zero necessary configuration. RIFT makes networks resilient, extensively traceable, and simpler to manage, thereby overcoming the deployment limitations of evolving IP fabrics.

    [See RIFT Overview].

Software Defined Networking (SDN)

  • OVSDB support with VMware NSX for vSphere (QFX5120-32C switches)—Starting with Junos OS Release 19.4R1, the Open vSwitch Database (OVSDB) management protocol provides a control plane through which an NSX controller can provision QFX5120-32C switches. In an environment in which NSX Release 6.4.5 or later is deployed, an NSX controller and these switches can exchange control and statistical information, thereby enabling virtual machine (VM) traffic from entities in a virtualized network to be forwarded to entities in a physical network and the reverse.

    The physical underlay network over which OVSDB-VXLAN is commonly deployed is a two-layer IP fabric that includes spine and leaf devices. The spine devices function as Layer 3 VXLAN gateways, and the leaf devices function as Layer 2 VXLAN gateways. You can deploy QFX5120 switches as leaf devices in this fabric.

    [See Understanding the OVSDB Protocol Running on Juniper Networks Devices.]

  • Layer 2 and Layer 3 VXLAN gateways (QFX5120-32C switches)—Starting with Junos OS Release 19.4R1, you can deploy QFX5120-32C switches as follows:

    • As a Layer 2 VXLAN gateway, or a Layer 2 and Layer 3 VXLAN gateway in an EVPN overlay network

    • As a Layer 2 VXLAN gateway in an OVSDB overlay network

    VXLAN is an overlay technology that allows you to stretch Layer 2 connections over an intervening Layer 3 network by encapsulating (tunneling) Ethernet frames in a VXLAN packet that includes IP addresses. Using VXLANs to connect Layer 2 domains over a Layer 3 network means that you do not need to use the Spanning Tree Protocol (STP) to converge the topology (so no links are blocked) but can use more robust routing protocols in the Layer 3 network instead.

    [See Understanding VXLANs.]

System Logging

  • Improved intermodule communication between FFP and MGD (ACX Series, EX Series, MX Series, PTX Series, QFX Series, and SRX Series)—Starting in Junos OS Release 19.4R1, intermodule communication is improved to enhance software debugging. To enhance error messages with more context, the exit conditions from libraries have been updated as follows:

    • Additional information is now logged for MGD-FFP intermodule communication.

    • Commit errors that previously were only shown onscreen are now logged.

    We provide a new operational command, request debug information, to speed up the initial information-gathering phase of debugging.

    [See request debug information.]

System Management

  • Precision Time Protocol (PTP) transparent clock (QFX5120 and QFX5210)—Starting in Junos OS Release 19.4R1, you can use a transparent clock to update the PTP packets with the residence time as the packets pass through the switch. There is no master/slave designation. The switches support end-to-end transparent clocks, which include only the residence time. The transparent clock can update the residence time in a one-step process, which means it sends the timestamps in one packet.

    To use a transparent clock, enable the e2e-transparent statement at the [edit protocols ptp].

    [See Understanding Transparent Clocks in Precision Time Protocol.]

  • Additional support for Bidirectional Forwarding Detection (QFX5110, QFX5120, QFX5200, and QFX5210)—Starting in Junos OS Release 19.4R1, Bidirectional Forwarding Detection (BFD) can support sessions of less than 1-second intervals. Performance might vary depending on the configuration load within the system.

    Note

    IPv4 and standalone BFD sessions, as well as inline single-hop sessions are supported. Micro BFD implementation and logical router support are not supported.

    [See Understanding Bidirectional Forwarding Detection (BFD). ]

VLAN Infrastructure

  • Support for multiple Q-in-Q tags (QFX10000 switches)—Starting in Junos OS Release 19.4R1, the QFX10000 line of switches support the third and fourth Q-in-Q tags as payload (also known as pass-through tag) along with the existing two tags (for VLAN matching and operations). The QFX10000 switches support multiple Q-in-Q tags for both layer 2 bridging and EVPN-VXLAN cases. The Layer 2 access interfaces accept packets with three or four tags (all tags with the TPID value 0x8100). All the tags beyond the fourth tag (that is, from the fifth tag onward) are considered part of the Layer 3 payload and are forwarded transparently.

    Note

    In a one or two tagged packet, the tags (tag 1 and tag 2) can carry any TPID values (0x8100, 0x88a8, 0x9100, and 0x9200).

    [See Configuring Q-in-Q Tunneling and VLAN Q-in-Q Tunneling and VLAN Translation.]

What's Changed

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

Interfaces and Chassis

  • Logical Interface is created along with physical interface by default (MX Series, QFX Series, EX Series)—Starting in Junos OS Release 19.4R1, logical interfaces are created on ge, et, and xe interfaces along with the physical interface, by default. In earlier Junos OS releases, by default, only physical interfaces are created.

    For example, for ge interfaces, previously when you viewed the show interfaces command, by default, only the physical interface (ge-0/0/0), was displayed. Now, the logical interface (ge-0/0/0.16386) is also displayed.

Management

  • entPhysicalTable fetched on QFX10002—In Junos OS Release 19.4R1, the MIB data for entPhysicalTable will be fetched on a QFX10002-72Q or QFX10002-36Q switch.

    [See SNMP Explorer.]

Software Defined Networking (SDN)

  • Increase in the maximum value of delegation-cleanup-timeout (QFX Series)—You can now configure a maximum of 2147483647 seconds as the delegation cleanup time for a Path Computation Client (PCC). This extends the time taken by the PCC to retain the last provided path over a PCEP session from the last session down time.

    With the increase in maximum value of delegation-cleanup-timeout from 600 to 2147483647 seconds, you can benefit during a Path Computation Element (PCE) failover, or other network issues that may disrupt the PCEP session with the main active stateful PCE.

    [See delegation-cleanup-timeout.]

Known Limitations

Learn about known limitations in Junos OS Release 19.4R1 for QFX Series. 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

  • In EVPN multihomed active/active scenario when LACP is enabled on PE-CE child member links, LACP force-up feature should not be enabled in conjunction with EVPN core isolation feature (enabled by default) because it is currently not supported in this scenario as these two features are contradictory in terms of action they take. PR1461581

Layer 2 Features

  • The Targeted-broadcast forward-only command does not broadcast the traffic. PR1359031

Platform and Infrastructure

  • The chip has VLAN-based logical interface statistics. Since for a given logical interfaces on both IPv4 and IPv6 use the same VLAN, stats will count both V4 and V6 together. There is no way to separately count them. Hence, "IPv6 transit statistics" is always 0. However, the total transit statistics (IPv4 + IPv6) will be displayed under "Transit statistics". PR1327811

  • VLAN is not deleted in the hardware on IRB disable earlier, leading to ARP getting refreshed even though IRB is disabled. PR1421382

  • On QFX5110-32Q running Junos OS Release 18.1R1 and earlier, due to a platform limitation, the channelization of the ports should follow the following design recommendations:

    • With 100-gigabit transceivers connected in the port range 28–31, only ports 0–19 can be channelized in default system-mode.

    • If a 40-gigabit transceiver is connected in any of the 100G supported ports, only ports in the range 1–18 can be channelized in default system-mode.

    • If all 32 ports have 40-gigabit transceivers connected, only ports in the range 1–18 can be channelized in default system-mode.

    • In non-oversubscribed mode, all the valid ports (that is, 0-23) can be channelized as expected. PR1438319

  • There is a limitation regarding this behavior because 500 million is not sufficient for /var/rundb if there is a scaled configuration, which usually keeps the history of the configuration causes this issue and it is mostly seen during rollback and commit with scaled configurations. As a workaround, clean up /var/rundb when it is full and then proceed with commit. PR1452154

Routing Protocols

  • Targeted broadcast functionality with VXLAN is not supported yet on QFX5000 platforms. In case of a non-VXLAN case, broadcast destination IP lookup results in next hop with destination MAC of all 0xffs and gives the class-id for IFP to match and action to redirect to IPMC with vlan membership check. VXLAN case, L3 egress interface, egress L3 next hop, and ingress L3 entry creations are failing. PR1397086

Open Issues

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

Class of Service (CoS)

  • PFC feature will not be supported with QFX5120/EX4650 2-member Virtual Chassis currently due to BCM limitation. PR1431895

  • On QFX5110, QFX5100 and EX4600 platforms, if shaping-rate is configured, the shaping feature might not work after a reboot. The service might be impacted as the traffic cannot be rate limited. PR1432078

  • In Junos Fusion scenario, when traffic from AD (aggregation device) to SD (satellite device) is exported with different dscp marking, it might be changed into network-control queue on extended port of SD. PR1433252

EVPN

  • OVSDB-managed QFX5100 or QFX5110 is encapsulating VXLAN traffic and sending to incorrect destination MAC address when multiple remote VTEPs are in the same subnet and reachable via IRB interface in stretched VLAN. PR1424698

  • In an EVPN environment, proxy ARP and ARP suppression is enabled on the Provider Edge device by default for reducing the flooding of ARP packets; however, in the case of ARP probe packets used in the process of Duplicate Address Detection (DAD), the client may treat the IP address that it is in use as duplicated address after receiving the proxied packets from PE device. PR1427109

  • In Ethernet Virtual Private Network - Virtual Extensible LAN (EVPN-VXLAN) core Isolation scenario, the server is multihomed to the leaf devices through Link Aggregation Control Protocol (LACP) interfaces. If GR (Graceful Restart) is enabled, upon system reboot or restart routing on the leaf device, the core Isolation will not work. In the system reboot case, the issue results in the leaf device being dropped silently the traffic sent from the server during the time window between LACP coming up and Border Gateway Protocol (BGP) coming up. In the restart routing case, there might be no traffic drop because of the GR. PR1461795

High Availability (HA) and Resiliency

  • During unified ISSU from previous releases to Junos OS Release 19.4R1 for QFX5000 platforms, dc-pfe will crash continuously and hence ISSU will not work. PR1472183

Interfaces and Chassis

  • Customers might notice the flooding of ARP reply unicast packets as a result of an ARP request sent for the device's VRRP MAC address. This should not cause major issues. The ARP reply that is flooded in the VLAN by the device has the correct DMAC of the originator of the ARP request. In other words, the ARP reply is flooded but with the correct unicast DMAC. The ARP reply is not broadcast. For example: 15:15:58.378813 In -----original packet----- e4:5d:37:5e:e0:40 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 1123, p 0, ethertype ARP, arp who-has 10.110.59.158 tell 10.110.59.146 15:15:58.378854 Out -----original packet----- 00:00:5e:00:01:3b > e4:5d:37:5e:e0:40, ethertype 802.1Q (0x8100), length 50: vlan 1123, p 0, ethertype ARP, arp reply 10.110.59.158 is-at 00:00:5e:00:01:3b PR1454764

  • When dynamic DHCP sessions are existing in the device, if multiple commits in parallel are performed, the commit might hang up. PR1470622

  • Commit error was not thrown when member link was added to multiple aggregation group with different interface specific options. When member interface added to bundle with both ether and gig-ether interface specific options, gig-ether option takes precedence over ether options. PR1475634

Junos Fusion for Provider Edge

  • IGMP membership is not getting learned by the AD fully even when the IGMP queries is being sent out. PR1419265

Layer 2 Features

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

  • If Packet Forwarding Engine process is restarted manually for QFX5110-32Q, some of MAC address might not be seen on software MAC table in case of EVPN-VXLAN case even though MAC address will be present in hardware table. This is a timing issue and not always seen. This issue is seen only on QFX5110-32Q and not seen on any other platforms. PR1467466

Layer 2 Ethernet Services

  • In EVPN multihomed active/active scenario when LACP is enable on PE-CE child member links and after recovering from a core-isolation on PE device, the PE-CE child member links might be stuck in DETACHED state if LACP sync-reset feature is enabled on CE device. The child links on the CE device might show lacp state as Collecting Distributing, but on the PE the lacp state might be "DETACHED". PR1463791

MPLS

  • The show mpls static-lsp | display xml command produces INVALID XML when more than 100 static LSPs are configured. PR1469378

Platform and Infrastructure

  • In configurations with IRB interfaces, during times of interface deletion (for example, FPC reboot), the Packet Forwarding Engine might log the error as nh_ucast_change:291Referenced l2ifl not found. This condition should be transient, with the system reconverging on the expected state. PR1054798

  • On a QFX Series switch with a third-generation FPC, the error message is displayed when the FPC goes online or offline. PR1322491

  • QFX10000 platform drops the Aruba wireless access point (AP) heartbeat packets. As a result, the Aruba wireless AP cannot work. PR1352805

  • User might not be able to stop the ZTP bootstrap, when a QFX10016/QFX10008 switch with more number of line cards is powered on with factory-default configuration. PR1369959

  • USB upgrade of NOS image is not supported. PR1373900

  • With MLD-snooping enabled and when we have two receivers in the same VLAN interested in the same group address but from a different source, traffic will be received only on the receiver which sent the latest MLD report. This is because we do not install S, G routes in hardware when MLD snooping is enabled. PR1386440

  • On Junos OS Release 18.4R1 branch, Intermittent traffic loss is observed with RTG streams while flapping the RTG primary interface. PR1388082

  • On EX Series and QFX Series platforms, when bringing up clients (most likely in DHCP/PPP subscriber scenario), the subscribers might fail to bind. The reason is that when installing new software images, it might cause shared memory (created by previously running image) not to be cleared out. The issue will persist until the previous values in shared memory are removed, and the daemons affected by the data in shared memory might continue to generate core files and to crash and thus not be able to function properly. PR1396470

  • On QFX5000 platforms with scaled setup of the aggregated Ethernet (ae) bundles and VLANs, if Link Aggregation Control Protocol (LACP) is enabled, and there are scaled configuration changes, for example, delete 4000 VLANS/VXLANs and reapply them again, some interfaces of ae bundle might go to the detached state. Due to this issue, the running routing protocols (for example, LACP and BGP) will go down over the affected ae bundles. PR1406691

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

  • On QFX Series Virtual Chassis during shutdown, if an interrupt is received, the system gets into this state and vmcore is observed. PR1421250

  • LLDP frames received on a QFX5210 management em0 port might not show in show LLDP operational queries. Other non-em0 interfaces will display statistics. PR1426753

  • Hardware is not getting programmed on rebooting QFX5000 node for CoS rewrite on aggregated Ethernet (LAG) interfaces. PR1430173

  • When routing process is restarted, if system is configured with EVPN service, memory of l2 learning daemon is increasing by 4000 when you use show system processes extensive | match l2ald. PR1435561

  • The time it takes to install or delete IPv4/Pv6 routes into the FIB is slowed down in Junos OS Release 19.3. Analysis shows that rpd learning rates are not degraded, but RIB to FIB download rate is degraded. PR1441737

  • During unified ISSU upgrade process sometime if ISSU does not complete or state machine does not move forward, ISSU process if forced to time out and abort. during abort, ISSU states are cleared and ISSU is aborted . This is one of the corner cases where ISSU is not progressed and ISSU. After any such abort, it is good to have reboot of the system as recommended by ISSU console logs, which is also a workaround. PR1443342

  • On QFX10000 platforms and EVPN-VXLAN (spine-leaf) scenario, the QFX10000 spine switches are configured with VXLAN Layer3 gateway (utilizing the virtual-gateway) on an IRB interface, if enabling and then subsequently remove the VXLAN L3 gateway on this IRB interface on one or some of these spine switches, traffic drop might be observed. If all virtual-gateways are configured with an unique v4 or v6 mac-address, this issue would not happen. This is also the workaround. PR1446291

  • When all the members of tanzanite Virtual Chassis are rebooted while traffic is running, for a quite period of time (~15 minutes) backup will be disconnected from master as the master-backup socket connection will be down and will be re-established after 15 minutes and backup will join the Virtual Chassis. PR1453399

  • QFX5200-32c-32q : vmcore occurred at ...../.amd/svl-engdata1vs1/occamdev/build/freebsd/stable_11/20190614.234225 __ci_fbsd_builder_stable_11.0.269d466/src/sys/kern/kern_shutdown.c:313 after upgrade from 18.3Throttle image to Junos OS 19.3R1. PR1455851

  • When traceoptions is enabled for OSPF, rpd might crash if the interface cost is changed. PR1456054

  • In VXLAN setup containing very large number of child interfaces, significant link up delay was seen when one of FPCs in QFX5100 Virtual Chassis is rebooted. PR1456336

  • Show dynamic-tunnels database does not show v6 mapped next-hop flag for the 6PE routes that have labels. It is just a display issue. PR1458634

  • On QFX5100, when unified ISSU is performed with Layer3 protocols configured then traffic loss of 0.8 seconds is observed. PR1459701

  • A libvirtMib_suba core file might be seen after an image upgrade from Junos OS Release 17.3R3-S5.2 to 17.3R3-S6.3 on a QFX5110 device. There is no functional impact due to this core file generation. PR1462725

  • BGP route addition and deletion time increased in Junos OS Release 19.4. PR1464572

  • A few of DHCPvX INFORM Messages, specific to particular VLAN are not receiving any ACK from server. PR1467182

  • When tunnel-services are configured on a PIC, the optics measurements that subscribed via gRPC might not be streamed. PR1468435

  • In Junos Fusion Data Center environment, when a VM is moved from one satellite port to another using VMotion, MAC address of VM might not move to new satellite port in Aggregate Device's switching table. PR1468732

  • If system has 1000 BGP-V4 VRF (120000 routes) + 700 OSPF-V2 VRF (70000 routes) + 300 P2P ISIS V4 VRF (30000 routes) (nearly 220000 hardware routes), then deleting/reading VRF configurations might lead to all BGP sessions going down. PR1469881

  • On QFX5100 and EX4300 mixed-mode Virtual Chassis, the speed 10m might not be configured on the GE interface. PR1471216

  • In VXLAN scenario on QFX1000 series platforms, when VTEP source interface is configured in multiple routing instances, the traffic loss might occur if one of such routing instances is deleted. PR1471465

  • Because of change in new SDK, egress filter's slice usage became double and there will be only 512 entries in Junos OS Release 19.4R1. PR1472206

  • On QFX platforms, the shaping of CoS does not work after reboot when the shaping rate is configured with an absolute value. The line rate of traffic is sent out, no shaping occurs. This issue has traffic or service impact. PR1472223

  • In EVPN-VXLAN scenario, when an SP style interface is configured both with native-vlan-id and LLDP on QFX5000 platforms, continuous log messages might be observed. PR1474545

  • QFX5000 Leaf device might fail to forward the traffic to AR-replicator/Spines, on flapping bgp neighbors on AR-replicator/Spines. PR1475430

  • Interfaces are not detected on some of the ports when we swap the 25g sfps and insert 10g sfp. PR1475574

  • The commit synchronize command fails because the kernel socket gets stuck. PR1177692

  • On the QFX10002-60C, filter operation with log action is not supported for protocols other than Layer 2, IPv4, and IPv6. The following message is seen in firewall logs: Protocol 0 not recognized. PR1325437

Routing Protocols

  • QFX5110, used as VRRP peers, in some specific scenarios involving configuration of bpdu-block-on-edge might claim to be VRRP masters. PR1367439

  • Value added in Hexa after Unknown Ext-Community is getting reset to 0. PR1371448

  • On QFX-5100 VC/VCF, the following error is observed: BRCM_NH-,brcm_nh_bdvlan_ucast_uninstall(), 128:l3 nh 6594 unintsall failed in hardware with mini-PDT base configurations. There is no functionality impact because of this error message. PR1407175

  • On QFX5000/EX4600 platforms, the received traffic will be dropped if the destination UDP port is 521. PR1429543

  • In EVPN/VXLAN scenario with QFX5000 platform, all BGP sessions might go into down status if restarting overlay/underlay BGP session while traffic flow starts. PR1431259

  • QFX5110 MCLAG: L2_L3_INTF_OPS_ERROR messages are seen after node reboot. PR1435314

  • For Junos OS Release 19.3R1: On QFX5100 , when unified ISSU is performed, then traffic loss of 15-20 seconds is observed. PR1449581

  • In an EVPN-VXLAN multihomed environment with QFX5110/QFX5120 acting as leaf devices, if IGMP snooping is used, it might override the local bias filters on designated forwarder (DF) and nondesignated forwarder (NDF) devices, and forwards the packets, causing multicast packets loops. PR1457725

  • Example case: Send flow with interburst gap of 1000 micro seconds.

    1 Configure a flowlet timer value of 16 microseconds.

    2 The flows should split and the flows should be distributed among all the links in the ECMP.

    3 Now change the inactivity-timer to 10000 micro seconds.

    4 The flows should again fall back to single link because the inactivity timer is greater the interburst gap. The aforementioned steps list is the expected behavior in case of above timer value and interburst gap or IFG configured in the flows. But there may be cases when the above values are changed multiple times, the behavior can be unexpected, and flows will not move back to single link even though the inactivity-timer configured is more than the interburst gap or IFG. Trigger: Change the inactivity timer value from less (less than IFG or interburst gap) to more (more than IFG or interburst gap) multiple times. Expected behavior: Flows will move to single link when inactivity-timer is more than IFG. Current behavior: Flows will not move to single link when inactivity-timer is more than IFG. Recovery: Restart dc-pfe. PR1471729

Resolved Issues

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

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)

  • QFX10008: FPC0 generated core files after running the Packet Forwarding Engine command show cos sched-usage. PR1449645

  • The show cos scheds-per-pfe, show cos pfe-scheduler-ifds ,and pfe commands will restart forwarding planes on QFX10008 switches. PR1452013

EVPN

  • Asynchronous result between ARP table and Ethernet switching table happens if EVPN ESI link flaps multiple times. PR1435306

  • When using no-arp-suppression , an ARP request might not be sent out when an ARP entry aged out. PR1441464

  • ARP and IPv6 neighbor entries cannot be cleared when they are learned from EVPN multihomed ESI. PR1446957

  • EVPN-VXLAN NON-COLLAPSED: ARP will get resolved on QFX5100 for VXLAN having vlan-id of 2. PR1453865

  • ARP request/NS might be sent back to the local segment by DF router. PR1459830

Forwarding and Sampling

  • Commit error and dfwd core files might be observed when applying a firewall filter with action then traffic-class or then dscp. PR1452435

Interfaces and Chassis

  • VRRPv6 state is flapping with init and idle states after configuring vlan-tagging. PR1445370

  • On QFX10000 ARP entries might not be synchronized between MC-LAG devices. PR1449806

  • The traffic might be forwarded to the incorrect interfaces in MC-LAG scenario. PR1465077

  • Vrrpv3mibs are not working on QFX Series platform to poll VRRPv6 related objects. PR1467649

Layer 2 Features

  • Storm control configuration might be disabled for the interface. PR1354889

  • Packet loss might be seen when one of the spine switches fails or reboots. PR1421672

  • Ethernet ring protection switching (ERPS) nodes might not converge to IDLE state after failure recovery or reboot. PR1431262

  • EVPN-VXLAN NON-COLLAPSED: JTASK and multimove depth failed errors are seen after HALT. PR1434687

  • The MAC/ARP learning might not work for copper base SFP-T on QFX5100/QFX5110/EX4600. PR1437577

  • The traffic leaving QFX5000 and EX46000 switches might not be properly load-balanced over ae interfaces. PR1448488

  • Unequal LAG hashing might happen on QFX devices. PR1455161

  • The fxpc.core file might be seen when committing the configuration all together, for example, after the reboot. PR1467763

MPLS

  • The l2circuit traffic might be silently dropped at EVPN SPINE/MPLS LSP TRANSIT device if VXLAN access interface flaps on remote PE node (QFX5110). PR1435504

  • Packet loss might occur when ECMP resilient-hash is enabled on QFX5000 platforms. PR1442033

Platform and Infrastructure

  • QFX5100-VC MacDrainTimeOut and bcm_port_update failed: Internal error. PR1284590

  • On QFX5100 platforms, LR4 QSFP can take up to 15 minutes to come up after Virtual Chassis reboot. PR1337340

  • When powering off an individual FPC, the other FPC Packet Forwarding Engine might go offline too. PR1344395

  • Mib2d core file in mib2d_write_snmpidx at snmpidx_sync.c on both ADs while bringing up base traffic profile. PR1354452

  • Need new CLI command to enable copying of Open vSwitch Database (OVSDB) to RAM on Virtual Chassis backup Routing Engine instead of SSD. PR1382522

  • FEC error counts are not updating for QFX5110. PR1382803

  • QSFP-100GBASE-SR4/LR4 might take a long time to come up after disabling interface or reboot. PR1402127

  • Ping over loopback might not work over type 5 tunnel on QFX10000 platforms. PR1405786

  • QFX5200/5100 might not be able to send out control plane traffic to the peering device. PR1406242

  • No inner VLAN tag is added even with input-vlan-map push configured on QFX10000 platforms. PR1407347

  • The optic comes with Tx enabled by default. As the port is administratively disabled, the port is stopped but as the port has not been started, it does not disable Tx. PR1411015

  • QFX5120 : Route table full for IPv6 routes in some scenarios. PR1412873

  • Intermittently chassis alarms might not be raised after power-cycle of the device. PR1413981

  • IPv6 multicast traffic received on one Virtual Chassis member might be dropped when egressing on other Virtual Chassis member if MLD snooping is enabled. PR1423310

  • Ports might get incorrectly channelized if they are 10-Gigabit Ethernet already and they are channelized to 10-Gigabit Ethernet again. PR1423496

  • On QFX5000 or QFX10000 switches, packet drops might be seen for the traffic that has to go over type-5 overlay tunnel. PR1423928

  • The dcpfe/Packet Forwarding Engine might not start on AS7816-64X and QFX5000 TVP platform devices. PR1426737

  • QFX5210: Received LLDP frames on em0 not displaying in LLDP neighbor output. PR1426753

  • QFX5100-VCF - rollback for uncommitted configuration takes 1 hour. PR1427632

  • Packet drops, replication failure, or ksyncd crashes might be seen on the logical system of a device running Junos OS after Routing Engine switchover. PR1427842

  • The dcpfe process might crash and restart in MC-LAG scenario when the ARP/NDP next hop is changed. PR1427994

  • The global-mac-limit and global-mac-ip-limit might allow more entries than the configured values. PR1428572

  • [QFX10008] After Routing Engine switchover, LED status is not set for missing fan tray. PR1429309

  • The l2cpd process might crash and generate a core file when interfaces are flapping. PR1431355

  • The dcpfe might crash on all line cards on QFX10000 in a scaled setup. PR1431735

  • The FPC might crash when a firewall filter is modified. PR1432116

  • Outer VLAN tag might not be pushed in the egress VXLAN traffic toward the host for Q-in-Q scenario. PR1432703

  • Line card might crash due to plug in unsupported SFP-T module. PR1432809

  • Traffic loss might be seen on QFX10000/PTX10000 platforms using line card LC1105. PR1433300

  • Layer 3 filters applied to PVLAN IRB interface might not work after unified ISSU. PR1434941

  • QFX5100-Virtual Chassis : NSSU: there might be approximate 1 minute traffic loss during NSSU with LACP link protection configuration. PR1435519

  • The mc-ae interface might get stuck in waiting state in dual mc-ae scenario. PR1435874

  • QFX5200 NSSU: dcpfe core file is seen after NSSU upgrade of backup followed by reboot. PR1435963

  • DHCP discover packets sent to IP addresses in the same subnet as IRB interface cause the QFX5110 to send bogus traffic out of DHCP-snooping enabled interfaces. PR1436436

  • Unknown SNMP traps (1.3.6.1.4.1.2636.3.69.1.0.0.1) are sent on QFX5110 restart. PR1436968

  • The FPC might crash if both the ae boundle flapping on the local device and the configuration change on peer device occur at the same time. PR1437295

  • BGP neighborship might not come up if the MACsec feature is configured. PR1438143

  • The DHCP snooping table might be cleared for VLAN ID 1 after adding a new VLAN ID to it. PR1438351

  • Port LED turns red when cable is connected on QFX5210. PR1438359

  • Interfaces configured with flexible-vlan-tagging might loss connectivity. PR1439073

  • The xSTP recognizes 1G SFP-T optic interface as LAN type resulting, in slow STP convergence. PR1439095

  • LACP MUX state stuck in "Attached" after disabling peer active members when link protection is enabled on local along with force-up. PR1439268

  • DHCPv6 relay binding is not up while verifying the DHCP Snooping along with DHCPv6 relay. PR1439844

  • EX4600 Virtual Chassis does not comes up after replacing Virtual Chassis port from fiber connection to DAC cable. PR1440062

  • MAC addresses learned on RTG might not be aged out after a Virtual Chassis member is rebooted. PR1440574

  • QFX10002 MCLAG PDT: Layer 2, Layer 3 Traffic drop is seen on disabling/enabling MC-LAG. PR1440732

  • The Layer 3 communication might break on an interface that is configured with flexible-ethernet-services. PR1441690

  • The operational status of the interface in hardware and software might be out of synchronization in EVPN setup with arp-proxy feature enabled. PR1442310

  • Flow control does not work as expected on 100-Gigabit Ethernet interface of QFX5110. PR1442522

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

  • DHCPv6 client might fail to get an IP address. PR1442867

  • When a line card is rebooted, the MC-LAG might not get programmed after the line card comes back online. PR1444100

  • QFX5200: Observing DCBCM[bcore_init]: ioctl call failed ret:0 failure message when changing UFT profile in FPC logs. PR1445855

  • On QFX10008, traffic impact might be seen when the JSRV interface is used. PR1445939

  • CoS classifier might not work as expected. PR1445960

  • IPinIP: QFX - CoS rewrite happens to both inner and outer header. PR1446128

  • IPinIP: ptx/qfx - Upon steering of underlay dynamic tunnel PNHs to a different set of ECMP next hops, unrelated IPv6 based tunnel traffic is tagged with the incorrect VLAN. PR1446132

  • Traffic discarded for only specified VLAN in IPACL_VXLAN filters. PR1446489

  • Long IPv6 address are not displayed fully on IPv6 neighbor table. PR1447115

  • Unicast ARP requests are not replied with no-arp-trap option. PR1448071

  • Rebooting QFX5120-48Y using request system reboot doesn't take physical links offline immediately. PR1448102

  • QFX10000 -- QSFP28 100G AOC / 740-065632 & QSFP+ 40G / 740-043308 transceiver -- port LED remains lit green after disconnecting one end. PR1448121

  • QFX5100-48t's in a mixed Virtual Chassis with QFX5110 switches are experiencing rx crc errors on vc-ports 53 and 52. PR1449406

  • Except one AE member link, the other links do not send out sFlow sample packets for ingress traffic. PR1449568

  • REST API process will get non-responsive when a number of request coming with a high rate. PR1449987

  • RMPC core files are found after configuration changes are done on the network for PTP/Clock Synchronization. PR1451950

  • Vgd core files might be generated when tunnel gets deleted twice. PR1452149

  • DHCP offer packet with unicast flag set gets dropped by QFX10000 in a VXLAN multi-homed setup using anycast IP. PR1452870

  • Configuration change in VLAN all option might affect the per-VLAN configuration. PR1453505

  • The classifier configuration doesn't get applied to the interface in an EVPN/VXLAN environment. PR1453512

  • The show chassis led shows incorrect status. PR1453821

  • On QFX5100-VC VGD process hogs the CPU without switch-options vtep-source-interface lo0.0 configuration. PR1454014

  • Master FPC might come up in master state again after reboot instead of backup. PR1454343

  • QFX10002-60c: EVPN-VXLAN: MAC+IP Count is shown as Zero. PR1454603

  • QFX5120 : Untagged hosts ARP/NS connected on encapsulation ethernet-bridge interface are not being resolved. PR1454804

  • The PFC feature doesn't work on QFX10000 platforms. PR1455309

  • The laser from the 10G SFP+ interface is still on when the interface is disabled or the device is rebooted. PR1456742

  • Over temperature SNMP trap messages are shown after update even though the temperatures are within the system thresholds. PR1457456

  • Dual tag Q-in-Q is not working with EVPN-VXLAN. PR1458206

  • QFX5210 : LED does not light on port 64 and 65 after upgraded to Junos OS Release 19.2R1. PR1458514

  • The BPDU packet might be looped between leaf DF switch and non-DF switch and cause traffic blocking. PR1458929

  • The dhcpv6 LDRA relay bounded count is not as expected after dchp is configured. PR1459499

  • The fxpc process might crash due to BGP IPV6 session flaps. PR1459759

  • The forwarding option is missed in routing-instance type. PR1460181

  • The ’entPhysicalTable’ MIB is not fetching expected data on QFX10002-72Q / 36Q platforms. PR1462582

  • The firewall filter does not get hit for traceroute packets when destination MAC address is VRRP virtual MAC. PR1463425

  • On QFX5100 Virtual Chassis, the error BRCM-VIRTUAL,brcm_vxlan_walk_svp(),6916:Failed to find L2-iff for ifl: might appear during cleanup of EVPN-VXLAN configurations. These messages are harmless. PR1463939

  • A few of the interfaces stay down and keep flapping for QFX ULC-3DWDM-MACsec line cards on reboot. PR1464650

  • QFX5100-24Q: Not able to apply DSCP rewrite to firewall filter to a Layer 3 subinterface (for example, xe-0/0/0.100). PR1464883

  • PEM is not present spontaneously on QFX5210. PR1465183

  • The 10-Gigabit Ethernet port on QFX5100-48T negotiates with speed 1 GB with BRCM 10G/GbE 2+2P 57800-t rNDC. PR1465196

  • The QSFP-100G-PSM4 could not be correctly identified on QFX5200 or QFX5110 platforms. PR1465214

  • When BGP open messages with specific types of BGP optional capabilities are sent during BGP session establishment, incorrectly coded messages are later sent to the BMP Collector. PR1466477

  • Slow packet drops might be seen on QFX5000 platforms. PR1466770

  • Ingress drops to be included at CLI from interface statistics and added to InDiscards. PR1468033

  • QFX5120 is looping the IP routed packet through IS-IS or MPLS. PR1469998

  • l2ald core is seen (l2ald_mem_free, l2ald_update_comp_vmenh) after restarting dc-pfe in Virtual Chassis devices. PR1473521

Routing Protocols

  • Host-destined packets with filter log action might not reach to Routing Engine if log/syslog is enabled. PR1379718

  • The IRB transit traffic might not be counted for EVPN-VXLAN traffic. PR1383680

  • QFX5100 : BGP IPv4 and IPv6 convergence and RIB installation and deletion time are degraded in Junos OS Releases 19.1R1, 19.2R1, 19.3R1, and 19.4R1. PR1414121

  • The fxpc core file might be seen during the reboot of device on QFX5100/EX4600 switches. PR1432023

  • The IPv4 fragmented packets might be broken if PTP transparent clock is configured. PR1437943

  • Traffic might be dropped after the Q-in-Q enabled interface is flapped or a change is made to the vlan-id-list. PR1441402

  • QFX5210: firewall Filter DSCP action modifier does not work when firewall filter is mapped to IRB. PR1441444

  • IPv6 connectivity between MC-LAG peers might fail when multiple IRB interfaces are present. PR1443507

  • PIM (S,G) joins can cause MSDP to incorrectly announce source active messages in some cases. PR1443713

  • The QFX5120 might drop the tunnel encapsulated packets if it acts as a transit device. PR1447128

  • Loopback address exported into other VRF instances might not work on ACX Series, EX Series, and QFX Series platforms. PR1449410

  • MPLS LDP might still use stale MAC of the neighbor even the LDP neighbor's MAC changes. PR1451217

  • A few seconds of traffic drop might be seen on the existing receivers when another receiver joins/leaves. PR1457228

  • The egress interface in Packet Forwarding Engine for some end-hosts might not be correct on the Layer 3 gateway switch after it is rebooted. PR1460688

  • The "other querier present interval" timer cannot be changed in IGMP/MLD snooping scenario. PR1461590

  • When deleting IRB on the Layer 3 gateway, IRB does not get removed from Packet Forwarding Engine and will silently drop traffic to IRB MAC address. PR1463092

User Interface and Configuration

  • EX4600 and QFX5100 were unable to commit baseline configuration after being returned to zero. PR1426341

Documentation Updates

This section lists the errata and changes in Junos OS Release 19.4R1 for the QFX Series switches documentation.

Feature Guides Are Renamed As User Guides

  • Starting with Junos OS 19.4R1, we renamed our Feature Guides to User Guides to better reflect the purpose of the guides. For example, the BGP Feature Guide is now the BGP User Guide. We didn’t change the URLs of the guides, so any existing bookmarks you have will continue to work. To keep the terminology consistent on our documentation product pages, we renamed the Feature Guides section to User Guides. To find documentation for your specific product, check out this link.

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 19.4 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 19.4 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-19.4-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 19.4jinstall 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-19.4R1.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-19.4R1.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-19.4R1.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-19.4R1.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-19.4R1.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-19.4R1.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-19.4R1.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 17.1, 17.2 and 17.3 are EEOL releases. You can upgrade from Junos OS Release 17.1 to Release 17.2 or from Junos OS Release 17.1 to Release 17.3.

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.