interesting troubleshooting

[mark.tinka at seacom.mu (Mark Tinka)]

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.