The LAG and ECMP RTAG7 hashing algorithm on EX4300 and QFX5100 ​is used to make traffic-forwarding decisions and determine the next-hop interface for both Equal Cost Multi Path (ECMP) and link aggregation group (LAG). The switches will perform RTAG7 hashing on all ingress flows and send out a next-hop for traffic entering a LAG bundle or for traffic exiting a switch when ECMP is enabled. This article lists the default fields used by the hashing algorithm for different packet types, for both Equal Cost Multi Path (ECMP) and link aggregation group (LAG).

List the default fields used by the hashing algorithm for different packet types, for both Equal Cost Multi Path (ECMP) and link aggregation group (LAG).

The LAG and ECMP hashing algorithm on EX4300 and QFX5100 determines the member link to be used on an incoming packet depending on a subset of the following values in the packet header:

• Source MAC address
• Destination MAC address
• Ether type
• VLAN ID
• Source IP address
• Destination IP address
• Protocol (for IPv4 packets)
• Next header (for IPv6 packets)
• L4 source port
• L4 destination port
• MPLS label

Other than these packet header fields, two internal values, source-device-id and source-port-id, are also considered. source-device-id refers to the internal device number assigned to a packet when it first enters the switch and source-port-id refers to the internal representation of the network port.

Packets with the following ether-types are considered by the hash function and are currently supported in the software:

1. IPv4
2. IPv6
3. MPLS
4. MAC-in-MAC

NOTE: The hardware also supports FCoE and TRILL ether-types, but there is no software support for these packets. The software support will be available in a future release.

• The hashing algorithm classifies each packet into one of the above types and accordingly selects the fields for hash computation. A packet whose ether-type does not match any of the above is classified as an L2 packet and only the outer L2 header fields (see Table 4) are considered for hash computation.

• The fields are selected based only on the packet type and not based on the forwarding decision (bridged or routed). The selection of fields is also same irrespective of the egress LAG having L2 or L3 configuration.

• The same fields are selected initially for both unicast and multicast packets, but the actual hash index computation is done differently for unicast and multicast.

• The hash algorithms for ECMP and LAG use the same packet header fields, but the internal hash index is calculated differently for ECMP and LAG. This is done to avoid traffic polarization when a LAG bundle is part of an ECMP next-hop.

The following tables show the default fields used by the hashing algorithm for different packet types, for both ECMP and LAG. These values can be changed as per user requirement using CLI commands. See note at the end of this document.

Table 1 -  L3: IPv4/IPv6

Fields	LAG (EX4300)	ECMP(EX4300)	LAG (QFX5100)	ECMP(QFX5100)
Source MAC (0:47)	NO	NO	NO	NO
Destination MAC(0:47)	NO	NO	NO	NO
Ether Type(0:15)	NO	NO	NO	NO
Vlan id(0:11)	NO	NO	NO	NO
Source IP(0:31)	YES	YES	YES	YES
Destination IP(0:31)*	YES	YES	YES	YES
Protocol (for IPv4 packets)(0:7)	YES	YES	YES	YES
Next header (for IPv6 packets)(0:7)	YES	YES	YES	YES
L4 Source Port(0:15)	YES	YES	YES	YES
L4 Destination Port(0:15)	YES	YES	YES	YES
IPv6 Flow label (for IPv6 packets)(0:19)	NO	NO	NO	NO

 

Table 2 - MPLS

Fields	EX4300	QFX5100
Source MAC(0:47)	NO	NO
Destination Mac(0:47)	NO	NO
Ether Type(0:15)	NO	NO
Vlan id(0:11)	NO	NO
Source IP (0:31)*	YES	YES
Destination IP† (0:31)*	YES	YES
Protocol (for IPv4 packets)(0:7)	NO	NO
Next header (for IPv6 packets)(0:7)	NO	NO
L4 Source Port(0:15)	NO	NO
L4 Destination Port(0:15)	NO	NO
IPv6 flow label(0:19)	NO	NO
MPLS label 0(0:19)	YES	YES
MPLS label 1(0:19)	YES	YES
MPLS label 2(0:19)	YES	YES

 

* In the case of IPv6 packets, 32 bits collapsed source IPv6 address and 32 bits collapsed destination IPv6 address is used.

† For Non-terminated MPLS packets, if bottom of stack is seen (i.e., if packet with single MPLS label), then the payload is examined for IPv4/v6. If payload is IPv4/v6, then the IP source address and IP destination addresses are used for hashing, along with MPLS labels. If bottom of stack is not seen, only labels are used for hashing.

Table 3 - Mac-in-Mac

Fields	EX4300	QFX5100
L2 Payload Source MAC (0:47)	NO	YES
L2 Payload Destination MAC (0:47)	NO	YES
L2 payload Ether type(0:15)	NO	YES
L2 Payload outer vlan id(0:11)	NO	NO

 

Table 4 - L2

Fields	EX4300	QFX5100
Source MAC(0:47)	YES	YES
Destination MAC(0:47)	YES	YES
Ether type(0:15)	YES	YES
Vlan id(0:11)	YES	YES

 

NOTES:

1. Starting with Junos OS release 13.2X51-D15 for EX4300 and 13.2X51-D20 for QFX5100, CLI commands are available to configure the packet header fields as per user requirements. Configuring the packet header fields will have an impact on the hashing algorithm, and the traffic distribution across a LAG or ECMP bundle will change as per selected fields.
2. The same fields are also used in mixed-mode VC of EX4300 and QFX5100.
   The hash mode of the hashing algorithm is set to Layer 2 payload, by default. When the hash mode is set to Layer 2 payload, the hashing algorithm does not use fields in the Layer 2 header to make hashing decision

The default L2 behavior can be modified. Refer to layer2 (enhanced-hash-key)

 

You can verify the hashing algorithm configuration

DEFAULT L2 PAYLOAD:

 

L2 HEADER:

 

 

2020-10-20: Added VLAN ID support for hashing decisions. Added screenshots of commands to modify hashing algorithm and verify configuration.