This article explains how QFX5000 devices hash MPLS traffic inconsistency and to resolve it.
When the following conditions are met, the ECMP hash might not be consistent and the traffic may select a different next-hop within ECMP next-hop:
This issue is due to the QFX5000 device ECMP having Port/Mod-Id for hashing. The traffic incoming physical port is impacting the hash result and cause the traffic to select a different next-hop.
The issue can be fixed by applying the Junos CLI command below to change the register for removing the port/mod-id for hashing.
request pfe execute target fpc0 command "set dcbcm bcmshell \"modreg RTAG7_MPLS_L3_PAYLOAD_HASH_FIELD_BMAP MPLS_L3_PAYLOAD_BITMAP_B=0xff0 MPLS_L3_PAYLOAD_BITMAP_A=0xff0\""
The workaround will not impact service and take effect immediately.
The register value will restore to default value after device reboot or PFE crash. It can remain persistence via configuring the following Junos event script:
set event-options policy mod_mpls_hash_register events PIC set event-options policy mod_mpls_hash_register within 30 trigger on set event-options policy mod_mpls_hash_register within 30 trigger 1 set event-options policy mod_mpls_hash_register attributes-match PIC.message matches "FPC PFE resync_done fpc 0" set event-options policy mod_mpls_hash_register then execute-commands commands "request pfe execute target fpc0 command \"set dcbcm bcmshell \\"modreg RTAG7_MPLS_L3_PAYLOAD_HASH_FIELD_BMAP MPLS_L3_PAYLOAD_BITMAP_B=0xff0 MPLS_L3_PAYLOAD_BITMAP_A=0xff0\\"\""
This issue has been addressed since 15.1X53-D238 via adding the following new CLI to change it.
The device's default behavior is not changed. You have to change the config to archive it.
set forwarding-options enhanced-hash-key mpls no-incoming-port set forwarding-options enhanced-hash-key mpls no-incoming-device