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

Q: ¿Cómo sé si el Hardware Offload está funcionando?

Puedes comprobar la columna H en Bridge → Ports desde WinBox o utilizar el comando: /interface bridge port print

Ingrid Espinoza
octubre 20, 2026
7:42 am
No hay comentarios

Las redes basadas en MikroTik destacan por ofrecer un excelente rendimiento incluso en equipos de gama media. Gran parte de ese desempeño proviene del Hardware Offload, una función que permite que el tráfico de Capa 2 sea procesado directamente por el switch chip (ASIC) sin pasar por la CPU.

Sin embargo, una de las configuraciones más comunes que degrada el rendimiento consiste en crear múltiples bridges cuando no son realmente necesarios. Aunque esta práctica puede parecer una forma sencilla de segmentar la red, en muchos modelos provoca que el tráfico deje de ser conmutado por hardware y pase a ser procesado por el procesador principal del equipo.

En este artículo aprenderás cómo funciona el Hardware Offload, por qué se pierde al utilizar varios bridges, cómo verificar su estado y cuáles son las mejores prácticas recomendadas para mantener el máximo rendimiento en RouterOS.

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

Ir al Test

¿Qué es Hardware Offload en MikroTik?

El Hardware Offload es la capacidad del switch integrado para reenviar tramas Ethernet sin intervención de la CPU. En lugar de que cada paquete sea analizado por RouterOS, el ASIC aprende las direcciones MAC y realiza el reenvío directamente entre los puertos físicos.

Este enfoque ofrece ventajas importantes:

Mayor throughput.
Menor utilización de CPU.
Menor latencia.
Mayor escalabilidad.
Mejor desempeño bajo carga.

Cuando el Hardware Offload está activo, el tráfico entre puertos del mismo bridge permanece dentro del switch chip, permitiendo que la CPU quede disponible para tareas de enrutamiento, firewall, VPN, QoS y otros servicios de Capa 3.

¿Cómo funciona el switching por hardware?

En un escenario correctamente diseñado, el proceso es sencillo:

Un dispositivo envía una trama Ethernet.
El switch aprende la dirección MAC de origen.
Consulta la tabla FDB (Forwarding Database).
Reenvía la trama al puerto de destino mediante el ASIC.

La CPU no participa en este proceso, salvo en situaciones específicas como:

Tráfico destinado al propio router.
Protocolos de control.
Interfaces que no admiten Hardware Offload.
Configuraciones incompatibles.

Por esta razón, mantener el tráfico dentro del switch chip es fundamental para obtener el mejor rendimiento posible.

¿Qué ocurre al crear múltiples Bridges?

Uno de los errores más habituales es crear varios bridges para separar grupos de interfaces.

Por ejemplo:

Bridge-LAN
Bridge-Servidores
Bridge-CCTV
Bridge-WiFi

Aunque la organización parece lógica, muchos equipos MikroTik no pueden mantener el Hardware Offload entre varios dominios de bridge.

Como consecuencia, el tráfico comienza a pasar por la CPU.

Procesamiento mediante CPU

Cuando el Hardware Offload se pierde:

aumenta el uso del procesador;
disminuye el rendimiento de switching;
se incrementa la latencia;
el throughput puede reducirse significativamente;
el equipo alcanza antes su límite de procesamiento.

En redes con alto volumen de tráfico, esta diferencia puede ser notable.

Procesamiento mediante Switch Chip

Cuando todas las interfaces pertenecen a un único bridge compatible con Hardware Offload:

el tráfico permanece dentro del ASIC;
la CPU apenas interviene;
se obtiene la máxima velocidad disponible del hardware;
la conmutación es más eficiente.

Esta es la arquitectura que MikroTik recomienda para la mayoría de las implementaciones modernas.

¿Por qué múltiples Bridges deshabilitan Hardware Offload?

El switch chip está diseñado para operar principalmente dentro de un único dominio de conmutación.

Al crear varios bridges, RouterOS debe mover parte del procesamiento desde el ASIC hacia la CPU porque:

el tráfico deja de permanecer en un único dominio de switching;
algunos chips no pueden acelerar varios bridges simultáneamente;
determinadas funciones requieren procesamiento por software.

