The Article Provides details on the log message "fpc0 BRCM_NH_ECMP_THRESHOLD_REACHED: Maximum number of ECMP entries reached". seen on devcies

• In rare scenarios on Junos QFX5K/EX4K platforms that are part of Ethernet VPN - Virtual extensible LANs (EVPN-VXLAN) Fabric topology and employing ECMP (Equal Cost Multi-path) routing on the underlay interfaces between the Leaf and Spine.
• If one or more of these physical underlay interfaces flaps or their associated underlay protocol adjacency flaps and this time aligns precisely with the associated unicast next-hop deletion process, a race condition may occur, resulting in the potential failure to program the associated ECMP interface next-hop entry correctly in the hardware table

On Junos QFX5100, QFX5110, QFX5120, QFX5200, QFX5210, EX4600, EX4650, EX4400, EX4100 platforms in EVPN-VXLAN scenario with ECMP enabled.

This issue could lead to one of the following three scenarios :

1. Incorrect underlay traffic load balancing.

2. Incorrect underlay traffic forwarding.

3. Traffic drop on the impacted underlay interface.

• Upgrade the device to resolved Junos version,

21.2R3-S8

21.4R3-S7

22.2R3-S4

22.3R3-S3

22.4R3-S2

23.2R2-S1

23.4R2

24.2R1

24.3R1

• In the affected releases when the "BRCM-VIRTUAL,brcm_virtual_venh_unicast_uninstall(),2100:pending deleting nh" message is seen in the ukern trace, it suggests that IPC messages are out of order and it could point to a possible programming error. Note that this message could still be seen on the fixed releases however the fix would ensure that out of order IPC messages would not lead to a ECMP programming issue

This issue might be seen if the following conditions are met:

* On Junos QFX5100, QFX5110, QFX5120, QFX5200, QFX5210, EX4600, EX4650, EX4400, EX4100 platforms

* EVPN/VXLAN fabric design with ECMP routing employed for underlay interfaces

* Underlay physical interface flap or underlay protocol adjacency flap due to a rare race condition