nanog mailing list archives

Re: interesting troubleshooting


From: Mark Tinka <mark.tinka () seacom mu>
Date: Sun, 22 Mar 2020 16:25:02 +0200



On 22/Mar/20 11:52, Saku Ytti wrote:

So you're not even talking about multivendor, as both ends are JNPR?
Or are you confusing entropy label with FAT?

Some cases were MX480 to ASR920, but most were MX480 to MX480, either
transiting CRS.



Transit doesn't know anything about FAT, FAT is PW specific and is
only signalled between end-points. Entropy label applies to all
services and is signalled to adjacent device. Transit just sees 1
label longer label stack, with hope (not promise) that transit uses
the additional label for hashing.

So the latter. We used both FAT + entropy to provide even load balancing
of l2vpn payloads in the edge and core, with little success.



You really should be doing CW+FAT.

Yeah - just going back to basics with ECMP worked well, and I'd prefer
to use solutions that are less exotic as possible.


 And looking your other email, dear
god, don't do per-packet outside some unique application where you
control the TCP stack :). Modern Windows, Linux, MacOS TCP stack
considers out-of-order as packet loss, this is not inherent to TCP, if
you can change TCP congestion control, you can make reordering
entirely irrelevant to TCP. But in most cases of course we do not
control TCP algo, so per-packet will not work one bit.

Like I said, that was 2014. We tested it for a couple of months, mucked
around as much as we could, and decided it wasn't worth the bother.



Like OP, you should enable adaptive.

That's what I said we are doing since 2014, unless I wasn't clear.

Mark.


Current thread: