Force10: colisiones de hash y cómo evitarlas

Ejemplo de entrada de registro:

20 de mayo 19:12:20: %EX8PB:2 %MACAGT-2-HASH_COLLISION_LOG: Mac:00:02:e8:d6:58:20/Vlan:203 no se pudo agregar a CAM L2 en la tarjeta de línea 2 de la ruta de puerto 2 debido a una colisión de hash. Cantidad total de colisiones de hash: 30211

20 de mayo 19:12:20: %EX8PB:2 %MACAGT-2-HASH_COLLISION_LOG: Mac:00:02:e8:d6:58:20/Vlan:203 no se pudo agregar a CAM L2 en la tarjeta de línea portpipe 3 2 debido a una colisión de hash. Cantidad total de colisiones de hash: 31979

Cómo funciona:

En la tabla CAM del switch, hay una cantidad específica de entradas asignadas para la "tabla de host", que contiene una parte para ARP en redes /32 y una cantidad específica para todas las demás entradas.

Por ejemplo, si hay 1024 valores de índice que apuntan a arreglos de 8 ubicaciones de memoria, cada valor de índice puede tener ocho valores. Los 8 valores de un arreglo pueden ser ARP, pero en total, en todas las ubicaciones, las entradas de ARP no pueden exceder la porción dedicada para esta función. Los valores varían entre diferentes switches.

Al agregar una entrada de ARP de una dirección IP a la CAM del switch, el chip de conmutación calcula un valor de índice (0-1023) mediante la dirección IP, y la entrada de ARP se guarda en la ubicación a la que apunta este algoritmo de hash.

En ciertas instancias, el algoritmo de hash desea almacenar el índice en una ubicación en la que se están usando todas las ubicaciones de memoria, con lo que se produce una colisión de hash.

Cuando una dirección IP se enfrenta a una colisión de hash, su entrada de ARP no se agrega a la CAM.  En lugar de eso, la CPU debe cargarla en su tabla de software. Cuando se necesita reenviar el tráfico hacia esa IP, el switch no puede hacerlo mediante hardware.  El tráfico, entonces, se reenvía a la CPU y es reenviado mediante software.  Esto representa una carga adicional para la CPU.  Esto crea latencia en la ruta especificada. En ciertas instancias, la cantidad de reenvío mediante software puede superar la capacidad de la CPU para procesarlo, y provocar la pérdida de paquetes.

Soluciones alternativas para fallas de hash:

Actualizar a un software que permita HASH DOBLE. Algunas plataformas específicas después de la versión 9.3 tienen la capacidad de realizar hash dobles. Las tablas L2 y L3 soportan hash doble. Esta función está habilitada de manera predeterminada en todas esas plataformas con 9.3. El switch intenta volver a obtener hash y a solicitar tablas para incluir nuevas entradas cada vez que ocurre una colisión de hash.

Agregar una capa de enrutamiento.  Para fallas de hash de switch de núcleo.  La mejor manera de superar esta limitación es mediante un diseño de parte superior del rack (TOR) y habilitando enrutamiento entre el TOR y los switches de núcleo.  De esa forma, es posible reducir el tamaño de la tabla de ARP en el núcleo.  Esta capa de enrutamiento adicional entre los hosts individuales y el núcleo alivia al núcleo de tener que aprender las entradas de ARP de todos los hosts individuales.

Reducir el tiempo de espera de ARP. El valor predeterminado es de 4 horas. Mediante la reducción de la cantidad de tiempo que se conservan los ARP, se pueden ingresar nuevas entradas de ARP más frecuentemente. Obviamente, esto también fuerza a todas las entradas a hacer sus ciclos más rápidamente y aumenta el tráfico de ARP de las redes conectadas.

Distribuir las direcciones IP en la red L3 conectada.  Es posible crear un mapa de TODAS las posibles direcciones IP hacia sus valores hash en subredes importantes, pero es extremadamente engorroso. Las IP se pueden redistribuir para evitar fallas de hash. Esta es la corrección menos eficaz a corto plazo disponible.