Known Limitations
Learn about limitations in this release for the QFX Series switches.
For the most complete and latest information about known Junos OS Evolved defects, use the Juniper Networks online Junos Problem Report Search application.
General Routing
-
The recommended procedure for FPC card removal is to do a graceful OIR by following the documented steps. However, if the FPC card is ungracefully jacked out or plugged in several times in a short interval, the software may show the FPC status as "FAULT". Below are the steps to recover from the fault state: 1. Jack out the FPC 2. Wait for 1 minute for FPC state to become 'Fault' in 'show chassis fpc pic-status' command 3. Jack In FPC 4. Wait for 1 minute for FPC state shows as Present in 'show chassis fpc pic-status' command 5. Run cli command 'request chassis fpc online slot fpc slot number ' to bring FPC in online state 6. Wait for 3 minutes for all interfaces to come upPR1799333
-
When a VXLAN encapsulated IP packet, or an IP packet with UDP port matching the VXLAN UDP port, is received on a vlan-tagging enabled interface, the switch drops the frame. This issue is not seen if the incoming port is an untagged interface, or if the interface is actually doing VXLAN encap/decap operations. In such cases, the device forwards the frame correctly.PR1805922
-
On QFX5240 QFX5230 platforms with 23.4R2, when PFC watchdog feature configured with recovery action of "drop" and if PFC storm continuously detected and recovered , CRC error counter could increase with small number under "show interface extensive interface" output. These CRC errors could occur only for larger frames (mtu>1024) received at high rate. Packet drops will be seen on the interface due to PFC watchdog action of drop, which is expected. CRC errors will not be seen with PFC watchdog recovery action of "forward". PR1807420
-
On QFX5700E, " pci 0000:xx:xx.x BAR xx: failed to assign" messages are seen during boot in the logs. These messages have no impact to functionality.PR1807706
-
IPv4/IPv6 reserved multicast and L2 multicast traffic received over VXLAN access port will be flooded out of all ports of the VXLAN except vtep.PR1811158
-
Storm control does not work on multicast packets on QFX5130, QFX5700 platform if broadcast packets are excluded from the storm control profile. To support IGMP, MLD snooping functionality, we've added flood in vlan rules in asic pipeline which causes mcast packets to flooded as broadcast packets due to BCM TD4 asic limitation.PR1813514
-
On EVO QFX5K platforms , PFC XON and MRU values configured under congestion notification profile are properties of Ingress port priority-group. Junos CLI doesn't have any equivalent construct for ingress port priority-group, unlike queue which has forwarding-class construct in CLI. Codepoint (priority) to priority-group mapping happens in PFE based on CNP configuration using internal logic. As there are only 6 lossless priority groups per ingress port, there is possibility of more than one IEEE 802.1P / DSCP code points to get mapped to same PG (fate sharing). In this case if the code points mapped to same PG configured with different XON values, then the XON value associated with highest codepoint will be programmed in HW for the corresponding priority group. This is due to entries in CNP profile are processed and programmed in ascending order based on codepoint. If the code points mapped to same PG configured with different MRU values, then the MRU value associated with lowest codepoint will be used to calculate PFC headroom for that PG. PR1822023
-
The PFC watchdog can be triggered when it is set with a very low detection timer value, like 4 ms, while continuously receiving PFC XOFF frames from the peer device. On the peer device, two different priorities have been configured for PFC. One priority has a very high PFC XON offset (greater than 10,000), while the other priority uses the default PFC XON offset (20). As part of the PFC feature, BCM supports a PFC refresh functionality. When a priority experiences congestion and the current buffer utilization exceeds the PFC XOFF threshold, a PFC XOFF frame is sent. If the buffer utilization does not fall back to the PFC XON threshold within the default PFC refresh time, the port will generate a new PFC XOFF refresh frame to the peer device. For a 100G port, the default refresh time is 262 microseconds. This is why multiple PFC XOFF frames may be observed before a PFC XON frame is sent. This behavior is expected for the priority with the higher XON offset. However, due to hardware design limitations, the PFC refresh timer operates on a per-port basis. Therefore, when the per-port PFC refresh timer expires, the port triggers PFC refresh XOFF frames for all priorities that are in the XOFF state at that time. The hardware cannot distinguish which priority's refresh timer has expired. As a result, even for a priority with the default XON offset, multiple refresh XOFF frames may be sent continuously due to the expiration of the port-level PFC refresh timer. This could cause the peer device to detect a PFC storm for that priority as well. Since this is a hardware limitation, it cannot be resolved. Aside from the continuous XOFF frames that may trigger PFC watchdog detection on the peer, there are no other functional impacts due to this design. The recommendation is that if a user sets a very high XON offset for any priority on a port, which could lead to PFC refresh timer expiry and continuous XOFFs, the peer device should be configured with a longer PFC watchdog detection timer. For instance, if a PFC XON offset of 10,000 is set for a priority, the peer device should have a PFC watchdog detection timer of at least 10 ms.PR1833562
-
On restarting the picd app on QFX5700 , interfaces flap .PR1842469
-
EP-style L2 IFL statistics (ingress / egress) is not supported on EVO QFX platforms.PR1843854