Force10: collisioni hash e come evitarle

Esempio di voce del registro:

May 20 19:12:20: %EX8PB:2 %MACAGT-2-HASH_COLLISION_LOG: Mac:00:02:e8:d6:58:20/Vlan:203 could not be added to L2 CAM on portpipe 2 linecard 2 due to hash collision. Total number of hash collisions: 30211

May 20 19:12:20: %EX8PB:2 %MACAGT-2-HASH_COLLISION_LOG: Mac:00:02:e8:d6:58:20/Vlan:203 could not be added to L2 CAM on portpipe 3 linecard 2 due to hash collision. Total number of hash collisions: 31979

Come funziona:

Nella tabella CAM dello switch, è presente un numero specifico di voci assegnate per "Host Table" in cui sono contenute una quota per il protocollo ARP su reti /32 e una quota specifica per tutte le altre voci.

Ad esempio, se sono presenti 1024 valori Index che puntano ad array di 8 posizioni memoria, ogni valore Index può contenere otto valori. Tutti gli 8 valori in un array possono essere voci ARP, ma, complessivamente, per tutte le posizioni, le voci ARP non possono superare la quota destinata a tale funzione. I diversi modelli di switch presentano vari valori.

Quando si aggiunge una voce ARP per un indirizzo IP nella CAM dello switch, il chip di switching calcola un valore index (0-1023) utilizzando l'indirizzo IP e la voce ARP viene salvata nella posizione a cui fa riferimento l'algoritmo dell'hash.

In alcune istanze, l'algoritmo hash preferisce salvare l'index in una posizione in cui sono utilizzate tutte le posizioni di memoria, e pertanto si verifica una collisione hash.

Quando un indirizzo IP registra una collisione hash, la relativa voce ARP non viene aggiunta alla CAM.  Quindi, la CPU dovrà caricarla nella tabella software. Quando il traffico verso quell'indirizzo IP deve essere inoltrato, lo switch non può farlo a livello di hardware.  Tale traffico viene quindi inoltrato alla CPU, generando un "soft forwarding".  Ciò genera un carico aggiuntivo per la CPU.  Il risultato è la tendenza a una maggiore latenza per il percorso specificato. In alcuni casi, la quantità di soft forwarding potrebbe eccedere e superare la capacità effettiva della CPU nell'elaborare tali dati e portare quindi a una perdita di pacchetti di dati.

Soluzioni alternative per errori hash:

Aggiornamento a software in grado di eseguire un DOPPIO HASHING. Alcune piattaforme successive alla versione 9.3 consentono di eseguire un doppio hashing. È disponibile il supporto del doppio hashing per le tabelle L2 e L3. Questa funzione è attiva per impostazione predefinita su tutte le piattaforme con versione 9.3. Lo switch tenta di eseguire nuovamente l'hashing e e di riordinare le tabelle in modo da contenere le nuove voci ogniqualvolta si verifichi una collisione hash.

Aggiunta di un layer di routing.  Soluzione ideale per errori hash degli switch core.  Il modo migliore per superare questa limitazione è utilizzare una configurazione TOR (Top-of Rack) e attivare il routing tra gli switch TOR e gli switch core.  In questo modo, è possibile ridurre le dimensioni della tabella ARP sul core.  Con l'aggiunta di un layer di routing tra i singoli host e il core libera il core dal dover "imparare" tutte le voci ARP dei singoli host.

Riduzione del timeout ARP. L'impostazione predefinita è di 4 ore. Se si riduce la durata del periodo di conservazione ARP, è possibile introdurre più frequentemente nuove voci ARP. Questa modifica comporta un avanzamento più rapido di tutte le voci e un aumento del traffico ARP per le reti collegate.

Distribuzione degli indirizzi IP nella rete L3 collegata.  È possibile creare una mappatura di TUTTI gli indirizzi IP possibili nelle subnet principali, associandoli ai valori hash corrispondenti, ma si tratta di un'operazione molto complessa. È possibile ridistribuire gli indirizzi IP in modo da evitare gli errori hash. Si tratta della soluzione a breve termine meno efficace.