EIGRP-Nachbarn kommen im DMVPN-Overlay nicht hoch

Der Tunnel ist oben, ein Spoke kann einen anderen anpingen, und EIGRP zeigt am Hub weiterhin keinen Nachbarn. Diese Kombination ist normal und nicht rätselhaft: Ein Ping belegt Unicast-Erreichbarkeit über NHRP, und EIGRP-Hellos sind Multicast. In einem DMVPN-Overlay ist das Zustellmodell des Routingprotokolls eine zweite Konfigurationsfläche, und genau sie überspringen die Leute, weil die erste Fläche bereits gesund aussieht. Jede Schicht darunter wird mit ihrem eigenen Befehl geprüft, ein Fehler in einer Schicht schickt Sie also nicht zurück an den Anfang der Liste.

Schreiben Sie die erwarteten Nachbarschaften auf

Bevor Sie irgendeinen show-Befehl absetzen, machen Sie eine kurze Liste: Welcher Spoke soll mit welchem Hub peeren, über welche Tunnel-Schnittstelle, in welchem autonomen EIGRP-System. Designs mit mehreren Hubs scheitern in den Lücken zwischen den Hubs, und eine Liste verwandelt „EIGRP ist kaputt“ in „Spoke 3 registriert sich nicht an Hub 2“. Nehmen Sie die Tunnel-Subnetze auf, die Sie pro Link erwarten, denn eine Adressabweichung zwischen beiden Enden sieht genau wie ein Protokollfehler aus. Schreiben Sie die Liste ins Ticket, damit die nächste Schicht mit dem Design vergleicht und nicht mit dem letzten Screenshot.

Prüfen Sie NHRP, dann den Multicast-Pfad

Beginnen Sie mit dem Registrierungszustand und den Mappings, die der Hub tatsächlich hält. Ein Spoke ohne dynamischen Eintrag am Hub ist nicht registriert, und kein Routingprotokoll repariert das. Bestätigen Sie dann, dass der Spoke Multicast von der NBMA-Adresse des Hubs annimmt, was eine eigene Zeile gegenüber dem NHS-Eintrag ist.

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

Die Zeile ip nhrp map multicast ist es, die den Spoke seine Hellos als replizierten Multicast über das Overlay an den Hub senden lässt und die den Multicast des Hubs die registrierten Spokes erreichen lässt. Ohne sie funktioniert Unicast über NHRP und Multicast nicht, und genau diese Trennung lässt einen Ping wie einen Beweis aussehen. Der Cisco-Leitfaden IOS XE DMVPN dokumentiert das Multicast-Verhalten von Hub und Spokes für jede Phase, passen Sie Ihre Konfiguration also an die Phase an, die Sie wirklich ausgerollt haben, statt ein Fragment aus einer anderen Topologie zu kopieren.

Prüfen Sie die eigene Schnittstellen-Policy von EIGRP

Ein Tunnel, der nicht im EIGRP-Prozess ist oder passiv ist, bildet nie eine Nachbarschaft, egal wie gesund das Overlay ist. Lesen Sie die Teilnahme der Schnittstelle und die Nachbartabelle zusammen, denn die erste erklärt die zweite.

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

Authentifizierung und Metrikgewichte müssen an beiden Enden übereinstimmen. Eine Key-Chain im falschen Modus oder eine Abweichung beim K-Wert verwirft Hellos ohne offensichtliche Syslog-Zeile beim Empfänger. Wenn das Design explizit konfigurierte Unicast-Nachbarn nutzt, folgen Sie diesem Modell vollständig, statt es auf Multicast-Einstellungen zu stapeln, bis irgendetwas hochkommt.

Halten Sie GRE-Transport und IPsec-Schutz getrennt

DMVPN transportiert Multicast innerhalb von GRE, und IPsec schützt die GRE-Pakete statt des inneren Multicasts direkt. Deshalb ist die pauschale Behauptung, IPsec könne keinen Multicast transportieren, für dieses Design falsch und als Diagnose nutzlos. Prüfen Sie das IPsec-Profil am Tunnel, die Security Associations je Peer und den Zustand der Tunnel-Schnittstelle als drei getrennte Fakten.

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

Eine SA, die oben ist und deren Zähler laufen, während EIGRP unten bleibt, schiebt Ihre Untersuchung wieder die Stack-Ebene hinauf: Die Pakete werden geschützt und zugestellt, das Problem ist also, welche Pakete das Protokoll zu senden wählt.

Prüfen Sie Routen, nicht nur Nachbarzahlen

Sobald die Nachbarschaft steht, lesen Sie, was sie ankündigt und installiert. Auf einem Multipoint-Tunnel entscheiden Split Horizon und Next-Hop-Verhalten, ob ein Spoke über den Hub einen anderen erreicht, und Summarization kann ein Präfix verbergen, obwohl die Nachbarschaft perfekt ist.

Schließen Sie mit einer erlaubten Anwendung zwischen zwei Standorten ab und bestätigen Sie den Pfad, den sie nimmt. Direkte Spoke-zu-Spoke-Shortcuts sind eine Weiterleitungsanforderung mit eigenem NHRP- und Sicherheitszustand, und sie hinzuzufügen, damit die Nachbarzahl besser aussieht, erzeugt meist ein zweites Problem.

Halten Sie das phasenweise Design, das Multicast-Mapping und die EIGRP-Policy an einer Stelle fest. Der nächste Ingenieur braucht das Design, nicht das Transkript.