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.


These are the traffic types and related packet fields that Netvisor ONE currently supports by default to perform hashing on:


Table  Caption 4-1: Hardware Hashing Field Selection


Application

Traffic Type2

Hashed Fields3

Non-IP packets1

Ethernet (a.k.a. ‘Layer 2’)

Source MAC address, Destination MAC address, Ethertype, VLAN number, source physical port

Plain unicast and multicast IPv4 packets

IP

Source IPv4 address, Destination IPv4 address, VLAN number, Destination Layer 4 port, Source Layer 4 port, IP protocol number, source physical port

Plain unicast and multicast IPv6 packets

IP

Source IPv6 address, Destination IPv6 address, VLAN number, Destination Layer 4 port, Source Layer 4 port, IP protocol number, source physical port

VXLAN packets (UDP encapsulated)

IP

Source IP address, Destination IP address, VLAN number, Destination Layer 4 port, Source Layer 4 port, IP protocol number, source physical port


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 ONE 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.