Traccia route nella rete MPLS
Sommario
Introduzione
In questo documento viene descritto il comportamento traceroute del protocollo ICMP (Internet Control Message Protocol) nella rete MPLS (Multiprotocol Label Switching) e viene eseguito un rapido confronto con la traccia LSP.
Premesse
In ambiente IP, qualsiasi nodo che riceve un pacchetto e se il valore TTL (Time To Live) scade, genera un messaggio di errore ICMP "TTL Exceeded" (Tipo=11, Codice=0) e lo invia all'indirizzo di origine del pacchetto. Questo concetto viene usato per tracciare il percorso IP da origine a destinazione inviando un pacchetto UDP con TTL in sequenza a partire da 1. Si potrebbe notare che i requisiti di base per questa funzionalità sono:
- L'indirizzo di origine del pacchetto è raggiungibile dai nodi di transito
- ICMP non filtrato sul percorso
In ambiente MPLS, un LSR del provider di transito potrebbe non essere sempre raggiungibile all'indirizzo di origine e richiedere alcuni miglioramenti per la gestione di ICMP nel dominio MPLS.
Traceroute ICMP nella rete MPLS
Il comportamento predefinito di un LSR alla ricezione di un pacchetto con TTL=1 sull'etichetta superiore è quello tradizionale dell'IP di eliminare il pacchetto e attivare il messaggio di errore ICMP. Per instradare il messaggio ICMP all'origine, l'LSR eseguirà questa operazione:
- Memorizza nel buffer lo stack di etichette del pacchetto in arrivo (il pacchetto ricevuto con TTL=1)
- Genera messaggio di errore ICMP con origine come proprio indirizzo e destinazione come indirizzo di origine dal pacchetto ricevuto.
- Accodare tutte le etichette dalla parte inferiore della pila di etichette (memorizzata nel buffer in precedenza al passaggio 1) con TTL=255 ad eccezione della prima.
- Ottenere l'etichetta superiore dallo stack di etichette nel buffer ed eseguire una ricerca LFIB locale per ottenere l'etichetta da scambiare e l'hop successivo associato.
- Aggiungete la nuova etichetta all'inizio dello stack con TTL=255 e inviatela.
Con questo approccio, il messaggio di errore ICMP passa da un LSR di transito a un LER di uscita e quindi di nuovo a UN LER di entrata e all'origine effettiva.
Traccia ICMP attivata da PE a PE remoto
Di seguito è riportato un semplice esempio che spiega il comportamento quando la traccia ICMP viene attivata da PE a PE remoto all'interno dello stesso dominio MPLS:
In questa topologia, quando il traceroute ICMP viene attivato da R2 a 10.1.4.4, il primo pacchetto viene inviato con un valore TTL di 1. R3 alla ricezione del pacchetto diminuisce il valore TTL a 0 e attiva il meccanismo di generazione dell'ICMP.
R3 inserirà nello stack di etichette, genererà un messaggio di errore ICMP e includerà lo stack di etichette in arrivo dal buffer nel payload ICMP. L'intestazione IP viene inoltre popolata con l'indirizzo di origine dell'interfaccia in entrata del pacchetto etichettato, mentre l'indirizzo di destinazione rappresenta l'origine del pacchetto etichettato. Il valore TTL è impostato su 255. Spinge quindi lo stack di etichette dal buffer e consulta la tabella LFIB per l'azione di inoltro sull'etichetta superiore. In questa topologia, lo stack di etichette ricevute è 17. Quando si esegue una ricerca nella tabella LFIB, l'etichetta 17 viene scambiata con l'etichetta 16 e inoltrata verso la R6 successiva. R6 a sua volta visualizza l'etichetta superiore e inoltra alla R4 che inoltra il pacchetto IP verso R2.
Come è possibile notare nell'output del comando traceroute su R2, l'etichetta in arrivo verrà elencata da ciascun hop sul percorso.
Traccia ICMP attivata da CE a CE remoto
Di seguito è riportato un semplice esempio che spiega il comportamento quando la traccia ICMP viene attivata da CE a CE remoto su un dominio MPLS:
In questa topologia, quando il traceroute ICMP viene attivato da R1 (CE) a 192.168.5.5 (CE remoto), il primo pacchetto viene inviato con un valore TTL pari a 1. Si tratta di un pacchetto IP normale, quindi R2 segue il comportamento tradizionale della generazione di pacchetti ICMP e dell'invio diretto a R1. Il secondo pacchetto inviato con TTL=2 scadrà alle R3.
R3 inserirà nello stack di etichette, genererà un messaggio di errore ICMP e includerà lo stack di etichette in arrivo dal buffer nel payload ICMP. L'intestazione IP viene inoltre popolata con l'indirizzo di origine dell'interfaccia in entrata del pacchetto etichettato, mentre l'indirizzo di destinazione rappresenta l'origine del pacchetto etichettato. Il valore TTL è impostato su 255. Spinge quindi lo stack di etichette dal buffer e consulta la tabella LFIB per l'azione di inoltro sull'etichetta superiore. Nella topologia precedente, lo stack di etichette ricevute è {17, 18}. Quando si esegue una ricerca nella tabella LFIB per l'etichetta superiore, 17 verrà scambiato con l'etichetta 16 e verrà inoltrato verso la successiva R6. R6 a sua volta aprirà l'etichetta superiore e inoltrerà a R4. R4 utilizzerà l'etichetta VRF per identificare il VRF e inoltrare il pacchetto verso R1.
Come è possibile notare nell'output di traceroute su R1, lo stack di etichette in arrivo viene elencato da ciascun hop sul percorso.
Traceroute MPLS LSP in rete MPLS
A differenza del traceroute basato su ICMP, il traceroute LSP utilizza il meccanismo definito nella RFC4379. Usa l'incapsulamento IP/UDP con l'indirizzo di destinazione della richiesta impostato sull'indirizzo di loopback (intervallo 127.0.0.0/8). Si prevede che il ping LSP venga attivato nello stesso dominio MPLS, quindi la risposta verrà inviata direttamente all'iniziatore.
Quando il traceroute LSP ("traceroute mpls ipv4 <FEC>") viene attivato da un LSR, i dettagli sulla FEC da convalidare vengono inclusi in un TLV come "Stack FEC di destinazione" nella richiesta echo MPLS. Questo messaggio verrà inviato con TTL sullo stack di etichette in sequenza a partire da 1. Tutti gli LSR di transito che ricevono il pacchetto e se il TTL scade elaboreranno il pacchetto IP, poiché l'indirizzo di destinazione è l'indirizzo di loopback. e punt alla CPU per l'elaborazione OAM MPLS.
Facoltativamente, il risponditore eseguirà la convalida FEC recuperando le etichette dallo stack di etichette della richiesta echo MPLS ricevuta e i dettagli FEC dal TLV dello stack FEC di destinazione per convalidare la stessa operazione in base alle informazioni del control plane locale. In caso di traccia, il risponditore includerà le informazioni a valle, ad esempio l'etichetta In uscita e l'indirizzo del router adiacente a valle, in un TLV come TLV di Mapping a valle (DSMAP). DSMAP sarà deprecato da DMAP poiché è più flessibile di DSMAP.
Traccia LSP attivata da PE a PE remoto
In questa topologia, la traccia LSP viene attivata da R2 per convalidare l'LSP al prefisso 10.1.4.4/32. Il valore TTL sull'etichetta verrà impostato da 1. R3 alla ricezione verrà impostato sulla CPU per l'elaborazione OAM.
R3 risponderà a R2 con MPLS Echo Reply con DSMAP TLV contenente l'etichetta in uscita 16 e ulteriori informazioni come i dettagli dei vicini a valle. A differenza dei messaggi ICMP, MPLS Echo Reply verrà inoltrato direttamente dal responder R3 all'Initiator R2.
Come è possibile notare nell'output del comando traceroute LSP su R2, lo stack di etichette in uscita verrà elencato da ciascun hop sul percorso. Questo comportamento è diverso dal traceroute basato su ICMP, in cui l'etichetta elencata nell'output sarà lo stack di etichette in arrivo.
Traccia LSP attivata da CE a CE remoto
Ciò è applicabile in scenari simili a quelli CSC in cui MPLS è abilitato tra PE-CE. L'esecuzione della traccia LSP da CE a CE remoto su un dominio MPLS vettore presenta due problematiche:
- LSP Echo Reply verrà inviato direttamente all'iniziatore. Quindi il responder DEVE avere la raggiungibilità a Iniziatore. Nella topologia precedente, R3 potrebbe non essere raggiungibile da R1 come nel VRF.
- Per ciascuna etichetta nello stack di etichette, includere i dettagli FEC rilevanti nello stack FEC di destinazione per la convalida. La FEC inclusa da Initiator sarà 1, mentre PE spingerà 2 etichette. Nella topologia precedente, R1 invia una richiesta echo MPLS con FEC={192.168.5.5/32} e include l'etichetta 28 nello stack. Poiché R2 scambia l'etichetta 28 con {17, 27}, R3 riceverà la richiesta con 2 etichette nello stack mentre 1 FEC in TLV confonde la convalida FEC.
La RFC 6424 definisce il concetto di "FEC Stack change TLV" per risolvere la questione 2. Questo TLV verrà incluso in risposta alla FEC pertinente come PUSH/POP che può essere incluso dall'iniziatore nella successiva richiesta echo.
draft-ietf-mpls-lsp-ping-relay-reply definisce il concetto di trasporto dello stack di indirizzi dei nodi di relè in TLV che può essere utilizzato dal risponditore per inoltrare la risposta anche se non ha raggiungibilità verso l'iniziatore.
Questi 2 problemi non sono attualmente supportati in Cisco IOS®, quindi la traccia LSP da CE a CE remoto elencherà solo il PE in entrata e il CE remoto. Questo è incluso solo per completezza.
Informazioni correlate
Feedback