Resilient Hashing on LAGs and ECMP groups

Why You Might Want to Use Resilient Hashing and How It Works with Static Hashing

Resilient hashing works in conjunction with the default static hashing algorithm. When members are added to or deleted from a LAG/ECMP group, the static hashing algorithm might remap destination paths. With resilient hashing, the chances of a flow being remapped are minimal if its path is unaffected by the LAG/ECMP group's member change. When a flow is affected by a member change, the Packet Forwarding Engine rebalances the flow by reprogramming the flow set table.

Resilient hashing thus provides the following benefits:

• Minimizes traffic-distribution imbalances among members of a LAG/ECMP group when members are added to or deleted from the group.

• Minimizes the impact on flows bound to unaffected members when a new member is added or an existing member is deleted from the group.

In normal hash-based load balancing, with the static hashing algorithm used alone, flows are assigned to members through the mathematical mod (%) operation. Any increase or decrease in the number of group members results in a complete remapping of flows to member IDs, as shown in the following example:

• Member ID = Hash (key) mod (number of members in group)

• Example:

  • Hash (key) = 10

  • 10 mod 5 = 0 (member with ID 0 is selected for flow)

  • 10 mod 4 = 2 (member with ID 2 is selected for the same flow when the number of members is decreased by 1)

Resilient hashing minimizes the destination path remapping when a member in the LAG/ECMP group is added or deleted.

When the flow is affected by a member change in the group, resilient hashing rebalances the flow by reprogramming the flow set table.

Limitations and Caveats for Resilient Hashing

Notice the following limitation and caveats for the resilient hashing feature:

• Resilient hashing applies only to unicast traffic.

• Resilient hashing supports a maximum of 1024 LAGs, with each group having a maximum of 256 members.

• Resilient hashing does not guarantee that traffic distribution is even across all group members—it depends on the traffic pattern and on the organization of the resilient hashing flow set table in hardware. Resilient hashing minimizes remapping of flows to destination links when members are added to or deleted from the group.

• If resilient hashing is enabled on a LAG or ECMP group and if set forwarding-options enhanced-hash-key with one of the options hash-mode, inet, inet6, or layer2 is used, some flows might change destination links, because the new hash parameters might generate new hash indexes for the flows, and hence the new destination links.

• Resilient hashing is not supported on Virtual Chassis port (VCP) links.

• LAG-based resilient hashing is not supported on QFX5200 and QFX5210 switches. ECMP-based resilient hashing is supported on those switches.

Resilient Hashing on LAGs

A LAG combines Ethernet interfaces (members) to form a logical point-to-point link that increases bandwidth, provides reliability, and allows load balancing. Resilient hashing minimizes destination remapping behavior when a new member is added or deleted from the LAG.

A resilient hashing configuration on LAGs is per-aggregated-Ethernet-interface–based.

Resilient Hashing on ECMP

An ECMP group for a route contains multiple next-hop equal cost addresses for the same destination in the routing table. (Routes of equal cost have the same preference and metric values.)

Junos OS uses the static hashing algorithm to choose one of the next-hop addresses in the ECMP group to install in the forwarding table. Resilient hashing enhances ECMPs by minimizing destination remapping behavior when a new member is added or deleted from the ECMP group.

A resilient hashing configuration on ECMP is global—it applies to all ECMP groups.