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.