Conmutación por erro de WAN en DMVPN: política de ruta ou pechar o túnel?
A conmutación por erro significa dúas cousas distintas: unha política que deixa de escoller un seguinte salto, ou un túnel que cae administrativamente. Escolla segundo do que dependa.
Un concentrador DMVPN con dobre WAN conmuta por erro dunha de dúas maneiras, e a diferenza é maior do que parece. Unha cambia que seguinte salto escolle unha política de ruta, de xeito que os paquetes seguen fluíndo e só cambia a súa saída. A outra apaga o túnel administrativamente, o que derruba con el todos os servizos desa interface. Ambas poden ser correctas, porque responden a preguntas distintas.
A decisión chega antes da configuración
Tres condicións deciden iso por vostede. Depende algo máis de que a interface do túnel estea activa, como un segundo perfil DMVPN ou un monitor que lea o seu estado? O tráfico que debe conmutar leva a súa propia política, ou depende da táboa de enrutamento global? E o operador necesita un cambio de estado inequívoco, ou é aceptable un cambio de ruta silencioso? Responda esas tres e a elección adoita facerse soa.
Se un apagado derrubase servizos que funcionaban, a política de ruta é a acción máis pequena. Se o requisito é que o túnel non exista mentres a WAN principal está caída, ningunha entrada de política pode expresalo.
Escriba a resposta, porque a configuración é a parte fácil.
Que cambia realmente a política de ruta
Co enrutamento baseado en políticas, un obxecto seguido pode controlar un seguinte salto. A entrada do mapa de rutas nomea un seguinte salto candidato e o obxecto seguido que debe estar activo para usalo, e ese estado de seguimento vén dunha sonda IP SLA. Cando o obxecto cae, a entrada deixa de coincidir e o paquete avalíase pola seguinte entrada ou pola táboa de enrutamento ordinaria.
Ese último detalle sorprende á xente: unha política que deixa de escoller un seguinte salto adoita permitir o enrutamento normal en vez de bloquear o tráfico. Se necesita un burato negro en caso de fallo, ten que escribir un.
A sintaxe difire entre plataformas e versións, así que consulte a guía da versión que realmente executa.
Que cambia apagar o túnel
Apagar unha interface cambia o estado administrativo. Cada túnel, ruta e sesión que depende dela cae á vez, que é xusto o que quere se o túnel é o que debe desaparecer. Tamén é así como un applet EEM converte un problema de WAN nunha caída que inclúe servizos non relacionados.
Se toma este camiño, limite o applet a unha interface e un disparador, garde o estado administrativo anterior, defina a acción de recuperación e asegúrese de que os flaps repetidos non o poidan levar a un bucle.
Un comando de recuperación codificado tamén pode anular un apagado de mantemento que fixo outra persoa.
Faga que a sonda percorra o camiño que vostede cre
Unha sonda que segue a mellor ruta actual múdase á WAN de respaldo xunto con todo o demais, e logo informa que a principal está sa, porque xa non a usa.
Fixe a sonda á interface ou ao enderezo de orixe do camiño que está probando. Comprobe tamén a que apunta, xa que acadar o seguinte salto do provedor demostra menos que acadar o servizo para o que existe o túnel. Estableza os atrasos de subida e baixada a propósito: un atraso de baixada curto reacciona rápido e oscila, mentres que un longo aguanta os parpadeos e oculta fallos reais. A guía de Cisco sobre seguimento e enrutamento por políticas en IOS XE documenta as combinacións admitidas, e o conxunto de funcións da súa plataforma decide cales pode usar.
Anote ambos os valores de atraso xunto ao obxecto seguido, ou ninguén saberá por que se comportou así.
Decida a restauración e logo verifique
A restauración merece a súa propia decisión. Unha ligazón que cruza o limiar continuamente pode mover sesións máis a miúdo que unha que fallou claramente, e cada movemento custa renegociar claves e reintentos da aplicación. Escolla un requisito de estabilidade e deixe que o atraso o exprese. Logo verifique durante unha ventá de cambio co camiño da sonda visible: ruta seleccionada, camiño do par externo e que fixo realmente a aplicación.
Se a conmutación funciona pero a aplicación segue rompendo, o problema está por riba da capa de enrutamento e ningunha cantidade de seguimento o arranxará.
Conserve as probas desa ventá, porque o próximo cambio compararase con elas.