Fondamentaux MPLS pour opérateurs : LSPs, Traffic Engineering et dépannage en environnement SP

Quiconque exploite des réseaux dans un environnement proche des fournisseurs ou des carriers constate rapidement: MPLS est moins „ein Protokoll“ qu’un modèle opérationnel. Les MPLS-Grundlagen für Betreiber portent donc non seulement sur les labels, mais sur un contrôle propre des chemins (LSPs), une gestion maîtrisée de la charge (Traffic-Engineering) et une recherche d’incidents reproductible lorsque des VRF clients, des Pseudowires ou des sites entiers présentent des problèmes „sporadisch“. Cet article s’adresse aux opérateurs et aux administrateurs qui n’ont pas à connaître chaque RFC par cœur, mais qui doivent pouvoir décider de façon fiable en situation d’incident: le problème vient-il de l’Underlay (IGP), de la signalisation des labels (LDP/RSVP), de BGP/VRF ou d’un point MTU-/QoS?

Attitude fondamentale: Dans un environnement SP, MPLS est presque toujours stratifié en plusieurs niveaux. Underlay désigne le routage IP dans le cœur (typiquement OSPF ou IS-IS en tant qu’IGP, donc Interior Gateway Protocol). Overlay</em désigne des services comme L3VPN (VRF via MP-BGP) ou L2VPN (Pseudowire). Entre les deux se trouvent des LSPs (Label Switched Paths) en tant que rails de transport. Si vous vérifiez séparément ces couches, le temps jusqu’à la cause racine diminue sensiblement.

Fondamentaux MPLS pour opérateurs: pourquoi MPLS fonctionne différemment en exploitation que „IP-Routing“

MPLS (Multiprotocol Label Switching) achemine les paquets sur la base de labels courts plutôt que de l’adresse IP de destination complète. Un routeur dans le cœur MPLS devient un LSR (Label Switch Router). Le point d’entrée dans le cœur MPLS est l‘Ingress, la sortie est l‘Egress. En environnement client ou edge, on parle souvent de PE (Provider Edge) et de P (Core). Sur les routeurs PE se créent des services (VRFs, Pseudowires), tandis que les routeurs P se contentent de transporter.

Opérationnellement déterminant: MPLS sépare plus nettement le Forwarding de la décision de routage. Le routage (Control Plane) calcule des chemins (p. ex. via IS-IS/OSPF). MPLS construit par-dessus une structure de Forwarding (Data Plane) avec des informations de label. Quand le routage est „vert“, MPLS peut néanmoins être „rouge“ — par exemple si des voisinages LDP font défaut, si RSVP-TE ne signale pas ou si la pile de labels se brise à cause de la MTU.

Comprendre les LSPs: ce qu’est réellement un Label Switched Path

Un LSP (Label Switched Path) est le chemin orienté qu’empruntent les paquets MPLS à travers le réseau. Le fait qu’il soit „orienté“ est important: l’aller de A vers B est un LSP distinct, le retour de B vers A l’est aussi. En exploitation, vous rencontrerez deux variantes fondamentales:

• IGP-basierte LSPs (souvent via LDP): le LSP suit le chemin le plus court calculé par l’IGP. L’exploitant le pilote indirectement via les métriques IGP et la topologie.
• Explizite/TE-LSPs (classiquement via RSVP-TE ou de façon moderne via Segment Routing): le chemin est piloté de manière plus ciblée, p. ex. pour contourner des goulots d’étranglement ou satisfaire des exigences de bande passante/latence.

Le mécanisme central est le Label-Stack : un paquet peut porter plusieurs labels (au-dessus «Transportlabel», en dessous par ex. un label VPN pour la VRF de destination). Dans l’exploitation d’un SP, cela explique de nombreux symptômes : si le label de transport extérieur est correct, mais que le label de service interne ne l’est pas, le cœur est en général sain — le problème se situe plutôt au niveau du PE/BGP/VRF ou de la définition du service.

Opérations sur les labels : Push, Swap, Pop – et pourquoi PHP relevant ist

MPLS connaît trois opérations de base : Push (ajouter un label), Swap (échanger un label) et Pop (supprimer un label). De nombreux réseaux utilisent PHP (Penultimate Hop Popping) : le routeur avant-dernier retire le label de transport pour alléger le travail de l’Egress. Cela peut influer sur le diagnostic, car l’Egress présente moins d’informations MPLS « visibles » et certains outils/télémetries apparaissent différemment. Pour les opérateurs, cela signifie : si des traces à l’Egress ne montrent « soudainement » plus de labels externes, ce n’est pas automatiquement une erreur – cela peut être du PHP.

