Fundamentos de MPLS para operadores: LSPs, ingeniería de tráfico y resolución de fallos en el entorno SP

Quien opera redes en un entorno próximo a proveedores o Carrier nota pronto: MPLS es menos «un protocolo» que un modelo operativo. Las MPLS-Grundlagen für Betreiber tratan, por tanto, no solo de las etiquetas, sino de un control limpio de las trayectorias (LSPs), de una utilización controlada (Traffic-Engineering) y de una búsqueda de fallos reproducible cuando VRF de clientes, Pseudowires o emplazamientos completos muestran problemas «esporádicos». Este artículo está dirigido a operadores y administradores que no necesitan memorizar cada RFC, pero que desean decidir con solidez en caso de incidencia: ¿es el problema del underlay (IGP), de la señalización de etiquetas (LDP/RSVP), de BGP/VRF o de un borde MTU/QoS?

Importante como principio: en un entorno SP, MPLS casi siempre está estratificado en varios niveles. Underlay se refiere al enrutamiento IP en el core (típicamente OSPF o IS-IS como IGP, es decir, Interior Gateway Protocol). Overlay</em se refiere a servicios como L3VPN (VRF via MP-BGP) o L2VPN (Pseudowire). Entre ellos se sitúan los LSPs (Label Switched Paths) como «railes» de transporte. Si comprueba estas capas por separado, disminuye notablemente el tiempo hasta la Root Cause.

MPLS-Grundlagen für Betreiber: Warum MPLS im Betrieb anders tickt als „IP-Routing“

MPLS (Multiprotocol Label Switching) reenvía paquetes basándose en etiquetas cortas en lugar de en la dirección IP de destino completa. Un router en el core MPLS se convierte en LSR (Label Switch Router). El punto de entrada al core MPLS es el Ingress, la salida el Egress. En el entorno de cliente o edge a menudo se habla de PE (Provider Edge) y P (Core). En los routers PE se crean servicios (VRFs, Pseudowires), mientras que los routers P «solo» transportan.

Operativamente decisivo: MPLS separa el reenvío (Forwarding) con mayor claridad de la decisión de ruteo. El ruteo (Control Plane) calcula las rutas (p. ej., vía IS-IS/OSPF). MPLS construye sobre ello una estructura de reenvío (Data Plane) con información de etiquetas. Si el ruteo está «verde», MPLS aún puede estar «rojo» — por ejemplo, si faltan vecindades LDP, RSVP-TE no está señalizando o el Label-Stack se rompe por la MTU.

LSPs verstehen: Was ein Label Switched Path wirklich ist

Un LSP (Label Switched Path) es el trayecto dirigido que siguen los paquetes MPLS a través de la red. «Dirigido» es importante: la ida de A a B es un LSP propio, y el retorno de B a A también. En la operación se encuentran dos variantes básicas:

• LSPs basadas en IGP (frecuentemente vía LDP): el LSP sigue el camino más corto calculado por el IGP. El operador lo controla de forma indirecta mediante métricas del IGP y la topología.
• LSPs explícitas/TE (clásicamente vía RSVP-TE o, en la actualidad, vía Segment Routing): el trayecto se controla de forma más precisa, p. ej. para rodear cuellos de botella o para cumplir requisitos de ancho de banda/latencia.

El mecanismo central es la pila de etiquetas (Label-Stack): un paquete puede llevar varias etiquetas (arriba „etiqueta de transporte“, debajo, p. ej., una etiqueta VPN para la VRF de destino). En la operación diaria de un SP esto explica muchos síntomas: si la etiqueta de transporte externa es correcta, pero la etiqueta de servicio interna no lo es, normalmente el Core está sano: el problema suele residir en el PE/BGP/VRF o en la definición del servicio.

Operaciones de etiquetas: Push, Swap, Pop – y por qué PHP es relevante

MPLS conoce tres operaciones básicas: Push (añadir etiqueta), Swap (intercambiar etiqueta) y Pop (eliminar etiqueta). Muchas redes utilizan PHP (Penultimate Hop Popping): el penúltimo enrutador elimina la etiqueta de transporte para que el Egress tenga menos trabajo. Eso puede afectar la localización de fallos, porque en el Egress hay menos información MPLS „visible“ y algunas herramientas/telemetrías muestran un aspecto distinto. Para los operadores esto significa: si las trazas en el Egress de repente no muestran etiquetas externas, no es automáticamente un fallo: puede ser PHP.

Resumen del plano de control: LDP, RSVP-TE y Segment Routing

