6.3. Routing Locator Reachability (Raggiungibilità del Routing Locator)

6.3. Routing Locator Reachability (Raggiungibilità del Routing Locator)

Sono attualmente definiti diversi meccanismi per determinare la raggiungibilità di un Routing Locator (RLOC):

1. Un ETR può esaminare i Locator-Status-Bits nell'header LISP dei pacchetti dati incapsulati che riceve da un ITR. Se l'ETR funziona anche come ITR ed è necessario restituire il traffico al sito dell'ITR originale, può utilizzare queste informazioni di stato per aiutare nella selezione di un RLOC.

2. Un ITR può ricevere messaggi ICMP Network Unreachable o Host Unreachable per un RLOC che sta utilizzando. Questo indica che l'RLOC potrebbe essere diventato non raggiungibile. Si noti che affidarsi ai messaggi ICMP potrebbe non essere desiderabile, ma ignorarli completamente non è nemmeno desiderabile. Le implementazioni sono incoraggiate a seguire le migliori pratiche correnti nella gestione di queste situazioni.

3. Un ITR che partecipa al sistema di instradamento globale può determinare che un RLOC è non raggiungibile se non esiste una route nel BGP Routing Information Base (RIB) che corrisponda all'indirizzo IP RLOC.

4. Un ITR può ricevere un messaggio ICMP Port Unreachable dall'host di destinazione. Questo può accadere quando un ITR tenta di utilizzare i meccanismi di interworking [RFC6832] e i dati incapsulati LISP vengono inviati a un sito non abilitato LISP.

5. Un ITR può ricevere un Map-Reply da un ETR in risposta a un Map-Request precedentemente emesso. L'indirizzo RLOC di origine del Map-Reply è probabilmente up poiché l'ETR è stato in grado di inviare il Map-Reply all'ITR.

6. Quando un ETR riceve un pacchetto incapsulato da un ITR, l'RLOC di origine nell'header esterno del pacchetto è probabilmente up.

7. Una coppia ITR/ETR può utilizzare gli algoritmi di raggiungibilità del Locator descritti in questa sezione, ovvero Echo-Noncing o RLOC-Probing.

Quando si determina la raggiungibilità up/down del Locator esaminando i Locator-Status-Bits dai pacchetti dati incapsulati LISP, un ETR riceverà dallo ITR incapsulante lo stato aggiornato sulla raggiungibilità di tutti gli ETR in quel sito. Gli ITR basati su CE nel sito di origine possono determinare la raggiungibilità reciproca tramite l'IGP del sito come segue:

o In circostanze normali, ciascun ITR pubblicizzerà una route predefinita nell'IGP del sito.

o Se un ITR fallisce o il suo uplink al PE fallisce, la sua route predefinita scadrà o verrà ritirata.

Pertanto, ogni ITR può rilevare se un altro ITR sta ancora pubblicizzando una route predefinita e impostare i Locator-Status-Bits di conseguenza.

Gli RLOC elencati in un Map-Reply sono numerati con ordinali da 0 a n-1. I Locator-Status-Bits in un pacchetto incapsulato LISP sono numerati da 0 a n-1 partendo dal bit meno significativo. Ad esempio, se l'RLOC nella terza posizione del Map-Reply è down (l'ordinale è 2), tutti gli ITR nel sito cancellerebbero il terzo bit meno significativo (xxx x0xx) del campo Locator-Status-Bits che impostano per i pacchetti incapsulati.

Quando un ETR disincapsula un pacchetto, esamina il campo Locator-Status-Bits per rilevare eventuali modifiche. Quando un bit passa da 1 a 0, se l'ETR funziona anche come ITR, smette di incapsulare i pacchetti verso un RLOC contrassegnato come down. Riprenderà l'utilizzo di quel RLOC solo quando il Locator-Status-Bit corrispondente torna a 1. I Locator-Status-Bits sono associati al Locator-Set per ciascun EID-Prefix. Pertanto, quando un Locator diventa irraggiungibile, il Locator-Status-Bit corrispondente alla posizione del Locator nell'elenco restituito dall'ultimo Map-Reply viene azzerato per quell'EID-Prefix.

Quando gli ITR all'interno di un sito non sono distribuiti su router CE, può comunque essere utilizzato l'IGP per determinare la raggiungibilità dei Locator a condizione che i Locator siano inseriti nell'IGP. Questo è tipicamente il caso quando gli indirizzi /32 sono configurati sulle interfacce loopback.

Quando un ITR utilizza messaggi ICMP Network Unreachable o Host Unreachable come mezzo per determinare l'irraggiungibilità, smette di utilizzare i Locator descritti nell'elenco dei Locator del Map-Reply. Tuttavia, questo metodo è inaffidabile perché molti operatori di rete disattivano la generazione di ICMP Destination Unreachable.

Se un ITR riceve effettivamente un messaggio ICMP Network Unreachable o Host Unreachable, può generare autonomamente un messaggio ICMP Destination Unreachable per l'host che ha originato il pacchetto dati incapsulato dall'ITR.

Inoltre, un ITR abilitato BGP può esaminare unilateralmente il RIB per determinare se gli indirizzi locator del Locator-Set nella voce di mappatura corrispondono a un prefisso. Se non viene trovato e BGP viene eseguito nella Default-Free Zone (DFZ), può decidere di non utilizzare quel Locator anche se i Locator-Status-Bits indicano che il Locator è up. In questo caso, il percorso dall'ITR verso l'ETR al quale è assegnato il Locator non è disponibile. Vedere [LOC-ID-ARCH] per ulteriori dettagli.

Facoltativamente, un ITR può inviare un Map-Request a un Locator e, se viene restituito un Map-Reply, ha determinato che il Locator è raggiungibile. Ovviamente, l'invio di tali probe aumenta il numero di messaggi di controllo prodotti dai tunnel router per i flussi attivi, quindi si presume che i Locator pubblicizzati siano raggiungibili.

Questa ipotesi crea una dipendenza: l'irraggiungibilità del Locator viene rilevata tramite la ricezione di messaggi ICMP Host Unreachable. Quando un Locator è determinato come irraggiungibile, non viene più utilizzato per il traffico attivo, equivalente all'elenco di quel Locator in un Map-Reply con Priority 255.

Un ITR può testare la raggiungibilità di un Locator irraggiungibile inviando periodicamente una Request. Sia le Request che le Reply DEVONO essere limitate in frequenza. Il test di raggiungibilità del Locator non viene mai eseguito utilizzando pacchetti dati, poiché ciò aumenterebbe il rischio di perdita di pacchetti per le sessioni end-to-end.

Quando un ETR disincapsula un pacchetto, sa che è raggiungibile dall'ITR incapsulante poiché il pacchetto lo ha raggiunto seguendo quel percorso. Nella maggior parte dei casi l'ETR può raggiungere anche l'ITR, ma non si può presumere che sia sempre vero poiché i percorsi possono essere asimmetrici. Quando esiste traffico unidirezionale dall'ITR all'ETR, l'ITR NON DOVREBBE interpretare la mancanza di traffico di ritorno come un'indicazione che l'ETR sia irraggiungibile. Devono invece essere utilizzati altri meccanismi per determinare la raggiungibilità.