DMVPN phase 3 : lire le raccourci dans les deux sens
Un seul ping direct ne prouve pas un raccourci DMVPN phase 3. Parcourez le chemin aller et le chemin retour, puis lisez séparément l'état NHRP, de routage et IPsec.
Vous voyez un ping aller d'un spoke à un autre, il emprunte le long chemin via le hub, et le second passe en direct. Il est tentant de déclarer le raccourci fonctionnel à ce moment-là. Cette conclusion est à moitié juste. Le chemin aller peut être un raccourci tandis que le chemin retour passe encore par le hub, et l'état qui prouve chaque direction est un état différent. Parcourez les deux directions et lisez trois tableaux avant d'accepter le design comme sain.
Commencez par le chemin du paquet que vous voyez réellement
Partez d'un spoke avec une destination qui devrait être directe. Suivez le premier paquet : il suit la route du spoke vers le hub, car aucun raccourci n'existe encore. Le hub le transfère et, dans un design phase 3, envoie aussi une redirection à la source indiquant qu'un meilleur chemin existe.
Cette redirection est le déclencheur, pas la preuve. Elle dit que le hub a vu du trafic qui pourrait être optimisé. Elle ne dit pas que la source a construit le raccourci, que la destination a répondu à la résolution, ni que le chemin de retour l'utilise.
La première observation utile est donc un avant et un après : le premier flux via le hub, le flux suivant en direct.
Trois états qui ressemblent à un seul tunnel
Le raccourci dépend de trois éléments d'état, et chacun a sa propre durée de vie et sa propre commande.
| 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 |
Une entrée du cache NHRP associe une adresse overlay à une adresse de transport NBMA. Une route ou un raccourci décide où une destination interne donnée est transférée. Une association IPsec protège le trafic qui en résulte. Une réponse absente peut venir de l'un des trois, et les commandes vous disent lequel manque.
Lisez-les dans cet ordre, car une correspondance absente rend les deux autres sans intérêt.
Parcourez la requête et la réponse séparément
Depuis le spoke A, demandez la résolution et observez ce qui revient. La requête passe par le chemin de transfert NHRP pris en charge, et la destination peut répondre directement au lieu de passer par le hub. Cette asymétrie est normale, et c'est pourquoi la réponse est la moitié intéressante de l'échange.
Inversez maintenant les rôles. Envoyez de B vers A et répétez les mêmes trois lectures. Un design qui raccourcit un sens et pas l'autre n'est pas symétrique, et l'asymétrie vient généralement d'un préfixe manquant d'un côté ou d'une résolution qui n'a jamais reçu de réponse.
La réponse du pair n'a pas besoin de traverser le hub simplement parce que la requête l'a fait. Ne lisez pas cela comme une erreur et ne partez pas chasser un défaut de routage qui n'existe pas.
Lisez la redirection du hub, pas seulement sa route
La table de routage du hub vous dit où le hub enverrait un paquet. La redirection vous dit ce que le hub a demandé à la source de faire à ce sujet. Ce sont des faits différents, et un hub avec une route correcte et sans redirections maintiendra chaque flux sur le long chemin indéfiniment. Vérifiez les événements NHRP du hub et confirmez que des redirections sont générées pour le trafic qui vous intéresse.
La phase 3 change aussi ce que signifie la summarisation. Avec le comportement de raccourci, les spokes n'ont pas besoin de l'ensemble complet des routes distantes spécifiques qu'attendait un design phase 2, donc une route résumée sur le spoke n'est pas automatiquement un réseau manquant. Confirmez la phase et la politique de routage avant de lire un résumé comme un défaut.
Ce seul malentendu provoque plus de tickets DMVPN que tout le reste.
Consignez la conclusion comme un objet manquant
Terminez par un flux applicatif autorisé et sa réponse, et notez pour chaque sens s'il a utilisé le chemin direct. Écrivez ensuite la conclusion comme l'objet qui manquait : une correspondance, un raccourci de transfert, une association de protection ou une réponse applicative.
Une adjacence de routage et une association de sécurité partagée sont des preuves de santé, pas des preuves du chemin. Les deux peuvent être parfaits alors que chaque paquet fait encore le grand tour. Vérifiez d'abord la décision de transfert, puis l'association qui la porte. L'ordre compte, car l'association se forme de toute façon.
Cette habitude paie au ticket suivant. « Le tunnel est monté mais lent » devient « B n'a pas de raccourci pour l'hôte de A », et la seconde affirmation est une correction de cinq minutes. Gardez la sortie des commandes avec la conclusion, et gardez le parcours phase 3 du fournisseur à côté.