On 21/Mar/20 09:58, Saku Ytti wrote:
No.
FAT adds additional MPLS label for entropy, ingressPE calculates flow hash, based on traditional flow keys and injects that flow number as MPLS label, so transit LSR can use MPLS labels for balancing, without being able to parse the frame. Similarly VPN provider could do that, and inject that flow hash as SPORT at the time of tunneling, by looking at the inside packet. And any defensive VPN provider should do this, as it would be a competitive advantage. Now for some vendors, like Juniper and Nokia transit LSR can look inside pseudowire L3 packet for flow keys, so you don't even need FAT for this. Some other like ASR9k cannot, and you'll need FAT for it.
But all of this requires that there is entropy to use, if it's truly just single fat flow, then you won't balance it. Then you have to create bias to the hashResult=>egressInt table, which by default is fair, each egressInt has same amount of hashResults, for elephant flows you want the congested egressInt to be mapped to fewer amount of hashResults.
So the three or four times we tried to get FAT going (in a multi-vendor network), it simply didn't work. Have you (or anyone else) had any luck with it, in practice? Mark.