Fondamenti MPLS per operatori: LSPs, Traffic-Engineering e diagnostica dei guasti nel contesto SP

Chi gestisce reti in ambito vicino ai Provider o ai Carrier nota rapidamente: MPLS è meno «un protocollo» che un modello operativo. I fondamenti MPLS per gli operatori non riguardano quindi solo le label, ma il controllo preciso dei percorsi (LSPs), la gestione controllata del carico (Traffic-Engineering) e una ricerca guasti ripetibile quando VRF dei clienti, Pseudowire o interi siti mostrano problemi «sporadici». Questo contributo è rivolto a operatori e amministratori che non devono conoscere a memoria ogni RFC, ma vogliono decidere con affidabilità in caso di guasto: è colpa dellUnderlay (IGP), della segnalazione dei label (LDP/RSVP), di BGP/VRF o di un problema di MTU/QoS?

Importante come atteggiamento di base: in un contesto SP MPLS è quasi sempre stratificato in più livelli. Underlay indica il routing IP nel Core (tipico OSPF o IS-IS come IGP, cioè Interior Gateway Protocol). Overlay</em> indica servizi come L3VPN (VRF via MP-BGP) o L2VPN (Pseudowire). Tra di essi si trovano LSPs (Label Switched Paths) come «binari» di trasporto. Se si verificano separatamente questi livelli, il tempo per individuare la causa principale diminuisce notevolmente.

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

MPLS (Multiprotocol Label Switching) instrada i pacchetti in base a brevi label invece che sull’intero indirizzo IP di destinazione. Un router nel core MPLS diventa un LSR (Label Switch Router). Il punto di ingresso nel core MPLS è l‘Ingress, l’uscita l‘Egress. Nell’ambito cliente o di edge si parla spesso di PE (Provider Edge) e P (Core). Sui router PE sorgono servizi (VRFs, Pseudowires), mentre i router P si limitano a trasportare.

Operativamente decisivo: MPLS separa in misura maggiore l’inoltro (Forwarding) dalla decisione di routing. Il routing (Control Plane) calcola i percorsi (p. es. via IS-IS/OSPF). MPLS costruisce su questo una struttura di Forwarding (Data Plane) con informazioni sui label. Quando il routing è «verde», MPLS può comunque essere «rosso» — ad esempio quando mancano le adiacenze LDP, RSVP-TE non segnala, o lo stack di label si interrompe a causa della MTU.

LSPs verstehen: Was ein Label Switched Path wirklich ist

Un LSP (Label Switched Path) è il percorso diretto che i pacchetti MPLS percorrono nella rete. «Diretto» è importante: il percorso di andata da A a B è un LSP distinto, così come il ritorno da B ad A. In esercizio incontrerete due varianti fondamentali:

• LSP basati su IGP (spesso via LDP): l’LSP segue il percorso più breve calcolato dall’IGP. L’operatore controlla indirettamente tramite le metriche IGP e la topologia.
• LSP espliciti/TE (classici via RSVP-TE o moderni via Segment Routing): il percorso è controllato in modo più mirato, p. es. per evitare colli di bottiglia o per soddisfare requisiti di larghezza di banda/latenza.

Il meccanismo centrale è lo stack di etichette: un pacchetto può portare più etichette (in alto «transport label», sotto ad esempio un’etichetta VPN per la VRF di destinazione). Nella pratica degli SP questo spiega molti sintomi: se il transport label esterno è corretto ma il label di servizio interno no, di solito il Core è sano — il problema è più probabilmente su PE/BGP/VRF o nella definizione del servizio.

Operazioni sulle etichette: Push, Swap, Pop — e perché PHP è rilevante

MPLS conosce tre operazioni di base: Push (aggiungere un label), Swap (scambiare un label) e Pop (rimuovere un label). Molte reti usano PHP (Penultimate Hop Popping): il router penultimo rimuove il transport label, in modo che l’Egress abbia meno lavoro. Questo può influenzare il troubleshooting, perché all’Egress sono visibili meno informazioni MPLS e alcuni tool/telemetria appaiono diversi. Per gli operatori significa: se le traces all’Egress improvvisamente non mostrano più label esterni, non è automaticamente un guasto — potrebbe essere PHP.

Panoramica del Control Plane: LDP, RSVP-TE e Segment Routing

