Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Known Behavior

 

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

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

Class of Service (CoS)

  • With Pechip version 1.1 if dot1p rewrites are configured on a interface then packets which are not matching to a rewrite rule will not retain there previous value, and set it to 0. This functionality is fixed in pechip version 2.0 PR1294471

EVPN

  • A provider edge (PE) device running EVPN IRB with an IGP configured in a VRF associated with the EVPN instance will be unable to establish an IGP adjacency with a CE device attached to a remote PE device. The IGP instance running in the VRF on the PE might be able to discover the IGP instance running on the remote CE through broadcast or multicast traffic, but will be unable to send unicast traffic directly to the remote CE device. PR977945

  • A QFX10000 switch running Junos OS Release 17.4R1 or later software might experience a small and continuous traffic loss under the following conditions:

    • The switch is configured as a Layer 2 and/or Layer 3 VXLAN gateway in an EVPN-VXLAN topology with either a two-layer or collapsed IP fabric.

    • The switch has default ARP and MAC aging timer values.

    Under these conditions, the following types of traffic flows might be impacted:

    • Bidirectional Layer 3 traffic in a multihomed topology.

    • Unidirectional Layer 3 traffic in a single-homed topology.

    Note that this issue does not impact bidirectional Layer 3 traffic in a single-homed topology.

    To prevent loss in these traffic flows, you must set the aging-timer configuration statement in the [edit system arp] hierarchy level so that the value is less than the value of the global-mac-table-aging-time configuration statement in the [edit protocols l2-learning] hierarchy level. PR1309444

  • Even though an ARP route is learned locally, the show arp command output on the provider edge (PE) device on which the route was learned might display the route as permanent remote. In Junos OS releases before Junos OS Release 17.4R1, permanent remote means that the ARP route was learned from a remote PE device as an EVPN Type 2 route (MAC+IP route).

    This issue might occur under the following conditions:

    • A customer edge (CE) device is multihomed to QFX10000 switches in an EVPN-VXLAN topology with a two-layer IP fabric or collapsed IP fabric.

    • The QFX switches function as Layer 3 only, or Layer 2 and Layer 3 PE devices.

    • The QFX switches run Junos OS Release 17.4R1 or later.

    To work around this issue, you can view locally learned ARP routes by entering the show evpn database origin local command on the PE devices. PR1324824

High Availability (HA) and Resiliency

  • During a nonstop software upgrade (NSSU) on an EX4300 Virtual Chassis, a traffic loop or loss might occur if the Junos OS software version that you are upgrading and the Junos OS software version that you are upgrading to use different internal message formats. PR1123764

Interfaces and Chassis

  • Configuring link aggregation group (LAG) hashing with the edit forwarding-options enhanced-hash-key inet vlan-id statement uses the VLAN ID in the hashing algorithm calculation. On some switching platforms, when this option is configured for a LAG that spans FPCs, such as in a Virtual Chassis or Virtual Chassis Fabric (VCF), packets are dropped due to an issue with using an incorrect VLAN ID in the hashing algorithm. As a result, the vlan-id hashing option is not supported in a Virtual Chassis or VCF containing any of the following switches as members: EX4300, EX4600, QFX3500, QFX3600, QFX5100, or QFX5110 switches. Under these conditions, use any of the other supported enhanced-hash-key hashing configuration options instead. PR1293920

Layer 2 Features

  • On QFX5100 Virtual Chassis interfaces on which flexible VLAN tagging has been enabled, STP, RSTP, MSTP, and VSTP protocols are not supported. PR1075230

