Malas configuraciones en Capa 2: Limitaciones de Hardware Offload en Múltiples Bridges

Mauro Escalante
octubre 30, 2023
5:16 pm
No hay comentarios

Imaginemos un dispositivo de red con un chip de switch incorporado, configurado para gestionar el tráfico entre múltiples puertos. Para aislar ciertos puertos entre sí, se han creado varios bridges.

Se ha habilitado la funcionalidad de hardware offload en estos bridges con el objetivo de mejorar el rendimiento al permitir que el propio chip de switch maneje el tráfico, en lugar de utilizar la CPU del dispositivo.

Al final del artículo encontrarás un pequeño test que te permitirá evaluar los conocimientos adquiridos en esta lectura

Ir al Test

Configuración

				
					/interface bridge
add name=bridge1
add name=bridge2
/interface bridge port
add bridge=bridge1 interface=ether1
add bridge=bridge1 interface=ether2
add bridge=bridge2 interface=ether3
add bridge=bridge2 interface=ether4

Problema

Tras llevar a cabo pruebas de rendimiento, se observan inconsistencias significativas en la velocidad de transmisión de datos entre los diferentes bridges. Mientras que el primer bridge es capaz de manejar el tráfico a la velocidad máxima del cable, los bridges subsiguientes muestran un rendimiento considerablemente menor.

Además, los paquetes que necesitan ser enrutados experimentan una latencia considerablemente alta.

Al inspeccionar el estado del sistema, se descubre que la CPU está operando a su capacidad máxima. Al verificar el estado del hardware offload, se revela que solo el primer bridge tiene activada esta funcionalidad.

Esto significa que todo el tráfico que pasa a través de los bridges subsiguientes se maneja a través de la CPU, generando un cuello de botella y resultando en un rendimiento subóptimo.

				
					[admin@MikroTik] > /interface bridge port print
Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload
 #     INTERFACE                                 BRIDGE                                 HW
 0   H ether1                                    bridge1                                yes
 1   H ether2                                    bridge1                                yes
 2     ether3                                    bridge2                                yes
 3     ether4                                    bridge2                                yes

La causa raíz de este problema es que el dispositivo en cuestión no soporta el aislamiento de puertos en su chip de switch. En dispositivos que no tienen esta capacidad, solo un bridge puede beneficiarse de la funcionalidad de hardware offload.

Esto se traduce en una alta utilización de la CPU para el tráfico que pasa a través de los otros bridges, lo que lleva a una disminución del rendimiento y a problemas de latencia.

Síntomas:

Ausencia de la bandera “H” (indicador de hardware offload) en los puertos de los bridges subsiguientes.
Velocidad de transmisión de datos baja en los bridges que no son el primero.
Uso elevado de la CPU.
Latencia alta para los paquetes que necesitan ser enrutados a través de los bridges sin hardware offload.

El problema radica en las limitaciones del dispositivo para manejar múltiples bridges con hardware offload habilitado, debido a la falta de soporte para el aislamiento de puertos.

Este problema lleva a un rendimiento de red inconsistentes y potencialmente inaceptables en entornos que requieren un alto grado de aislamiento y eficiencia.

Posibles Consecuencias:

1. Rendimiento Inconsistente:

La primera y más obvia consecuencia sería el rendimiento inconsistentemente bajo para diferentes segmentos de tu red, lo cual podría ser especialmente problemático si se espera un nivel constante de rendimiento para aplicaciones o servicios críticos.

2. Sobrecarga de la CPU:

El uso constante y elevado de la CPU no solo afecta el rendimiento del tráfico que pasa a través de los bridges, sino que también podría tener un impacto en otras funciones y servicios que se ejecutan en el mismo dispositivo.

3. Problemas de Latencia:

En aplicaciones o servicios que son sensibles a la latencia, como VoIP o juegos en línea, las consecuencias podrían ser aún más graves, llegando al punto de hacer que esos servicios sean prácticamente inutilizables.

4. Costos Ocultos:

La necesidad de cambiar o actualizar hardware para resolver este problema podría conllevar costos adicionales no anticipados. Además, el tiempo y los recursos gastados en la identificación y solución de problemas representan otros costos ocultos.

Soluciones Sugeridas:

1. Cambio de Hardware:

La forma más directa de resolver el problema es cambiando a un dispositivo que soporte aislamiento de puertos en múltiples bridges con hardware offload.

2. Optimización de la Configuración:

Aunque no es ideal, puedes asignar manualmente la funcionalidad de hardware offload al bridge que maneje el tráfico más crítico o voluminoso, reduciendo así la carga en la CPU.

				
					/interface bridge port set [find where bridge=bridge1] hw=no
/interface bridge port set [find where bridge=bridge2] hw=yes

3. Implementación de VLANs:

El uso de VLANs para segregar el tráfico de red puede ser una alternativa más eficiente al uso de múltiples bridges, especialmente si el hardware actual no soporta múltiples instancias de hardware offload.

4. Actualización de Firmware/Software:

En algunos casos, las actualizaciones de firmware o software podrían habilitar características adicionales que ayuden a mitigar o resolver el problema, aunque esto es menos probable si se trata de una limitación de hardware.

5. Monitorización y Análisis:

Herramientas de monitorización pueden ayudar a identificar cuellos de botella y ofrecer insights sobre cómo reconfigurar la red para optimizar el rendimiento, aunque esto no resolvería el problema subyacente.

En conclusión

La limitación de hardware offload en múltiples bridges es un problema serio que puede tener múltiples consecuencias negativas en el rendimiento y la eficiencia de una red.

Identificar y entender el problema es el primer paso para encontrar la solución más adecuada, que podría variar desde una simple reconfiguración hasta un cambio completo de hardware.