About Layer 2 Hardware Hashing

A hardware hashing operation comprises two parts that can be performed at extremely high speed: first, packet field selection and extraction, then a mathematical bitwise computation.

The first step therefore is for the hardware parsing logic to select a number of packet fields ‘to be hashed’ depending on the traffic type.

The Table 4-1 describes the traffic types and related packet fields that NetVisor OS currently supports by default to perform hashing on:

Table  Caption 4-1: Hardware Hashing Field Selection

Note:

• 1 Certain traffic types such as Mac-in-Mac, FCoE and SCTP are currently not supported for field selection; hence they are not load balanced as opposed to the supported traffic types (see also the next section). 
• 2 Traffic types are based on IANA’s Ethertype definitions (e.g., 0x0800 for IPv4 and 0x86DD for IPv6). Packet fields are based on standard protocol definitions (IEEE 802.3 for Ethernet, RFC 791 and RFC 8200 for IPv4 and IPv6 respectively).
• 3 (v)LAG hashing applies to bridged as well as routed traffic without distinction.

Once the proper field values are extracted based on the traffic type (as per the table above), the second step performed by the hardware is the hash function calculation. NetVisor OS uses the standard CRC16 CCITT cyclic redundancy check algorithm for the hash function calculation.

However, before calculating the CRC, 128-bit IPv6 source and destination addresses get ‘folded’ into 32-bit shortened versions with the FoldAndXOR method:

address_bits(127:96)  ^  address_bits(95:64)  ^  address_bits(63:32)  ^  address_bits(31:0)

where  ^  means 32-bit XOR.

This preserves the variability over the entire 128-bit address length when fed in 32-bit chunks to the CRC16 CCITT calculation.

Starting from NetVisor OS release 6.1.0, the default hashing mode is called enhanced hashing. It reflects the hashing field selection described in Table 4-1 above.

As an alternate configuration for special cases, it is possible to select only a subset of the fields in Table 4-1 by explicitly configuring the hash mode to one of the following hashing options:

• source MAC address based
• destination MAC address based
• source and destination MAC address based
• source IP address based
• destination IP address based
• source and destination IP address based

These modes are less granular than the default enhanced mode, therefore they should be used only when the purpose is to have a less granular load balancing behavior (which in most cases means a less optimal traffic distribution).

About Resilient Hashing

Starting from NetVisor OS release 6.1.0, a new resilient hashing mode is introduced. It is called resilient because it helps prevent unnecessary traffic disruption when the number of trunk member ports changes. It takes advantage of regular hashing field selection as shown in Table 4-1 and employs an advanced table-based mechanism to provide better port selection resiliency. This feature is applicable to unicast flows only.

Resilient hashing can be configured when a trunk is created. Its configuration is not modifiable on the fly.

In case of auto trunks, they will come up using the default hashing mode, that is, enhanced. In order to apply resilient mode to these trunks, they need to be converted into regular (manual) trunks. In other words, for each of them you need to disable all the required auto-trunk ports, delete the trunk and re-create it as a regular trunk with resilient hashing configured. However, in such case you lose the convenience of the automatic trunk creation.

About Symmetric Hashing

In addition to regular (asymmetric) hashing, NetVisor OS supports symmetric hashing for IPv4 and IPv6 traffic. When this mode is enabled, IP traffic is normalized before the fields are hashed. That means that the source and destination IP addresses and Layer 4 ports are swapped so that both directions of a bidirectional IP connection are hashed to the same output port in a LAG.

Symmetric hashing’s normalization algorithm has to ignore certain fields that can vary on a per direction basis, such as the VLAN number, protocol value, and the ingress physical interface.

Moreover, as shown in Table 4-1, for the Hardware Hashing Field Selection, certain fields such as the GRE key or the IPSec SPI are intrinsically unidirectional. If any GRE or IPSec traffic is expected in the network, then NetVisor OS provides an additional option for symmetric hashing to ignore these unidirectional GRE and IPSec fields so that the normalization only uses source and destination IP addresses and L4 ports for the hash computation.

Symmetric hashing is useful when traffic in both directions needs to be hashed to the same member port in a LAG. This is required, for instance, for analysis and correlation purposes, when a monitoring device connected to a member port of a trunk needs to receive a copy of all the packets of a connection in both directions (that is, both requests and replies).