Per la creazione di un LSP, i router devono distribuire label o segnalare percorsi. Nella pratica si incontrano più frequentemente questi modelli:

• LDP (Label Distribution Protocol): distribuisce label lungo la topologia IGP. Operativamente semplice, poca «policy», ma capacità di TE classico limitate.
• RSVP-TE (Resource Reservation Protocol – Traffic Engineering): segnala LSP TE espliciti e può riservare larghezza di banda. A livello operativo più potente, ma basato su stato (State) e quindi più sensibile in scenari di scalabilità/guasto.
• Segment Routing (SR-MPLS): controlla i percorsi tramite Segment ID (SID), solitamente strettamente integrato con IS-IS/OSPF. Meno stato per flusso nella rete, ma diversa logica operativa (policy, SID, eventuale SR-TE).

Importante dal punto di vista dell’operatore: che si tratti di LDP, RSVP-TE o SR, l’underlay deve essere stabile. Se l’IGP è instabile (flapping), anche gli LSP saranno instabili. Se le adiacenze sono instabili, le decisioni TE e FRR (Fast Reroute) sono solo una gestione dei sintomi.

Insidie tipiche in LDP

• Allineamento IGP/LDP: se LDP gira solo su una parte delle interfacce del Core o IGP e LDP scelgono interfacce diverse, si creano «LDP Holes» — raggiungibilità IGP sì, percorso Label-Switched no.
• Trasporto su loopback: molti design usano il loopback del router come identità LDP/Router-ID. Se la reachability del loopback o la policy IGP sono errate, le adiacenze si interrompono.
• Graceful RESTart / Session Protection: senza meccanismi di RESTart puliti i riavvii della control plane causano cadute di traffico, anche se il data plane potrebbe essere ancora operativo.

Insidie tipiche con RSVP-TE

• Stato e scalabilità: RSVP mantiene per LSP uno stato (Soft State). Molti LSP o intervalli di refresh brevi sovraccaricano CPU/control plane.
• Modello di larghezza di banda: «riservato» non significa automaticamente «garantito», se l’architettura QoS e delle code non è adeguata. Viceversa, una admission control troppo rigida può impedire LSP pur quando esiste capacità fisica.
• Calcolo del percorso vs. realtà: TE si basa su informazioni IGP-TE (es. larghezza di banda disponibile). Se questi valori sono obsoleti, errati o incoerenti, TE pianificherà male.

MPLS Traffic Engineering nella pratica: obiettivi, prerequisiti, rischi

MPLS Traffic Engineering è in esercizio soprattutto uno strumento per gestire in modo più controllato picchi di carico, colli di bottiglia o finestre di manutenzione. Obiettivi tipici sono: attenuare i punti di congestione nel Core, utilizzare percorsi definiti per servizi sensibili alla latenza o sfruttare la capacità in modo pianificabile senza «semplicemente» alterare le metriche IGP.

Prerequisiti affinché TE non diventi un problema ricorrente:

• Topologia IGP pulita con metriche stabili e attributi TE coerenti (se utilizzati).
• Dati di capacità affidabili (larghezza di banda delle interfacce, riservazioni, regole di overbooking) e un sistema di monitoraggio che non si limiti a «Link up/down», ma osservi utilizzo, Drops, Queueing e latenza.
• Ciclo di vita operativo: le policy TE richiedono controllo delle modifiche, documentazione, revisioni e una chiara responsabilità. «Un reindirizzamento rapido una tantum» è l’inizio della proliferazione disordinata delle configurazioni.

Rischi ed errori operativi tipici:

• TE come sostituto della capacità: TE può distribuire i colli di bottiglia, ma non farli sparire. Se tutti i percorsi sono saturi, TE sposta solo il problema.
• Domini di guasto non chiari: TE può pianificare oltre rischi condivisi (SRLG, Shared Risk Link Group – dipendenze fisiche comuni come canalizzazioni o percorsi di cavi) se questi non sono modellati. Allora la «diversità» teorica passa comunque lungo la stessa tratta.
• Asimmetria: il verso di andata viene ottimizzato, il ritorno resta con impostazione predefinita IGP. Questo può falsare latenza, firewall, stabilità delle sessioni e misurazioni.