Plan de contrôle en bref : LDP, RSVP-TE et Segment Routing

Pour qu’un LSP soit établi, les routeurs doivent distribuer des labels ou signaler des chemins. Dans la pratique, vous rencontrerez le plus souvent ces modèles :

• LDP (Label Distribution Protocol) : distribue les labels le long de la topologie IGP. Simple en exploitation, peu de « policy », mais TE classique limité.
• RSVP-TE (Resource Reservation Protocol – Traffic Engineering) : signale des TE-LSP explicites et peut réserver de la bande passante. Plus puissant opérationnellement, mais à état (State) et donc plus sensible en termes d’échelle et de scénarios d’incident.
• Segment Routing (SR-MPLS) : contrôle les chemins via des Segment-IDs (SIDs), généralement étroitement intégré à IS-IS/OSPF. Moins d’état par flux dans le réseau, mais une logique opérationnelle différente (politiques, SIDs, éventuellement SR-TE).

Important du point de vue exploitant : que ce soit LDP, RSVP-TE ou SR – l’underlay doit être stable. Si l’IGP flappe, les LSP flappent. Si les adjacences sont instables, les décisions TE et le FRR (Fast Reroute) ne traitent que les symptômes.

Pièges typiques liés à LDP

• IGP-/LDP-Alignment : si LDP ne fonctionne que sur une partie des interfaces du cœur ou si l’IGP et LDP ont des sélections d’interface différentes, des « LDP Holes » apparaissent – atteignabilité IGP oui, chemin commuté par label non.
• Transport via les loopbacks : de nombreux designs utilisent les loopbacks des routeurs comme identité LDP/Router-ID. Si la reachability du loopback ou la politique IGP est défectueuse, les voisinages tombent.
• Graceful RESTart / Session Protection : sans mécanismes de redémarrage bien conçus, les redémarrages de la control plane entraînent des chutes de trafic, alors que le plan de données pourrait encore être viable.

Pièges typiques liés à RSVP-TE

• État et montée en charge : RSVP maintient de l’état par LSP (Soft State). Un grand nombre de LSP ou des intervalles de rafraîchissement courts sollicitent fortement le CPU/la control plane.
• Modèle de bande passante : « réservé » ne signifie pas automatiquement « garanti » si l’architecture QoS et des files d’attente n’est pas adaptée. Inversement, un contrôle d’admission trop strict peut empêcher des LSP alors que la capacité physique est disponible.
• Calcul de chemin vs réalité : le TE repose sur les informations IGP-TE (p. ex. bande passante disponible). Si ces valeurs sont obsolètes, erronées ou incohérentes, le TE oriente mal.

MPLS Traffic Engineering en pratique : objectifs, prérequis, risques

MPLS Traffic Engineering est en exploitation avant tout un outil pour maîtriser de manière plus contrôlée les pics de charge, les goulets d’étranglement ou les fenêtres de maintenance. Les objectifs typiques sont : atténuer les points chauds dans le cœur, utiliser des chemins définis pour des services sensibles à la latence, ou exploiter la capacité de façon planifiable sans se contenter de modifier les métriques IGP.

Conditions préalables pour que le TE ne devienne pas une source permanente d’incidents :

• Topologie IGP propre avec des métriques stables et des attributs TE cohérents (lorsqu’ils sont utilisés).
• Données de capacité fiables (bande passante des interfaces, réservations, règles d’overbooking) et un monitoring qui ne se limite pas au « lien up/down », mais qui surveille l’utilisation, les pertes, la mise en file d’attente et la latence.
• Cycle de vie opérationnel : les politiques TE nécessitent une gestion des changements, de la documentation, des revues et une responsabilité clairement définie. « Rediriger rapidement une fois » est la porte d’entrée vers un désordre de configurations.

Risques et erreurs typiques des opérateurs :

• TE comme substitut à la capacité : le TE peut répartir les goulots d’étranglement, mais pas les faire disparaître. Lorsque tous les chemins sont saturés, le TE ne fait que déplacer le problème.
• Domaines de défaillance mal définis : le TE peut planifier en ignorant des risques partagés (SRLG, Shared Risk Link Group – dépendances physiques communes comme des conduits de câbles) si ceux-ci ne sont pas modélisés. Dans ce cas, la « diversité » théorique emprunte en réalité le même tracé.
• Asymétrie : le sens aller est optimisé, le retour reste en configuration IGP par défaut. Cela peut fausser la latence, les pare-feu, la stabilité des sessions et les mesures.