Routing Protocols

  • During a graceful Routing Engine switchover (GRES) on QFX10000 switches, some IPv6 groups might experience momentary traffic loss. This issue occurs when IPv6 traffic is running with multiple paths to the source, and the join-load-balance statement for PIM is also configured. PR1208583

  • Configuring link aggregation group (LAG) hashing with the [edit forwarding-options enhanced-hash-key] inet vlan-id statement uses the VLAN ID in the hashing algorithm calculation. On some switching platforms, when this option is configured for a LAG that spans FPCs, such as in a Virtual Chassis or Virtual Chassis Fabric (VCF), packets are dropped due to an issue with using an incorrect VLAN ID in the hashing algorithm. As a result, the VLAN ID hashing option is not supported in a Virtual Chassis or VCF containing any of the following switches as members: EX4300, EX4600, QFX3500, QFX3600, QFX5100, or QFX5110 switches. Under these conditions, use any of the other supported enhanced-hash-key hashing configuration options instead. PR1293920

  • For the QFX10002 and QFX10008 switches, you might observe an increase in the convergence time of OSPF routes when compared to Junos OS 17.3 releases. An average increase of 1.5 seconds is seen for 100,000 OSPFv3 routes. PR1297541

  • A QFX10000 switch running Junos OS Release 17.3Rx or 17.4Rx software might experience a small and continuous traffic loss under the following conditions: 1) The switch is configured as a Layer 2 and/or Layer 3 VXLAN gateway in an EVPN-VXLAN topology with either a two-layer or collapsed IP fabric, and 2) The switch has default ARP and MAC aging timer values. Under these conditions, the following types of traffic flows might be impacted: 1) Bidirectional Layer 3 traffic in a multihomed topology, and 2) Unidirectional Layer 3 traffic in a single-homed topology. Note that this issue does not impact bidirectional Layer 3 traffic in a single-homed topology. PR1309444

Platform and Infrastructure

  • On a QFX5110-32C switch, if a splitter cable is connected to a Spirent 10G CV/MX card, ports will not come up due to varied pre-empt settings for the splitter and DAC cables. There is a hardware limitation where we have no way in EEPROM to differentiate between splitter and DAC cable to apply different settings. As a workaround, use a 40G Spirent card with internal channelization on the Spirent side and manual channelization on the QFX5110-32C side. PR1280593

  • ERPS convergence takes time after GRES switchover and hence traffic loss is observed for a brief period. PR1290161

  • On QFX Series, the logical interface (IFD) and the physical interface (IFL) go down when traffic exceeds rate-limit. Storm control is supported only on interfaces configured in family Ethernet-switching. Moreover, in this family, we support only one IFL per IFD. Due to this, bringing down the IFD is acceptable. Flexible VLAN tagging is not supported on the interfaces enabled for storm control. PR1295523

  • Traffic drop occurs on sending Layer 3 traffic across MPLS LSP. PR1311977

  • Traffic drop occurs on sending traffic over "et" interfaces due to CRC errors. PR1313977

  • On Junos Automation Enhancement images there is a way to use Python interpreter in interactive mode. When Python interpreter is used in an interactive mode on a shell, the prompt does not seem to return immediately. Example of the session is given below: -- % python Python 2.7.8 (default, Nov 10 2017, 01:45:13) [GCC 4.2.1 (for JUNOS)] on junos Type "help", "copyright", "credits" or "license" for more information. >>> >>> print "hello" >>> hello ----------> waiting here, hit 'enter' here to return the python prompt >>> quit() >>> % -- The regular script run is not impacted. PR1324124

Storage and Fibre Channel

  • If the configuration changes or any aggregation devices (AD) restart, you might see inconsistency in the output of show ethernet-switching table and show fip snooping satellite on different ADs for some time. It takes time for the ADs to completely restart and hence MAC addresses might be learned over EVPN (DRP flag). When AD restart is complete, MAC addresses should be learned locally and hence the DRP flag moves to the S flag. It can take up to 10 minutes to get consistent output for show commands. The output for show ethernet-switching table on all ADs will show all the MAC addresses. However, the flags against the MAC addresses might be different on the ADs because the MAC addresses might be learned statically on some ADs and dynamically on others. The flag against the dynamic MAC addresses will be changed from D to S once those MAC addresses are relayed from the satellite device (SD) to the AD, which can take up to 10 minutes. However, there should not be any traffic drop. Traffic drop is expected only initially, when the AD has just been restarted. PR1304173