FRR e riparazione locale: perché «veloce“ non è automaticamente «pulito»

FRR (Fast Reroute) deve commutare localmente molto rapidamente in caso di guasti di link/nodo, senza attendere la completa convergenza IGP. Questo stabilizza l’esperienza cliente, ma può complicare il troubleshooting: subito dopo un guasto il percorso può sembrare «strano» perché è attivo un bypass locale, fino al completamento del ricalcolo globale. Suggerimento operativo: verificate durante la finestra di guasto se state osservando percorsi FRR prima di ipotizzare «routing loop» o «metriche errate».

Servizi su MPLS: L3VPN (VRF) come caso operativo più frequente

Molti team nel quotidiano dicono «MPLS», ma intendono in realtà BGP/MPLS L3VPN. Qui la VRF (Virtual Routing and Forwarding) è centrale: una tabella di routing separata per cliente/servizio. La distribuzione delle rotte avviene di norma tramite MP-BGP (Multiprotocol BGP), spesso con Route Targets (RT) per il controllo di import/export. Il forwarding vero e proprio usa quindi label MPLS: esternamente il trasporto (Core), internamente il label VPN (la VRF corretta sull’Egress-PE).

Conseguenza pratica per il troubleshooting: se un cliente «non ha routing», il Core può comunque funzionare perfettamente. Allora verificate prima di tutto: le rotte VPN arrivano in MP-BGP? Gli RT sono corretti? Il label VPN è presente nella LFIB (Label Forwarding Information Base)? E la MTU è adeguata per lo stack di label?

MTU e stack di label: la causa silenziosa dei guasti

Un label MPLS aggiunge tipicamente 4 Byte per label. Con più label (transport + service, eventualmente altri) il pacchetto cresce. Se interfacce, LAG o percorsi tunnel sono configurati con margine ridotto, si verificano frammentazione o drop. Particolarmente insidioso: molti messaggi ICMP (PMTUD – Path MTU Discovery) vengono filtrati negli ambienti dei provider o si perdono su percorsi asimmetrici. Risultato: i pacchetti „grandi“ restano bloccati, quelli piccoli transitano. Se volete affrontare sistematicamente i problemi di MTU, è utile una guida dedicata; in continuità si adatta il contributo Analizzare i problemi di MTU e frammentazione ed evitarli tramite GRE/IPsec, perché la logica di verifica (PMTUD, MSS, drop) è molto simile.

Ricerca guasti nell’ambiente SP: modello a livelli e sequenza di controlli

In caso di guasti i team perdono tempo se saltano tra tutti i livelli. È consolidata una sequenza fissa da documentare come runbook. Obiettivo: chiarire prima se l’underlay è stabile, poi il trasporto MPLS, poi l’overlay di servizio (VRF/BGP), infine temi a contatto con il cliente (CPE, firewall, NAT, applicazione).

1) Verificare l’underlay: IGP, adiacenze, convergenza

Underlay significa: i core router si raggiungono a livello IP e le adiacenze IGP sono stabili? Sintomi tipici di problemi di underlay sono flapping dei link, CPU elevata, picchi di latenza e perdita di pacchetti „casuale“ su molti servizi contemporaneamente.

Controlli pratici (formulati vendor-neutral):

• Stato dei neighbor IGP: Up/Down, contatore flap, Dead-Timer, errori di interfaccia.
• Route verso la loopback dei PE/P-Router: sono presenti in RIB/FIB? Il Next Hop cambia frequentemente?
• Consistenza ECMP: con Equal-Cost Multi-Path singoli percorsi possono essere difettosi e interessare solo una parte dei flussi.

2) Verificare il trasporto MPLS: LDP/RSVP/SR e LFIB

Ora verificate se il livello MPLS è continuo: le adiacenze LDP o RSVP-TE sono up? Esistono label per le FEC rilevanti (Forwarding Equivalence Classes – raggruppamento di traffico trattato allo stesso modo)? I label-swap nel LFIB corrispondono?

Se la vostra piattaforma lo supporta, LSP Ping e MPLS Traceroute sono molto utili: testano non solo l’IP, ma la catena di forwarding MPLS. Importante: questi strumenti possono essere influenzati da PHP e da filtri ICMP. Un trace „incompleto“ non è automaticamente sinonimo di MPLS guasto – può essere anche una policy/ACL.