El resultado depende del modelo de equipo, del switch chip y de la versión de RouterOS, pero en muchos dispositivos la consecuencia es la pérdida parcial o total del Hardware Offload.

Cómo comprobar si Hardware Offload está activo

Una comprobación sencilla puede evitar problemas de rendimiento.

Desde WinBox

Abre Bridge.
Entra en Ports.
Observa la columna H.

Si aparece la letra H, significa que ese puerto está utilizando Hardware Offload.

Si desaparece, conviene revisar la configuración del bridge y las funciones habilitadas.

Mediante CLI

También puedes comprobar el estado desde la terminal:

/interface bridge port print

En la salida aparecerá el indicador correspondiente para los puertos que están utilizando aceleración por hardware.

Además, es recomendable revisar periódicamente el consumo de CPU durante transferencias intensivas para detectar configuraciones que estén obligando al tráfico a ser procesado por software.

Casos donde sí tiene sentido usar varios Bridges

Aunque la recomendación general es utilizar un único bridge, existen escenarios donde varios bridges pueden ser necesarios.

Por ejemplo:

laboratorios de pruebas;
entornos con aislamiento físico específico;
arquitecturas heredadas;
determinados diseños con hardware concreto.

No obstante, antes de adoptar esta estrategia conviene confirmar las capacidades del switch chip del equipo y validar si el Hardware Offload continuará disponible.

Diseño recomendado por MikroTik

La mayoría de las implementaciones empresariales funcionan mejor siguiendo un diseño sencillo.

Utilizar un único Bridge

Crear un único bridge permite que todos los puertos físicos compartan el mismo dominio de switching y facilita que el ASIC procese el tráfico.

Esta aproximación también simplifica la administración y reduce la probabilidad de errores de configuración.

Segmentar mediante VLAN

Cuando se requiere separar departamentos, servicios o clientes, la mejor práctica consiste en utilizar Bridge VLAN Filtering sobre un único bridge.

De esta manera se obtiene:

aislamiento lógico;
administración centralizada;
compatibilidad con Hardware Offload en los modelos que lo soportan;
mejor rendimiento general.

Las VLAN ofrecen una solución mucho más flexible que crear múltiples bridges independientes.

Errores comunes en configuraciones Layer 2

Los siguientes errores aparecen con frecuencia:

crear varios bridges sin necesidad;
asumir que todos los modelos soportan múltiples bridges acelerados;
no comprobar el indicador H después de modificar la configuración;
mezclar funciones avanzadas sin validar su impacto sobre el Hardware Offload;
utilizar configuraciones heredadas que ya no representan las mejores prácticas en RouterOS v7.

Evitar estos errores ayuda a mantener una red estable y preparada para crecer.

Buenas prácticas para mantener el máximo rendimiento

Para aprovechar todo el potencial del hardware de MikroTik:

utiliza un único bridge siempre que sea posible;
implementa la segmentación mediante VLAN;
verifica el estado del Hardware Offload tras cada cambio;
monitoriza el uso de CPU en condiciones reales de carga;
revisa la documentación específica del modelo antes de habilitar funciones avanzadas;
mantén RouterOS actualizado para beneficiarte de mejoras de compatibilidad y rendimiento.

Aplicar estas recomendaciones reduce el riesgo de cuellos de botella y permite que el switch chip haga el trabajo para el que fue diseñado.

Conclusión

El Hardware Offload es uno de los principales responsables del excelente rendimiento de los equipos MikroTik en tareas de switching. Sin embargo, una configuración aparentemente sencilla, como crear múltiples bridges, puede provocar que el tráfico deje de ser procesado por el ASIC y pase a la CPU, reduciendo el rendimiento de la red.

En la mayoría de los despliegues, la estrategia más eficiente consiste en utilizar un único bridge y realizar la segmentación mediante VLAN Filtering, verificando siempre que el indicador de Hardware Offload permanezca activo después de cada cambio.

Diseñar la infraestructura siguiendo estas buenas prácticas no solo mejora el rendimiento, sino que también facilita la administración, reduce la complejidad y prepara la red para futuras ampliaciones.