L3HW en MikroTik CRS: Hardware Offloading de Routing explicado

Uno de los features más mal entendidos de los switches MikroTik CRS es el L3HW — Layer 3 Hardware Offloading. Cuando está activo, el switch ruta paquetes entre VLANs a velocidad de silicio sin tocar la CPU. Cuando está inactivo (por cualquiera de las causas que lo deshabilitan), el routing vuelve a la CPU del RouterBoard — con un techo de rendimiento radicalmente inferior.

Esta guía explica exactamente qué es L3HW, qué chips lo soportan, qué acciones lo deshabilitan automáticamente, cómo verificar su estado, y cómo configurar el switch para aprovecharlo al máximo.

1. ¿Qué es L3HW y por qué importa?

En un switch MikroTik CRS con RouterOS, tienes dos caminos para rutar paquetes entre VLANs:

• CPU path: el paquete sube al CPU del RouterBoard, RouterOS lo procesa con su stack de red normal (firewall, NAT, routing table), y lo reenvía. Limitado por la velocidad del CPU (generalmente 800 MHz a 1.2 GHz en los CRS).
• Hardware path (L3HW): el chip Marvell consulta su tabla de ruteo interna programada por RouterOS y reenvía el paquete directamente en el silicio. No hay interrupción al CPU. Velocidad: wire-speed del switch (56-136 Gbps según el modelo).

La diferencia en práctica: un CRS326 con L3HW activo puede rutar entre VLANs a ~56 Gbps total. Con L3HW deshabilitado y routing por CPU, el techo baja a decenas o cientos de Mbps dependiendo del tamaño de paquete y la carga de CPU. En ISPs con múltiples VLANs de clientes y tráfico intenso, esto es la diferencia entre que el switch sea un cuello de botella o no.

2. Chips MikroTik que soportan L3HW

3. Qué activa L3HW

L3HW se activa automáticamente cuando se cumplen todas estas condiciones en RouterOS:

1. El bridge tiene vlan-filtering=yes
2. Las interfaces VLAN están creadas sobre el bridge (/interface vlan)
3. Las interfaces VLAN tienen IPs asignadas (/ip address)
4. No hay reglas de firewall stateful en chain=forward para ese tráfico
5. No hay mangle marks en chain=forward
6. No hay Queue Tree aplicado en forward

RouterOS programa automáticamente la tabla de ruteo del chip cuando detecta estas condiciones. No hay comando explícito para "activar L3HW" — RouterOS lo decide según la configuración.

4. Qué deshabilita L3HW (lista completa)

5. Verificar estado de L3HW

# Ver rutas con hw-offload activo
/ip route print detail where active=yes
# Busca: hw-offload=yes en las rutas — indica que ese prefijo se ruta por hardware

# Ver estado del chip de switching
/interface ethernet switch print

# Ver tabla de hosts/rutas programadas en el chip
/interface ethernet switch host print
# Estas son las entradas actualmente en el silicio

# Ver ACL rules del chip (reglas programadas en hardware)
/interface ethernet switch rule print

# Ver estadísticas por puerto (tráfico procesado en HW)
/interface ethernet switch port print stats

# Monitorear si el CPU está procesando tráfico que debería ir por HW
# (CPU% alto con tráfico de routing inter-VLAN indica L3HW inactivo)
/system resource monitor

6. Diagnóstico: L3HW deshabilitado sin razón aparente

# Paso 1: Verificar bridge con vlan-filtering
/interface bridge print detail
# vlan-filtering debe ser "yes"

# Paso 2: Verificar que no hay firewall stateful en forward
/ip firewall filter print where chain=forward
# Si hay reglas con connection-state, esas están forzando CPU path

# Paso 3: Verificar mangle en forward
/ip firewall mangle print where chain=forward
# Marks en forward deshabilitan L3HW para ese tráfico

# Paso 4: Verificar Queue Tree
/queue tree print
# Si parent=global o parent=bridge1, puede afectar L3HW

