Voisin EIGRP ou transit DMVPN ? Vérifiez d’abord le rôle

L’adjacence manque, et le routeur du milieu ressemble au suspect évident. Il peut être innocent. Transmettre les paquets externes du tunnel et participer au protocole de routage overlay sont deux tâches différentes, et un équipement peut faire la première sans faire la seconde. Déroulez les cinq vérifications ci-dessous dans l’ordre et arrêtez-vous à la première qui échoue.

Étape 1 : dessinez les deux rôles

Dessinez l’adjacence EIGRP prévue comme une connexion logique entre deux routeurs, puis dessinez les routeurs underlay qui transportent ses paquets de tunnel. Le même équipement ne doit pas forcément figurer dans les deux listes, et confondre les listes est la raison la plus fréquente pour laquelle un routeur de transit sain est accusé de casser l’adjacence.

Un routeur de transit transmet les paquets externes avec son routage IP et sa politique habituels. Il n’a pas besoin d’exécuter le protocole transporté à l’intérieur du tunnel protégé, ni d’un processus EIGRP pour faire passer ces paquets.

Étape 2 : vérifiez ce que termine l’équipement du milieu

Si le routeur du milieu termine le tunnel et doit former des adjacences EIGRP avec les spoke, la réponse change complètement. Cet équipement a besoin du comportement de routage overlay pris en charge, et le qualifier de transit ne fait pas disparaître l’exigence de voisin. Lisez la configuration du tunnel avant celle du routage. Cette réponse détermine toutes les vérifications suivantes.

La première vraie question n’est donc pas quel protocole régler. C’est de savoir si la boîte est un hub, un spoke, un simple saut underlay ou un service Layer 2 qui transporte des trames entre les extrémités.

Étape 3 : vérifiez le plan de contrôle du voisin

Sur chaque équipement qui doit être voisin, confirmez quatre choses : l’instance EIGRP et le numéro de système autonome, les paramètres d’authentification, l’interface qui participe au processus et la commande réseau qui couvre cette interface. Un écart sur l’une d’elles maintient l’adjacence en bas tandis que l’interface reste active et que le ping continue de fonctionner.

Le RFC 7868 décrit EIGRP comme un protocole IP doté d’un échange de contrôle multicast, et c’est pourquoi une relation de voisinage n’est pas quelque chose qu’un routeur intermédiaire peut remplacer en routant des paquets vers une destination. Soit l’échange de contrôle atteint le pair, soit l’adjacence ne se forme pas.

Étape 4 : vérifiez que le transport achemine l’échange de contrôle

Ensuite, vérifiez que l’overlay transporte réellement le trafic de contrôle entre les extrémités prévues. Inspectez le mappage NHRP du pair et la route externe qui l’atteint, puis confirmez que l’interface du tunnel est active et laisse passer le trafic. Un ping underlay réussi prouve que le chemin externe existe ; il ne prouve pas que l’échange de contrôle de l’overlay a été livré.

Un service Layer 2 transparent, un tunnel point à point et un cloud DMVPN multipoint livrent le multicast différemment. Suivez le modèle d’interface, NHRP et multicast pris en charge pour celui qui est réellement déployé au lieu de supposer que les trois se comportent de la même façon.

Étape 5 : reconcevez la frontière si elle ne peut pas participer

Si un équipement overlay requis ne peut pas exécuter le protocole, changez le design explicitement. Utilisez un protocole ou un modèle d’échange pris en charge à cette frontière, ou mettez en place un tunnel de bout en bout adapté pour que les voisins soient les extrémités qui se parlent réellement. Ne supposez pas qu’une route statique transforme un non-participant en relais pour chaque paquet de contrôle.

Notez le rôle de chaque équipement sur le schéma et conservez-le avec la configuration. RFC 7868 définit l’échange de protocole, et cette définition est la référence pour comprendre pourquoi la relation de voisinage ne peut pas être simulée par le routage de transit.

Lorsque l’adjacence échoue encore après les cinq vérifications, les suspects restants sont des fonctions de plateforme comme le traitement du multicast sur l’interface du tunnel et une politique qui filtre le protocole 88. Ce sont des causes précises et testables, et elles valent plus qu’un nouveau tour à blâmer le routeur du milieu.