DMVPN fase 3: leggere la scorciatoia in entrambe le direzioni
Un solo ping diretto non dimostra una scorciatoia DMVPN fase 3. Percorri il percorso di andata e quello di ritorno, poi leggi separatamente lo stato NHRP, di routing e IPsec.
Osservi un ping andare da spoke a spoke, prende la strada lunga attraverso l'hub, e il secondo va diretto. È tentatore dichiarare la scorciatoia funzionante in quel momento. Quella conclusione è mezza giusta. Il percorso di andata può essere una scorciatoia mentre quello di ritorno passa ancora dall'hub, e lo stato che dimostra ciascuna direzione è uno stato diverso. Percorri entrambe le direzioni e leggi tre tabelle prima di accettare il progetto come sano.
Inizia dal percorso del pacchetto che riesci davvero a vedere
Parti da uno spoke con una destinazione che dovrebbe essere diretta. Traccia il primo pacchetto: segue la rotta dello spoke verso l'hub, perché non esiste ancora alcuna scorciatoia. L'hub lo inoltra e, in un progetto fase 3, invia anche un reindirizzamento all'origine dicendo che esiste un percorso migliore.
Quel reindirizzamento è il grilletto, non la prova. Dice che l'hub ha visto traffico che potrebbe essere ottimizzato. Non dice che l'origine ha costruito la scorciatoia, che la destinazione ha risposto alla risoluzione, né che il percorso di ritorno la usi.
Quindi la prima osservazione utile è un prima e dopo: il primo flusso attraverso l'hub, il flusso successivo diretto.
Tre stati che sembrano un solo tunnel
La scorciatoia dipende da tre pezzi di stato, e ciascuno ha la propria durata e il proprio comando.
| State | What it answers | Where to read it |
|---|---|---|
| NHRP cache | Which transport address maps to this overlay address | show ip nhrp |
| Route or shortcut | Where one specific inner prefix is forwarded | show ip route 10.10.20.5 |
| IPsec association | Which peer traffic is protected, and by which SA | show crypto ipsec sa peer 203.0.113.5 |
Una voce della cache NHRP mappa un indirizzo overlay su un indirizzo di trasporto NBMA. Una rotta o una scorciatoia decide dove viene inoltrata una destinazione interna. Un'associazione IPsec protegge il traffico che ne risulta. Una risposta mancante può venire da uno qualsiasi dei tre, e i comandi ti dicono quale manca.
Leggile in quell'ordine, perché una mappatura mancante rende le altre due poco interessanti.
Percorri la richiesta e la risposta separatamente
Dallo spoke A, chiedi la risoluzione e osserva cosa torna. La richiesta passa per il percorso di inoltro NHRP supportato, e la destinazione può rispondere direttamente invece che tramite l'hub. Questa asimmetria è normale, ed è per questo che la risposta è la metà interessante dello scambio.
Ora inverti i ruoli. Invia da B ad A e ripeti le stesse tre letture. Un progetto che scorcia una direzione e non l'altra non è simmetrico, e l'asimmetria di solito deriva da un prefisso mancante su un lato o da una risoluzione che non ha mai ricevuto risposta.
La risposta del peer non deve attraversare l'hub solo perché la richiesta l'ha fatto. Non leggerlo come un errore e non iniziare a inseguire un guasto di routing che non esiste.
Leggi il reindirizzamento dell'hub, non solo la sua rotta
La tabella delle rotte dell'hub ti dice dove l'hub invierebbe un pacchetto. Il reindirizzamento ti dice cosa l'hub ha chiesto all'origine di fare al riguardo. Sono fatti diversi, e un hub con la rotta corretta e senza reindirizzamenti manterrà ogni flusso sul percorso lungo all'infinito. Controlla gli eventi NHRP dell'hub e conferma che vengano generati reindirizzamenti per il traffico che ti interessa.
La fase 3 cambia anche cosa significa summarizzazione. Con il comportamento di scorciatoia, gli spoke non hanno bisogno dell'intero insieme di rotte remote specifiche che un progetto fase 2 si aspettava, quindi una rotta riassunta sullo spoke non è automaticamente una rete mancante. Conferma la fase e la politica di routing prima di leggere un riepilogo come guasto.
Quel singolo malinteso causa più ticket DMVPN di qualsiasi altra cosa.
Registra la conclusione come un oggetto mancante
Termina con un flusso applicativo autorizzato e la sua risposta, e annota per ciascuna direzione se ha usato il percorso diretto. Poi scrivi la conclusione come l'oggetto che mancava: una mappatura, una scorciatoia di inoltro, un'associazione di protezione o una risposta applicativa.
Un'adiacenza di routing e un'associazione di sicurezza condivisa sono prove di salute, non prove del percorso. Entrambe possono essere perfette mentre ogni pacchetto fa ancora il giro lungo. Controlla prima la decisione di inoltro, poi l'associazione che la trasporta. L'ordine conta, perché l'associazione si forma comunque.
Quell'abitudine ripaga al ticket successivo. «Il tunnel è su ma lento» diventa «B non ha una scorciatoia per l'host di A», e la seconda affermazione è una correzione di cinque minuti. Tieni l'output dei comandi con la conclusione, e tieni la guida fase 3 del fornitore accanto.