Para que se cree un LSP, los enrutadores deben distribuir etiquetas o señalizar caminos. En la práctica, estos modelos son los que encontrará con mayor frecuencia:

• LDP (Label Distribution Protocol): distribuye etiquetas a lo largo de la topología IGP. Sencillo en operación, poca „policy“, pero con capacidades limitadas de TE clásico.
• RSVP-TE (Resource Reservation Protocol – Traffic Engineering): señaliza LSPs TE explícitos y puede reservar ancho de banda. Operativamente más potente, pero con estado (State) y por tanto más sensible a la escalabilidad y a escenarios de fallo.
• Segment Routing (SR-MPLS): controla caminos mediante IDs de segmento (SIDs), normalmente integrado estrechamente en IS-IS/OSPF. Menos estado por flujo en la red, pero con otra lógica operativa (políticas, SIDs, si procede SR-TE).

Importante desde la perspectiva del operador: tanto si usa LDP, RSVP-TE o SR, el underlay debe ser estable. Si el IGP hace flapping, los LSPs también. Si las adyacencias son inestables, las decisiones TE y el FRR (Fast Reroute) solo tratan los síntomas.

Escollos típicos en LDP

• IGP-/LDP-Alignment: si LDP solo está activado en una parte de las interfaces del Core o IGP y LDP usan selecciones de interfaz distintas, aparecen „LDP Holes“ – reachability IGP sí, camino con etiquetas (Label-Switched Path) no.
• Transporte sobre loopbacks: muchos diseños usan los loopbacks del router como identidad LDP/Router-ID. Si la alcanzabilidad del loopback o la política IGP es defectuosa, las adyacencias pueden caer.
• Graceful RESTart / Session Protection: sin mecanismos de RESTart limpios, los reinicios del plano de control provocan caídas de tráfico, aunque el plano de datos pudiera seguir siendo viable.

Escollos típicos en RSVP-TE

• State und Skalierung: RSVP mantiene por LSP un estado (Soft State). Muchos LSPs o intervalos de refresco cortos cargan la CPU/plano de control.
• Modelo de ancho de banda: „reservado“ no equivale automáticamente a „garantizado“ si la arquitectura de QoS y las colas no están alineadas. A la inversa, un control de admisión demasiado estricto puede impedir LSPs aunque exista capacidad física.
• Cálculo de rutas vs. realidad: TE se basa en información IGP-TE (p. ej. ancho de banda disponible). Si esos valores están desactualizados, erróneos o son inconsistentes, TE encaminará de forma equivocada.

MPLS Traffic Engineering en la práctica: objetivos, requisitos, riesgos

MPLS Traffic Engineering es en operación sobre todo una herramienta para controlar de forma más dirigida picos de carga, cuellos de botella o ventanas de mantenimiento. Objetivos típicos: mitigar puntos calientes en el core, utilizar rutas definidas para servicios sensibles a la latencia o aprovechar la capacidad de forma planificable, sin „simplemente“ torcer las métricas del IGP.

Requisitos para que TE no se convierta en un foco de problemas permanente:

• Topología IGP limpia con métricas estables y atributos TE consistentes (si se utilizan).
• Datos de capacidad fiables (ancho de banda de interfaz, reservas, reglas de overbooking) y un monitoreo que no solo detecte „link up/down“, sino que observe utilización, pérdidas (drops), encolamiento y latencia.
• Ciclo de vida operacional: las políticas de TE requieren control de cambios, documentación, revisiones y una responsabilidad clara. „Redirigir rápidamente una vez“ es la puerta de entrada al desorden en las configuraciones.

Riesgos y errores típicos de operadores:

• TE como sustituto de capacidad: TE puede distribuir cuellos de botella, pero no hacerlos desaparecer. Si todas las rutas están llenas, TE solo traslada el problema.
• Dominios de fallo poco claros: TE puede planificar pasando por riesgos compartidos (SRLG, Shared Risk Link Group – dependencias físicas comunes como tendidos de cable) si estos no están modelados. Entonces la „diversidad“ en teoría atraviesa el mismo tendido.
• Asimetría: El sentido de ida se optimiza y el de vuelta queda por defecto según el IGP. Eso puede falsear latencia, cortafuegos, estabilidad de sesiones y las mediciones.

FRR y reparación local: por qué „rápido“ no es automáticamente „limpio“