FRR et réparation locale : pourquoi « rapide » n’est pas automatiquement « propre »

FRR (Fast Reroute) doit basculer très rapidement localement en cas de défaillance de lien/nœud, sans attendre la convergence complète de l’IGP. Cela stabilise l’expérience client, mais peut compliquer le dépannage : juste après une panne, le chemin peut sembler « étrange » parce qu’un contournement local est actif, jusqu’à ce que le recalcul global soit terminé. Conseil opérateur : vérifiez pendant la fenêtre d’incident si vous observez des chemins FRR avant de suspecter des « boucles de routage » ou des « métriques incorrectes ».

Services sur MPLS : L3VPN (VRF) comme cas d’exploitation le plus fréquent

Beaucoup d’équipes disent « MPLS » au quotidien, mais parlent en réalité de BGP/MPLS L3VPN. La VRF (Virtual Routing and Forwarding) est ici centrale : une table de routage séparée par client/service. La distribution des routes s’effectue généralement via MP-BGP (Multiprotocol BGP), souvent avec des Route Targets (RT) pour contrôler l’import/export. Le forwarding effectif utilise ensuite des labels MPLS : à l’extérieur le transport (Core), à l’intérieur le label VPN (la VRF correcte sur l’Egress-PE).

Conséquence pratique pour le dépannage : si un client « n’a pas de routage », le core peut néanmoins fonctionner parfaitement. Vérifiez d’abord : les routes VPN arrivent-elles dans le MP-BGP ? Les RT sont-ils corrects ? Le label VPN est-il présent dans la LFIB (Label Forwarding Information Base) ? Et la MTU est-elle adaptée pour la pile de labels ?

MTU et empilement d’étiquettes : la cause silencieuse de panne

Un label MPLS ajoute typiquement 4 octets par label. Avec plusieurs labels (transport + service, éventuellement d’autres), le paquet augmente. Si les interfaces, LAGs ou segments de tunnel sont configurés juste à la limite, cela entraîne de la fragmentation ou des drops. Particulièrement sournois : de nombreux messages ICMP (PMTUD – Path MTU Discovery) sont filtrés dans les environnements provider ou se perdent sur des chemins asymétriques. Résultat : les paquets « trop grands » restent bloqués, les petits passent. Si vous voulez aborder systématiquement les problèmes de MTU, un guide dédié est utile ; en complément, l’article Analyser les problèmes de MTU et de fragmentation et les éviter via GRE/IPsec convient, car la logique de vérification (PMTUD, MSS, drops) est très similaire.

Recherche de pannes en environnement SP : modèle en couches et ordre des vérifications

En cas d’incidents, les équipes perdent du temps lorsqu’elles sautent d’un niveau à l’autre. Il est éprouvé d’avoir un ordre fixe, documenté comme runbook. Objectif : d’abord vérifier si l’underlay est stable, puis le transport MPLS, ensuite l’overlay de service (VRF/BGP), puis les sujets proches du client (CPE, firewall, NAT, application).

1) Vérifier l’underlay : IGP, voisinages, convergence

Underlay signifie : les routeurs core peuvent-ils se joindre au niveau IP et les adjacences IGP sont-elles stables ? Les symptômes typiques d’un problème d’underlay sont des link-flaps, une forte charge CPU, des pics de latence et une perte de paquets « random “ sur de nombreux services simultanément.

Vérifications pratiques (formulées de manière vendor-neutral) :

• Statut des voisins IGP : Up/Down, compteur de flaps, Dead-Timer, erreurs d’interface.
• Routes vers la loopback des PE/P-Router : figurent-elles dans le RIB/FIB ? Le Next Hop change-t-il fréquemment ?
• Cohérence ECMP : avec Equal-Cost Multi-Path, des chemins individuels peuvent être défaillants et n’affecter qu’une partie des flows.

2) Vérifier le transport MPLS : LDP/RSVP/SR et LFIB

Vérifiez maintenant si la couche MPLS est continue : les voisinages LDP ou RSVP-TE sont-ils up ? Existe-t-il des labels pour les FECs pertinents (Forwarding Equivalence Classes – regroupement du trafic traité de la même manière) ? Les Label-Swaps dans le LFIB correspondent-ils ?

