Load Sharing in MPLS Core

Here’s a question that bothered me for years till I finally gave up and labbed it: does ECMP load sharing work in an MPLS core? More specifically, will an LSP split into multiple LSPs?

The Scenario

Imagine a network with alternate paths across the network core. We know that IP traffic takes all paths across the core (usually as long as they are equal-cost, and based on the load sharing algorithm).

Does MPLS work the same way? For example, would labeled traffic from A to Z go over B-C-E and B-D-E links? Would the A-Z LSP split into two LSPs at B?

I was somewhat pleasantly surprised to figure out ECMP works with MPLS. As expected, there are two entries in the IP routing table on router B for the loopback interface of router Z:

B#show ip route                    
Routing entry for
Known via "isis", distance 115, metric 40, type level-2
Redistributing via isis
Last update from on Serial1/1, 00:02:39 ago
Routing Descriptor Blocks:, from, 00:02:39 ago, via Serial1/2
Route metric is 40, traffic share count is 1
*, from, 00:02:39 ago, via Serial1/1
Route metric is 40, traffic share count is 1

Interestingly, there are also two entries in the corresponding LFIB entry. Inbound traffic with label 1015 is split across two outbound LSPs with labels 2013 and 3015.

B#show mpls forwarding-table detail
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
1015 2013 0 Se1/1 point2point
MAC/Encaps=4/8, MRU=1500, Label Stack{2013}
FF030281 007DD000
No output feature configured
Per-destination load-sharing, slots: 0
3015 0 Se1/2 point2point
MAC/Encaps=4/8, MRU=1500, Label Stack{3015}
FF030281 00BC7000
No output feature configured
Per-destination load-sharing, slots: 1

Please note that ECMP in MPLS core works only with LDP-established paths (which use IP routing table for topology discovery) – MPLS TE tunnels are unidirectional paths established and controlled by the tunnel head-end router. If you want to perform ECMP load balancing across the MPLS TE tunnels, you have to establish multiple tunnels from the head-end router (and use affinity bits or loose source routing to ensure they go across different paths in the MPLS core).


  1. L2VPNs require the FAT-PW "flow label" feature in order to load balance individual traffic flows across ECMP paths in the core.
    1. Also, there is a Entropy Label RFC 6790 to load-balance fat L2VPN across LAG links.
  2. Ivan, I am wondering how widely MPLS is used in today's SP networks. It used to be the craze in early to mid 2000s. But of late there is not much excitement around MPLS. MPLS based L3 VPN was probably the killer feature. Is it still widely deployed ? How about other features like TE/L2VPN/VPLS ?
  3. This would have to be per-packet load-balancing, since router B would not have any awareness of IP flows coming from Router A, no?

    Also, what does the "Per-destination load-sharing" mean in the context of the "show mpls forwarding-table detail"? Would this apply only to IP traffic arriving at the router without an MPLS header (and without a VPN label)? And since the destination is a /32 anyway, would the load sharing choice displayed essentially mean no load-balacing?
    1. You'll find most of the answers in these posts:

Add comment