MPLS Hashing: Control Word and Entropy Label

A good presentation on this topic: https://ripe66.ripe.net/presentations/141-RIPE66_Understanding_MPLS_Hashing-Snijders.pdf

• MPLS Lable doesn't have encapsulated protocol information. So after the bottom label, 2 possibilities:
• IPv4/v6 packets if L3VPN, the 1st 4-bit is ipVersion, 4=ipv4, 6=ipv6
• Ethernet frames if L2VPN, the 1st 48-bit is dstMAC
• Along the LSP, if P routers like to do ECMP by hashing, it has to guess like above to do hashing the 5-tuple fields (src/dstAddr, src/dstPort, protoNum)
• So the problem happens if the dstMac starts with 4 or 6

The solution for the above issue is MPLS control word (RFC 4385, Feb 2006), a 4-byte all-zero (same length as a label) control word after the bottom label. 

• Arista EOS 4.21.3F: Configurable L2 EVPN MPLS control word
• mpls evpn; label-stack control-word
• Arista EOS 4.22.1F: Control Word support on LDP Pseudowire
• mpls ldp; pseudowire <name>; control-word

So the MPLS control word is to prevent incorrect hashing. How does the LSR do the load-balancing? The answer is Entropy Label (RFC 6790, Nov 2012)

• Increase the label stack by 2: 1 for ELI (entropy label indicator = 7), 1 for EL (entropy label)
• Aristea EOS 4.26.0F: LDP Entropy Label Support
• 4.25.2F: LSR support
• 4.26.0F: LER support
• mpls ldp; entropy-label
• This feature has a limitation: PHP LSR can't pop ELI + EL labels, so has to rely on LER to pop up [ELI, ELI, VPN] labels. 

Another solution is FAT - Flow Aware Transport on LDP pseudowires (4.24.0F) based on RFC 6391

• mpls ldp; pseudowire; pseudowire <name>; label flow

L2 Control Packet Fwding on J-based system

[Update, Nov 1, 2019] Starting from 4.22.0F, EOS can support multiple L2 protocols packets but NEED to create/apply a TCAM profile. 

The L2 control packets like LACP/LLDP/STP are trapped by a switch and sent to CPU for processing. But for some use cases, this behavior requires to be changed. For example, In the below diagram, the CE1 and CE2 want to form a port-channel across the service provider's MPLS cloud network. 



Another use case is the create an L2 harness switch. As shown below, R1 and R2 can establish a port-channel across a harness switch transparently. 




Starting from Arista EOS 4.21.3F, a feature called - L2 protocol forwarding was introduced. With that, above requirement can be achieved. 

The configurations are quite straightforward, 
1) Step 1 - create l2-protocol forwarding profile and enable lacp forward
2) Step 2 - apply this profile under all the client facing interfaces
3) Step 3 - configure LDP type 5 pw - local patch to stitch 2 local eth ports

1. The port-channel is up. 

R1.gts425.15:54:21#sh port-ch 100
Port Channel Port-Channel100:
  Active Ports: Ethernet21 Ethernet22

2. "show lldp neighbor" shows remote and intermediate devices

R1.gts425.16:15:26#sh lldp nei et21, 22
Port       Neighbor Device ID   Neighbor Port ID           TTL
Et21       lp232                Ethernet12/1               120
Et21       R2.hss457            Ethernet21                 120
Et22       lp232                Ethernet12/2               120
Et22       R2.hss457            Ethernet22                 120

Limitation:

• In 4.21.3F, only LACP/LLDP supported. STP and other L2 protocols will be supported in later releases. 
• From 4.22.0F, more protocols are supported, but need to create a tcam profile.