FRR (Fast Reroute) debe conmutar localmente muy rápido ante fallos de enlace/nodo, sin esperar a la convergencia completa del IGP. Eso estabiliza la experiencia del cliente, pero puede complicar el troubleshooting: justo tras una caída la ruta puede verse „rara“ porque hay un desvío local activo hasta que finaliza el recálculo global. Consejo para operadores: compruebe durante la ventana de incidencia si está viendo rutas FRR antes de suponer „loops de enrutamiento“ o „métricas incorrectas“.

Servicios sobre MPLS: L3VPN (VRF) como caso operativo más frecuente

Muchos equipos hablan a diario de „MPLS“, pero en realidad se refieren a BGP/MPLS L3VPN. Aquí la VRF (Virtual Routing and Forwarding) es central: una tabla de enrutamiento separada por cliente/servicio. La distribución de rutas suele realizarse mediante MP-BGP (Multiprotocol BGP), a menudo con Route Targets (RT) para controlar import/export. El reenvío real utiliza entonces etiquetas MPLS: por fuera transporte (Core), por dentro etiqueta VPN (la VRF correcta en el Egress-PE).

Consecuencia práctica para la resolución de fallos: si un cliente „no tiene enrutamiento“, el Core puede seguir funcionando perfectamente. Entonces compruebe primero: ¿llegan las rutas VPN en MP-BGP? ¿Están correctos los RT? ¿Está presente la etiqueta VPN en la LFIB (Label Forwarding Information Base)? ¿Y es adecuada la MTU para el stack de etiquetas?

MTU y pila de etiquetas: la causa silenciosa de fallos

Una etiqueta MPLS añade típicamente 4 Byte por etiqueta. Con varias etiquetas (transporte + servicio, y en su caso más) el paquete aumenta de tamaño. Si las interfaces, LAGs o los tramos de túnel están configurados justo al límite, aparecen fragmentación o descartes. Especialmente insidioso: muchos mensajes ICMP (PMTUD – Path MTU Discovery) se filtran en entornos de proveedor o se pierden en rutas asimétricas. Resultado: los paquetes «grandes» se quedan colgados, los pequeños atraviesan. Si quiere abordar problemas de MTU de forma sistemática, conviene una guía propia; como complemento encaja el artículo MTU- und Fragmentierungsprobleme analysieren und über GRE/IPsec vermeiden, porque la lógica de comprobación (PMTUD, MSS, descartes) es muy similar.

Fehlersuche im SP-Umfeld: Schichtenmodell und Prüfreihenfolge

En incidencias, los equipos pierden tiempo si saltan entre todas las capas. Es recomendable mantener un orden fijo, que documente como Runbook. Objetivo: primero aclarar si el underlay es estable, luego el transporte MPLS, después el overlay de servicio (VRF/BGP) y por último temas cercanos al cliente (CPE, Firewall, NAT, aplicación).

1) Underlay prüfen: IGP, Nachbarschaften, Konvergenz

Underlay significa: ¿pueden los routers core alcanzarse a nivel IP y son estables las adyacencias IGP? Síntomas típicos de problemas de underlay son flaps de enlace, alta carga de CPU, picos de latencia y pérdida de paquetes «aleatoria» en muchos servicios simultáneamente.

Comprobaciones prácticas (formuladas vendor-neutral):

• IGP-Neighbor-Status: Up/Down, contador de flaps, Dead-Timer, errores de interfaz.
• Routen zur Loopback der PE/P-Router: ¿Están en el RIB/FIB? ¿Cambia frecuentemente el Next Hop?
• ECMP-Konsistenz: En Equal-Cost Multi-Path, rutas individuales pueden fallar y afectar solo a una parte de los flujos.

2) MPLS-Transport prüfen: LDP/RSVP/SR und LFIB

Ahora compruebe si la capa MPLS es continua: ¿están up las adyacencias LDP o RSVP-TE? ¿Existen etiquetas para las FEC relevantes (Forwarding Equivalence Classes – agrupación de tráfico que se trata de la misma manera)? ¿Concuerdan los intercambios de etiquetas en el LFIB?

Si su plataforma lo soporta, son muy valiosos LSP Ping y MPLS Traceroute: prueban no solo IP, sino la cadena de forwarding MPLS. Importante: estas herramientas pueden verse afectadas por PHP y por filtros ICMP. Un trace «incompleto» no implica automáticamente que MPLS esté roto: también puede ser una Policy/ACL.

3) Dienst-Overlay prüfen: VRF, MP-BGP, RT/RD, Labels

Si los LSP de transporte están establecidos, compruebe la capa de servicio:

• VRF-Existenz und Interface-Bindings: ¿Está realmente la interfaz del cliente en la VRF correcta? ¿Coinciden subinterfaces/tags VLAN?
• MP-BGP Sessions: Up/Down, Route-Refresh, flaps, cambios de política.

4) Kanten prüfen: QoS, Policing, ACLs, MTU, asymmetrisches Routing

Muchos «problemas de MPLS» se encuentran en los límites: policing incorrecto, drops en una cola, cambios en ACLs o una MTU que solo funciona en una dirección. Especialmente en entornos SP es frecuente el enrutamiento asimétrico (ida por el camino A, regreso por el camino B). Esto no es per se incorrecto, pero puede romper componentes con estado (Firewalls, NAT, Session-Pinning). Si necesita un enfoque metódico para ello, merece la pena un artículo de troubleshooting dedicado al tema.

Praktisches Runbook: Von Symptom zu Ursache in 30–60 Minuten

La siguiente lista de verificación está deliberadamente formulada de manera operativa. Adáptela a su plataforma (Cisco/Juniper/Nokia/Arista/FRR) y a su telemetría.

A) Symptomklassifikation (erste 5 Minuten)

• ¿Un Kunde/VRF betroffen o varios a la vez?
• ¿Fallo completo o solo ciertas Applikationen/Ports/Packet-Sizes?
• ¿Seit wann (ventana de cambios, Wartung, Link-Events, eventos DDoS)?
• ¿Nur ein Standort o mehrere? ¿Nur ein PE o mehrere PEs?

B) Transportpfad validieren (10–20 Minuten)

Avance hop-by-hop: Underlay hasta Loopback, luego MPLS-Transport y después el Service.

• IP-Ping/Trace entre los Loopbacks relevantes (PE↔PE).
• Pruebas específicas de MPLS (LSP Ping/Trace), si están disponibles.
• Comprobar LFIB/Label-Table: ¿Hay entradas para la FEC objetivo? ¿Muestra el Outgoing-Label/Next-Hop algo plausible?

C) Servicepfad validieren (10–20 Minuten)

• MP-BGP: ¿Sesión estable? ¿Número de rutas plausible? ¿Últimos cambios de Policy?
• VRF-Routing: ¿Existe Default-Route? ¿Hay prefijos específicos?
• ARP/ND en el borde del cliente (según L2/L3), para descartar que «Layer-2 parece muerto».

D) Datenebene prüfen (10–20 Minuten)

• Contadores de interfaz: descartes (Drops), CRC, errores de entrada/salida, descartes en colas (Queue Drops).
• QoS/Policer: ¿Ha empezado a aplicarse una policer repentinamente? ¿Han cambiado los Classifier?
• MTU/MSS: ¿Indicios de „Fragmentation Needed“? ¿Correlación con «solo paquetes grandes»?

Typische Fehlerbilder und wie Sie sie erkennen

Los siguientes patrones aparecen con regularidad en entornos SP y carrier. Es clave buscar para cada patrón una «prueba», en lugar de reaccionar por corazonadas.

Fehlerbild 1: „Routing ist da, aber Traffic verschwindet“

A menudo se trata de un tema de transporte MPLS (etiqueta faltante) o un problema de MTU/QoS. Si la reachability del IGP es correcta pero falta la entrada LFIB, la palanca está en la control plane entre routers (LDP/RSVP/SR). Si la LFIB es correcta pero los contadores muestran drops: capa de datos, no enrutamiento.

Fehlerbild 2: „Nur eine VRF/Kunde betroffen“

Muy frecuente en overlay: RTs incorrectos, rutas MP-BGP faltantes, VRF-Binding incorrecto en la interfaz o un único PE con una política defectuosa. El Core suele estar sano. Best Practice: primero comprobar la definición del servicio, luego escalar al transporte.

Fehlerbild 3: „Nur bestimmte Anwendungen / nur große Pakete“

MTU/MSS o filtros relacionados con fragmentación. En dominios MPLS esto puede agravarse por overhead adicional de etiquetas. Si ya documenta en un Runbook qué enlaces/Jumbo-Profile se aplican en el Core, ahorrará mucho tiempo.

Fehlerbild 4: „Nach Wartung: alles up, aber Latenz/Umwege“

Esto suele ser un efecto residual de TE/FRR: el tráfico circula por caminos de protección porque un enlace está „up“, pero los atributos TE o la adyacencia IGP no están correctos. Compruebe: ¿está el enlace realmente en el IGP? ¿Son de nuevo consistentes los anuncios TE? ¿Quedan temporizadores „hold-down“ o pesos administrativos que evitan la ruta?

