About Layer 3 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 5-1: Hardware Hashing Field Selection

Application	Traffic Type1	Hashed Fields
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 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 (RFC 791 and RFC 8200 for IPv4 and IPv6 respectively).

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.