[c-nsp] Pseudowire and load-balancing - revisit

[James Bensley]

On Tue, 12 Feb 2019 at 18:19, James Jun <james at towardex.com> wrote:
>
> Hey all,
>
> I have a PW scenario that looks like this:
>
>  Customer --- PE1 ---- P ----[4x10GE LAG]---- PE2 -- Customer
>
> PE1, P and PE2 routers are all ASR9K.
>
> EoMPLS PW is delivered to customer; both PE1 and PE2 configure FAT-PW as follows:
>
> !
> l2vpn
>  load-balancing flow-src-ip
>  !
>  pw-class fat
>   encapsulation mpls
>    control-word
>    load-balancing
>     flow-label both static
>    !
>  !! xconnect p2p uses pw-class fat under neighbor
>

Hi James,

I'm guessing that the ingress PE won't read beyond the Ethernet
headers because the Ethertype is 0x8847 when your customer uses MPLS.
The ingress PE probably only has the same source and destination MACs
to hash on to generate the FAT label. This means that in the scenario
that your customer is using MPLS the required level of entropy isn't
available to the ingress PE to generate a range of FAT labels.

At your P node, if the label stack is smaller than 4 labels
Typhoon/Tomahawk should see the Ethernet headers after the MPLS label
stack and be able to hash on those, but not the payload IP headers
after the payload Ethernet headers. However, this P node will suffer
from the same problem as your ingress PE trying to generate FAT
labels, it's probably always the same source and destination MAC
addresses after the MPLS label stack. I've made some notes here for
reference: https://null.53bits.co.uk/index.php?page=asr9000-load-balancing#p-node


On Wed, 13 Feb 2019 at 14:52, James Jun <james at towardex.com> wrote:
> Thanks! I figured as much.  It seems like ASR9K only creates entropy for
> pure IP traffic as passenger traffic entering the PW.  MPLS run over PW by
> client user seems to break load balancing completely.

That is not strictly true. ASR9K can pull entropy from Ethernet
headers entering the pseudowire; I think the problem in your case is
that it's always the same src/dst.

> In the meantime, we'll just have to replace the LAG with 100GE to make
> this problem go away.

If that is easy for you to do then that will definately fix this
problem (for now, untill you add a 2nd 100G link :) ).

Cheers,
James.