MPLS MikroTik: VPLS y L3VPN para transporte ISP

Todo ISP o WISP que crece llega al mismo punto: la red plana de VLANs y rutas estáticas deja de escalar, los clientes empresariales piden entregas Layer 2 punto a punto entre sedes, y el core empieza a mezclar tablas de ruteo que deberían estar aisladas. Ahí es donde entra MPLS MikroTik como capa de transporte. Si operas un backbone sobre RouterOS y todavía llevas todo con enrutamiento IP puro o túneles EoIP apilados, este artículo es para ti: vamos a ver cómo encajan MPLS y VPLS en MikroTik, qué necesitas configurar y dónde están los detalles que suelen morder en producción.

Qué resuelve MPLS MikroTik en un backbone de ISP

MPLS (Multiprotocol Label Switching) cambia la lógica del reenvío. En lugar de que cada router mire la IP de destino y consulte su tabla de ruteo salto a salto, el paquete recibe una etiqueta (label) al entrar al backbone, y los routers intermedios lo conmutan solo mirando esa etiqueta. El destino IP se resuelve una vez, en el borde; el núcleo solo hace label switching. Eso trae tres ventajas concretas para un operador:

• Desacople del core respecto a las rutas del cliente. Los routers P (provider, de tránsito puro) no necesitan cargar la tabla completa de internet ni las rutas de cada cliente. Solo conmutan etiquetas.
• Transporte de servicios sobre una misma infraestructura. Sobre el mismo LSP (Label Switched Path) puedes montar pseudowires L2 (VPLS), VPNs L3 y tráfico de internet, sin túneles artesanales por cada servicio.
• Ingeniería de tráfico y convergencia predecible. Al separar el plano de transporte del plano de servicios, ganas control sobre cómo viaja cada clase de tráfico por el backbone.

En la terminología que verás en la documentación de RouterOS, los routers de borde se llaman PE (Provider Edge) y los de tránsito P (Provider). Un despliegue típico es PE-P-PE: el cliente entra por un PE, el tráfico cruza uno o más P conmutando etiquetas, y sale por el PE remoto.

LDP: el motor que distribuye las etiquetas

Para que MPLS funcione, los routers necesitan ponerse de acuerdo sobre qué etiqueta usar para llegar a cada destino. Ese trabajo lo hace LDP (Label Distribution Protocol). LDP no calcula rutas: se apoya en tu IGP (típicamente OSPF) para saber la topología, y sobre esa base distribuye las etiquetas entre vecinos. Por eso el orden de construcción de un backbone MPLS MikroTik es siempre el mismo:

1. Un loopback por router, que será el identificador estable (LSR-ID) y la dirección de transporte de LDP.
2. Un IGP (OSPF) que anuncie esos loopbacks y dé conectividad interna al backbone.
3. LDP encima, activado en las interfaces del core, para distribuir las etiquetas.

Recién con esas tres capas estables tiene sentido montar servicios (VPLS o VPN L3) por encima. Un error clásico es intentar levantar VPLS antes de verificar que LDP tiene vecindades establecidas y que los loopbacks se alcanzan por el IGP.

Base de configuración en RouterOS v7

Este es el esqueleto de un PE sobre RouterOS v7. La sintaxis exacta de algunas propiedades cambió entre v6 y v7, así que valida siempre contra la versión que corres en producción:

# 1. Loopback: identidad estable del router en el backbone
/ip address add address=10.255.0.1 interface=lo

# 2. IGP OSPF: anuncia loopbacks y da conectividad interna
/routing ospf instance add name=core router-id=10.255.0.1
/routing ospf area add name=backbone area-id=0.0.0.0 instance=core
/routing ospf interface-template add area=backbone networks=10.255.0.0/24

# 3. LDP: distribuye etiquetas usando el loopback como transporte
/mpls ldp add afi=ipv4 lsr-id=10.255.0.1 transport-addresses=10.255.0.1
/mpls ldp interface add interface=ether1

# Verificacion: vecindades LDP y etiquetas aprendidas
/mpls ldp neighbor print
/mpls forwarding-table print

Con LDP conmutando etiquetas entre loopbacks, ya tienes un plano de transporte MPLS operativo. Lo que montes encima —VPLS, VPN L3, o simplemente aislar la tabla de internet del core— es una decisión de diseño de servicios, no de transporte.

VPLS: entregar Ethernet punto a punto sobre el backbone

Acá es donde MPLS se vuelve un producto vendible. VPLS (Virtual Private LAN Service) transporta tramas Ethernet de un cliente entre dos o más puntos del backbone como si estuvieran en el mismo switch, aunque los separen varios saltos de core. Para el cliente, sus dos sedes ven el mismo dominio Layer 2; para ti, es un pseudowire que viaja etiquetado sobre los LSP que ya construiste con LDP.

En RouterOS, una VPLS se configura como una interfaz que apunta a un peer remoto (por su loopback) y se identifica con un VPLS-ID que debe coincidir en ambos extremos:

# PE-A: pseudowire hacia el PE-B (loopback 10.255.0.2)
/interface vpls add name=vpls-cliente1 remote-peer=10.255.0.2 vpls-id=100:1 disabled=no

# En el PE-B se crea el espejo apuntando a 10.255.0.1 con el mismo vpls-id

Un detalle importante de RouterOS: la interfaz VPLS se comporta como una interfaz Ethernet más. Eso significa que la entregas al cliente agregándola a un bridge junto con la interfaz física o la VLAN de su servicio. De hecho, en la propia documentación de MikroTik las interfaces VPLS aparecen entre las que se agregan dinámicamente a un bridge, igual que PPP o EoIP. Así, el tráfico que entra por el puerto del cliente en el PE-A sale por el puerto del cliente en el PE-B, transparente a Layer 2.

Dos advertencias de terreno con VPLS:

• MTU. Cada trama del cliente carga etiquetas MPLS adicionales sobre el backbone. Debes dimensionar el L2MTU del core para absorber ese overhead sin fragmentar; una VPLS que "funciona con ping pero se cae con tráfico real" casi siempre es un problema de MTU mal calculado.
• Dominio de broadcast. Estás extendiendo un dominio Layer 2 entre sedes. El broadcast, el ARP y cualquier tormenta del cliente cruzan el pseudowire. Diséñalo con control de storm y, cuando el caso lo permita, evalúa si el cliente realmente necesita L2 o le sirve una entrega L3.

MPLS, BGP y VRF: cuando el servicio es Layer 3

No todo cliente quiere Ethernet extendido. Muchos necesitan una VPN L3: cada uno con su propio espacio de direcciones, aislado del resto y del core, pero enrutado sobre el mismo backbone. Ahí MPLS se combina con VRF (Virtual Routing and Forwarding) y con BGP para transportar rutas por cliente sin mezclarlas con la tabla global.

La VRF crea tablas de ruteo separadas dentro del mismo router; en RouterOS la tabla por defecto es main, y cada cliente vive en su propia VRF. BGP (con las familias de direcciones VPN) se encarga de anunciar las rutas de cada VRF entre los PE, mientras MPLS provee el transporte etiquetado entre ellos. Es la base del clásico L3VPN de operador: el core sigue sin conocer las rutas del cliente, y cada cliente queda estrictamente aislado. Diseñar bien esta capa —qué rutas se anuncian, cómo se filtran, cómo converge ante una caída— es donde un backbone MPLS deja de ser un experimento de laboratorio y pasa a sostener SLAs.

Detalles de RouterOS que muerden en producción

Antes de llevar MPLS MikroTik a un backbone real, hay características de la plataforma que conviene tener claras:

Tema	Qué debes saber
Offload por hardware	El offload de funciones MPLS al switch-chip existió en RouterOS v6 sobre equipos puntuales (CRS317, CRS309), pero fue removido en RouterOS v7. Dimensiona el forwarding MPLS contra la CPU del equipo, no asumas aceleración por hardware.
Ethertypes MPLS	El tráfico etiquetado viaja como mpls-unicast (0x8847) y mpls-multicast (0x8848). Útil cuando filtras o clasificas a nivel de bridge/switch y necesitas identificar tramas MPLS.
TTL y null explícito	En ciertos escenarios (por ejemplo el penúltimo salto) entran en juego el explicit null y la propagación de TTL. Son decisiones de diseño que afectan cómo se ve tu red en un traceroute y cómo se comporta el borde.
MPLS sobre PPP	Si transportas MPLS sobre enlaces PPP/PPPoE, el perfil PPP tiene la propiedad use-mpls (yes/no/require) para habilitar explícitamente el soporte de etiquetas sobre ese enlace.

Ninguno de estos puntos es un obstáculo; son las decisiones que separan un backbone que "levanta" de uno que aguanta hora peak, convergencia ante caídas y crecimiento de clientes sin rediseñar todo. La combinación de un IGP sano, LDP estable y una capa de servicios (VPLS o L3VPN) bien pensada es lo que hace que MPLS sea, hoy, la forma correcta de transportar en un ISP sobre RouterOS.

Dónde ponemos foco en el diseño

Levantar LDP y una VPLS de prueba entre dos routers es relativamente directo. Lo difícil —y lo que realmente importa para un operador— es el diseño: jerarquía PE/P, plan de loopbacks y direccionamiento, cálculo de MTU extremo a extremo, política de convergencia del IGP, y cómo integras MPLS y VPLS con tu enrutamiento BGP y tus servicios existentes sin cortar producción durante la migración. Ese trabajo de arquitectura es exactamente el tipo de proyecto que abordamos en nuestra consultoría de ingeniería de redes.

En MikroTik Chile diseñamos, implementamos y operamos transporte carrier-grade sobre RouterOS —MPLS, VPLS, VRF y BGP— para ISPs y redes de misión crítica. Si estás evaluando llevar tu backbone a MPLS o tienes un despliegue que no termina de estabilizar, conversemos sobre tu caso.