Las VLANs en un MikroTik se pueden armar de dos formas: etiquetando el tráfico por software con una pila de interfaces VLAN separadas, o usando el filtrado de VLAN del bridge para que el propio switch chip haga el etiquetado en hardware. La segunda opción es la que querés en cualquier equipo con switch chip — saca por completo el tráfico de VLAN de la CPU, algo que importa mucho apenas empezás a mover tráfico real. El problema es que activarlo mal, o en el orden equivocado, es una de las formas más comunes de terminar bloqueado afuera de un MikroTik que administrás por ese mismo bridge.
Creá el bridge con el filtrado de VLAN desactivado
Empezá siempre con vlan-filtering=no. Lo vas a activar recién al final, una vez que cada puerto y VLAN ya estén configurados.
/interface bridge add name=bridge1 vlan-filtering=noAgregá los puertos físicos al bridge
Poné el PVID del puerto de acceso sin tag a la VLAN a la que debería pertenecer. Un puerto con clientes que no entienden tags de VLAN (un switch común o un equipo final) tiene que quedar sin tag y solo recibir un PVID.
/interface bridge port add bridge=bridge1 interface=ether2 pvid=10Definí la VLAN y qué puertos la llevan con tag y cuáles sin
tagged=bridge1 acá significa que la VLAN va con tag del lado de la CPU del propio bridge (hace falta si el router tiene una IP en esa VLAN); untagged=ether2 significa que el tráfico sale de ese puerto físico sin tag, coincidiendo con el PVID del paso anterior.
/interface bridge vlan add bridge=bridge1 vlan-ids=10 tagged=bridge1 untagged=ether2Repetí esto por cada VLAN, agregando cada puerto que la tenga que llevar — con tag para los uplinks a switches/APs, sin tag para los puertos de acceso.
Recién ahora, activá el filtrado de VLAN
/interface bridge set bridge1 vlan-filtering=yesDesde este momento, el bridge empieza a aplicar de verdad la tabla de VLANs que armaste — cualquier puerto o VLAN que te hayas olvidado de agregar queda inalcanzable a través del bridge.
Verificá antes de irte
Chequeá que el offload de hardware realmente se haya activado — hw tiene que mostrar yes en las entradas de VLAN offloadeadas:
/interface bridge vlan printSi estás haciendo este cambio de forma remota, mantené abierta una segunda sesión o acceso por consola hasta confirmar que todavía llegás al router — si un puerto por el que administrás quedó afuera de la tabla de VLANs, es acá donde te vas a enterar.
Por qué hacerlo así
El orden acá no es arbitrario: RouterOS empieza a aplicar la tabla de VLANs en el instante en que vlan-filtering pasa a yes, no antes. Si configurás puertos y VLANs de a uno con el filtrado ya activado, cada estado intermedio es una tabla de VLANs en vivo, aplicada (e incompleta) — incluyendo el momento en que el puerto y el PVID de tu propia conexión de gestión todavía no se agregaron. Armar toda la tabla primero con el filtrado apagado, y recién activarlo como último paso, hace que el switch solo aplique alguna vez una configuración completa, nunca una a medio terminar en la que vos mismo estás sentado adentro.
Cómo te ayuda MoniTik
MoniTik grafica el tráfico y el uso de CPU por interfaz, así que podés confirmar que el offload de hardware realmente está funcionando — la CPU tendría que mantenerse estable a medida que crece el tráfico de VLAN, y un gráfico que no lo hace es una señal de que algo se sigue switcheando por software. Y si un cambio de VLAN te llega a bloquear el acceso de gestión local del router, el túnel remoto de WinBox de MoniTik llega al router por su conexión saliente hacia nosotros, sin depender de lo que acaba de pasar en el bridge — sin necesidad de viajar al sitio para deshacer un error.
Mateo da soporte a ISPs inalámbricos que usan equipos MikroTik, desde la primera instalación hasta el soporte del día a día.