[j-nsp] LAG/ECMP hash performance
Saku Ytti
saku at ytti.fi
Thu Aug 29 05:23:58 EDT 2019
On Thu, 29 Aug 2019 at 11:52, James Bensley
<jwbensley+juniper-nsp at gmail.com> wrote:
> Hmm, interesting, but has anyone confirmed to you these devices to use
> a CRC32 for the hashing are you trying to reverse engineer this? Is
> there any reason why this couldn't just be a dodgy Juniper proprietary
> hash algo? I'm just playing devils advocate here.
JNPR states CRC31+CRC16, but I'd rather have like proper pseudocode so
I could implement it myself and see how well its diffusion performs.
Because you have to have the transistors there for FCS anyway,
historically the same block has been used for other functions than
checking FCS. Like hash buckets for MAC addresses. And it stands to
reason, for LAG/ECMP balancing.
> This is interesting.
I think the removal of L4 keys improving results mirrors the report I
got from NOK owner. The NOK owner added SystemID (static 32b input),
which fixed balancing problem for them. Implying that the input bits
which cause weak diffusion were move to the left or right, and now
the changing input bits were no longer weak bits.
For CRC's designed function, of course, diffusion isn't important
quality. CRC is very very good for FCS.
--
++ytti
More information about the juniper-nsp
mailing list