[prev in list] [next in list] [prev in thread] [next in thread] 

List:       juniper-nsp
Subject:    Re: [j-nsp] LAG/ECMP hash performance
From:       Saku Ytti <saku () ytti ! fi>
Date:       2019-11-26 17:37:07
Message-ID: CAAeewD_m-PS7Zj4AQ=sJHKBdL5mHZpdNtRzqOQB9H5N=etwUZQ () mail ! gmail ! com
[Download RAW message or body]

On Tue, 26 Nov 2019 at 18:27, James Bensley
<jwbensley+juniper-nsp@gmail.com> wrote:

> Tomahawk NPU is using CRC32 for load-balancing so not sure why the
> MX2020 box you tested was so uneven if also using CRC32. It could be

Pure CRC32 would be terrible, JNPR is doing like CRC32 rotated by
CRC16 which is not horrible.

> This is not 100% apples to apples, because I'm interested in tested
> how pseudowire traffic is load-balanced towards the core and I expect
> your looking at layer 3 ECMP, however it is kind of the same; The
> pseudowire ingress PE has access to the layer 2 / 3 / 4 headers of the
> L2VPN payload traffic, so it has the same keys to feed into a CRC32.

You were also using lot of random keys, which should yield good
result. I was copying what I saw in production, as well as reasonable.
There will be pathological biases in balancing with unlucky set of
keys, because the algorithms aren't perfectly diffusing.
If I use random, I get more or less perfect balancing, but in this
example I was not using random IP addresses. Anyhow adaptive balancing
fixes it and of course also fixes elephant flows, something which
perfectly diffusing algorithm can't fix, so adaptive load balancing is
superior solution anyhow to a better algorithm.

-- 
  ++ytti
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[prev in list] [next in list] [prev in thread] [next in thread]