Diseno de arquitectura de red con MikroTik

Cuando una red creció a punta de parches —un router más aquí, un switch plano allá, VLANs improvisadas y rutas estáticas que nadie documentó—, cada nueva sede o cada peak de tráfico se convierte en una apuesta. Los responsables de TI, NOC e ingenieros de ISP conocen el síntoma: la red funciona hasta que deja de funcionar, y nadie tiene claro por qué. Una arquitectura de red MikroTik bien diseñada ataca ese problema de raíz, definiendo capas, dominios de falla y protocolos de enrutamiento antes de encender el primer equipo, para que crecer no signifique rediseñar todo cada seis meses.

En este artículo revisamos cómo abordar el diseño de arquitectura sobre RouterOS con criterios de ingeniería reales: segmentación con VLANs, jerarquía de capas, elección entre OSPF y BGP, y el transporte carrier-grade cuando la red pasa de una oficina a un operador. No es una receta única —cada red tiene su contexto— pero sí un marco para tomar decisiones defendibles.

Por qué la arquitectura de red MikroTik empieza por las capas

El error más común no es de configuración, es de topología. Una red plana, donde todos los dispositivos comparten el mismo dominio de broadcast, escala mal: el tráfico de control crece, los problemas se propagan sin barreras y no hay dónde aplicar políticas. El modelo jerárquico clásico —acceso, distribución y núcleo— sigue siendo la base porque separa responsabilidades:

• Acceso: donde se conectan usuarios finales, abonados o servidores. Aquí viven los puertos access untagged y las asignaciones de VLAN por PVID.
• Distribución: agrega el acceso, aplica enrutamiento inter-VLAN, filtrado y políticas de calidad de servicio. Es la frontera entre capa 2 y capa 3.
• Núcleo (core): mueve paquetes rápido entre puntos de distribución, con la menor cantidad de lógica posible. Convergencia y redundancia son sus prioridades.

En una red MikroTik pequeña estas capas pueden colapsar en uno o dos equipos; en un ISP se despliegan en hardware separado. Lo importante es que el diseño defina dónde ocurre cada función, no que aparezca por accidente.

Segmentación con VLANs sobre RouterOS

La segmentación es el primer control real que aplicas. En RouterOS moderno, las VLANs se manejan con el bridge con vlan-filtering, que permite offload por hardware en los switch-chips y evita el enfoque antiguo de bridges separados. El patrón de referencia distingue puertos trunk (transportan tráfico etiquetado entre switches y hacia el router) de puertos access (untagged hacia el dispositivo final).

Un punto crítico de diseño: crea el bridge con vlan-filtering=no mientras configuras. Activar el filtrado antes de terminar restringe el tráfico de inmediato y puedes quedarte sin acceso al equipo. Solo al final lo enciendes.

/interface/bridge
add name=bridge1 vlan-filtering=no

/interface/bridge/port
add bridge=bridge1 interface=ether2 frame-types=admit-only-vlan-tagged
add bridge=bridge1 interface=ether6 pvid=200 frame-types=admit-only-untagged-and-priority-tagged
add bridge=bridge1 interface=ether7 pvid=300 frame-types=admit-only-untagged-and-priority-tagged
add bridge=bridge1 interface=ether8 pvid=400 frame-types=admit-only-untagged-and-priority-tagged

/interface/bridge/vlan
add bridge=bridge1 tagged=ether2 vlan-ids=200
add bridge=bridge1 tagged=ether2 vlan-ids=300
add bridge=bridge1 tagged=ether2 vlan-ids=400

/interface/bridge
set bridge1 vlan-filtering=yes

Aquí ether2 es el trunk que sube al router de distribución; ether6 a ether8 son accesos, cada uno con su pvid, que asigna la VLAN al tráfico untagged que entra por ese puerto. El parámetro frame-types refuerza el diseño: un puerto access rechaza tramas etiquetadas y un trunk rechaza las untagged, cerrando la puerta a errores de cableado y a VLAN hopping. Para enrutar entre VLANs, se crean interfaces /interface/vlan sobre el bridge y ahí aplicas firewall y QoS por segmento.

Elegir el protocolo de enrutamiento: OSPF, BGP o ambos

La capa 3 es donde una arquitectura de red MikroTik se define como estable o frágil. La pregunta no es "¿qué protocolo uso?" sino "¿qué problema resuelvo en cada dominio?". La distinción práctica:

Criterio	OSPF	BGP
Rol típico	Enrutamiento interno (IGP): descubrir la topología propia y converger rápido	Enrutamiento entre dominios: peering, tránsito, tabla completa de internet
Escala	Decenas a cientos de routers por área; se segmenta en áreas	Cientos de miles de rutas; control fino por política
Convergencia	Rápida y automática ante cambios de enlace	Más lenta, pero controlable y predecible
Control de políticas	Limitado (costos de enlace)	Alto: filtros, communities, local-preference, prepend
Cuándo usarlo	Núcleo y distribución de una red empresarial o de un ISP	Borde con proveedores, multihoming, intercambio con otros ASN

En la práctica conviven: OSPF como IGP para que la red conozca sus propios enlaces y converja sola, y BGP en el borde para hablar con el mundo. En RouterOS 7, ambos protocolos viven bajo el menú /routing con un motor reescrito respecto a v6, lo que cambia cómo se declaran instancias, filtros y tablas. Si tu red intercambia rutas con transporte o hace multihoming, el diseño de políticas BGP —qué anuncias, qué aceptas y cómo priorizas salidas— es tan importante como el hardware. Un filtro mal escrito puede convertirte en tránsito de rutas que no te corresponden.

Transporte carrier-grade: cuándo entra MPLS

Para un ISP o una red con muchas sedes que necesitan aislamiento real, el enrutamiento IP puro se queda corto. Ahí entra MPLS, que conmuta por etiquetas en lugar de mirar la IP destino en cada salto, y habilita servicios que un diseño plano no puede ofrecer:

• VPLS: extender un mismo dominio de capa 2 entre sitios distantes, como si estuvieran en el mismo switch.
• VRF: tablas de enrutamiento independientes sobre la misma infraestructura, para separar clientes o áreas de negocio sin equipos duplicados.
• Ingeniería de tráfico: dirigir flujos por caminos específicos, no solo por el costo del IGP.

MPLS no es para toda red: agrega complejidad y exige un IGP (típicamente OSPF) sano por debajo, porque las etiquetas siguen la topología que el IGP descubre. Pero cuando el requisito es entregar L2 entre puntos o aislar tráfico por cliente, un diseño con transporte MPLS/VPLS es la respuesta correcta y RouterOS lo soporta en hardware de la línea CCR. La decisión de incorporarlo debe salir del diseño, no de agregarlo después sobre una red que ya duele.

Redundancia y dominios de falla: diseñar para cuando algo se cae

Una arquitectura seria asume que los enlaces y equipos fallan. El objetivo no es evitar toda falla —eso no existe— sino contener el daño y converger rápido. Algunos principios de diseño que aplicamos:

• Dominios de falla acotados: que una caída en acceso no arrastre la distribución ni el núcleo. Las capas existen justamente para esto.
• Redundancia de rutas: enlaces alternativos que el IGP active automáticamente, con costos de enlace que reflejen la topología real.
• Multihoming en el borde: dos proveedores con BGP, para que la caída de uno no deje a la red sin salida.
• Convergencia medible: no basta con tener respaldo; hay que saber cuánto tarda en tomar el relevo y si el tráfico crítico lo tolera.

Este es el punto donde muchos diseños fallan en silencio: la redundancia está "en el papel", pero nunca se probó un failover real bajo carga, con tráfico de producción y en hora peak. Un buen diseño se documenta, se etiqueta y se verifica en laboratorio o en ventana de mantención, no se asume que funcionará el día que de verdad se necesita.

El diseño como proceso, no como diagrama

Diseñar una arquitectura de red MikroTik no termina en un diagrama bonito. Es un ciclo: entender los requisitos reales (tráfico, sedes, servicios, crecimiento esperado), definir capas y segmentación, elegir protocolos por dominio, dimensionar el hardware, documentar el direccionamiento y probar los escenarios de falla. Cada decisión —una VLAN, un área OSPF, un filtro BGP— debe poder justificarse. Cuando eso ocurre, la red deja de ser una caja negra y pasa a ser una infraestructura que puedes operar, auditar y hacer crecer con control.

En MikroTik Chile diseñamos e implementamos exactamente esta capa: arquitectura, segmentación, enrutamiento y transporte sobre RouterOS, con documentación y pruebas de failover que respaldan cada decisión. Si tu red creció sin plan y quieres darle una estructura que aguante el próximo peak y la próxima sede, conversemos sobre tu caso en nuestra consultoría de ingeniería MikroTik.