Es hora de dejar el spanning tree: redes overlay con MPLS y VXLAN para ISPs pequeños
Hay una conversación que se repite en los equipos de red de ISPs pequeños y medianos de Latinoamérica: el NOC detecta un loop de capa 2 en el backbone de distribución —uno de esos que Spanning Tree debería haber prevenido pero no logró contener—, alguien tiene que rastrear manualmente el puerto que causó el problema, y mientras tanto una porción de los suscriptores está sin servicio. El incidente se cierra, se agrega un comentario al wiki, y todos saben que va a pasar de nuevo.
Este patrón no es un problema de configuración. Es un problema de arquitectura. Y tiene solución.
El problema raíz: redes switcheadas a escala ISP
Las redes switcheadas con VLANs y Spanning Tree Protocol (STP/RSTP/MSTP) fueron diseñadas para un contexto específico: redes de área local de campus, donde la capa 2 necesita llegar a los dispositivos de usuario final y los dominios de broadcast son relativamente pequeños.
Cuando un ISP crece y empieza a usar esa misma arquitectura para interconectar nodos de distribución, sites remotos, o para transportar servicios de cliente, los problemas emergen de forma predecible:
Spanning Tree no escala bien con la topología física. En una red con múltiples anillos de fibra y redundancia activa/standby, STP bloquea puertos para romper loops. Eso significa que parte de la capacidad instalada queda inactiva. La convergencia cuando hay un cambio de topología —aunque sea con RSTP— introduce cortes que se miden en segundos o decenas de segundos.
El dominio de broadcast es un blast radius. Una tormenta de broadcast en un segmento afecta a todos los dispositivos en el mismo dominio de VLANs. En una red ISP donde ese dominio cruza múltiples nodos, un solo equipo malcomportado puede degradar el servicio a cientos de suscriptores.
La separación de servicios con VLANs tiene un techo. El espacio de IDs de VLAN (802.1Q) es de 4094 etiquetas. Para un ISP que crece y necesita aislar servicios, clientes enterprise, y segmentos de management, ese techo llega antes de lo que parece.
La operación es manual y frágil. Cada nueva VLAN se configura manualmente en cada switch a lo largo del path. Un error de configuración en cualquier punto rompe la conectividad de esa VLAN en el segmento. Sin automatización, la probabilidad de error crece con el tamaño de la red.
La alternativa: mover los servicios al overlay
La arquitectura correcta para un ISP —sin importar su tamaño— es separar el plano de transporte del plano de servicios:
- El underlay es una red IP simple: cada nodo tiene una dirección IP de loopback, los nodos se interconectan con enlaces punto a punto sobre IP, y un protocolo de routing (OSPF, IS-IS, o eBGP) distribuye la alcanzabilidad de todos los loopbacks.
- El overlay son los servicios que corren sobre ese underlay: circuitos L2 de cliente, VPNs de capa 3, segmentos de servicios propios. Estos servicios usan túneles encima de IP —MPLS, VXLAN, o ambos— en lugar de depender de la capa 2 del underlay.
El resultado es una red donde:
- No hay spanning tree en el backbone
- La redundancia es activa/activa con ECMP (Equal-Cost Multipath)
- Un loop en el underlay tiene el mismo impacto que cualquier falla de routing —convergencia en segundos con IGP fast-reroute, sin broadcast storms
- Los servicios de cliente están completamente aislados entre sí en el overlay
- Agregar un nuevo servicio o cliente no requiere tocar la configuración de los switches de transporte
MPLS: la opción probada para ISPs
MPLS (Multiprotocol Label Switching) es la tecnología de overlay más madura para redes de proveedores. Permite transportar servicios L2 (pseudowires, VPLS) y L3 (L3VPN) sobre un underlay IP con eficiencia y escala demostrada en redes de carriers grandes durante décadas.
Para un ISP pequeño, MPLS habilita dos casos de uso inmediatos:
VPLS o EVPN-VPLS para transporte L2 de cliente: en lugar de extender una VLAN a través de múltiples switches físicos, el tráfico del cliente entra en el edge del ISP y se encapsula en un pseudowire MPLS hasta el otro extremo del servicio. La red de backbone ve solo etiquetas MPLS, no tráfico de cliente.
L3VPN para servicios de conectividad empresarial: cada cliente enterprise tiene su propio plano de routing en el ISP, aislado de otros clientes y de la red de la infraestructura del ISP. El PE (Provider Edge) mantiene una tabla de routing por cliente (VRF), y el tráfico se encamina entre PEs con MPLS.
MPLS en Huawei VRP
Los equipos Huawei de la familia CE (data center), NE (core routing), y AR (acceso enterprise) soportan MPLS con un stack completo. En el VRP de Huawei, habilitar MPLS en el underlay requiere:
mpls lsr-id <loopback-ip>
mpls
mpls ldp
Y en cada interfaz del underlay:
interface GigabitEthernet1/0/0
mpls
mpls ldp
Con LDP corriendo sobre OSPF u OSPFv3, los equipos descubren automáticamente los caminos MPLS entre todos los LSRs de la red. El mismo stack soporta después servicios L2 vía Martini (pseudowires) o EVPN.
MPLS en MikroTik RouterOS
MikroTik soporta MPLS desde RouterOS 2.9 y está disponible en todos los equipos con RouterOS, incluyendo los CCR (Cloud Core Router) ampliamente usados en ISPs de la región. El soporte incluye LDP, VPLS (con señalización LDP), y pseudowires básicos.
Configurar LDP en RouterOS es directo desde Winbox o la terminal:
/mpls ldp
set enabled=yes lsr-id=<loopback-ip> transport-address=<loopback-ip>
/mpls ldp interface
add interface=ether1
add interface=ether2
Con OSPF corriendo en el underlay y LDP habilitado en las interfaces de backbone, los routers MikroTik establecen sesiones LDP automáticamente y pueden transportar VPLS entre sitios.
Limitación importante de MikroTik: el soporte de MPLS en RouterOS es funcional para casos de uso básicos (VPLS, pseudowires LDP), pero el stack no incluye RSVP-TE (traffic engineering) ni EVPN sobre MPLS en versiones actuales. Para ISPs que solo necesitan transporte L2 de cliente o VPNs simples, esto suele ser suficiente.
VXLAN: el overlay moderno para entornos multi-vendor
VXLAN (Virtual Extensible LAN) usa UDP como transporte en lugar de MPLS y fue diseñado originalmente para entornos de data center, pero su adopción en redes de acceso y distribución de ISPs creció fuertemente en los últimos años. Sus ventajas sobre MPLS en redes ISP pequeñas:
Sin plano de control separado para el underlay. VXLAN corre sobre IP pura con UDP 4789. No requiere LDP ni RSVP. El underlay solo necesita conectividad IP entre los VTEPs (VXLAN Tunnel Endpoints).
Escala de segmentos. El VNI (VXLAN Network Identifier) tiene 24 bits — más de 16 millones de identificadores de red, contra los 4094 de VLANs.
Integración con EVPN para plano de control distribuido. EVPN sobre VXLAN (RFC 7432 + RFC 8365) usa BGP para distribuir información de accesibilidad MAC/IP entre VTEPs, eliminando la necesidad de flooding de BUM (Broadcast, Unknown unicast, Multicast) en el overlay. Esto es clave para escalar VXLAN a redes medianas.
VXLAN en Huawei
Los equipos Huawei de las series CE6800, CE8800, y NE series soportan VXLAN con EVPN, (aunque algunas funcionalidades pueden requerir ciertas licencias).
Parte de la configuración base de un VTEP puede ser algo como:
interface Nve1
source <loopback-ip>
vni <id> head-end peer-list protocol bgp
Combinado con BGP EVPN para el plano de control, Huawei implementa un fabric VXLAN con distribución automática de MACs y supresión de ARP.
VXLAN en MikroTik
En v7, MikroTik agregó soporte de VXLAN con flooding controlado y mejoras en el plano de datos.
La limitación actual: EVPN sobre VXLAN (BGP EVPN como plano de control) tiene soporte parcial en RouterOS 7.x. Para implementaciones de producción multi-vendor con EVPN completo, MikroTik funciona mejor como VTEP en topologías donde otro equipo actúa como route reflector EVPN (por ejemplo un equipo Huawei).
Para ISPs que solo tienen MikroTik, VXLAN con flooding estático (lista de peers explícita) es una alternativa funcional para pequeñas redes:
/interface vxlan
add name=vxlan10 vni=10 port=4789
/interface vxlan vteps
add interface=vxlan10 remote-ip=<vtep-remoto>
El camino de migración: cómo hacer el cambio sin cortar el servicio
Migrar de una red switcheada a un overlay no requiere un cambio big-bang. El enfoque recomendado para ISPs pequeños:
Fase 1: Construir el underlay IP (sin tocar los servicios)
Habilitar OSPF o IS-IS en las interfaces de backbone, asignar loopbacks a cada nodo, y verificar que la conectividad IP funciona correctamente entre todos los nodos. En este punto, la red de capa 2 sigue siendo la misma — el underlay IP corre en paralelo.
Fase 2: Levantar el overlay para servicios nuevos
Los primeros servicios que van al overlay son los nuevos: nuevos clientes L2, nuevas VPNs. Se configuran VPLS o VXLAN para estos servicios desde el día uno. Los servicios existentes siguen en VLANs.
Fase 3: Migrar servicios existentes uno por uno
Con el overlay funcionando y validado, los servicios existentes se migran de VLANs a overlay en ventanas de mantenimiento. Cada migración es atómica: se configura el servicio en el overlay, se verifica, y se elimina la VLAN correspondiente.
Fase 4: Eliminar spanning tree del backbone
Una vez que todos los servicios están en overlay, el backbone deja de necesitar spanning tree. Se puede deshabilitar STP en las interfaces de backbone y convertir los switches de distribución en routers de overlay.
Cuándo tiene sentido esta arquitectura
Esta migración vale la pena cuando:
- El ISP tiene más de 2-3 nodos de distribución interconectados
- Hay incidentes recurrentes relacionados con STP o loops de capa 2
- La red necesita escalar el número de servicios de cliente sin aumentar la complejidad operativa proporcional
- Se está evaluando agregar servicios enterprise (MPLS L3VPN) al portfolio
No vale la pena si el ISP tiene un único nodo central sin topología física redundante. En ese caso, una red plana con VLANs bien diseñada es suficiente y más simple de operar.
Cómo ayudamos desde Ayuda.LA
En Ayuda.LA trabajamos con ISPs en Latinoamérica —incluyendo operadores con equipamiento MikroTik y Huawei— en el diseño e implementación de arquitecturas overlay:
- Auditoría de arquitectura actual: identificamos los riesgos operativos de la red existente y las oportunidades de mejora con overlay.
- Diseño de underlay y overlay: definimos el plan de numeración, la topología de routing, el modelo de servicios MPLS o VXLAN, y los mecanismos de redundancia.
- Migración sin corte de servicio: diseñamos la secuencia de migración por fases, servicio por servicio, con validación en cada paso.
- Capacitación del equipo NOC: el equipo aprende a operar una red overlay —cómo diagnosticar, cómo agregar servicios, cómo escalar— antes de que el sistema esté en producción.
Si tu red tiene spanning tree en el backbone y querés evaluar la alternativa, el primer paso es una auditoría de arquitectura.
¿Querés saber si tu red está lista para un overlay? Escribinos a [email protected] — respondemos todos los mensajes.