On Thu, 29 Aug 2019 at 22:17, Thomas Bellman <[email protected]> wrote:
> I don't think anyone has said that any product use the ethernet > packet's CRC for LAG/ECMP hashing. Just that they might reuse > the CRC circuitry in the NPU/ASIC for calculating this hash, but > based on different inputs. Exactly and even that isn't true anymore today, since PHY and lookup are usually different physical chips (still exceptions exist). Reuse of CRC circuitry for MAC table hashing and LAG hashing does of course make sense, for some specific constrains, which usually are not today in modern devices and I think people have just grandfathered old solution. Obviously FCS on Ethernet specifically has bias, because it will detect every single and every double bit flip at 1500B, so it particularly avoids collisions on small changes. Where hash function with good diffusion quality would not have such bias and would be terrible FCS, as at FCS we care more about coverage of small changes than consider all changes equal importance. To say it otherwise CRC is great FCS, okish LAG balancer, but ideally LAG should use hash which has theoretically ideal diffusion and such hash can be implemented cheaply. -- ++ytti _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