3) Verificare l’overlay di servizio: VRF, MP-BGP, RT/RD, label

Se i LSP di trasporto sono attivi, verificate lo strato di servizio:

• Esistenza delle VRF e binding delle interfacce: l’interfaccia del cliente è davvero nella VRF corretta? Subinterface/tag VLAN coincidono?
• Sessioni MP-BGP: Up/Down, Route-Refresh, flap, cambiamenti di policy.

4) Verificare i bordi: QoS, policing, ACL, MTU, instradamento asimmetrico

Molti „problemi MPLS“ si verificano ai confini: policing errato, drop in una coda, modifiche alle ACL o una MTU che funziona solo in una direzione. Proprio nell’ambito dei service provider (SP) l‘instradamento asimmetrico è frequente (andata su percorso A, ritorno su percorso B). Questo non è di per sé sbagliato, ma può interrompere componenti con stato (firewall, NAT, session-pinning). Se serve un approccio metodico, vale la pena un articolo di troubleshooting dedicato.

Runbook pratico: dal sintomo alla causa in 30–60 minuti

La checklist seguente è formulata intenzionalmente in modo operativo. Adattatela alla vostra piattaforma (Cisco/Juniper/Nokia/Arista/FRR) e alla vostra telemetria.

A) Classificazione del sintomo (primi 5 minuti)

• Un cliente/VRF interessato o molti contemporaneamente?
• Guasto completo o solo determinate applicazioni/porte/dimensioni pacchetto?
• Da quando (finestra di change, manutenzione, eventi di link, eventi DDoS)?
• Solo un sito o più siti? Solo un PE o più PE?

B) Validare il percorso di trasporto (10–20 minuti)

Procedete hop-by-hop: underlay fino ai loopback, poi il trasporto MPLS, infine il servizio.

• IP-Ping/trace tra i loopback rilevanti (PE↔PE).
• Test specifici MPLS (LSP Ping/Trace), se disponibili.
• Controllare LFIB/Label-Table: ci sono voci per la FEC di destinazione? L’Outgoing-Label/Next-Hop appare plausibile?

C) Validare il percorso di servizio (10–20 minuti)

• MP-BGP: sessione stabile? Numero di route plausibile? Ultime modifiche alle policy?
• Routing VRF: route di default presenti? Prefix specifici disponibili?
• ARP/ND al perimetro del cliente (a seconda di L2/L3), per escludere il caso „Layer-2 sembra morto”.

D) Verificare il piano dati (10–20 minuti)

• Contatori di interfaccia: drop, CRC, errori input/output, queue drops.
• QoS/Policer: è entrata in funzione una policy di policing improvvisamente? Sono cambiati i classifier?
• MTU/MSS: segni di Fragmentation Needed? Correlazione con „solo pacchetti grandi”.

Modelli di errore tipici e come riconoscerli

I pattern seguenti si presentano regolarmente nelle reti vicine a SP e carrier. È fondamentale cercare per ogni pattern una „prova”, anziché reagire d’istinto.

Scenario di errore 1: „Il routing c’è, ma il traffico scompare”

Spesso è un problema del trasporto MPLS (label mancante) o un problema MTU/QoS. Se la reachability IGP è corretta ma manca una voce LFIB, il punto critico è la control plane tra router (LDP/RSVP/SR). Se la LFIB è corretta ma i contatori mostrano drop: è il piano dati, non il routing.

Scenario di errore 2: „Solo una VRF/cliente interessato”

Molto spesso è un overlay: RT errati, rotte MP-BGP mancanti, VRF-binding errato sull’interfaccia o un singolo PE con policy difettosa. Il core è generalmente sano. Best practice: verificare prima la definizione del servizio, poi scalare sul trasporto.

Scenario di errore 3: „Solo alcune applicazioni / solo pacchetti grandi”

MTU/MSS o filtri legati alla frammentazione. Nelle domini MPLS questo può essere aggravato dall’overhead aggiuntivo delle label. Se nel Runbook annotate già quali link/profilo jumbo valgono nel core, risparmierete molto tempo.

Scenario di errore 4: „Dopo la manutenzione: tutto up, ma latenza/percorsi più lunghi”

