Commutació per error de WAN a DMVPN: política de ruta o tancar el túnel?

Un concentrador DMVPN amb doble WAN commuta per error d'una de dues maneres, i la diferència és més gran del que sembla. Una canvia quin següent salt tria una política de ruta, de manera que els paquets continuen circulant i només canvia la seva sortida. L'altra tanca el túnel administrativament, cosa que fa caure amb ell tots els serveis d'aquella interfície. Totes dues poden ser correctes, perquè responen a preguntes diferents.

La decisió arriba abans de la configuració

Tres condicions decideixen això per vosaltres. Depèn alguna cosa més que la interfície del túnel estigui activa, com ara un segon perfil DMVPN o un monitor que llegeixi el seu estat? El trànsit que ha de commutar porta la seva pròpia política, o depèn de la taula d'encaminament global? I l'operador necessita un canvi d'estat inequívoc, o és acceptable un canvi de camí silenciós? Responeu aquestes tres i l'elecció normalment es fa sola.

Si un tancament fes caure serveis que funcionaven, la política de ruta és l'acció més petita. Si el requisit és que el túnel no existeixi mentre la WAN primària està caiguda, cap entrada de política ho pot expressar.

Escriviu la resposta, perquè la configuració és la part fàcil.

Què canvia realment la política de ruta

Amb l'encaminament basat en polítiques, un objecte seguit pot controlar un següent salt. L'entrada del mapa de rutes nomena un següent salt candidat i l'objecte seguit que ha d'estar actiu perquè s'utilitzi, i aquest estat de seguiment prové d'una sonda IP SLA. Quan l'objecte cau, l'entrada deixa de coincidir i el paquet s'avalua per l'entrada següent o per la taula d'encaminament ordinària.

Aquest últim detall sorprèn la gent: una política que deixa de triar un següent salt normalment permet l'encaminament normal en lloc de bloquejar el trànsit. Si necessiteu un forat negre en cas de fallada, l'heu d'escriure.

La sintaxi difereix entre plataformes i versions, així que consulteu la guia de la versió que feu servir realment.

Què canvia tancar el túnel

Tancar una interfície canvia l'estat administratiu. Cada túnel, ruta i sessió que en depèn cau alhora, que és exactament el que voleu si el túnel és el que ha de desaparèixer. També és així com un applet EEM converteix un problema de WAN en una caiguda que inclou serveis no relacionats.

Si aneu per aquest camí, limiteu l'applet a una interfície i un disparador, deseu l'estat administratiu anterior, definiu l'acció de recuperació i assegureu-vos que les oscil·lacions repetides no el puguin portar a un bucle.

Una ordre de recuperació codificada també pot anul·lar un tancament de manteniment fet per algú altre.

Feu que la sonda viatgi pel camí que penseu

Una sonda que segueix la millor ruta actual es mou a la WAN de reserva amb tota la resta, i després informa que la primària està sana perquè ja no la utilitza.

Fixeu la sonda a la interfície o a l'adreça d'origen del camí que proveu. Comproveu també a què apunta, ja que arribar al següent salt del proveïdor demostra menys que arribar al servei pel qual existeix el túnel. Establiu els retards de pujada i baixada deliberadament: un retard de baixada curt reacciona ràpid i oscil·la, mentre que un de llarg aguanta els espasmes i amaga les fallades reals. La guia de Cisco sobre seguiment i encaminament per polítiques a IOS XE documenta les combinacions admeses, i el conjunt de funcions de la vostra plataforma decideix quines podeu utilitzar.

Anoteu tots dos valors de retard al costat de l'objecte seguit, o ningú no sabrà per què es va comportar així.

Decidiu la restauració i després verifiqueu

La restauració mereix una decisió pròpia. Un enllaç que travessa el llindar contínuament pot moure sessions més sovint que un que ha fallat clarament, i cada moviment costa renegociar claus i reintents de l'aplicació. Trieu un requisit d'estabilitat i deixeu que el retard l'expressi. Després verifiqueu durant una finestra de canvi amb el camí de la sonda visible: ruta seleccionada, camí del par exterior i què va fer realment l'aplicació.

Si la commutació funciona però l'aplicació encara es trenca, el problema és per sobre de la capa d'encaminament i cap quantitat de seguiment no el corregirà.

Conserveu les proves d'aquella finestra, perquè el proper canvi es compararà amb elles.