# Paso 5: Verificar tamaño de tabla de rutas
/ip route print count-only
# Si supera los límites del chip (13,312 para 98DX3236), hay overflow

# Paso 6: Ver log por errores de L3HW
/log print where topics~"switch"

7. Configuración óptima para máximo L3HW

# Bridge con VLAN filtering (obligatorio para L3HW)
/interface bridge add name=bridge1 vlan-filtering=yes \
  protocol-mode=rstp ingress-filtering=yes \
  frame-types=admit-all

# Puertos al bridge
/interface bridge port add bridge=bridge1 interface=ether1 pvid=10
/interface bridge port add bridge=bridge1 interface=ether2 pvid=10
/interface bridge port add bridge=bridge1 interface=ether3 pvid=20
/interface bridge port add bridge=bridge1 interface=sfp-sfpplus1 pvid=1

# VLANs en el bridge
/interface bridge vlan add bridge=bridge1 vlan-ids=10 \
  tagged=sfp-sfpplus1 untagged=ether1,ether2
/interface bridge vlan add bridge=bridge1 vlan-ids=20 \
  tagged=sfp-sfpplus1 untagged=ether3

# Interfaces VLAN para L3
/interface vlan add name=vlan10-clientes interface=bridge1 vlan-id=10
/interface vlan add name=vlan20-servidores interface=bridge1 vlan-id=20

# IPs en las VLANs (esto activa L3HW automáticamente)
/ip address add address=10.10.0.1/24 interface=vlan10-clientes
/ip address add address=10.20.0.1/24 interface=vlan20-servidores

# NUNCA agregar esto en un CRS con L3HW activo:
# /ip firewall filter add chain=forward connection-state=established (deshabilita L3HW)
# /ip firewall mangle add chain=forward ... (deshabilita L3HW)
# /queue tree add parent=global ... con tráfico inter-VLAN (deshabilita L3HW)

# Verificar resultado
/ip route print where active=yes
# hw-offload=yes en las rutas = L3HW activo

8. Topología correcta: CRS + CCR para ISP

La arquitectura que maximiza L3HW en producción separa las responsabilidades:

• CRS354/CRS326: switching L2/L3 entre VLANs, distribución de clientes, LACP, STP — todo en hardware
• CCR2004/CCR2216: terminación PPPoE, firewall stateful, NAT, Queue Tree QoS, BGP/OSPF — todo en CPU dedicado de alto rendimiento

El CRS ve IPs de clientes PPPoE en sus VLANs y ruta entre ellas en hardware. El CCR recibe el tráfico que va hacia Internet (una ruta default apuntando al CCR) y aplica todas las políticas que requieren CPU. El resultado: cada equipo hace lo que hace mejor.

# En el CRS: ruta default hacia el CCR (que está en una VLAN de gestión)
/ip route add dst-address=0.0.0.0/0 gateway=10.99.0.1 \
  comment="Default route via CCR — tráfico internet"

# Las rutas inter-VLAN locales van por L3HW automáticamente
# La ruta default (Internet) va al CCR por CPU (es lo esperado)

# Verificar: rutas locales deben mostrar hw-offload=yes
/ip route print detail where active=yes and dst-address!=0.0.0.0/0

Conclusión

L3HW es lo que hace que un switch CRS MikroTik sea radicalmente diferente de un switch genérico de la misma gama de precio: routing inter-VLAN a velocidad de silicio, sin impacto en la CPU. Pero aprovecharlo requiere entender qué lo deshabilita y mantener el switch en su rol correcto — switching y routing de distribución, sin firewall ni QoS stateful en el CRS mismo.

La combinación correcta para ISP es siempre CRS para distribución + CCR para políticas. Intentar hacer todo en el CRS termina en L3HW deshabilitado y un CPU de 800 MHz procesando el tráfico de cientos de clientes.

En MikroHelp auditamos configuraciones de switching donde L3HW está deshabilitado sin que el operador lo sepa. Si tu CRS tiene CPU alto o rendimiento inter-VLAN bajo de lo esperado, contáctanos para diagnosticar.