Considere el siguiente escenario: Se ha configurado un bridge con la opción de hardware offloading habilitada para maximizar el rendimiento de la red en un dispositivo con RouterOS. Debido a esta configuración, el dispositivo funciona como un switch en lugar de un simple puente a nivel de software.
Esto mejora el rendimiento al permitir que el chip del switch maneje la reenvío de paquetes entre puertos, en lugar de hacer que la CPU del dispositivo lo haga.
Al final del artículo encontrarás un pequeño test que te permitirá evaluar los conocimientos adquiridos en esta lectura
Configuración
/interface bridge
add name=bridge1
/interface bridge port
add bridge=bridge1 hw=yes interface=ether1 learn=yes
add bridge=bridge1 hw=yes interface=ether2 learn=yes
Problema
Cuando se activan herramientas como Sniffer o Torch para capturar paquetes en la red, se observa una anomalía: sólo algunos paquetes son visibles, generalmente aquellos que son de broadcast/multicast. Esto se debe a cómo el chip del switch maneja el tráfico en una configuración con hardware offloading.
MAC Learning y Host Table
El chip del switch mantiene una tabla de direcciones MAC y puertos asociados conocida como “Host table”. Cada vez que un paquete necesita ser reenviado, el chip del switch consulta esta tabla para determinar qué puerto debe ser usado para reenviar el paquete. Si no encuentra la dirección MAC destino en la tabla, el paquete se inunda hacia todos los puertos, incluido el puerto de la CPU.
Por lo tanto, si la dirección MAC de destino ya se ha aprendido y está en la tabla, el chip del switch puede reenviar el paquete directamente sin pasar por la CPU. Esto significa que dicho paquete no será visible para herramientas como Sniffer o Torch, que capturan paquetes a nivel de CPU.
Síntomas
- Paquetes no visibles en Sniffer o Torch.
- Las reglas de filtrado pueden no funcionar como se esperaba.
Solución
Para solucionar este problema, es posible utilizar reglas de ACL (Access Control List) para copiar o redirigir ciertos paquetes hacia la CPU. Por ejemplo, puedes configurar una regla que envíe una copia de los paquetes destinados a una dirección MAC específica a la CPU para su análisis.
/interface ethernet switch rule
add copy-to-cpu=yes dst-mac-address=4C:5E:0C:4D:12:4B/FF:FF:FF:FF:FF:FF
ports=ether1 switch=switch1
Se debe tener en cuenta que enviar paquetes a la CPU para su procesamiento aumentará la carga de la CPU, lo que podría afectar al rendimiento general del dispositivo.
El hardware offloading es una técnica poderosa para mejorar el rendimiento de la red, pero viene con ciertas limitaciones en términos de visibilidad y control a nivel de CPU. Para casos de uso que requieran análisis de paquetes o filtrado, es necesario realizar configuraciones adicionales como las reglas de ACL para asegurarse de que los paquetes necesarios sean procesados por la CPU.
Consideraciones Adicionales
1. Priorización de Tráfico:
En redes más complejas, podrías querer implementar QoS (Quality of Service) para priorizar ciertos tipos de tráfico. Esto generalmente requiere que los paquetes pasen por la CPU, lo que podría entrar en conflicto con una configuración de hardware offloading.
2. Seguridad:
El hardware offloading puede limitar la capacidad de implementar medidas de seguridad más estrictas, como el análisis profundo de paquetes (DPI, Deep Packet Inspection), ya que los paquetes podrían no pasar por la CPU.
3. Capacidad de la CPU:
Es fundamental tener en cuenta la capacidad de procesamiento de la CPU al redirigir tráfico a ella. Demasiados paquetes enviados para procesamiento en la CPU pueden saturarla, llevando a una disminución del rendimiento general del sistema.
4. Compatibilidad:
No todos los dispositivos y chips de switch soportan hardware offloading o tienen las mismas capacidades. Asegúrate de que tu hardware sea compatible con las características que deseas utilizar.
5. Actualizaciones de Firmware/Software:
Asegúrate de que estés utilizando una versión de RouterOS que sea compatible con todas las características que deseas implementar. Los problemas y limitaciones pueden variar entre diferentes versiones.
Soluciones Avanzadas
Para escenarios más complejos, es posible utilizar API o scripts para automatizar la adición y eliminación de reglas de ACL en función de ciertos eventos o condiciones. Esto podría ser especialmente útil en entornos dinámicos donde las direcciones MAC de destino pueden cambiar con frecuencia.
Resumen
El hardware offloading es una técnica eficaz para mejorar el rendimiento de una red, pero tiene sus desafíos cuando se trata de diagnóstico y control detallado del tráfico.
Las herramientas como Sniffer o Torch son menos efectivas en este contexto porque muchos paquetes se reenvían a nivel de chip de switch y nunca llegan a la CPU.
Sin embargo, con una planificación cuidadosa y el uso de características como ACL, es posible equilibrar el rendimiento con las necesidades de diagnóstico y seguridad.
Breve cuestionario de conocimientos
¿Qué te pareció este artículo?
¿Te atreves a evaluar tus conocimientos aprendidos?
Libro recomendado para éste artículo
Libro Switching y Brindging RouterOS v7
Material de estudio para el Curso de Certificación MTCSWE actualizado a RouterOS v7
Artículos Relacionados
- Malas configuraciones en Capa 2: Limitaciones de Hardware Offload en Múltiples Bridges
- Malas configuraciones en Capa 2: Interfaces LAG y balanceo de carga
- Entendiendo el Concepto de MTU en Capa 2 y Capa 3: Impactos y Consideraciones
- Bonding XOR (balance-xor) en MikroTik
- Bonding Broadcast en MikroTik