On Thu, Aug 29, 2019 at 2:52 AM James Bensley <jwbensley+juniper-...@gmail.com> wrote: <snip> > Different parameters may or may not change the diffusion density, but > they may increase the range of results, i.e. perfect diffusion over > 2^2 outcomes vs. perfect diffusion over 2^6 outcomes. > > Also, ASR9Ks use a CRC32 on Typhoon cards but not of the whole frame, > "Post IOS-XR 4.2.0, Typhoon NPUs use a CRC based calculation of the > L3/L4 info and compute a 32 bit hash value." So actually, your results > below should have good diffusion in theory if this was an ASR9K > (although I'm sure that's not the case in reality). Is the Juniper > taking (1) the whole frame into the CRC function (2) all the headers > but no payload, or (3) just the specific headers fields (S/D > MAC/IP/Port/Intf)? <snip>
I think 802.3ad and ECMP both require a given connection to hash to the same link to prevent out-of-order delivery. Taking full frames or even full headers into your hashing algorithm would likely break the expectation of in-order delivery (unless your have the same vendor on both sides with something proprietary). Ignoring that requirement, you could ditch hashing altogether and go for round-robin. Standards-compliant hashing implementations can only look at header fields that don't change for a flow, namely src/dest mac, ip, protocol, and port for TCP/UDP (maybe adding in certain MPLS, VLAN, etc. fields or interface ids or other proprietary information available to the chip that satisfies that requirement). -- Eldon _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp