Hierarchisches DMVPN: eine Cloud pro Tunnelbeziehung

Ein Filialknoten registriert sich erfolgreich bei seinem regionalen Hub und erreicht dennoch keinen Dienst in einer anderen Region. Der Tunnel steht, der NHS-Zustand wirkt gesund, und der Fehler zeigt sich nur bei Zielen, die eine Ebenengrenze überschreiten. Dieses Muster bedeutet meist, dass das Design nie festhielt, welche Geräte an welcher DMVPN-Cloud teilnehmen, sodass die Ebenen nach Gefühl gebaut wurden und nun nicht zusammenpassen.

Das Symptom zeigt sich an der Ebenengrenze

In einem hierarchischen Design hat ein zentraler Hub, mehrere regionale Hubs und viele Filialknoten jeweils eine Position. Ein regionaler Hub kann mehr als eine Tunnelbeziehung besitzen, und Filialen müssen sich nicht bei jedem zentralen Endpunkt registrieren. Die entscheidenden Pfade sind Filiale zu regionalem Dienst, Filiale zu einem anderen zugelassenen regionalen Knoten und Filiale zu einem zentralen Ziel.

Wenn einer dieser Pfade ausfällt, während die anderen funktionieren, ist das Problem fast immer eine fehlende oder widersprüchliche Rollendefinition und kein defekter Tunnel. Schreiben Sie die beabsichtigten Pfade auf und vergleichen Sie sie mit dem, was die Geräte tatsächlich gebaut haben. Dieser Vergleich dauert eine Stunde und erspart eine Woche Rätselraten. Bewahren Sie ihn beim Designdokument auf.

Eine Cloud, ein Schnittstellenvertrag

Halten Sie für jede Cloud die Tunnelschnittstelle, die Overlay-Adressierung, die lokale Underlay-Quelle, die NHS- und NBMA-Beziehungen, die Multicast-Zustellung und die Schutzrichtlinie fest. Geben Sie außerdem an, welche Routen zwischen dem regionalen und dem zentralen Kontext verlaufen, denn genau dieser Satz ist das Design.

Ein regionaler Hub mit zwei Tunnelschnittstellen braucht zwei Verträge, nicht einen mit zwei Adressen. Die Underlay-Quelle, die NHRP-Domäne und die Routen können sich pro Schnittstelle unterscheiden, und ein Dokument, das sie zusammenfasst, führt den in die Irre, der die zweite konfiguriert.

IDs sind lokaler Kontext, keine Zugriffskontrolle

NHRP-Netzwerk-IDs und GRE-Schlüssel sind die beiden Werte, die am häufigsten für globale Einstellungen gehalten werden. Der IOS XE NHRP-Leitfaden beschreibt die Netzwerk-ID als lokal bedeutsam, daher authentifizieren übereinstimmende Nummern auf entfernten Routern nichts, und das Ändern der lokalen Nummer eines Routers schafft keine Zugriffsgrenze.

Ein GRE-Schlüssel hilft, wo das Design einen verwendet, den empfangenden Tunnelkontext zu erkennen, und wird zwischen den Endpunkten vereinbart, die diesen Kontext teilen. Er ist kein Kennwort und ersetzt weder die IKE-Authentifizierung noch die Routing-Richtlinie. Behandeln Sie beide Werte als Konfigurationskontext, der innerhalb einer Beziehung übereinstimmen muss, nicht als Sicherheitskontrollen, die Regionen trennen.

Routen Sie bewusst zwischen den Ebenen

Legen Sie fest, welche Präfixe der regionale Hub nach oben ankündigt und welche zentralen Ziele er seinen Filialen anbietet. Prüfen Sie dann für jeden Pfad den tatsächlichen nächsten Hop und das phasenspezifische Abkürzungsverhalten, denn eine Zusammenfassungsroute und eine Abkürzung können eine ganz andere Weiterleitung ergeben, als das Diagramm nahelegt.

Nutzen Sie Routing und Zugriffsrichtlinie, um die regionale Trennung durchzusetzen. Wenn eine Filiale eine andere Region nicht direkt erreichen darf, müssen Route und Richtlinie das sagen, statt sich auf eine ID zu verlassen, die nie dafür gedacht war, dies durchzusetzen. Schreiben Sie die Richtlinie neben die ID. Sonst nimmt der nächste Ingenieur an, die Nummer erledige die Arbeit.

Diagnostizieren Sie die unerwartete Abkürzung

Wenn eine Filiale eine direkte Beziehung zu einem zentralen Endpunkt aufbauen will, prüfen Sie ihre Route, ihr NHRP-Mapping und den gewählten Tunnelkontext, bevor Sie IDs willkürlich ändern. Fehlende Erreichbarkeit, eine unbeabsichtigte NHS-Beziehung und eine legitime, aber nicht genehmigte Abkürzung verlangen drei verschiedene Korrekturen.

Der DMVPN-Konfigurationsleitfaden zeigt Tunnel- und NHRP-Einstellungen zusammen, und genau deshalb müssen die Bereiche zuerst auf dem Papier getrennt werden. Halten Sie die Cloud-Verträge fest, halten Sie die Ebenenrouten ausdrücklich, und der nächste Grenzfehler hat einen Punkt, auf den er zeigen kann.