Benannter vs. nummerierter DMVPN-Hub: Was die FQDN ändert

Ein DMVPN-Spoke kann seinen Hub auf Plattformen, die diese Funktion unterstützen, über einen Hostnamen finden, und die erste Versuchung ist, diesen Hostnamen als eine andere Schreibweise der Hub-Tunneladresse zu lesen. Das ist er nicht. Der Name wird zu einem Transportendpunkt aufgelöst, während die Hub-Protokolladresse den nächsten Hop innerhalb des Overlays angibt, und beide Rollen bleiben in jeder Konfigurationsform erhalten. Diese Unterscheidung entscheidet, was eine Umbenennung beheben kann und was nicht.

Zwei Adressen, zwei Aufgaben

In einem erklärten Beispiel teilt hub.example.net dem Spoke mit, wohin Transportverkehr zu senden ist, und 10.90.0.1 kennzeichnet den NHS innerhalb des Tunnels. Discovery arbeitet mit der ersten; Registrierung und Routing arbeiten mit der zweiten. Eine Änderung des Namens betrifft den Pfad zum Endpunkt, während eine Änderung der Protokolladresse die Overlay-Beziehung selbst betrifft.

Die Trennung der Rollen macht die benannte Form debugbar. Wenn ein Spoke die Registrierung nicht schafft, können Sie zwei verschiedene Fragen stellen: Wurde der Name zu der Adresse aufgelöst, die ich erwartet hatte, und stimmte diese Adresse mit der Protokolladresse überein, die die Konfiguration behauptet? Keine Antwort bedingt die andere.

Vergleichen Sie die beiden Konfigurationsformen

Eine Form konfiguriert die NHS-Protokolladresse ausdrücklich neben dem Namen. Die andere lässt den Spoke diese Protokolladresse aus der Registrierungsantwort lernen. Beide sind dokumentiert, und beide enden bei Erfolg mit derselben Art von NHS-Beziehung.

Die ausdrückliche Form hat eine Einschränkung, die man sich merken sollte: Eine aufgelöste Transportadresse, die nicht auf die konfigurierte Protokolladresse abgebildet wird, verhindert die Registrierung. Das ist kein DNS-Fehler, obwohl das Symptom direkt nach einer DNS-Änderung auftritt. Der Name wurde korrekt aufgelöst, und das Ergebnis wurde aus einem anderen Grund abgelehnt. Lesen Sie die aufgelöste Adresse und die konfigurierte Protokolladresse nebeneinander.

Die lernende Form entfernt einen manuellen Schritt und eine Quelle der Abweichung, um den Preis, dass die Zuordnung von der Antwort abhängt. Wählen Sie die ausdrückliche Form, wenn die Hub-Adresse stabil ist und Sie wollen, dass die Nichtübereinstimmung laut scheitert. Wählen Sie die lernende Form, wenn sich die Hub-Protokolladresse ändern kann und der Spoke ihr lieber folgen soll. Notieren Sie in jedem Fall, welche Form das Design verwendet.

Vergleichen Sie DNS-Caching mit einem statischen Hub

Eine statische Hub-Adresse ändert sich, wenn jemand die Konfiguration bearbeitet. Ein benannter Hub ändert sich, wenn sich DNS ändert, und DNS-Antworten werden für ihre Lebensdauer zwischengespeichert. Die Dokumentation merkt an, dass zwischengespeicherte Informationen bis zum Ablauf nutzbar bleiben und eine spätere Abfrage dann die neue Adresse zurückgeben kann.

Dieser Unterschied ist ein Zeitunterschied, keine sofortige Migration. Eine lange Cache-Lebensdauer verzögert die Übernahme eines umbenannten Endpunkts, und die Verzögerung ist unsichtbar, wenn Sie nur den DNS-Eintrag beobachten. Planen Sie eine Umbenennung um die Cache-Lebensdauer und das Registrierungsverhalten der installierten Version herum, statt anzunehmen, jeder Tunnel bewege sich gleichzeitig.

Die statische Form hat natürlich ihre eigene Verzögerung: Nichts ändert sich, bis jeder Spoke bearbeitet ist. Der Vergleich gilt einem koordinierten Konfigurationsstoß gegenüber einer zwischengespeicherten Discovery-Aktualisierung, nicht langsam gegenüber sofort.

Vergleichen Sie, was gleich bleibt

Die Peer-Authentifizierung verschiebt sich nicht. Ein Hostname, der den Transportendpunkt lokalisiert, ersetzt weder die konfigurierte IKE-Identität noch die Authentifizierungsrichtlinie, die den Peer validiert. Ist die Identität falsch, bringt Sie eine erfolgreiche DNS-Auflösung nur schneller zu einem abgelehnten Tunnel.

Auch der geschützte Verkehr bleibt unverändert. Ein antwortender NHS beweist nicht, dass die Kundenroute existiert oder dass der Anwendungsfluss erlaubt ist. Registrierung, Routing und Richtlinie sind drei Prüfungen, und der Name betrifft nur den ersten Schritt, der sie speist.

Ein Vergleich, den Sie überprüfen können

Cisco dokumentiert getrennte Beobachtungen für die Sitzung und die NHS-Beziehung. Verwenden Sie show dmvpn, um Peer- und Sitzungsstatus zu lesen, und show ip nhrp nhs, um die NHS-Registrierungsansicht zu lesen. Vergleichen Sie die aufgelöste Transportadresse, den Overlay-Peer und den Registrierungsstatus in dieser Reihenfolge.

Das IOS-XE-Kapitel zu FQDN-DMVPN dokumentiert das Discovery-, Cache- und Einschränkungsverhalten hinter diesem Vergleich. Lesen Sie es gegen Ihre installierte Version, bevor Sie einen umbenannten Hub als direkten Ersatz für einen nummerierten behandeln.