Conmutación por error de WAN en DMVPN: ¿política de ruta o apagar el túnel?

Un concentrador DMVPN con doble WAN conmuta por error de una de dos maneras, y la diferencia es mayor de lo que parece. Una cambia qué siguiente salto elige una política de ruta, de modo que los paquetes siguen fluyendo y solo cambia su salida. La otra apaga el túnel administrativamente, lo que tumba con él todos los servicios de esa interfaz. Ambas pueden ser correctas, porque responden a preguntas distintas.

La decisión llega antes de la configuración

Tres condiciones lo deciden por usted. ¿Depende algo más de que la interfaz del túnel esté activa, como un segundo perfil DMVPN o un monitor que lea su estado? ¿El tráfico que debe conmutar lleva su propia política, o depende de la tabla de enrutamiento global? ¿Y el operador necesita un cambio de estado inequívoco, o es aceptable un cambio de ruta silencioso? Responda esas tres y la elección suele hacerse sola.

Si un apagado tumbara servicios que funcionaban, la política de ruta es la acción más pequeña. Si el requisito es que el túnel no exista mientras la WAN principal está caída, ninguna entrada de política puede expresarlo.

Escriba la respuesta, porque la configuración es la parte fácil.

Qué cambia realmente la política de ruta

Con el enrutamiento basado en políticas, un objeto seguido puede controlar un siguiente salto. La entrada del mapa de rutas nombra un siguiente salto candidato y el objeto seguido que debe estar activo para usarlo, y ese estado de seguimiento proviene de una sonda IP SLA. Cuando el objeto cae, la entrada deja de coincidir y el paquete se evalúa por la siguiente entrada o por la tabla de enrutamiento ordinaria.

Ese último detalle sorprende a la gente: una política que deja de elegir un siguiente salto suele permitir el enrutamiento normal en lugar de bloquear el tráfico. Si necesita un agujero negro en caso de fallo, tiene que escribir uno.

La sintaxis difiere entre plataformas y versiones, así que consulte la guía de la versión que realmente ejecuta.

Qué cambia apagar el túnel

Apagar una interfaz cambia el estado administrativo. Cada túnel, ruta y sesión que depende de ella cae a la vez, que es justo lo que quiere si el túnel es lo que debe desaparecer. También es así como un applet EEM convierte un problema de WAN en una caída que incluye servicios no relacionados.

Si toma este camino, limite el applet a una interfaz y un disparador, guarde el estado administrativo anterior, defina la acción de recuperación y asegúrese de que los flaps repetidos no puedan llevarlo a un bucle.

Un comando de recuperación codificado también puede anular un apagado de mantenimiento que haya hecho otra persona.

Haga que la sonda recorra el camino que usted cree

Una sonda que sigue la mejor ruta actual se mueve a la WAN de respaldo junto con todo lo demás, y luego informa que la principal está sana porque ya no la usa.

Fije la sonda a la interfaz o a la dirección de origen del camino que está probando. Compruebe también a qué apunta, ya que alcanzar el siguiente salto del proveedor demuestra menos que alcanzar el servicio para el que existe el túnel. Establezca los retardos de subida y bajada a propósito: un retardo de bajada corto reacciona rápido y oscila, mientras que uno largo aguanta los parpadeos y oculta fallos reales. La guía de Cisco sobre seguimiento y enrutamiento por políticas en IOS XE documenta las combinaciones admitidas, y el conjunto de funciones de su plataforma decide cuáles puede usar.

Anote ambos valores de retardo junto al objeto seguido, o nadie sabrá por qué se comportó así.

Decida la restauración y luego verifique

La restauración merece su propia decisión. Un enlace que cruza el umbral continuamente puede mover sesiones más a menudo que uno que ha fallado claramente, y cada movimiento cuesta renegociar claves y reintentos de la aplicación. Elija un requisito de estabilidad y deje que el retardo lo exprese. Luego verifique durante una ventana de cambio con el camino de la sonda visible: ruta seleccionada, camino del par externo y qué hizo realmente la aplicación.

Si la conmutación funciona pero la aplicación sigue rompiéndose, el problema está por encima de la capa de enrutamiento y ninguna cantidad de seguimiento lo arreglará.

Conserve las pruebas de esa ventana, porque el próximo cambio se comparará con ellas.