DMVPN-WAN-Failover: Routing-Policy oder Tunnel abschalten?

Ein DMVPN-Hub mit zwei WANs schaltet auf eine von zwei Arten auf Backup um, und der Unterschied ist größer, als er aussieht. Die eine ändert, welchen nächsten Hop eine Routing-Policy wählt, sodass Pakete weiterfließen und sich nur ihr Ausgang ändert. Die andere fährt den Tunnel administrativ herunter, was jeden Dienst auf dieser Schnittstelle mitreißt. Beide können richtig sein, denn sie beantworten verschiedene Fragen.

Die Entscheidung kommt vor der Konfiguration

Drei Bedingungen entscheiden das für Sie. Hängt noch etwas anderes davon ab, dass die Tunnel-Schnittstelle aktiv ist, etwa ein zweites DMVPN-Profil oder ein Monitor, der ihren Zustand liest? Trägt der Verkehr, der ausweichen muss, eine eigene Policy, oder verlässt er sich auf die globale Routing-Tabelle? Und braucht der Betreiber eine unmissverständliche Zustandsänderung, oder ist ein leiser Pfadwechsel akzeptabel? Beantworten Sie diese drei, und die Wahl trifft sich meist von selbst.

Würde ein Herunterfahren Dienste mitnehmen, die funktionierten, ist die Routing-Policy die kleinere Maßnahme. Wenn die Anforderung lautet, dass der Tunnel nicht existieren darf, solange das primäre WAN nicht läuft, kann kein Policy-Eintrag das ausdrücken.

Schreiben Sie die Antwort auf, denn die Konfiguration ist der leichte Teil.

Was die Routing-Policy tatsächlich ändert

Beim richtlinienbasierten Routing kann ein verfolgtes Objekt einen nächsten Hop steuern. Der Route-Map-Eintrag nennt einen Kandidaten für den nächsten Hop und das verfolgte Objekt, das aktiv sein muss, damit er verwendet wird, und dieser Tracking-Zustand kommt von einer IP-SLA-Sonde. Fällt das Objekt aus, passt der Eintrag nicht mehr, und das Paket wird vom nächsten Eintrag oder von der normalen Routing-Tabelle bewertet.

Das letzte Detail überrascht viele: Eine Policy, die keinen nächsten Hop mehr wählt, erlaubt meist normales Routing, statt Verkehr zu blockieren. Wenn Sie ein schwarzes Loch bei Ausfall brauchen, müssen Sie eines schreiben.

Die Syntax unterscheidet sich zwischen Plattformen und Releases, also prüfen Sie den Leitfaden für die Version, die Sie tatsächlich betreiben.

Was das Abschalten des Tunnels ändert

Eine Schnittstelle abzuschalten ändert den administrativen Zustand. Jeder Tunnel, jede Route und jede Sitzung, die davon abhängt, geht auf einmal down, was genau das ist, was Sie wollen, wenn der Tunnel das sein muss, was verschwinden soll. So macht auch ein EEM-Applet aus einem WAN-Problem einen Ausfall, der unabhängige Dienste einschließt.

Wenn Sie diesen Weg gehen, beschränken Sie das Applet auf eine Schnittstelle und einen Auslöser, sichern Sie den vorherigen administrativen Zustand, definieren Sie die Wiederherstellungsaktion und stellen Sie sicher, dass wiederholte Flaps es nicht in eine Schleife treiben können.

Ein fest codiertes Wiederherstellungskommando kann auch ein Wartungs-Herunterfahren überschreiben, das jemand anderes durchgeführt hat.

Lassen Sie die Sonde den Pfad nehmen, den Sie meinen

Eine Sonde, die der aktuell besten Route folgt, wechselt mit allem anderen auf das Backup-WAN und meldet dann das primäre als gesund, weil sie es nicht mehr benutzt.

Binden Sie die Sonde an die Schnittstelle oder Quelladresse des Pfads, den Sie testen. Prüfen Sie auch, worauf sie zielt, denn den nächsten Hop des Providers zu erreichen beweist weniger, als den Dienst zu erreichen, für den der Tunnel existiert. Setzen Sie die Up- und Down-Verzögerungen bewusst: Eine kurze Down-Verzögerung reagiert schnell und flappt, während eine lange Ausschläge übersteht und echte Ausfälle verdeckt. Ciscos Leitfaden für Tracking und Policy-Routing in IOS XE dokumentiert die unterstützten Kombinationen, und das Funktionspaket Ihrer Plattform entscheidet, welche davon Sie nutzen können.

Notieren Sie beide Verzögerungswerte neben dem verfolgten Objekt, sonst weiß niemand, warum es sich so verhalten hat.

Entscheiden Sie die Wiederherstellung, dann prüfen Sie

Die Wiederherstellung verdient eine eigene Entscheidung. Eine Strecke, die ständig die Schwelle überschreitet, kann Sitzungen häufiger verschieben als eine, die klar ausgefallen ist, und jeder Wechsel kostet Neuaushandlung der Schlüssel und Wiederholungen der Anwendung. Wählen Sie eine Stabilitätsanforderung und lassen Sie die Verzögerung sie ausdrücken. Prüfen Sie dann in einem Änderungsfenster mit sichtbarem Sondenpfad: gewählte Route, äußerer Peer-Pfad und was die Anwendung tatsächlich getan hat.

Wenn der Failover funktioniert, die Anwendung aber weiter bricht, sitzt das Problem über der Routing-Schicht, und kein Tracking wird es beheben.

Bewahren Sie die Belege aus diesem Fenster auf, denn die nächste Änderung wird damit verglichen.