EIGRP-Nachbar oder DMVPN-Transit? Prüfen Sie zuerst die Rolle

Die Nachbarschaft fehlt, und der Router in der Mitte wirkt wie der offensichtliche Verdächtige. Er kann unschuldig sein. Das Weiterleiten der äußeren Tunnelpakete und die Teilnahme am Overlay-Routingprotokoll sind zwei verschiedene Aufgaben, und ein Gerät kann die erste erledigen, ohne die zweite zu erledigen. Arbeiten Sie die fünf Prüfungen unten der Reihe nach ab und halten Sie bei der ersten an, die scheitert.

Schritt 1: Zeichnen Sie die zwei Rollen

Zeichnen Sie die beabsichtigte EIGRP-Nachbarschaft als logische Verbindung zwischen zwei Routern und dann die Underlay-Router, die ihre Tunnelpakete tragen. Dasselbe Gerät muss nicht in beiden Listen auftauchen, und die Verwechslung der Listen ist der häufigste Grund, warum ein gesunder Transitrouter beschuldigt wird, die Nachbarschaft zu brechen.

Ein Transitrouter leitet die äußeren Pakete mit seinem gewöhnlichen IP-Routing und seiner Policy weiter. Er muss das im geschützten Tunnel transportierte Protokoll nicht ausführen und braucht keinen EIGRP-Prozess, um diese Pakete durchzuleiten.

Schritt 2: Prüfen Sie, was das mittlere Gerät terminiert

Wenn der mittlere Router den Tunnel terminiert und EIGRP-Nachbarschaften mit Spokes bilden soll, ändert sich die Antwort vollständig. Dieses Gerät braucht das unterstützte Overlay-Routingverhalten, und es Transit zu nennen beseitigt die Nachbaranforderung nicht. Lesen Sie die Tunnelkonfiguration vor der Routingkonfiguration. Diese Antwort entscheidet jede folgende Prüfung.

Die erste echte Frage ist also nicht, welches Protokoll abzustimmen ist. Sie lautet, ob die Box ein Hub, ein Spoke, ein reiner Underlay-Hop oder ein Layer-2-Dienst ist, der Frames zwischen Endpunkten trägt.

Schritt 3: Prüfen Sie die Kontrollebene des Nachbarn

Bestätigen Sie auf jedem Gerät, das Nachbar sein soll, vier Dinge: die EIGRP-Instanz und die Autonomous-System-Nummer, die Authentifizierungsparameter, die am Prozess beteiligte Schnittstelle und die Netzwerk-Anweisung, die diese Schnittstelle abdeckt. Eine Abweichung bei einem davon hält die Nachbarschaft unten, während die Schnittstelle oben bleibt und der Ping weiter funktioniert.

RFC 7868 beschreibt EIGRP als IP-Protokoll mit einem Multicast-Kontrollaustausch, weshalb eine Nachbarbeziehung nichts ist, was ein Zwischenrouter durch Routing von Paketen zu einem Ziel stellvertretend übernehmen kann. Entweder erreicht der Kontrollaustausch den Peer, oder die Nachbarschaft entsteht nicht.

Schritt 4: Prüfen Sie, ob der Transport den Kontrollaustausch zustellt

Prüfen Sie als Nächstes, ob das Overlay den Kontrollverkehr tatsächlich zwischen den beabsichtigten Endpunkten trägt. Sehen Sie sich das NHRP-Mapping für den Peer und die äußere Route dorthin an und bestätigen Sie dann, dass die Tunnelschnittstelle oben ist und Verkehr durchlässt. Ein erfolgreicher Underlay-Ping beweist, dass der äußere Pfad existiert; er beweist nicht, dass der Overlay-Kontrollaustausch zugestellt wurde.

Ein transparenter Layer-2-Dienst, ein Punkt-zu-Punkt-Tunnel und eine Multipoint-DMVPN-Cloud stellen Multicast unterschiedlich zu. Folgen Sie dem unterstützten Schnittstellen-, NHRP- und Multicast-Modell für das tatsächlich eingesetzte Verfahren, statt anzunehmen, dass sich alle drei gleich verhalten.

Schritt 5: Entwerfen Sie die Grenze neu, wenn sie nicht teilnehmen kann

Wenn ein erforderliches Overlay-Gerät das Protokoll nicht ausführen kann, ändern Sie das Design ausdrücklich. Verwenden Sie an dieser Grenze ein unterstütztes Protokoll oder Austauschmodell, oder richten Sie einen geeigneten End-to-End-Tunnel ein, sodass die Nachbarn die Endpunkte sind, die tatsächlich miteinander sprechen. Nehmen Sie nicht an, dass eine statische Route einen Nichtteilnehmer in ein Relay für jedes Kontrollpaket verwandelt.

Notieren Sie die Rolle jedes Geräts im Diagramm und bewahren Sie sie mit der Konfiguration auf. Die RFC 7868-Definition des Protokollaustauschs ist die Referenz dafür, warum die Nachbarbeziehung nicht durch Transit-Weiterleitung simuliert werden kann.

Wenn die Nachbarschaft auch nach allen fünf Prüfungen scheitert, sind die verbleibenden Verdächtigen Plattformfunktionen wie die Multicast-Behandlung auf der Tunnelschnittstelle und eine Policy, die Protokoll 88 filtert. Das sind konkrete, testbare Ursachen, und sie sind mehr wert als eine weitere Runde, in der der Router in der Mitte beschuldigt wird.