BGP hat das Präfix gelernt, doch der Verkehr umgeht den Tunnel weiterhin

Das Zweigstellen-Gateway zeigt das Cloud-Präfix in seiner BGP-Tabelle, die Sitzung zum Anbieter ist aufgebaut, und trotzdem verlässt die Anfrage eines Nutzers an dieses Präfix die falsche Schnittstelle. Nichts ist so kaputt, wie das Monitoring nahelegt, denn „BGP hat es gelernt“ ist eine Aussage über die Steuerungsebene. Zwischen dieser Tabelle und dem Paket liegen vier getrennte Übergänge, und der Fluss bleibt an genau einem davon stehen. Gehen Sie die Tore der Reihe nach durch und halten Sie beim ersten an, das scheitert.

Erstes Tor: was der Nachbar tatsächlich gesendet hat

Beginnen Sie mit dem Präfix so, wie es empfangen wurde, nicht wie es zusammengefasst ist. Suchen Sie das exakte Netz und die Maske in der BGP-Tabelle und notieren Sie den nächsten Hop, den AS-Pfad und jede Community, auf die eine Importrichtlinie passen könnte. Eine Sammelroute in einem Dashboard kann verbergen, dass das konkrete Präfix nie akzeptiert wurde.

Die Importrichtlinie ist der übliche Ort, an dem eine Route ohne Fehler verschwindet. Eine Präfixliste, ein Community-Filter oder eine eingehende Routenmap kann das Update verwerfen, während die Sitzung oben und gesund bleibt, weshalb ein grünes Nachbarlicht so wenig beweist. Das Fehlen einer Logzeile bedeutet nicht das Fehlen einer Entscheidung. Meist heißt es, die Entscheidung fiel still, genau wie konfiguriert.

show ip bgp 10.60.20.0/24
show ip bgp neighbors 203.0.113.5 advertised-routes
show ip route 10.60.20.0
show ip cef 10.60.20.0

Lesen Sie die Ausgabe in dieser Reihenfolge. Die ersten beiden Befehle sagen, ob die Information ankam und was der Peer zu senden behauptet; die letzten beiden, ob etwas die Routing- und Weiterleitungstabellen erreicht hat. Ein Präfix, das im ersten Befehl vorhanden und im dritten abwesend ist, ist ein Auswahl- oder Installationsproblem, kein Konnektivitätsproblem.

Zweites Tor: Auswahl, dann Installation

BGP wählt einen besten Pfad, und der gewählte Pfad wird nicht automatisch installiert. Der nächste Hop muss aufgelöst werden, und eine andere Routenquelle besitzt das Präfix womöglich bereits mit besserer administrativer Distanz. Eine statische Route, die von der Migration übrig blieb, gewinnt ohne Weiteres gegen einen gültigen BGP-Pfad und schickt den Verkehr woandershin.

RFC 4271 hält drei Ideen auseinander: was ein Peer gesendet hat, was dieser Speaker als besten gewählt hat und was er weiter ankündigen wird. Das sind konzeptionelle Rollen, nicht drei physische Datenbanken, die ein Hersteller offenlegen muss, doch genau diese Trennung macht „es steht in BGP“ zu einer unvollständigen Antwort.

Prüfen Sie auch, welchen Routingkontext Sie lesen. Eine Route, die in einer VRF installiert ist, zu der die Schnittstelle des Nutzers nicht gehört, ist für dessen Pakete unsichtbar, und die Tabelle sieht die ganze Zeit korrekt aus.

Drittes Tor: die Suche, die für diesen Fluss gilt

Hören Sie nun auf, nach der Route zu fragen, und fragen Sie nach dem Paket. Notieren Sie Quelladresse, Ziel, Protokoll, Port und Eingangsschnittstelle des Nutzers, denn jede davon kann eine andere Richtlinie auswählen. Schauen Sie dann auf die Suche, die für diese Kombination gilt, statt auf die allgemeine Routingtabelle.

ip route get 10.60.20.25 from 10.60.10.40
ip rule show
sudo tcpdump -ni tun0 'host 10.60.20.25'

Ein spezifischeres Präfix ist hier die häufigste Überraschung, eine Policy-Route die zweite. Beide überstimmen die Aggregatroute, die Sie betrachtet haben, und keine von beiden ist in einer Zusammenfassung der BGP-Tabelle sichtbar.

Ein Ping vom Gateway selbst ist kein Beleg über die Sitzung eines Nutzers. Andere Quelladresse, anderer Richtlinienpfad und oft ein anderes Ergebnis. Testen Sie mit derselben Quelle, die die Anwendung nutzt, oder akzeptieren Sie, dass der Test eine andere Frage beantwortet.

Viertes Tor: die ferne Hälfte des Pfades

Wenn die lokale Suche den Tunnel tatsächlich auswählt, muss das Paket noch von der Schutzrichtlinie akzeptiert, von der Weiterleitungsregel erlaubt und von etwas auf der Gegenseite beantwortet werden. Eine Crypto-ACL ohne das Adresspaar verwirft den Verkehr, während der Tunnel sich als oben meldet, was einen Timeout erzeugt, der von einem Routingfehler nicht zu unterscheiden ist.

Der Rückweg zählt genauso viel wie der Hinweg. Die Cloud-Seite muss wissen, wie sie die Zweigstellenquelle erreicht, sei es über eine Route oder über eine Übersetzung, die Sie bewusst konfiguriert haben. Asymmetrische Rückwege sind in Entwürfen üblich, die nur aus einer Richtung getestet wurden.

Korrelieren Sie eine frische autorisierte Verbindung über drei Beobachtungen: die lokale Richtlinie, die gepasst hat, die Tunnelzähler, die sich bewegt haben, und den Empfang auf der fernen Seite, wo er sichtbar ist. Bewegen sich die Zähler nicht, ist das Paket nie in den Tunnel gelangt, egal was die Routentabelle sagt. Bewegen sie sich und kommt nichts an, verwirft oder fehlleitet die ferne Seite es. Diese beiden Ergebnisse führen zu völlig verschiedenen Teams.

Benennen Sie den Übergang, der gescheitert ist

Schreiben Sie das Ergebnis als einen von fünf Zuständen: nicht empfangen, nicht von der Richtlinie akzeptiert, nicht ausgewählt, nicht installiert oder von diesem Fluss nicht getroffen. Fügen Sie einen sechsten für den Fall hinzu, dass der lokale Pfad korrekt ist und das ferne Ende nicht antworten kann. Dieser Satz ist das Ergebnis und weit nützlicher als ein Screenshot eines aufgebauten Nachbarn.

Behalten Sie auch einen Negativtest im Abnahmeplan: ein Ziel, das den Tunnel nicht durchlaufen darf, geprüft nach der Änderung. Eine Checkliste, die nur den glücklichen Pfad belegt, fängt die breite Richtlinienregel nicht ab, die jemand im nächsten Wartungsfenster hinzufügt.