Alguien te pide resumir los spokes y el ticket se cierra con menos prefijos en el hub. Una semana después, el tráfico entre sucursales que antes iba directo vuelve a pasar por el hub, y nadie relaciona los dos cambios. La frase resumir los spokes cubre dos operaciones distintas que tocan dos tablas distintas. Nombra qué estado estás reduciendo antes de tomar prestado un comando de otro ejemplo de DMVPN.

El síntoma: el tráfico directo entre spokes volvió al hub

La distinción importa sobre todo cuando una discusión de Phase 2 se aplica a un diseño de Phase 3. Las mismas palabras aparecen en ambas conversaciones, y el efecto sobre el reenvío no es el mismo.

Por eso también el cambio parecía correcto al revisarlo: la revisión comprobó la tabla de enrutamiento, que es solo uno de los tres estados implicados.

Una agregación, dos tablas

Las dos operaciones son así:

OperationWhat it actually changes
Routing summaryAggregates the prefixes the routing protocol advertises and changes the next hop the receiver installs
NHRP summary mapChanges the network returned in a resolution reply, so a requesting spoke resolves to a different address
Protection pathIPsec state for the peer you actually resolved; neither aggregation changes it

Un resumen de rutas es una afirmación sobre lo que anuncia el hub y lo que el spoke receptor instala como ruta. Un mapa de resumen NHRP es una afirmación sobre la respuesta que envía un spoke cuando otro spoke pregunta cómo llegar a una dirección. Son preguntas distintas con modos de fallo distintos, y un diseño puede cambiar una dejando la otra exactamente como estaba. Tratarlas como un solo mando es la forma en que un cambio de agregación se convierte en silencio en un cambio de reenvío.

Ninguna de las dos operaciones es una afirmación sobre la ruta de protección, porque esta se negocia para el par que realmente resolviste.

Qué cambia realmente el resumen del hub

La guía de Cisco sobre mapas de resumen NHRP entre spokes describe un montaje de Phase 3 en el que el hub anuncia un resumen y sigue siendo el siguiente salto del enrutamiento. Una redirección y una resolución NHRP posterior proporcionan entonces una ruta de reenvío más directa. Por eso leer solo la ruta agregada no describe todo el estado de reenvío, y no significa que cada paquete deba atravesar el hub para siempre. El resumen trata de alcanzabilidad, no del camino.

Por eso una revisión de diseño que se detiene en la tabla de enrutamiento puede aprobar un cambio que altera el comportamiento de resolución. Inspecciona la ruta seleccionada, el resultado NHRP y la ruta de protección como tres observaciones separadas.

Si no puedes decir cuál de los tres cambió, no has terminado el cambio.

Qué cambia el mapa de resumen NHRP

Toma un spoke que posee 10.32.0.0/19 mediante varias rutas LAN más específicas, mientras el hub anuncia una agregación mayor a los demás spokes. Una petición de 10.32.12.10 recibiría de otro modo información de resolución para la red más pequeña coincidente. La función documentada de mapa de resumen NHRP permite que el spoke devuelva en su lugar su prefijo de cobertura configurado, lo que puede reducir el trabajo repetido de resolución para las redes que pertenecen a ese spoke. No convierte el resumen de rutas del hub y el resumen de resolución del spoke en el mismo objeto.

Dale a ese prefijo de cobertura un modelo de propiedad deliberado. Una respuesta amplia que incluya direcciones que pertenecen a otro sitio, o huecos que no son alcanzables, puede enviar el tráfico posterior hacia un par inadecuado.

Comprueba las rutas reales y los casos denegados previstos antes de ampliar el prefijo, no después.

Compara el primer destino y uno dentro del resumen

Elige dos destinos: el primero que probaste y otro que quede dentro del resumen propuesto. Para cada uno, registra la ruta seleccionada, el estado NHRP usado para llegar a él y la ruta de respuesta real. Esa comparación te dice si cambiaste la escala de enrutamiento, la escala de resolución o un error de reenvío, que es la única conclusión útil. Una pantalla con menos prefijos no es prueba de ninguna de esas cosas.

Confirma la fase desplegada y el comportamiento de siguiente salto del protocolo de enrutamiento antes de aplicar un ejemplo de Phase 3 a tu red. Un ejemplo corto no demuestra que otro diseño conserve la misma ruta directa entre spokes.

El ticket debe decir qué tabla redujiste y cuál dejaste intacta. Cualquier cosa menos que eso se volverá a diagnosticar desde cero dentro de un mes.

Artículos relacionados