Welche VRF erreicht den VPN-Peer und welche trägt das Paket?

Jeder Tunnel innerhalb eines Kunden-Routingkontexts muss seinen entfernten Peer trotzdem erreichen, und dieser Lookup kann in einer völlig anderen Tabelle stattfinden. Ein Fehler hier erzeugt einen der verwirrendsten Ausfälle in VRF-bewusstem IPsec: Der Tunnel kommt hoch, die Routen scheinen vorhanden zu sein, und der Verkehr stirbt, weil einer der beiden Lookups den falschen Kontext verwendet hat. Führen Sie die vier Schritte unten der Reihe nach aus und halten Sie die beiden Ziele getrennt schriftlich fest.

Zwei Lookups, ein Tunnel

Das äußere gekapselte Paket ist an die Transportadresse des Peers adressiert und wird geroutet, bevor irgendein Schutz existiert. Das innere Paket ist an einen Kundenserver adressiert und wird nach der Entkapselung geroutet, innerhalb des Kundenkontexts. Das sind zwei Ziele, zwei Lookups und oft zwei verschiedene Tabellen.

Die Cisco-Dokumentation für VRF-bewusstes IPsec nennt sie Front-Door-VRF und Inside-VRF. Das Front Door trägt den verschlüsselten Transport, und der Inside-Kontext trägt den geschützten Verkehr. Nichts daran, einen Tunnel nach einem Kunden zu benennen, lässt eine der beiden Routen erscheinen.

Listen Sie daher vier Fakten auf, bevor Sie eine Konfiguration ändern: die Transportadresse des Peers und den Kontext, der sie erreicht, dann das Serverpräfix und den Kontext, der es erreicht. Wenn Sie nicht alle vier ausfüllen können, stehen Sie kurz davor zu raten. Raten ist in diesem Bereich teuer, denn eine Route in der falschen Tabelle kann einen Fluss funktionieren lassen und einen anderen still brechen. Die vier Fakten brauchen zehn Minuten zum Sammeln und sparen einen Tag Paketanalyse.

Bestätigen Sie den Transport-Lookup für den Peer

Beginnen Sie mit dem Front Door, denn ein Tunnel, der seinen Peer nicht erreicht, wird niemals ein einziges geschütztes Paket durchlassen. Fragen Sie unter IOS die Route zum Peer innerhalb der Transport-VRF ab und nicht in der globalen Tabelle.

show ip route vrf wan-blue 203.0.113.20
show ip vrf brief
show crypto ikev2 sa

Der erste Befehl beantwortet, ob die Peer-Adresse in diesem Kontext erreichbar ist, der zweite listet die VRFs auf, die tatsächlich existieren, und der dritte zeigt, ob eine Sicherheitsassoziation entstanden ist. Eine Peer-Adresse, die nur in der globalen Tabelle aufgelöst wird, ist der klassische Front-Door-Fehler, und er zeigt sich als IKE-Verhandlung, die nie beginnt.

Prüfen Sie auch die Schnittstellenzuordnung. Das dokumentierte Verhalten verlangt, dass die Front-Door-VRF des Tunnels und die VRF der WAN-Schnittstelle übereinstimmen; eine Abweichung kann ein Paket hinauslassen und dennoch verhindern, dass die Antwort im richtigen Kontext verarbeitet wird.

Bestätigen Sie den Inside-Lookup für den Server

Wenn das Front Door bewiesen ist, wechseln Sie in den Kundenkontext und stellen dieselbe Frage zum Serverpräfix. Dieser Lookup entscheidet, ob ein entkapseltes Paket weitergeleitet werden kann.

show ip route vrf customer-blue 10.60.4.0
show crypto session detail

Der erste Befehl zeigt die Inside-Route, der zweite den Sitzungszustand zusammen mit den Kontexten, die die Plattform damit verbunden hat. Wenn die Route existiert, die Sitzungsdetails aber den falschen Inside-Kontext nennen, leitet der Tunnel in eine Tabelle weiter, die das Kundenpräfix nicht kennt.

Eine Route in der globalen Tabelle ist kein Beleg für einen der beiden Lookups. Globale Routen werden verwendet, wenn ein Paket keinem VRF zugeordnet ist, und eine Tunnelschnittstelle, die einem Kundenkontext zugewiesen ist, ändert diese Zuordnung. Fehlt die Inside-Route, wird das Paket entkapselt und dann mangels Weiterleitungseintrag verworfen, was wie Paketverlust aussieht und nicht wie ein Routingfehler.

Setzen Sie die Einstellung dorthin, wo das Modell sie erwartet

Dieselbe Dokumentation unterscheidet Konfigurationsmodelle, und eine Einstellung, die zu einem gehört, gehört nicht zwangsläufig zu einem anderen. Bei Tunnelschnittstellen mit Tunnelschutz wird die Inside-VRF auf der Tunnelschnittstelle definiert. Bei crypto map-basierten Designs ist die Inside-VRF Teil des crypto map-Eintrags. Einen ähnlich benannten Befehl ohne Prüfung seiner Rolle zwischen Modellen zu verschieben, ist der Weg, auf dem ein funktionierendes Design unregelmäßig wird.

Routing und Identität sind getrennte Angelegenheiten. Erreichbarkeit ersetzt niemals ein Peer-Profil, das das Gerät akzeptiert, und eine VRF-Umbenennung darf die angebotenen Anmeldedaten nicht ändern. Prüfen Sie beides nach jeder Änderung, denn ein Tunnel, der mit dem falschen Profil verhandelt, kann trotzdem eine Assoziation bilden und nichts weiterleiten.

Schließlich halten Sie die vier Fakten und die Befehle, die sie bewiesen haben, im Änderungsprotokoll fest. Der nächste Ingenieur erbt den Tunnel und nicht die Begründung, und eine kurze Notiz, die beide Kontexte nennt, ist mehr wert als ein Diagramm, das niemand aktualisiert.