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

[adamv0025 at netconsultings.com]

Thanks for sharing,
This sucks, but at least it's limited to load-sharing over bundle members only (as opposed to ECMP load-sharing) right?

I was going to object that this can't possibly be by design cause what if I have 100 labels on the packet, then I realized that ASR1k's QFP gets the whole packets not just the first N bytes, so I guess I can see the thought process like "since we are getting the whole packet we might as well look into IP header and balance based on what we'll find there".
And I'm not sure if at the time of ASR1k design the methods to indicate flow using label/label-stack were around, but I would have thought that the problems related to PW traffic load-sharing were known already, suggesting that making the parser look for v4/v6 in bundle scenario as a hard and fast rule might not be the right way forward? (After all they got it right in the ECMP scenario right?...)

 
adam

> -----Original Message-----
> From: cisco-nsp <cisco-nsp-bounces at puck.nether.net> On Behalf Of Lukas
> Tribus
> Sent: Monday, December 30, 2019 2:24 PM
> To: Cisco-nsp <cisco-nsp at puck.nether.net>
> Subject: [c-nsp] Rant: ASR1000 MPLS (not) load-balancing
> 
> 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
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/