BGP-Sitzung steht, Kundenpfad ist kaputt: MPLS über DMVPN

Das Peering steht seit Wochen, die Prefix-Zahl sieht richtig aus, und trotzdem nimmt der Verkehr eines Kunden weiter den langen Weg oder kommt nie an. Zwei verschiedene Dinge werden an derselben Anzeige beurteilt. Eine BGP-Sitzung meldet, dass zwei Peers über eine TCP-Verbindung Nachrichten austauschen können; über die Frage, ob das Overlay ein gelabeltes Paket für genau diesen Kunden tragen kann, sagt sie nichts.

Diese Lücke sieht man am leichtesten in einem MPLS-over-DMVPN-Design, wo der Hub-Pfad und der direkte Spoke-Pfad sich aus Gründen unterschiedlich verhalten können, die nichts mit dem Peering zu tun haben.

Was die Sitzung tatsächlich beweist

BGP läuft über TCP, also braucht jeder Peer eine Route zur Adresse des anderen Endpunkts, bevor irgendetwas anderes passieren kann. Wählen Sie ein Loopback als diesen Endpunkt, haben Sie eine Erreichbarkeitsanforderung geschaffen, keine Weiterleitungsgarantie. Die Sitzung kann dann über eine Schnittstelle bestehen bleiben, die der Kundenverkehr nie nutzen würde.

Notieren Sie an beiden Enden vier Fakten, bevor Sie Schlüsse ziehen: die Quelladresse der Sitzung, ihre Zieladresse, den Routing-Kontext, in dem sie liegt, und welche Schnittstelle der Kernel oder Router für dieses Paar wählen würde. Diese Fakten beschreiben die Steuerungsebene. Kundenpakete fügen darüber eine VRF, einen Label-Stack und ein Overlay-Mapping hinzu.

Vier Mechanismen, nicht einer

Ciscos Dokumentation zu MPLS über DMVPN trennt die Teile sauber. MP-BGP verteilt die Overlay-Labels des Kunden zwischen den Geräten am Provider-Rand. MPLS nutzt diese Labels, um den Weiterleitungskontext für ein Paket zu wählen. NHRP ordnet eine Overlay-Adresse dem Transportendpunkt zu, den ein dynamischer Tunnel braucht. IPsec schützt den Peer-Pfad, wo es greift.

Jeder der vier kann richtig sein, während ein anderer falsch ist, und die Kombination trägt den Verkehr. Ein Routenaustausch kann abgeschlossen sein, während die Label-Bindung für eine VRF fehlt, während das NHRP-Mapping auf eine veraltete Transportadresse zeigt oder während der Tunnel existiert, aber keine Policy das innere Paket erlaubt. Keine dieser Bedingungen bringt die Sitzung zum Abfallen.

Vergleichen Sie den Hub-Pfad mit der Abkürzung, jeweils eine Variable

Fixieren Sie Quellhost, Zielhost und VRF und verfolgen Sie dann denselben Fluss zweimal. Auf dem Hub-Pfad notieren Sie den nächsten Hop, das Service-Label, das den entfernten Kundenkontext identifiziert, und das verwendete Overlay-zu-Transport-Mapping. Auf dem beabsichtigten direkten Pfad notieren Sie dieselben drei Dinge. Die Differenz zwischen den beiden Listen ist der Fehler, oder sein Fehlen.

Halten Sie den Fluss während des Vergleichs konstant. Quellhost, VRF oder Ziel zwischen den Beobachtungen zu wechseln, erzeugt zwei unzusammenhängende Geschichten, und das ist der häufigste Weg, auf dem diese Übung schiefgeht.

Halten Sie Loopback-Tests in ihrem eigenen Abteil

Ein Ping mit Quelladresse eines Router-Loopbacks ist ein nützlicher Test, und er prüft einen anderen Fall als ein Fluss von einem Host. Die Quelladresse gehört dem Router, sein Routing-Kontext kann global statt einer VRF sein, und der Antwortpfad kann sich von dem unterscheiden, den ein Kundenprefix nehmen würde. Also sind das antwortende Loopback und die über die Abkürzung funktionierende Anwendung getrennte Ergebnisse, und nur das zweite beschreibt den Kunden.

Testen Sie beides und kennzeichnen Sie es dann getrennt in Ihren Notizen. Wenn sie sich widersprechen, haben Sie etwas Konkretes darüber gelernt, wo das Design abweicht, und das ist mehr, als ein einzelnes grünes Häkchen je sagen wird.

Versions- und Defektaussagen brauchen eigene Belege

Feldberichte empfehlen manchmal, eine Hostmaske oder eine BGP-Quelladresse zu ändern, und solche Berichte lohnt es sich nur zusammen mit dem Defekt zu lesen, über den sie geschrieben wurden, und den betroffenen Releases. Ein Workaround aus einem Release ist keine Aussage, dass jedes /32-Prefix von der Architektur nicht unterstützt wird.

Verwenden Sie Dokumentation, die zu Ihrer DMVPN-Phase, Plattform und Ihrem Release passt, und bedenken Sie, dass ein Kapitel mehrere Anordnungen abdecken kann, einschließlich FlexVPN. Ein Beispiel aus einer Anordnung überträgt sich nicht stillschweigend auf eine andere. Wählen Sie Sitzungsendpunkte für das Steuerungsebenen-Design, das Sie tatsächlich brauchen, und prüfen Sie dann den Weiterleitungspfad des Kunden getrennt, denn das Umschreiben jeder Loopback-Maske ersetzt nicht die Feststellung, welche Aufgabe fehlgeschlagen ist.