Failover WAN in DMVPN: politica di routing o chiusura del tunnel?

Un hub DMVPN con doppio WAN esegue il failover in uno di due modi, e la differenza è più grande di quanto sembri. Uno cambia quale next hop seleziona una politica di routing, così i pacchetti continuano a fluire e cambia solo la loro uscita. L'altro chiude amministrativamente il tunnel, portando giù con sé ogni servizio su quell'interfaccia. Entrambi possono essere corretti, perché rispondono a domande diverse.

La decisione viene prima della configurazione

Tre condizioni lo decidono per voi. Dipende qualcos'altro dal fatto che l'interfaccia del tunnel sia attiva, come un secondo profilo DMVPN o un monitor che ne legge lo stato? Il traffico che deve eseguire il failover porta una propria politica, o si affida alla tabella di routing globale? E l'operatore ha bisogno di un cambio di stato inequivocabile, o è accettabile un cambio di percorso silenzioso? Rispondete a queste tre e la scelta di solito si fa da sola.

Se una chiusura portasse giù servizi che funzionavano, la politica di routing è l'azione più piccola. Se il requisito è che il tunnel non esista mentre il WAN primario è giù, nessuna voce di politica può esprimerlo.

Scrivete la risposta, perché la configurazione è la parte facile.

Cosa cambia davvero la politica di routing

Con il routing basato su politiche, un oggetto tracciato può controllare un next hop. La voce della route-map nomina un next hop candidato e l'oggetto tracciato che deve essere attivo perché venga usato, e quello stato di tracciamento proviene da una sonda IP SLA. Quando l'oggetto cade, la voce smette di corrispondere e il pacchetto viene valutato dalla voce successiva o dalla tabella di routing ordinaria.

Quest'ultimo dettaglio sorprende: una politica che smette di scegliere un next hop di solito permette il routing normale invece di bloccare il traffico. Se avete bisogno di un buco nero in caso di guasto, dovete scriverlo voi.

La sintassi varia tra piattaforme e release, quindi consultate la guida per la versione che eseguite davvero.

Cosa cambia chiudere il tunnel

Chiudere un'interfaccia cambia lo stato amministrativo. Ogni tunnel, route e sessione che ne dipende cade insieme, che è esattamente ciò che volete se il tunnel è la cosa che deve sparire. È anche così che un applet EEM trasforma un problema WAN in un'interruzione che include servizi non correlati.

Se scegliete questa strada, limitate l'applet a un'interfaccia e a un trigger, salvate lo stato amministrativo precedente, definite l'azione di ripristino e assicuratevi che flap ripetuti non possano spingerlo in un loop.

Un comando di ripristino codificato può anche sovrascrivere una chiusura per manutenzione eseguita da qualcun altro.

Fate viaggiare la sonda sul percorso che pensate

Una sonda che segue la migliore rotta attuale si sposta sul WAN di backup insieme a tutto il resto, poi dichiara il primario sano perché non lo usa più.

Fissate la sonda all'interfaccia o all'indirizzo sorgente del percorso che state testando. Controllate anche cosa punta, perché raggiungere il next hop del provider dimostra meno che raggiungere il servizio per cui esiste il tunnel. Impostate i ritardi di salita e discesa di proposito: un ritardo di discesa breve reagisce in fretta e oscilla, mentre uno lungo assorbe i micro-cali e nasconde i guasti reali. La guida Cisco su tracciamento e routing basato su politiche in IOS XE documenta le combinazioni supportate, e il set di funzionalità della vostra piattaforma decide quali potete usare.

Annotate entrambi i valori di ritardo accanto all'oggetto tracciato, altrimenti nessuno saprà perché si è comportato così.

Decidete il ripristino, poi verificate

Il ripristino merita una decisione propria. Un collegamento che supera continuamente la soglia può spostare sessioni più spesso di uno chiaramente guasto, e ogni spostamento costa una nuova negoziazione delle chiavi e nuovi tentativi dell'applicazione. Scegliete un requisito di stabilità e lasciate che il ritardo lo esprima. Poi verificate durante una finestra di cambiamento con il percorso della sonda visibile: rotta selezionata, percorso del peer esterno e cosa ha fatto davvero l'applicazione.

Se il failover funziona ma l'applicazione si rompe ancora, il problema sta sopra il livello di routing e nessun tracciamento lo risolverà.

Conservate le prove di quella finestra, perché il prossimo cambiamento sarà confrontato con esse.