[j-nsp] LAG/ECMP hash performance

[Robert Raszuk]

Hi Eldon,

You are very correct. I was very highly surprised to read Saku mentioning
use of CRC for hashing but then quick google revealed this link:

https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/hash-parameters-edit-forwarding-options.html


Looks like ECMP and LAG hashing may seriously spread your flows as clearly
CRC includes payload and payload is likely to be different with every
packet.

Good that this is only for QFX though :-)

For MX I recall that the hash is not computed with entire packet. The
specific packet's fields are taken as input (per configuration) and CRC
functions are used to mangle them - which is very different from saying
that packet's CRC is used as input.

But I admit looking as few prod MXes load across LAG members is far from
being well balanced.

Thx,
R.


On Thu, Aug 29, 2019 at 4:56 PM Eldon Koyle <
ekoyle+puck.nether.net at gmail.com> wrote:

> On Thu, Aug 29, 2019 at 2:52 AM James Bensley
> <jwbensley+juniper-nsp at 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 at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>