Si votre plateforme le supporte, LSP Ping et MPLS Traceroute sont très utiles : ils testent non seulement l’IP, mais la chaîne de forwarding MPLS. Important : ces outils peuvent être influencés par PHP et par des filtres ICMP. Un trace « incomplet “ n’indique pas automatiquement un MPLS défaillant – cela peut aussi être une policy/ACL.

3) Vérifier l’overlay de service : VRF, MP-BGP, RT/RD, labels

Lorsque les LSP de transport sont établis, vérifiez la couche service :

• Existence de la VRF et bindings d’interface : l’interface client est-elle vraiment dans la bonne VRF ? Les subinterfaces / VLAN-tags correspondent-ils ?
• Sessions MP-BGP : Up/Down, Route-Refresh, flaps, changements de policy.

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

Viele „MPLS-Probleme“ sitzen an den Grenzen: falsches Policing, Drops in einer Queue, ACL-Änderungen oder eine MTU, die nur in eine Richtung passt. Gerade im SP-Umfeld ist asymmetrisches Routing häufig (Hinweg über Pfad A, Rückweg über Pfad B). Das ist nicht per se falsch, kann aber Zustandsbehaftetes (Firewalls, NAT, Session-Pinning) brechen. Wenn Sie dafür ein methodisches Vorgehen brauchen, lohnt sich ein eigener Troubleshooting-Artikel zum Thema.

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

Die folgende Checkliste ist bewusst operational formuliert. Passen Sie sie an Ihre Plattform (Cisco/Juniper/Nokia/Arista/FRR) und an Ihre Telemetrie an.

A) Symptomklassifikation (erste 5 Minuten)

• Ein Kunde/VRF betroffen oder viele gleichzeitig?
• Komplettausfall oder nur bestimmte Applikationen/Ports/Packet-Sizes?
• Seit wann (Change-Fenster, Wartung, Link-Events, DDoS-Events)?
• Nur ein Standort oder mehrere? Nur ein PE oder mehrere PEs?

B) Transportpfad validieren (10–20 Minuten)

Arbeiten Sie sich hop-by-hop vor: Underlay bis Loopback, dann MPLS-Transport, dann Service.

• IP-Ping/Trace zwischen relevanten Loopbacks (PE↔PE).
• MPLS-spezifische Tests (LSP Ping/Trace), wenn verfügbar.
• LFIB/Label-Table prüfen: Gibt es Einträge für die Ziel-FEC? Zeigt der Outgoing-Label/Next-Hop plausibel?

C) Servicepfad validieren (10–20 Minuten)

• MP-BGP: Session stabil? Route-Anzahl plausibel? Letzte Policy-Änderungen?
• VRF-Routing: Default-Route vorhanden? Spezifische Prefixes da?
• ARP/ND an der Kundenkante (je nach L2/L3), um „Layer-2 sieht tot aus“ abzugrenzen.

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

• Interface-Counter: Drops, CRC, Input/Output Errors, Queue Drops.
• QoS/Policer: Trifft eine Police plötzlich? Haben sich Classifier geändert?
• MTU/MSS: Hinweise auf Fragmentation Needed? Korrelation mit „nur große Pakete“.

Typische Fehlerbilder und wie Sie sie erkennen

Die folgenden Muster kommen in SP- und Carrier-nahen Netzen regelmäßig vor. Entscheidend ist, dass Sie pro Muster einen „Beweis“ suchen, statt auf Bauchgefühl zu reagieren.

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

Oft ist das ein MPLS-Transportthema (fehlendes Label) oder ein MTU-/QoS-Problem. Wenn IGP reachability stimmt, aber LFIB-Eintrag fehlt, ist die Control Plane zwischen Routern (LDP/RSVP/SR) der Hebel. Wenn LFIB stimmt, aber Counter Drops zeigen: Datenebene, nicht Routing.

Fehlerbild 2: „Nur eine VRF/Kunde betroffen“

Sehr häufig Overlay: falsche RTs, fehlende MP-BGP-Routen, falsches VRF-Binding am Interface oder ein einzelner PE mit defekter Policy. Der Core ist dann meistens gesund. Best Practice: Erst Service-Definition prüfen, dann Transport eskalieren.

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

MTU/MSS oder fragmentationsbezogene Filter. In MPLS-Domains kann das durch zusätzliche Label-Overhead verstärkt werden. Wenn Sie in einem Runbook bereits festhalten, welche Links/Jumbo-Profile im Core gelten, sparen Sie viel Zeit.

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

