La continuità dei LSP MPLS PE-PE è un aspetto chiave nel funzionamento dei più importanti servizi MPLS. Come noto infatti, tutti questi servizi (es. L3VPN, L2VPN, 6PE, 6VPE, ecc.) hanno un denominatore comune, utilizzano sul piano dati più etichette MPLS.
Queste etichette MPLS sono di due tipi:
Queste etichette MPLS sono di due tipi:
- Una o più Transport Label, che sono etichette il cui compito è "guidare" il pacchetto da un router PE di ingresso verso un router PE di uscita. Queste etichette possono essere viste come delle "istruzioni" per i router di transito, per portare correttamente il pacchetto verso il router di uscita corretto. Nelle applicazioni classiche la Transport Label è una sola, o più di una in casi particolari (es. traffic engineering + fast rerouting). In questo post supporrò che la Transport Label sia unica.
- Una Service Label, che è una etichetta a cui corrisponde un servizio. Questa etichetta può essere vista come una "istruzione" per il router PE di uscita della rete IP/MPLS, per eseguire una determinata operazione (esempio: fai un lookup sulla VRF X, manda il payload verso l'interfaccia Y, ecc.).
Ora, cosa accade in caso di interruzione di un LSP MPLS PE-PE ? Interruzione causata ad esempio dalla caduta di una sessione LDP tra due LDP peer adiacenti ? Bene, iniziamo con il vedere quale problema causa questo fuori servizio.
NOTA: nel seguito di questo post ipotizzerò che i LSP PE-PE siano di tipo Hop-by-Hop, realizzati attraverso il protocollo (standard) LDP. Nulla cambierebbe comunque nel caso (raro per la verità nelle applicazioni pratiche) di LSP PE-PE di tipo Explicitly Routed realizzati attraverso la segnalazione RSVP-TE.
IL TALLONE D'ACHILLE ...
Il punto debole del trasporto MPLS è che l’interruzione di un LSP tra due PE, provoca la perdita di traffico che entra in un PE e diretto verso il PE all’altro estremo del LSP. L’interruzione di un LSP è causata dalla mancanza di una sessione LDP su un qualsiasi tratto del LSP (anche l’ultimo !). Possibili motivi sono errori di configurazione, e/o bug software. È importante tenere bene in mente che LDP non è un protocollo di routing e quindi non cambia percorso al traffico, in caso di down della sessione LDP.
La figura seguente riporta un esempio di perdita di traffico dovuta ad una interruzione del LSP tra PE1-1 e PE3-1, a causa dello stato down della sessione LDP tra P1 e P3. Il pacchetto IP con destinazione 10.3.33.1 è per ipotesi, un pacchetto di un servizio L3VPN (anche fosse di un altro servizio tipo ad esempio L2VPN non cambierebbe la sostanza delle cose), che viene trasportato all'interno del backbone IP/MPLS con due etichette MPLS: la service label 16.101, annunciata a PE1-1 da PE3-1 via MP-iBGP, e la transport label 16.005, annunciata a PE1-1 da P1 via LDP.
Il pacchetto MPLS arriva regolarmente al router P1, il quale, non avendo nella propria LFIB una etichetta uscente corrispondente all’etichetta 16.005 associata al BGP Next-Hop 192.168.0.31, invia il pacchetto a P3 ma senza alcuna etichetta MPLS.
P3 riceve quindi il pacchetto IP (senza etichette MPLS) da P1, ma non avendo nella sua tabella di routing alcuna informazione su come instradare traffico verso il prefisso L3VPN 10.3.32.0/22, scarta il pacchetto. E questo avviene anche se l’interruzione si fosse verificata sull’ultimo tratto del LSP, ossia nel tratto P3<-->PE3-1. Il perché è lasciato come esercizio al lettore.
È curioso notare che se oltre alla sessione LDP (in realtà, indipendentemente dal suo stato), anche l’adiacenza IGP tra P1 e P2 fosse down, il traffico verrebbe inoltrato regolarmente, seppur su un percorso diverso (e con etichette MPLS parzialmente diverse).
Il traffico tra due PE può essere perso, seppur temporaneamente, anche a causa della mancata sincronizzazione tra il protocollo IGP e LDP. Ad esempio, si può avere perdita di traffico quando l’adiacenza IGP è up ma la sessione LDP è ancora down, oppure l’adiacenza IGP e la sessione LDP sono entrambe up, ma le etichette MPLS non sono state completamente comunicate.
Da questo semplice esempio si deduce che la continuità dei LSP PE-PE è un elemento vitale per il funzionamento dei servizi MPLS. Per cui è molto importante avere a disposizione strumenti di troubleshooting efficaci.
PING E TRACEROUTE CLASSICI: PROBLEMI
Gli arcinoti strumenti di troubleshooting ping e traceroute, quando utilizzati in ambito MPLS hanno un difetto: non sempre riescono a rivelare la discontinuità dei LSP MPLS, ossia se nel percorso verso la destinazione, qualche sessione LDP è andata nello stato down.
Si consideri come esempio la rete della figura seguente, dove si suppone che la sessione LDP tra i router P2 e PE2-1 sia nello stato down. (NOTA: la rete è costituita da router Cisco. Nel caso di router Juniper il funzionamento del traceroute è leggermente diverso, nel senso che le etichette MPLS vengono mostrate solo se l'indirizzo IP destinazione del traceroute è parte di un prefisso IP annunciato via BGP).
Un "traceroute 192.168.0.21" eseguito sul router PE1-1 per tracciare il percorso MPLS verso l’interfaccia "Loopback 0" di PE2-1, non rivela alcunché di errato. Infatti, il risultato mostra le etichette MPLS su tutte le tratte del percorso ad eccezione dell’ultima. Purtroppo la mancanza dell’etichetta nell’ultima tratta potrebbe essere normale, a causa del meccanismo Penultimate Hop Popping, oppure potrebbe essere causata dalla mancanza sulla LIB di P2 dell’etichetta MPLS per la FEC 192.168.0.21/32, mancanza causata dallo stato down della sessione LDP tra P2 e PE2-1.
Ora, quando P2 non ha nella LIB l’etichetta ricevuta dall'IGP Next-Hop di una determinata FEC, altro non fa che inviare il pacchetto unlabelled, ossia senza alcuna etichetta MPLS. In molti servizi MPLS (es. L3VPN, L2VPN, trasporto di IPv6, ecc.), questo provoca perdita di traffico su PE2-1. In realtà, per queste tipologie di servizi, come visto nella sezione precedente, è sufficiente una discontinuità su un qualsiasi tratto del LSP MPLS, per causare perdita di traffico.
Con il ping la situazione è addirittura peggiore. Infatti, mentre con un traceroute è possibile individuare discontinuità intermedie nei LSP MPLS (è sufficiente verificare la presenza o meno delle etichette MPLS sulle varie tratte), ad eccezione, come nel caso della figura dell’ultimo tratto, i ping tra un estremo e l’altro di un LSP funzionano sempre, indipendentemente dalla presenza o meno di discontinuità in qualsiasi tratto del LSP.
Risulta quindi di notevole importanza, ai fini di un corretto e veloce troubleshooting, avere uno strumento, anche nelle situazioni più subdole, come quella mostrata nella figura, che consenta una rapida determinazione della continuità dei LSP MPLS. Per questa ragione, entrambe le applicazioni ping e traceroute sono state estese per la soluzione di questo problema.
PING E TRACEROUTE MPLS
Per le reti IP/MPLS sono state progettate estensioni dei classici ping e traceroute, in grado di rivelare eventuali discontinuità nei LSP MPLS e quindi facilitare le operazioni di troubleshooting del piano dati. Queste caratteristiche forniscono un potente mezzo per isolare eventuali malfunzionamenti, aggiungendo a MPLS funzionalità di OAM (Operation, Administration and Maintenance).
I ping e traceroute MPLS non utilizzano messaggi ICMP, ma entrambi due messaggi "ad hoc", trasportati via UDP, con porta 3503:
- MPLS echo request: include informazioni circa la FEC (Forwarding Equivalence Class) sotto test (es. un prefisso IP), codificata attraverso un modulo TLV (Type, Length, Value). Al messaggio possono essere aggiunti moduli TLV per richiedere ulteriori informazioni. Ad esempio, il modulo TLV "downstream detailed mapping" può essere utilizzato per richiedere a un LSR informazioni di tipo downstream verso la FEC, come ad esempio l’etichetta MPLS utilizzata nella direzione downstream (ossia, quella annunciata dal Next-Hop verso la FEC).
- MPLS echo reply: ha lo stesso formato dei pacchetti MPLS echo request, con in più i moduli TLV che contengono le informazioni richieste attraverso i messaggi MPLS echo request.
I messaggi MPLS echo request sono trasportati in pacchetti IP/UDP, incapsulati con l’etichetta MPLS downstream (ossia, uscente) relativa alla FEC sotto test. Il valore di TTL MPLS viene posto a 255. I pacchetti IP sono inviati con indirizzo IP sorgente quello dell’interfaccia che emette il pacchetto, indirizzo IP destinazione 127.0.0.1 e TTL IP = 1. Inoltre viene aggiunta l’opzione Router Alert per fare in modo che il pacchetto venga elaborato dal Route Processor. L’utilizzo di un indirizzo IP destinazione del prefisso riservato 127/8, consente a un LSR di non inoltrare il messaggio MPLS echo request qualora questo arrivi al LSR senza etichette MPLS; questo accade se il LSP è discontinuo in qualche punto.
L’utilizzo di ping e traceroute MPLS è descritto nella recentissima RFC 8029 - Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures, Marzo 2017, che è una rielaborazione della precedente RFC 4327 con lo stesso titolo. I ping e traceroute MPLS sono supportati da tutti i principali costruttori di apparati. L'unica cosa che bisogna verificare nelle applicazioni pratiche, nel caso di interlavoro tra macchine diverse, la compatibilità con alcune modifiche introdotte dalla nuova RFC 8029.
Nella prossima sezione illustrerò alcuni esempi in una rete di laboratorio costituita da router Cisco della serie ASR 9000, con IOS XR 5.3.0. Farò anche vedere l'analisi via wireshark, dei messaggi MPLS Echo Request e MPLS Echo Reply.
ESEMPI (FUNZIONAMENTO NORMALE)
I comandi utilizzati nelle varie versioni dell’IOS Cisco per i ping e traceroute MPLS sono rispettivamente: "ping mpls ipv4 <FEC> ..." e "traceroute mpls ipv4 <FEC> ...", dove la FEC è la rete sotto test (specificata da prefisso e maschera). I comandi hanno molte opzioni, alcune delle quali saranno mostrate con degli esempi. Per il resto si rimanda alla documentazione ufficiale Cisco. Per il funzionamento di questi comandi è necessario abilitare, solo nell'IOS XR, le funzionalità MPLS OAM con il comando a livello globale "mpls oam".
Si noti che questi comandi possono essere utilizzati solo su router PE e P, ma non su router che non hanno alcuna interfaccia abilitata MPLS. La ragione è che il loro compito è verificare la connettività downstream verso una determinata FEC, e non verso un indirizzo IP. Possono inoltre essere utilizzate per verificare la continuità di LSP Hop-by-Hop, Explicitly Routed e Pseudowire.
La figura seguente riporta un esempio di applicazione base di un ping MPLS, senza utilizzare nel comando alcuna opzione.
La prima differenza che salta agli occhi rispetto a un ping tradizionale è che il test non è verso un singolo indirizzo IP ma verso una intera rete IP, ossia verso una FEC (nell’esempio FEC = 192.168.0.21/32). Dal valore della FEC, PE1-1 deduce l’etichetta uscente, l’interfaccia di uscita e le informazioni di Livello 2 per il messaggio MPLS echo request. Il risultato mostra che il LSP MPLS tra PE1-1 e PE2-1 è continuo (confermato dai «!», che indicano la corretta ricezione di messaggi MPLS echo reply).
Vi riporto di seguito, la cattura con Wireshark di un messaggio MPLS echo request:
Frame 6 (114 bytes on wire, 114 bytes captured)
Ethernet II, Src: ca:00:15:b8:00:08 (ca:00:15:b8:00:08), Dst: ca:01:15:b8:00:08 (ca:01:15:b8:00:08)
MultiProtocol Label Switching Header, Label: 24007, Exp: 0, S: 1, TTL: 255
Internet Protocol, Src: 10.1.1.2 (10.1.1.2), Dst: 127.0.0.1 (127.0.0.1)
Version: 4
Header length: 24 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 96
Identification: 0x2789 (10121)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 1
Protocol: UDP (0x11)
Header checksum: 0x32fc [correct]
Source: 10.1.1.2 (10.1.1.2)
Destination: 127.0.0.1 (127.0.0.1)
Options: (4 bytes)
Router Alert: Every router examines packet
User Datagram Protocol, Src Port: lsp-ping (3503), Dst Port: lsp-ping (3503)
Multiprotocol Label Switching Echo
Si noti che il messaggio MPLS echo request viene inviato con etichetta MPLS = 24007, che è l’etichetta downstream per la FEC 192.168.0.21/32, inviata a PE1-1 dal Next-Hop P1.
La figura seguente riporta invece un esempio di applicazione base di un traceroute MPLS, senza utilizzare nel comando alcuna opzione. L’esempio fa riferimento allo stesso identico scenario della diapositiva precedente.
Anche qui, come per il ping MPLS, la prima differenza che salta agli occhi rispetto a un traceroute tradizionale è che il test non è verso un singolo indirizzo IP ma verso una intera rete IP, ossia verso una FEC (nell’esempio FEC = 192.168.0.21/32). Dal valore della FEC, PE1-1 deduce l’etichetta uscente, l’interfaccia di uscita e le informazioni di Livello 2 per il messaggio MPLS echo request.
Il risultato mostra che il LSP MPLS tra PE1-1 e PE2-1 è continuo, confermato dal «!» dell’ultima riga, che indica che la FEC sotto test è stata raggiunta correttamente. Il risultato inoltre, al pari del traceroute tradizionale per le reti IP/MPLS, consente di conoscere le etichette MPLS utilizzate sulle varie tratte del percorso. In particolare, per ciascuna riga viene riportata l’etichetta MPLS downstream. Ad esempio, sulla seconda riga l’etichetta MPLS riportata (= 24011) è quella annunciata a P1 attraverso un messaggio LDP LABEL MAPPING, dal suo Next-Hop verso la FEC 192.168.0.21/32, ossia il router P.
NOTA: il traceroute MPLS utilizza, come già detto, i messaggi MPLS echo request e MPLS echo reply. La logica di funzionamento è comunque simile a quella del traceroute tradizionale: dapprima viene inviato un messaggio MPLS echo request con TTL MPLS = 1 e quindi si attende la risposta, ossia il messaggio MPLS echo reply di ritorno; quindi la procedura si ripete aumentando ogni volta il TTL MPLS di una unità. La procedura termina, come per un ping MPLS, quando il messaggio MPLS echo request arriva al router PE di uscita (questa è la ragione per cui nell’ultima riga compare il simbolo «!», come nei ping MPLS).
Si noti che un traceroute classico, benché mostri le etichette MPLS segmento per segmento, non consente di rivelare un down della sessione LDP sull'ultimo segmento. Il perché è lasciato come esercizio (comunque l'ho detto sopra !).
CONCLUSIONI
La continuità dei LSP PE-PE è vitale per il funzionamento dei principali servizi MPLS. A volte si ha che il piano di controllo è perfettamente funzionante, ma il traffico non passa. Una delle possibili ragioni è la discontinuità dei LSP MPLS. Un'altra potrebbe essere una MTU MPLS insufficiente (vi ricordo che l'aggiunta di ogni etichetta MPLS fa aumentare la lunghezza del pacchetto MPLS di 4 byte). Due potenti strumenti che aiutano a risolvere queste problematiche sono i ping e traceroute MPLS, illustrati in questo post. In realtà queste tecniche sono già note da tempo, però sono stato stimolato a scrivere questo post dalla revisione della precedente RFC 4379, aggiornata e rielaborata sulla base dell'esperienza operativa, nella RFC 8029 citata sopra, e uscita pochi giorni prima che io scrivessi questo post. Un aspetto interessante, che tratterò in futuro post, è come proteggersi da eventuali down delle sessioni LDP, per evitare alla radice la discontinuità dei LSP MPLS PE-PE. Però devo confessarvi una cosa, si va facendo strada in me che l'utilizzo di LDP sia dubbio: i servizi MPLS, rinunciando a qualche funzionalità minore, possono essere realizzati facendo a meno sia di LDP che RSVP-TE, eliminando così un protocollo dalla rete (il che non guasta mai !). Ma qui c'è spazio per un post dedicato.
Se volete saperne di più su MPLS, da zero all'infinito, oppure avete bisogno di ulteriori approfondimenti, seguite i nostri molti corsi sull'argomento, tra cui vi segnalo:
Si noti che questi comandi possono essere utilizzati solo su router PE e P, ma non su router che non hanno alcuna interfaccia abilitata MPLS. La ragione è che il loro compito è verificare la connettività downstream verso una determinata FEC, e non verso un indirizzo IP. Possono inoltre essere utilizzate per verificare la continuità di LSP Hop-by-Hop, Explicitly Routed e Pseudowire.
La figura seguente riporta un esempio di applicazione base di un ping MPLS, senza utilizzare nel comando alcuna opzione.
La prima differenza che salta agli occhi rispetto a un ping tradizionale è che il test non è verso un singolo indirizzo IP ma verso una intera rete IP, ossia verso una FEC (nell’esempio FEC = 192.168.0.21/32). Dal valore della FEC, PE1-1 deduce l’etichetta uscente, l’interfaccia di uscita e le informazioni di Livello 2 per il messaggio MPLS echo request. Il risultato mostra che il LSP MPLS tra PE1-1 e PE2-1 è continuo (confermato dai «!», che indicano la corretta ricezione di messaggi MPLS echo reply).
Vi riporto di seguito, la cattura con Wireshark di un messaggio MPLS echo request:
Frame 6 (114 bytes on wire, 114 bytes captured)
Ethernet II, Src: ca:00:15:b8:00:08 (ca:00:15:b8:00:08), Dst: ca:01:15:b8:00:08 (ca:01:15:b8:00:08)
MultiProtocol Label Switching Header, Label: 24007, Exp: 0, S: 1, TTL: 255
Internet Protocol, Src: 10.1.1.2 (10.1.1.2), Dst: 127.0.0.1 (127.0.0.1)
Version: 4
Header length: 24 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 96
Identification: 0x2789 (10121)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 1
Protocol: UDP (0x11)
Header checksum: 0x32fc [correct]
Source: 10.1.1.2 (10.1.1.2)
Destination: 127.0.0.1 (127.0.0.1)
Options: (4 bytes)
Router Alert: Every router examines packet
User Datagram Protocol, Src Port: lsp-ping (3503), Dst Port: lsp-ping (3503)
Multiprotocol Label Switching Echo
Si noti che il messaggio MPLS echo request viene inviato con etichetta MPLS = 24007, che è l’etichetta downstream per la FEC 192.168.0.21/32, inviata a PE1-1 dal Next-Hop P1.
Anche qui, come per il ping MPLS, la prima differenza che salta agli occhi rispetto a un traceroute tradizionale è che il test non è verso un singolo indirizzo IP ma verso una intera rete IP, ossia verso una FEC (nell’esempio FEC = 192.168.0.21/32). Dal valore della FEC, PE1-1 deduce l’etichetta uscente, l’interfaccia di uscita e le informazioni di Livello 2 per il messaggio MPLS echo request.
Il risultato mostra che il LSP MPLS tra PE1-1 e PE2-1 è continuo, confermato dal «!» dell’ultima riga, che indica che la FEC sotto test è stata raggiunta correttamente. Il risultato inoltre, al pari del traceroute tradizionale per le reti IP/MPLS, consente di conoscere le etichette MPLS utilizzate sulle varie tratte del percorso. In particolare, per ciascuna riga viene riportata l’etichetta MPLS downstream. Ad esempio, sulla seconda riga l’etichetta MPLS riportata (= 24011) è quella annunciata a P1 attraverso un messaggio LDP LABEL MAPPING, dal suo Next-Hop verso la FEC 192.168.0.21/32, ossia il router P.
NOTA: il traceroute MPLS utilizza, come già detto, i messaggi MPLS echo request e MPLS echo reply. La logica di funzionamento è comunque simile a quella del traceroute tradizionale: dapprima viene inviato un messaggio MPLS echo request con TTL MPLS = 1 e quindi si attende la risposta, ossia il messaggio MPLS echo reply di ritorno; quindi la procedura si ripete aumentando ogni volta il TTL MPLS di una unità. La procedura termina, come per un ping MPLS, quando il messaggio MPLS echo request arriva al router PE di uscita (questa è la ragione per cui nell’ultima riga compare il simbolo «!», come nei ping MPLS).
ESEMPI (LSP INTERROTTO)
Con lo stesso scenario della sezione precedente, supponiamo che la sessione LDP tra P2 e PE2-1, per un qualche motivo vada nello stato down. Il risultato del ping MPLS rivela in questo caso una interruzione del LSP. L'interruzione si evince dal risultato del ping MPLS, che mostra una serie di «B», dove «B» (vedi legenda nella figura), indica "unlabeled output interface", ossia l'attraversamento di un'interfaccia che non ha però ricevuto un'etichetta MPLS dal Next-Hop, er la FEC in questione.
A titolo di esempio, riportiamo la cattura con Wireshark, di un messaggio MPLS echo reply:
Frame 7 (90 bytes on wire, 90 bytes captured)
Ethernet II, Src: ca:01:15:b8:00:08 (ca:01:15:b8:00:08), Dst: ca:00:15:b8:00:08 (ca:00:15:b8:00:08)
Internet Protocol, Src: 172.16.22.2 (172.16.22.2), Dst: 10.1.1.2 (10.1.1.2)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN: 0x00)
Total Length: 76
Identification: 0x5e06 (24070)
Flags: 0x00
Fragment offset: 0
Time to live: 253
Protocol: UDP (0x11)
Header checksum: 0x91c5 [correct]
Source: 172.16.22.2 (172.16.22.2)
Destination: 10.1.1.2 (10.1.1.2)
User Datagram Protocol, Src Port: lsp-ping (3503), Dst Port: lsp-ping (3503)
Source port: lsp-ping (3503)
Destination port: lsp-ping (3503)
Length: 56
Checksum: 0xd0e6 [validation disabled]
L’analisi del messaggio mostra che questo è stato generato dal LSR P2 (IP sorgente = 172.16.22.2). La ragione è che una volta che il messaggio MPLS echo request arriva a P2, questo non ha una etichetta MPLS downstream per inviarlo verso il Next-Hop, a causa dell’interruzione del LSP MPLS. Il LSR P2 analizza allora il pacchetto IP contenuto nel messaggio MPLS echo request, e sulla base delle informazioni contenute genera il messaggio MPLS echo reply. Il pacchetto IP contenuto nel messaggio MPLS echo request non può essere inoltrato al di fuori di P2 poiché il suo indirizzo IP destinazione è 127.0.0.1, che è parte del prefisso non-routable 127/8.
A titolo di esempio, riportiamo la cattura con Wireshark, di un messaggio MPLS echo reply:
Frame 7 (90 bytes on wire, 90 bytes captured)
Ethernet II, Src: ca:01:15:b8:00:08 (ca:01:15:b8:00:08), Dst: ca:00:15:b8:00:08 (ca:00:15:b8:00:08)
Internet Protocol, Src: 172.16.22.2 (172.16.22.2), Dst: 10.1.1.2 (10.1.1.2)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN: 0x00)
Total Length: 76
Identification: 0x5e06 (24070)
Flags: 0x00
Fragment offset: 0
Time to live: 253
Protocol: UDP (0x11)
Header checksum: 0x91c5 [correct]
Source: 172.16.22.2 (172.16.22.2)
Destination: 10.1.1.2 (10.1.1.2)
User Datagram Protocol, Src Port: lsp-ping (3503), Dst Port: lsp-ping (3503)
Source port: lsp-ping (3503)
Destination port: lsp-ping (3503)
Length: 56
Checksum: 0xd0e6 [validation disabled]
L’analisi del messaggio mostra che questo è stato generato dal LSR P2 (IP sorgente = 172.16.22.2). La ragione è che una volta che il messaggio MPLS echo request arriva a P2, questo non ha una etichetta MPLS downstream per inviarlo verso il Next-Hop, a causa dell’interruzione del LSP MPLS. Il LSR P2 analizza allora il pacchetto IP contenuto nel messaggio MPLS echo request, e sulla base delle informazioni contenute genera il messaggio MPLS echo reply. Il pacchetto IP contenuto nel messaggio MPLS echo request non può essere inoltrato al di fuori di P2 poiché il suo indirizzo IP destinazione è 127.0.0.1, che è parte del prefisso non-routable 127/8.
Il problema del ping MPLS è però che non aiuta a localizzare il problema, ma si limita solo a dire che c’è un problema. Con lo stesso scenario, vediamo come sia possibile la localizzazione del problema con un traceroute MPLS. Il risultato del traceroute MPLS è riportato nella figura seguente.
Dal risultato si vede che fino al LSR P2, il LSP MPLS è continuo. Il risultato prodotto dal traceroute MPLS fa infatti vedere tutte le etichette downstream, e l’ultima è proprio quella annunciata (via LDP) da P2 a P. Dal router P2 nel traceroute MPLS compare nella prima colonna il codice «B», che indica che l’interfaccia di uscita verso il Next-Hop non ha una etichetta MPLS disponibile per la FEC sotto test, e quindi vi è una interruzione del LSP MPLS. La stessa informazione è riportata anche alla fine della riga («No Label»).
NOTA: la localizzazione del punto di interruzione potrebbe anche essere effettuata manualmente, attraverso una sequenza di ping MPLS con TTL MPLS crescente (a partire da 1), utilizzando nei messaggi MPLS Echo Request il modulo TLV "downstream detailed mapping". Il TTL MPLS crescente consente di avere, tratta per tratta, l’etichetta downstream. Quando si ottiene come risultato un codice «B», significa che in quel punto il LSP è interrotto. Riportiamo di seguito, per motivi di spazio, solo il primo e ultimo ping MPLS. Si noti l’opzione "dsmap", che consente di aggiungere ai messaggi MPLS echo request il modulo TLV "downstream detailed mapping" e l’opzione "ttl ...", che consente di specificare il valore di TTL MPLS (l’opzione "repeat 1" consente di limitare a 1 il numero di messaggi MPLS echo request, e non a 5 come è il default).
RP/0/0/CPU0:PE1-1# ping mpls ipv4 192.168.0.21/32 dsmap ttl 1 repeat 1
. . . <output omesso> . . .
Type escape sequence to abort.
L Echo Reply received from 10.1.1.1
DSMAP 0, DS Router Addr 127.0.0.1, DS Intf Addr 0
Depth Limit 0, MRU 1500 [Labels: 24011 Exp: 0]
Multipath Addresses:
. . . <output omesso> . . .
RP/0/0/CPU0:PE1-1# ping mpls ipv4 192.168.0.21/32 dsmap ttl 3 repeat 1
. . . <output omesso> . . .
Type escape sequence to abort.
B Echo Reply received from 172.16.22.2
DSMAP 0, DS Router Addr 40.1.1.2, DS Intf Addr 40.1.1.2
Depth Limit 0, MRU 1504 [No Label]
Multipath Addresses:
. . . <output omesso> . . .
CONCLUSIONI
La continuità dei LSP PE-PE è vitale per il funzionamento dei principali servizi MPLS. A volte si ha che il piano di controllo è perfettamente funzionante, ma il traffico non passa. Una delle possibili ragioni è la discontinuità dei LSP MPLS. Un'altra potrebbe essere una MTU MPLS insufficiente (vi ricordo che l'aggiunta di ogni etichetta MPLS fa aumentare la lunghezza del pacchetto MPLS di 4 byte). Due potenti strumenti che aiutano a risolvere queste problematiche sono i ping e traceroute MPLS, illustrati in questo post. In realtà queste tecniche sono già note da tempo, però sono stato stimolato a scrivere questo post dalla revisione della precedente RFC 4379, aggiornata e rielaborata sulla base dell'esperienza operativa, nella RFC 8029 citata sopra, e uscita pochi giorni prima che io scrivessi questo post. Un aspetto interessante, che tratterò in futuro post, è come proteggersi da eventuali down delle sessioni LDP, per evitare alla radice la discontinuità dei LSP MPLS PE-PE. Però devo confessarvi una cosa, si va facendo strada in me che l'utilizzo di LDP sia dubbio: i servizi MPLS, rinunciando a qualche funzionalità minore, possono essere realizzati facendo a meno sia di LDP che RSVP-TE, eliminando così un protocollo dalla rete (il che non guasta mai !). Ma qui c'è spazio per un post dedicato.
Se volete saperne di più su MPLS, da zero all'infinito, oppure avete bisogno di ulteriori approfondimenti, seguite i nostri molti corsi sull'argomento, tra cui vi segnalo:
- IPN272: MPLS: dalla teoria alla Pratica
- IPN273: MPLS: aspetti avanzati
- IPN276: MPLS nell’IOS XR Cisco
- IPN258: MPLS nel JunOS Juniper
Nessun commento:
Posta un commento