Reset Search
 

 

Article

Hash collision messages may occur when there is contention for L3 Hash table

« Go Back

Information

 
TitleHash collision messages may occur when there is contention for L3 Hash table
Symptoms
Hash collision messages may occur when there is contention for L3 Hash table

10-01-2017 13:08:02.06 <Warn:Kern.IPv4Adj.Warning> vrId 6647110 adj 0x84234334 Error finding adjacency when deleting hash collision.
10-01-2017 13:02:45.08 <Warn:Kern.IPv4Adj.Warning> vrId -2078063720 adj 0x63743A20 Error finding adjacency when deleting hash collision.
10-01-2017 13:01:24.28 <Warn:Kern.IPv4Adj.Warning> vrId 0 adj 0x00000002 Error finding adjacency when deleting hash collision.
10-01-2017 12:48:17.00 <Warn:Kern.IPv4Mc.Warning> IPv4 multicast entry not added. Hardware L3 Table full. (Logged at most once per hour.)
10-01-2017 12:48:17.00 <Warn:Kern.IPv4Adj.Warning> Error finding adjacency when deleting hash collision.
Environment
  • EXOS 16.1.3.6
Cause
Hash functions are primarily used in the hash tables to quickly locate MAC addresses, the hash function is used to map the search key to an index; the index gives the place in the hash table where the corresponding MAC addresses should be stored.

Typically, the domain of a hash function (the set of possible keys) is larger than its range (the number of different table indices), and so it will map several different keys to the same index. Therefore, each slot of a hash table is associated with (implicitly or explicitly) a set of MAC addresses, rather than a single MAC addresses. For this reason, each slot of a hash table is often called a bucket, and hash values are also called bucket indices.

Hashing algorithm determines what bucket a MAC address should be programmed. Each bucket in hardware can only hold only 8 entries. Hash collisions occur when the Algorithm chooses to add a MAC address in a bucket which has 8 entries already. Hash collisions can be considered table full as the bucket that the MAC is going to be programed to is full. This is an expected behavior.

Depending on some other settings two things can happen.
- The system will replace a random entry, this is the normal operation.
- The new entry will be forwarded in software, this last option is used when all existing entries belong to L2/L3 protocols.

The issue we have here is that the pseudo-random host chosen was not the same on every slot in a chassis or stack, so this could show differences among the slots, which caused confusion to the system, hence the messages.
The impact is that traffic for specific hosts can be also moved to software forwarding if their entry is deleted in one slot and not in another.
Resolution
This behavior will be corrected CR# xos0066950
Additional notes

Feedback

 

Was this article helpful?


   

Feedback

Please tell us how we can make this article more useful.

Characters Remaining: 255