interesting troubleshooting

Sat Mar 21 16:15:24 UTC 2020

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.