Cómo: Stack mínimo de herramientas para operadores (sin dependencia del proveedor)

No todos los equipos usan los mismos comandos en todas partes. Aun así, se puede definir una caja de herramientas universal: pruebas IP, MPLS-OAM, contadores/telemetría, captura de paquetes en los bordes.

Para puntos de medición o máquinas virtuales de prueba basadas en Linux (p. ej. en redes cercanas a PE) son útiles estas bases:

# Basis: Erreichbarkeit und Pfad (IP-Ebene)
ping -c 5 <ziel-ip>
traceroute -n <ziel-ip>

# MTU-Check (Beispiel IPv4, DF gesetzt):
ping -M do -s 1472 -c 3 <ziel-ip>

# Paketmitschnitt (Edge-nah, um Drops/ICMP zu sehen):
sudo tcpdump -ni <interface> host <ziel-ip> -vv

Por qué funciona: con ping -M do (Do-not-fragment) fuerza que los problemas de MTU sean visibles en lugar de fragmentarse en segundo plano. tcpdump muestra si el ICMP „Fragmentation Needed“ vuelve. Límites: en muchos núcleos de proveedores no verá ICMP o este se filtra; entonces solo queda medir en los bordes o mediante OAM del router.

Cambios, rollback y estrategia de retroceso en MPLS/TE

Los operadores no solo piensan „cómo reparo“, sino también „cómo evito daños colaterales“. Para MPLS/Traffic-Engineering rige: cualquier cambio en métricas IGP, políticas TE o parámetros RSVP/SR puede tener efectos de gran alcance.

Procedimiento recomendado durante la ventana de cambios

• Puntos de medición antes/después: defina 2–3 rutas (PE↔PE, relevantes para el cliente) y mida latencia, pérdida y, si procede, MTU.
• Limitar el alcance: preferible cambiar primero un LSP/política en un par de PEs en lugar de globalmente.
• Preparar el rollback: documente la configuración y la vuelta esperada (p. ej. tiempo de convergencia IGP). El rollback no es solo „volver a aplicar y listo“ — debe verificar que la ruta de datos efectivamente haya regresado.
• Ajustar temporalmente alertas de monitoring: no apagarlas, pero reducir el „ruido“ por mantenimiento para que los errores reales sigan siendo visibles.

Estrategia de retroceso si TE genera problemas inesperados: primero retirar el control específico de TE (policy/LSP), luego volver al comportamiento por defecto del IGP (LDP/Shortest Path), en lugar de cambiar métricas de forma apresurada. Los cambios de métricas suelen tener un mayor blast radius que desactivar una única TE-Policy.

Seguridad y operación: MPLS no es una VPN en el sentido criptográfico

En muchas empresas se etiqueta MPLS como „VPN“. En contexto de proveedor, „VPN“ (p. ej. L3VPN) significa principalmente separación lógica (VRF/Label), no cifrado. Si necesita protección frente a la intercepción en enlaces de transporte, requiere medidas adicionales como MACsec (cifrado en Layer 2) o IPsec (Layer 3), o emplear overlays cifrados a nivel de aplicación (TLS). Para los operadores es importante: esta decisión afecta la MTU, el monitoring (tráfico cifrado), la resolución de fallos y la planificación de rendimiento.

Conclusión: Operar MPLS de forma estable significa separar capas y demostrar rutas

Los fundamentos más importantes de MPLS para operadores son menos «teoría de etiquetas» que un modelo operativo disciplinado: estabilizar primero el underlay, luego validar el transporte MPLS (LSPs y Label-Forwarding) y solo después evaluar servicios como VRF/MP-BGP. El Traffic-Engineering es una herramienta potente cuando se cumplen las condiciones previas (calidad del IGP, modelo de capacidad, monitorización, proceso de cambios); de lo contrario se convierte en un tratamiento especial permanente.

Si va a crear su propio Runbook, documente por capa pruebas concretas (estado de los vecinos, existencia de LFIB, resultados de OAM, contadores/descartes, pruebas de MTU). Esto hace que las incidencias sean reproducibles, reduce los tiempos de escalación y mejora la colaboración entre NOC, Engineering y los equipos cercanos al cliente.

Para este tema también son importantes los LSP de MPLS. El artículo contextualiza estos aspectos de forma comprensible y muestra qué es relevante en la práctica diaria.