In this article we are going to see two features that improve the load-balancing in the MLPS Core.
In the networking when dealing with redundancy of links or paths we are facing the polarization issue. This problem happens when one of the link is congested. Let’s take the example of LAGs, if the hashing algorithm is not efficient all the flows will pass through the same member of the LAG. In the MPLS World we are facing this especially for Layer 2 technologies: VPWS, VPLS.
Note that we can have the same issue for ECMP.
The hashing in the MPLS Core vary from vendors, let’s take the example of Cisco, for IP payloads the load-balancing is done on IP header (L3/L4 fields) and for non-IP payloads it is done on the last label, this is required to preserve the characteristics of the emulated service (VPWS).
The routers distinguish the IP from non-IP payloads by checking the version field of the paylods: 4 for IPv4 and 6 for IPv6. But unfortunately if you have some non-IP payloads that starts with 4 or 6, the load-balancing can be messy, and it already happens with MAC addresses starting with 4 ;). So Cisco highly recommend to use for non-IP payloads in the L2VPN the CW which starts with a 0.
For your information, the router will check the IP header up to 4 labels in the stack, if you have more labels it won’t go further for load-balancing!
Here are some illustrations:
In this example we have only one VPWS, or AToM circuit so we will have for the two flows only one PW MPLS Label. So as stated before P1 will do the hash based on the bottom label which is the same and not efficient because all the flows will go on the bottom or top member of the LAG between the P routers.
In the IETF, they worked on solutions in order to fix this issue:
– Flow-Aware Transport (FAT) Label, RFC 6391
– Entropy Label, RFC 6790
The main goal is to extract the appropriate keys from a given packet on the customer face side on the ingress PE (src/dst IP, MAC), input them to its load-balancing function, and place the result in an additional label in order to load-balance efficiently over an MPLS network.
It applies only for L2VPN service. The concept is to insert a flow label (an MPLS label like) on the ingress PE which encapsulates the layer 2 packets from the attachment circuit (customer) in MPLS packets. This will allow to have more entropy in the label stack. At the P, it is a traditional MPLS packet, load-balanced based on the bottom label which is the Flow label. Once arrived at the Egress PE, it will decapsulate the flow label and sends the layer 2 packets to the customer. The only routers that are aware of the flow label is the PE.
This is signaled by LDP with two flavors:
– Static, locally configured
– Dynamic, T/R bits (in the Flow Label sub-TLV ) capabilities exchanged through LDP
The FAT label is inserted between the CW and the PW MPLS Label.
This is used for L2VPN and L3VPN. Here we have two labels inserted, the top one is a reserved label called ELI for Entropy Label indicator, if the value is 7 then we will have the presence of an Entropy label (EL) just after. This is required to distinguish unambiguously between entropy labels and service labels on the Egress PE.
Depending on the implementation, the LSRs (Label Switching Router or P) will use the Entropy Label for hashing or the entire stack label (except the ELI Label).
It is signaled by LDP, BGP or RSVP.
Pros and cons
Entropy allows to do have the same hashing methodology whatever vendor or payload/service (L2/3VPNs) present on your network. You can improve the performance by not doing fairly deep packet inspection (.ie 4 labels) in order to do the hashing for IP payloads.
Not only the PEs but the P must support also Entropy Label.
Flow Label is easy to implement: only on the PEs but applies only for L2VPN traffic.