Il s’agit souvent d’un effet de post-convergence TE/FRR : le trafic circule sur des chemins de protection parce qu’un lien est « up » mais que les attributs TE ou l’adjacence IGP ne sont pas correctement établis. Vérifiez : le lien est-il réellement présent dans l’IGP ? Les annonces TE sont-elles redevenues cohérentes ? Existe-t-il encore des temporisateurs de « hold-down » ou des poids administratifs qui évitent le chemin ?

How-to : Stack d’outils minimal pour exploitants (sans dépendance fournisseur)

Toutes les équipes n’ont pas les mêmes commandes. Néanmoins, on peut définir une trousse à outils universelle : tests IP, MPLS-OAM, compteurs/télémétrie, capture de paquets en bordure.

Pour Linux-basierte points de mesure ou machines virtuelles de test (p. ex. dans des réseaux proches des PE), ces éléments de base sont utiles :

# 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

Pourquoi cela fonctionne : avec ping -M do (Do-not-fragment) vous forcez la visibilité des problèmes de MTU, au lieu qu’ils soient fragmentés en arrière-plan. tcpdump montre si un ICMP « Fragmentation Needed » revient du tout. Limites : dans de nombreux cœurs de fournisseurs, vous ne voyez pas l’ICMP ou il est filtré ; il ne reste alors que la mesure en bordure ou via l’OAM des routeurs.

Modifications, rollback et stratégie de repli pour MPLS/TE

Les exploitants ne réfléchissent pas seulement à « comment réparer », mais aussi à « comment éviter des dommages collatéraux ». Pour MPLS/Traffic-Engineering, chaque modification des métriques IGP, des policies TE ou des paramètres RSVP/SR peut avoir un effet à grande échelle.

Procédure éprouvée pendant la fenêtre de changement

• Points de mesure avant-après : Définissez 2–3 chemins (PE↔PE, pertinents pour le client) et mesurez la latence, la perte et, le cas échéant, la MTU.
• Limiter le périmètre : Mieux vaut d’abord modifier un LSP/une Policy sur une paire de PE que globalement.
• Préparer le rollback : Documentez la configuration et le retour attendu (p. ex. le temps de convergence IGP). Le rollback n’est pas un simple « replay » : il faut vérifier que le chemin de données est effectivement revenu.
• Adapter temporairement l’alerte du monitoring : Ne pas désactiver, mais réduire le « bruit » pour qu’une erreur réelle reste visible pendant la maintenance.

Stratégie de repli si le TE provoque des problèmes inattendus : retirez d’abord le contrôle spécifique au TE (Policy/LSP), puis retombez sur le comportement IGP par défaut (LDP/Shortest Path), plutôt que de changer frénétiquement les métriques. Les modifications de métriques ont souvent un rayon d’impact plus important que la désactivation d’une seule policy TE.

Sécurité et exploitation : MPLS n’est pas un VPN au sens cryptographique

Dans de nombreuses entreprises, MPLS est désigné par le terme « VPN ». Dans le contexte fournisseur, « VPN » (p. ex. L3VPN) signifie avant tout une séparation logique (VRF/Label), pas un chiffrement. Si vous avez besoin de protection contre l’interception sur les liaisons de transport, vous devez prévoir des mesures supplémentaires comme MACsec (chiffrement de couche 2) ou IPsec (couche 3), ou utiliser des overlays chiffrés côté application (TLS). Point important pour les exploitants : cette décision influence la MTU, le monitoring (trafic chiffré), le dépannage et la planification des performances.

Conclusion : Exploiter MPLS de façon stable implique de séparer les couches et de prouver les chemins

Les principes fondamentaux de MPLS pour les opérateurs relèvent moins de la « théorie des labels » que d’un modèle d’exploitation discipliné : stabiliser d’abord l’underlay, puis valider le transport MPLS (LSPs et Label-Forwarding), et seulement ensuite évaluer des services comme VRF/MP-BGP. Le Traffic-Engineering est un outil puissant lorsque les prérequis (qualité de l’IGP, modèle de capacité, monitoring, processus de changement) sont réunis — sinon il devient un traitement d’exception permanent.

Si vous rédigez votre propre Runbook, consignez pour chaque couche des preuves concrètes (état des voisins, existence du LFIB, résultats OAM, compteurs/drops, tests MTU). Cela rend les incidents reproductibles, réduit les délais d’escalade et améliore la collaboration entre le NOC, l’ingénierie et les équipes proches du client.

Les MPLS-LSPs sont également importants pour ce sujet. Cet article situe ces aspects de manière compréhensible et montre ce qui compte au quotidien.