Just enabling CW does not stop transit from mis-guessing payload.
Complete solution requires
a) Enable CW
b) Disable payload heuristics in transit (only rely on labels)
c) Enable Entropy or FAT (ECMP/LAG is essentially non-optional today).
Why enabling just CW won't help, is that some platforms, like JunOS
will by default try to detect presence of CW and proceed with
heuristics with different offset if or not CW was detected.
This creates several problem, first if you have CW and non-CW traffic,
then non-CW traffic with XEROX DMAC will cause wrong offset for
heuristics, allowing transit to misidentify.
JunOS isn't just checking for first nibble, it'll need etherType,
ipVer and and ipLen to match. But as detecting CW doesn't actually
change the heuristics, just offset. There is 0 guarantee that we are
actually seeing IP packet when we think we are. It is highly probable
we guess right, but really convenient packet, and we will misidentify.
Because it'll need extremely convenient frame, it will happen very
very rarely, but when it does, no one will be able to troubleshoot it.
How can you attribute problem like this to core 'everything works
perfectly on every station before we added GRE tunnels to our
stations, but after we added GRE tunnels to our station, _one_ station
experiences packet loss', this is possible outcome in JunOS
implementation with or without CW, unless heuristics is also disabled.
[hidden email] set forwarding-options enhanced-hash-key
family mpls ?
no-ether-pseudowire Omit IP payload over ethernet PW from the hash-key
no-payload Omit MPLS payload data from the hash key