On Thu, 29 Aug 2019 at 11:52, James Bensley <[email protected]> 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 _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
