Las ACL (Listas de Control de Acceso) en dispositivos de red pueden implementarse tanto a nivel de hardware como a nivel de software, o, dicho de manera más común, como ACL basadas en hardware y software. Y si las ACL basadas en software son fáciles de entender — son reglas que se almacenan y procesan en la memoria RAM (es decir, en el Plano de Control), con todas las limitaciones que esto conlleva, en esta artículo vamos a analizar cómo se implementan y funcionan las ACL basadas en hardware. Como ejemplo, utilizaremos los conmutadores de la serie ExtremeSwitching de Extreme Networks.
Dado que nos interesa principalmente las ACL basadas en hardware, es fundamental para nosotros entender la implementación interna del Plano de Datos, o los chipsets utilizados (ASIC). Todos los modelos de conmutadores de Extreme Networks están construidos sobre ASIC de Broadcom, por lo que la mayor parte de la información que se presenta a continuación también será aplicable a otros conmutadores disponibles en el mercado y que utilizan ASIC similares.
Como se puede ver en la imagen anterior, el trabajo de las ACL en el chipset está a cargo del “ContentAware Engine”, separado en “ingress” y “egress”. Arquitectónicamente son iguales, pero “egress” es menos escalable y funcional. Físicamente, ambos “ContentAware Engine” consisten en memoria TCAM más lógica asociada, y cada regla ACL, ya sea usuario o del sistema, es una simple máscara de bits (bit-mask) escrita en esta memoria. Por eso, el procesamiento del tráfico por el chipset se lleva a cabo paquete por paquete y sin degradación del rendimiento.
Físicamente, la misma TCAM Ingress/Egress se divide lógicamente en varios segmentos (dependiendo de la cantidad de memoria disponible y de la plataforma), los llamados “ACL slices”. Por ejemplo, lo mismo ocurre con un solo HDD físico en su computadora portátil, cuando crea varios discos lógicos en él – C:>, D:>. Cada ACL slice, a su vez, consiste en celdas de memoria, en forma de “filas” donde se escriben las “rules” (reglas/máscaras de bits).
La división de la TCAM en ACL slices tiene una lógica específica. En cada uno de los ACL slices individuales solo se pueden escribir “rules” compatibles entre sí. Si alguna de las “rules” no es compatible con la anterior, se escribirá en el siguiente ACL slice, independientemente de cuántas filas libres para “rules” queden en el anterior.
¿De dónde proviene entonces esta compatibilidad o incompatibilidad de las reglas ACL? La cuestión es que una "fila" de TCAM, donde se graban las "reglas", tiene una longitud de 232 bits y se divide en varios campos: Fixed, Field1, Field2, Field3. Los 232 bits o 29 bytes de memoria TCAM son más que suficientes para grabar una máscara de bits de una dirección MAC o IP específica, pero son considerablemente menos que el encabezado completo de un paquete Ethernet. En cada ACL-slice, el ASIC realiza una búsqueda independiente utilizando la máscara de bits establecida en F1-F3. En general, esta búsqueda puede realizarse en los primeros 128 bytes del encabezado Ethernet. En realidad, es precisamente porque la búsqueda puede realizarse en 128 bytes, mientras que solo se pueden grabar 29 bytes, que para una búsqueda correcta debe establecerse un desplazamiento (offset) relativo al inicio del paquete. El offset para cada ACL-slice se establece al grabar la primera regla, y si al grabar una regla posterior se detecta la necesidad de otro offset, esa regla se considera incompatible con la primera y se graba en el siguiente ACL-slice.
La tabla a continuación muestra el orden de compatibilidad de las condiciones que se escriben en el ACL. Cada fila individual contiene las máscaras de bits que son compatibles entre sí, y las que son incompatibles con otras filas.
Cada paquete individual procesado por el ASIC inicia una búsqueda paralela en cada ACL-slice. La verificación se realiza hasta el primer coincidencia en el ACL-slice, pero se permite múltiples coincidencias para el mismo paquete en diferentes ACL-slices. Cada "regla" individual tiene una acción correspondiente que debe ejecutarse en caso de una coincidencia de condición (máscara de bits). Si se produce una coincidencia en varios ACL-slices, se toma una decisión en el bloque "Resolución de Conflictos de Acción" en base a la prioridad del ACL-slice sobre qué acción realizar. Si el ACL tiene tanto "acción" (permitir / negar) como "modificador de acción" (contar / QoS / registrar / ...), en caso de múltiples coincidencias, solo se ejecutará la "acción" más prioritaria, mientras que todos los "modificadores de acción" se ejecutarán.
con información más detallada sobre el funcionamiento de ACL disponible públicamente en el sitio . Cualquier pregunta que surja o permanezca se puede dirigir siempre a los empleados de nuestra oficina – .
Fuente: habr.com
