Riepilogo delle rotte DMVPN vs mappa di riepilogo NHRP: tabelle diverse
Un riepilogo delle rotte cambia il prefisso annunciato e il next hop. Una mappa di riepilogo NHRP cambia ciò che restituisce una risposta di risoluzione. Stessa parola, tabella diversa.
Qualcuno ti chiede di riepilogare gli spoke e il ticket si chiude con meno prefissi sull’hub. Una settimana dopo il traffico tra filiali che prima passava diretto torna a passare dall’hub, e nessuno collega i due cambiamenti. L’espressione riepilogare gli spoke copre due operazioni diverse che toccano due tabelle diverse. Nomina quale stato stai riducendo prima di prendere in prestito un comando da un altro esempio DMVPN.
Il sintomo: il traffico diretto tra spoke è tornato sull’hub
La distinzione conta soprattutto quando una discussione su Phase 2 viene applicata a un progetto Phase 3. Le stesse parole compaiono in entrambe le conversazioni, e l’effetto sull’inoltro non è lo stesso.
È anche per questo che la modifica sembrava corretta in fase di revisione: la revisione ha controllato la tabella di routing, che è solo uno dei tre stati coinvolti.
Un’aggregazione, due tabelle
Le due operazioni sono queste:
| Operation | What it actually changes |
|---|---|
| Routing summary | Aggregates the prefixes the routing protocol advertises and changes the next hop the receiver installs |
| NHRP summary map | Changes the network returned in a resolution reply, so a requesting spoke resolves to a different address |
| Protection path | IPsec state for the peer you actually resolved; neither aggregation changes it |
Un riepilogo delle rotte è un’affermazione su ciò che l’hub annuncia e su ciò che lo spoke ricevente installa come rotta. Una mappa di riepilogo NHRP è un’affermazione sulla risposta che uno spoke invia quando un altro spoke chiede come raggiungere un indirizzo. Sono domande diverse con modalità di guasto diverse, e un progetto può cambiarne una lasciando l’altra esattamente com’era. Trattarle come un’unica leva è il modo in cui un cambio di aggregazione diventa silenziosamente un cambio di inoltro.
Nessuna delle due operazioni è un’affermazione su il percorso di protezione, perché questo viene negoziato per il peer che hai effettivamente risolto.
Cosa cambia davvero il riepilogo sull’hub
La guida Cisco sulle mappe di riepilogo NHRP tra spoke descrive un assetto Phase 3 in cui l’hub annuncia un riepilogo e resta il next hop del routing. Un redirect e una successiva risoluzione NHRP forniscono poi un percorso di inoltro più diretto. Leggere solo la rotta aggregata quindi non descrive tutto lo stato di inoltro, e non significa che ogni pacchetto debba attraversare l’hub per sempre. Il riepilogo riguarda la raggiungibilità, non il percorso.
Per questo una revisione di progetto che si ferma alla tabella di routing può approvare una modifica che altera il comportamento di risoluzione. Ispeziona la rotta selezionata, il risultato NHRP e il percorso di protezione come tre osservazioni separate.
Se non sai dire quale dei tre è cambiato, non hai finito la modifica.
Cosa cambia la mappa di riepilogo NHRP
Prendi uno spoke che possiede 10.32.0.0/19 tramite diverse rotte LAN più specifiche, mentre l’hub annuncia un’aggregazione più ampia agli altri spoke. Una richiesta per 10.32.12.10 riceverebbe altrimenti informazioni di risoluzione per la rete più piccola corrispondente. La funzione documentata della mappa di riepilogo NHRP consente allo spoke di restituire invece il proprio prefisso di copertura configurato, il che può ridurre il lavoro di risoluzione ripetuto per le reti che appartengono a quello spoke. Non rende il riepilogo delle rotte dell’hub e il riepilogo di risoluzione dello spoke lo stesso oggetto.
Dai a quel prefisso di copertura un modello di proprietà deliberato. Una risposta ampia che include indirizzi che appartengono altrove, o lacune non raggiungibili, può inviare il traffico successivo verso un peer inadeguato.
Controlla le rotte reali e i casi negati previsti prima di ampliare il prefisso, non dopo.
Confronta la prima destinazione e una dentro il riepilogo
Scegli due destinazioni: la prima che hai testato e un’altra che si trova dentro il riepilogo proposto. Per ciascuna, registra la rotta selezionata, lo stato NHRP usato per raggiungerla e il percorso di risposta reale. Quel confronto ti dice se hai cambiato la scala di routing, la scala di risoluzione o un errore di inoltro, ed è l’unica conclusione utile. Un display con meno prefissi non è prova di nessuna di queste cose.
Conferma la fase distribuita e il comportamento di next hop del protocollo di routing prima di applicare un esempio Phase 3 alla tua rete. Un esempio breve non dimostra che un altro progetto conservi lo stesso percorso diretto tra spoke.
Il ticket deve dire quale tabella hai ridotto e quale hai lasciato stare. Qualcosa di meno verrà diagnosticato da zero tra un mese.