[c-nsp] Rant: ASR1000 MPLS (not) load-balancing

[Lukas Tribus]

Dear list,


tl;dr: this is a rant about ASR1000 not load-balancing (Eo-)MPLS traffic.


So the common approach to load-balance MPLS packets at the LSR
(ingress MPLS, egress MPLS) is to either look at the payload
(IPv4/IPv6 source/destination address if that is detected) or to
fallback to load-balancing based on the bottom of stack label (for
example in the EoMPLS case). At least the latter should be a common
denominator in all load-balancing MPLS implementations because it's
just so basic and for the EoMPLS case it basically means per-VC
load-balancing.

Or so I thought naively ...


In a LSR configuration (ingress MPLS, egress MPLS) with port-channels,
the ASR1000:

- does load-balance when detecting vpnv4/vpnv6 traffic (first octet 4
or 6 in the mpls payload), based on the L3 source/destination address
in the MPLS payload
- does not load-balance at all when not detecting 4 or 6 traffic
(*not* considering the bottom of stack label to load-balance this
traffic)


So what does that mean for:

- EoMPLS traffic with or without control word?
- EoMPLS traffic with FAT or entropy labels?


It's not getting load-balanced at all [1]. Bucked-ID 0 is assigned
always, so the *ENTIRE* EoMPLS traffic (whatever the number of VC's)
is egressing on a single link (the one assigned to Bucked-ID 0).


But this can't be right I hear you saying ... I mean load-balancing
based on the MPLS payload is much more complex than load-balancing
based on the bottom of stack label, so it must just be an oversight,
right?


The response by the BU is of course the usual "status quo is by design":

> It is by design from ASR1K implementation

and:

> BU has updated the documentation [2]:
>
> “This feature achieves load balancing of MPLS traffic only by using source IP address and destination IP address. The MPLS label is not considered for load balancing.”

The ASR1000 is of course not designed to be a P box. But sometimes you
do have MPLS traffic transiting a box and load-balancing works fine
for much more complicated use-cases (vpnv4/6 address, or EoMPLS in
ECMP configurations). I personally find it ridiculous to drop the
D-bomb in this case, when clearly it is just an oversight. The fact
that it was an oversight some 10 years ago does not make it suddenly
"by design". Neither does lack of specification in the actual design.

Dropping the port-channels for ECMP now, hurray.


That was my rant for the day, I wish you all a happy new year (and may
it be "by design"),
lukas


[1] Except of course erroneous load-balancing of EoMPLS traffic
without control-word, if the first octet of the payload is 4 or 6
[2] https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/lanswitch/configuration/xe-16/lanswitch-xe-16-book/lnsw-flow-portchannel-load.html#GUID-2FB36A3D-6603-48DC-8FAA-CA3F604F462E