[j-nsp] LAG/ECMP hash performance
Saku Ytti
saku at ytti.fi
Sat Aug 24 05:05:29 EDT 2019
Has anyone ran into a set of flows where ostensibly you have enough
entropy to balance fairly, but you end up seeing significant imbalance
anyhow? Can you share the story? What platform? How did you
troubleshoot? How did you fix?
I'll take nonJNPR stories too.
It looks like many/most vendors are still using CRC for LAG/ECMP,
which historically makes sense, as you could piggyback on EthernetFCS
transistors for 0cost implementation. Today likely the transistors are
different anyhow as PHY and lookup engine are too separate, so CRC may
not be very good choice for the problem.
If I read this right (thanks David)
https://github.com/rurban/smhasher/blob/master/doc/crc32 - CRC32
appears to have less than perfect 'diffusion' quality, which would
communicate that there are scenarios where poor balancing is by design
and where another hash implementation with good diffusion quality
would balance fairly.
Thanks!
--
++ytti
More information about the juniper-nsp
mailing list