On Tue, 26 Nov 2019 at 18:27, James Bensley
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
On Wed, 28 Aug 2019 at 08:21, Saku Ytti wrote:
> SRC: (single 100GE interface, single unit 0)
> 23.A.B.20 .. 23.A.B.46
> TCP/80
> DST: (N*10GE LACP)
> 157.C.D.20 .. 157.C.D.35
> TCP 2074..65470 (RANDOM, this alone, everything else static, should
> have guaranteed fair balancing)
>
> I'm ru
On Thu, 29 Aug 2019 at 23:10, wrote:
> All this time watching the thread I'm thinking if it's just coincidence that
> in some cases no matter how good the hash value is the available buckets
> skew the balancing. (and I guess that's why three are knobs to shift the
> hash around.
Obviously there
On Thu, 29 Aug 2019 at 22:17, Thomas Bellman 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
> James Bensley
> Sent: Thursday, August 29, 2019 9:52 AM
>
> In the worst case scenario (1), with 4 bytes of CRC output to represent an
> entire frame there is a large amount of hash collisions; Min size frame; 6
byte
> SRC, 6 byte DST, 2 byte EType, 46 byte payload == 2^480 possible Ethernet
> f
On 2019-08-29 17:31 +0200, Robert Raszuk wrote:
> 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-parame
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
On Thu, Aug 29, 2019 at 2:52 AM James Bensley
wrote:
> 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
On Thu, 29 Aug 2019 at 11:52, James Bensley
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
On Wed, 28 Aug 2019 at 08:21, Saku Ytti wrote:
> I've had two issues where I cannot explain why there is imbalance. One
> in MX2020 another in PTX. I can't find any elephant flows in netflow,
> but I can find traffic grouped around with modest amount of IP address
> entropy (like 20-32 SADDR + 20-
On Wed, 28 Aug 2019 at 09:54, James Bensley
wrote:
> No. Out of curiosity, have you, which is what lead you to post this?
> If yes, what platform?
I've had two issues where I cannot explain why there is imbalance. One
in MX2020 another in PTX. I can't find any elephant flows in netflow,
but I ca
On Sat, 24 Aug 2019 at 10:06, Saku Ytti wrote:
Hi Saku,
> Has anyone ran into a set of flows where ostensibly you have enough
> entropy to balance fairly, but you end up seeing significant imbalance
> anyhow? Can you share the story? What platform? How did you
> troubleshoot? How did you fix?
N
12 matches
Mail list logo
