Les voisins EIGRP ne montent pas sur l’overlay DMVPN

Le tunnel est monté, un spoke peut pinger un autre, et EIGRP n’affiche toujours aucun voisin sur le hub. Cette combinaison est normale et non mystérieuse : un ping prouve la joignabilité unicast via NHRP, et les hello d’EIGRP sont multicast. Sur un overlay DMVPN, le modèle de livraison du protocole de routage est une seconde surface de configuration, et c’est justement celle que les gens sautent parce que la première surface paraît déjà saine. Chaque couche ci-dessous se vérifie avec sa propre commande, donc une panne sur l’une ne vous renvoie pas en haut de la liste.

Notez les adjacences que vous attendez

Avant toute commande show, faites une courte liste : quel spoke doit s’appairer avec quel hub, par quelle interface de tunnel, dans quel système autonome EIGRP. Les conceptions multi-hub échouent dans les écarts entre les hubs, et une liste transforme « EIGRP est cassé » en « le spoke 3 ne s’enregistre pas sur le hub 2 ». Incluez les sous-réseaux de tunnel que vous attendez sur chaque lien, car un désaccord d’adresse entre les deux extrémités ressemble exactement à une panne de protocole. Écrivez la liste dans le ticket, pour que l’équipe suivante compare au design plutôt qu’à la dernière capture d’écran.

Vérifiez NHRP, puis le chemin multicast

Commencez par l’état d’enregistrement et les mappages que le hub détient réellement. Un spoke sans entrée dynamique sur le hub ne s’est pas enregistré, et aucun protocole de routage n’y remédiera. Confirmez ensuite que le spoke accepte le multicast depuis l’adresse NBMA du hub, ce qui est une ligne distincte de l’entrée NHS.

show dmvpn
show ip nhrp
show ip nhrp nhs detail
interface Tunnel0
 ip nhrp network-id 1
 ip nhrp nhs 203.0.113.1 nbma 198.51.100.1
 ip nhrp map multicast 198.51.100.1
 tunnel mode gre multipoint
 tunnel key 100

La ligne ip nhrp map multicast est ce qui permet au spoke d’envoyer ses hello au hub en multicast répliqué sur l’overlay, et ce qui permet au multicast du hub d’atteindre les spokes qu’il a enregistrés. Sans elle, l’unicast via NHRP fonctionne et le multicast non, et c’est précisément cette séparation qui fait qu’un ping ressemble à une preuve. Le guide Cisco IOS XE DMVPN documente le comportement multicast du hub et des spokes pour chaque phase, alors alignez votre configuration sur la phase que vous avez réellement déployée au lieu de copier un fragment d’une autre topologie.

Vérifiez la politique d’interface propre à EIGRP

Un tunnel qui n’est pas dans le processus EIGRP, ou qui est passive, ne formera jamais une adjacence, aussi sain soit l’overlay. Lisez la participation de l’interface et la table des voisins ensemble, car la première explique la seconde.

show ip eigrp interfaces detail Tunnel0
show ip eigrp neighbors detail
show run | section router eigrp
router eigrp 100
 network 10.10.0.0 0.0.0.255
 passive-interface default
 no passive-interface Tunnel0

L’authentification et les poids de métrique doivent correspondre aux deux extrémités. Une chaîne de clés au mauvais mode, ou un désaccord sur la valeur K, fait tomber les hello sans ligne syslog évidente chez le récepteur. Si le design utilise des voisins unicast configurés explicitement, suivez ce modèle complètement au lieu de l’empiler sur les réglages multicast jusqu’à ce que quelque chose monte.

Gardez le transport GRE et la protection IPsec séparés

DMVPN transporte le multicast à l’intérieur de GRE, et IPsec protège les paquets GRE plutôt que le multicast interne directement. C’est pourquoi l’affirmation générale selon laquelle IPsec ne peut pas transporter de multicast est fausse pour ce design et inutile comme diagnostic. Vérifiez le profil IPsec du tunnel, les associations de sécurité de chaque peer et l’état de l’interface de tunnel comme trois faits distincts.

show crypto ipsec sa peer 198.51.100.1
show interfaces Tunnel0 | include line protocol
show ip nhrp multicast

Une SA montée dont les compteurs avancent alors qu’EIGRP reste en bas renvoie votre enquête plus haut dans la pile : les paquets sont protégés et livrés, donc le problème est de savoir quels paquets le protocole choisit d’envoyer.

Vérifiez les routes, pas seulement le nombre de voisins

Une fois l’adjacence formée, lisez ce qu’elle annonce et installe. Sur un tunnel multipoint, le split horizon et le comportement du next-hop décident si un spoke peut atteindre un autre spoke via le hub, et le résumé peut masquer un préfixe même quand la relation de voisinage est parfaite.

Terminez par une application autorisée entre deux sites et confirmez le chemin qu’elle emprunte. Les raccourcis directs spoke-to-spoke sont une exigence de transfert avec leur propre état NHRP et de sécurité, et les ajouter pour faire bonne figure sur le nombre de voisins crée généralement un second problème.

Consignez le design par phases, le mappage multicast et la politique EIGRP au même endroit. Le prochain ingénieur aura besoin du design, pas de la transcription.