DMVPN fase 3: leer el atajo en ambos sentidos
Un solo ping directo no demuestra un atajo de DMVPN fase 3. Recorra la ruta de ida y la de vuelta y después lea por separado el estado de NHRP, la ruta y IPsec.
Usted observa cómo un ping va de spoke a spoke, toma el camino largo por el hub, y el segundo va directo. Es tentador dar el atajo por bueno en ese punto. Esa conclusión es medio correcta. La ruta de ida puede ser un atajo mientras la de vuelta sigue pasando por el hub, y el estado que demuestra cada sentido es un estado distinto. Recorra ambos sentidos y lea tres tablas antes de aceptar el diseño como sano.
Empiece por la ruta del paquete que realmente puede ver
Empiece en un spoke con un destino que debería ser directo. Siga el primer paquete: sigue la ruta del spoke hacia el hub, porque todavía no existe ningún atajo. El hub lo reenvía y, en un diseño de fase 3, también envía una redirección al origen diciendo que existe una ruta mejor.
Esa redirección es el disparador, no la prueba. Dice que el hub vio tráfico que podría optimizarse. No dice que el origen haya construido el atajo, que el destino haya respondido la resolución ni que la ruta de vuelta lo use.
Así que la primera observación útil es un antes y un después: el primer flujo por el hub, el flujo posterior directo.
Tres estados que parecen un solo túnel
El atajo depende de tres piezas de estado, y cada una tiene su propia vida útil y su propio comando.
| State | What it answers | Where to read it |
|---|---|---|
| NHRP cache | Which transport address maps to this overlay address | show ip nhrp |
| Route or shortcut | Where one specific inner prefix is forwarded | show ip route 10.10.20.5 |
| IPsec association | Which peer traffic is protected, and by which SA | show crypto ipsec sa peer 203.0.113.5 |
Una entrada de la caché NHRP asigna una dirección overlay a una dirección de transporte NBMA. Una ruta o un atajo decide por dónde se reenvía un destino interno concreto. Una asociación IPsec protege el tráfico que resulte. Una respuesta ausente puede venir de cualquiera de las tres, y los comandos le dicen cuál falta.
Léalas en ese orden, porque una asignación ausente hace que las otras dos no interesen.
Recorra la petición y la respuesta por separado
Desde el spoke A, pida la resolución y observe qué vuelve. La petición pasa por la ruta de reenvío NHRP admitida, y el destino puede responder directamente en lugar de hacerlo por el hub. Esa asimetría es normal, y por eso la respuesta es la mitad interesante del intercambio.
Ahora invierta los papeles. Envíe de B a A y repita las mismas tres lecturas. Un diseño que hace atajo en un sentido y no en el otro no es simétrico, y la asimetría suele venir de un prefijo que falta en un lado o de una resolución que nunca recibió respuesta.
La respuesta del par no tiene que atravesar el hub solo porque la petición lo hizo. No lo lea como un error ni empiece a perseguir una falla de enrutamiento que no existe.
Lea la redirección del hub, no solo su ruta
La tabla de rutas del hub le dice adónde enviaría el hub un paquete. La redirección le dice qué pidió el hub al origen que hiciera al respecto. Son hechos distintos, y un hub con la ruta correcta y sin redirecciones mantendrá cada flujo en el camino largo indefinidamente. Revise los eventos NHRP del hub y confirme que se generan redirecciones para el tráfico que le interesa.
La fase 3 también cambia qué significa la summarización. Con el comportamiento de atajo, los spokes no necesitan el conjunto completo de rutas remotas específicas que esperaba un diseño de fase 2, así que una ruta resumida en el spoke no es automáticamente una red que falta. Confirme la fase y la política de enrutamiento antes de leer un resumen como una falla.
Ese único malentendido provoca más tiquets de DMVPN que cualquier otra cosa.
Registre la conclusión como un objeto que falta
Termine con un flujo de aplicación autorizado y su respuesta, y anote para cada sentido si usó la ruta directa. Después escriba la conclusión como el objeto que faltaba: una asignación, un atajo de reenvío, una asociación de protección o una respuesta de aplicación.
Una adyacencia de enrutamiento y una asociación de seguridad compartida son pruebas de salud, no pruebas de la ruta. Ambas pueden ser perfectas mientras cada paquete sigue dando el rodeo largo. Compruebe primero la decisión de reenvío y luego la asociación que la transporta. El orden importa, porque la asociación se forma de todos modos.
Ese hábito se paga en el siguiente tiquet. «El túnel está levantado pero va lento» se convierte en «B no tiene atajo para el host de A», y la segunda afirmación es una solución de cinco minutos. Guarde la salida de los comandos con la conclusión y tenga a mano el recorrido de fase 3 del proveedor.