Questo è spesso un effetto residuo di TE/FRR: il traffico scorre su percorsi di protezione perché un link è «up», ma gli attributi TE o l’adiacenza IGP non sono corretti. Verificate: il link è realmente nel IGP? Gli annunci TE sono tornati consistenti? Ci sono ancora timer «hold-down» o pesi amministrativi che evitano il percorso?

How-to: Stack minimo di strumenti per operatori (senza vincolo di vendor)

Non tutte le squadre hanno ovunque gli stessi comandi. Ciononostante si può definire una cassetta degli attrezzi universale: test IP, MPLS-OAM, contatori/telemetria, acquisizione pacchetti ai bordi.

Per Linux-basierte punti di misura o VM di test (ad es. in reti vicine ai PE) questi elementi di base sono utili:

# 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

Perché funziona: con ping -M do (Do-not-fragment) si forza che i problemi di MTU diventino visibili, invece di frammentare in background. tcpdump mostra se l’ICMP «Fragmentation Needed» ritorna effettivamente. Limiti: in molti core dei provider non vedrete l’ICMP o questo viene filtrato; in tal caso rimane la misura ai bordi o tramite Router-OAM.

Modifiche, rollback e strategia di fallback per MPLS/TE

Gli operatori non pensano solo «come riparo», ma anche «come evito danni collaterali». Per MPLS/Traffic-Engineering vale: ogni modifica alle metriche IGP, alle policy TE o ai parametri RSVP/SR può avere effetti estesi.

Procedure consolidate nella finestra di modifica

• Punti di misura prima/dopo: definite 2–3 percorsi (PE↔PE, rilevanti per il cliente) e misurate latenza, perdita, eventualmente MTU.
• Limitare lo scope: meglio prima modificare un LSP/policy su una coppia di PE piuttosto che globalmente.
• Preparare il rollback: documentate la configurazione e il ritorno atteso (es. tempo di convergenza IGP). Il rollback non è «ripristinare e finire» – dovete verificare che il percorso dei dati sia effettivamente ripristinato.
• Adattare temporaneamente l’alerting di monitoring: non disattivare, ma ridurre il «rumore» per manutenzione, in modo che i guasti reali restino visibili.

Strategia di fallback se TE causa problemi inattesi: prima rimuovere il controllo specifico TE (policy/LSP), poi ricadere sull’IGP di default (LDP/Shortest Path), invece di cambiare metriche in modo frenetico. Le modifiche alle metriche spesso hanno un blast radius maggiore rispetto alla disattivazione di una singola policy TE.

Sicurezza e operatività: MPLS non è una VPN in senso crittografico

In molte aziende MPLS viene classificato linguisticamente come «VPN». Nel contesto provider, però, «VPN» (es. L3VPN) indica principalmente una separazione logica (VRF/Label), non la cifratura. Se serve protezione contro l’intercettazione sulle tratte di trasporto, servono misure aggiuntive come MACsec (cifratura Layer 2) o IPsec (Layer 3), oppure si usano overlay cifrati a livello applicazione (TLS). Per gli operatori è importante: questa decisione influenza MTU, monitoring (Encrypted Traffic), troubleshooting e pianificazione delle prestazioni.

Conclusione: gestire MPLS in modo stabile significa separare i livelli e dimostrare i percorsi

Le basi MPLS più importanti per gli operatori non sono tanto una «teoria delle label» quanto un modello operativo disciplinato: prima stabilizzare l’Underlay, poi validare il trasporto MPLS (LSPs e Label-Forwarding), e solo successivamente valutare servizi come VRF/MP-BGP. Il Traffic-Engineering è uno strumento potente quando i prerequisiti (qualità dell’IGP, modello di capacità, monitoring, processo di change) sono soddisfatti – altrimenti si trasforma in una gestione speciale permanente.

Se crea il suo Runbook, annoti per ogni livello prove concrete (stato dei Neighbor, esistenza della LFIB, risultati OAM, contatori/perdite, test MTU). Questo rende gli incidenti riproducibili, riduce i tempi di escalation e migliora la collaborazione tra NOC, Engineering e i team a diretto contatto con il cliente.

Per questo tema sono importanti anche Mpls Lsp. L’articolo inquadra questi aspetti in modo comprensibile e mostra cosa conta nella pratica quotidiana.