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

Saku Ytti saku at ytti.fi
Tue Feb 12 14:25:18 EST 2019

Hey James,

> However, when customer is running their own MPLS/IP network over the provided PW, load balancing
> completely breaks with the above fat-pw setup.  Imbalance occurs and customer traffic is lopsided
> only on 1 member of the 4x10G LAG between P and PE2.

> Anyone else run into this issue? I haven't tried removing control-word along with FAT-PW, but I don't
> believe that will make a difference in this case.  I think the issue is that A9K PE's are not looking
> deeper into passenger traffic on L2CKT when customer themselves are running MPLS.

With FAT the balancing decision happens on ingress, so you can forget
about rest of the network. So your only question is, how does the
ingressPE parse the incoming frame, how and what entropy it finds

This is what I know
a) JNPR P by default even on MPLS transit will balance IP inside MPLS
pseudowire (so you can do without FAT)
b) CSCO P cannot balance on MPLS transit based on IP inside MPLS
pseudowire (so you need FAT)

However, I don't know how packet is parsed at ingress. Based on your
explanation it seems on ingress side ASR9k only parses ethertype 0x800
for entropy (and maybe 86dd), 0x8847 it does not try to parse for
entropy, not for labels, not for IP after MPLS. I do not think this is
hardware limitation, so this is something you need to talk to your
account team with, ask them to parse 8847 for entropy, be specific, if
you want 8847+IPV4 be parsed for L3/L4 keys, ask for it.

Removing CW or FAT will do nothing, ingress looks at the frame,
decides hash and imposes that as FAT label. Your problem is, it's not
finding entropy in the ingress frame.


More information about the cisco-nsp mailing list