Warum Ihre BGP-Sitzung nicht in der VPC-Routentabelle auftaucht

Die Geschichte, die ständig wiederholt wird, lautet: Ein Routing-Daemon auf einer EC2-VPN-Appliance bringt der VPC ihre entfernten Präfixe bei, sobald BGP hochkommt. Die Hälfte davon stimmt. Die Sitzung kommt hoch, und in der Routentabelle der VPC ändert sich dadurch nichts, weshalb das erste Symptom meist ein Subnetz ist, das Verkehr still ins Leere schickt.

Hier werden zwei verschiedene Dinge verwechselt: das Peering mit einem Route Server und das Installieren von Routen in eine Tabelle.

Der Mythos: BGP hochbringen, und die VPC lernt die Präfixe

BGP ist ein Gespräch zwischen zwei Sprechern, und in diesem Entwurf sind die Sprecher der Routing-Daemon auf Ihrer Appliance und ein VPC-Route-Server-Endpunkt, den AWS in einem Subnetz platziert, das Ihnen gehört. Dieses Gespräch transportiert Präfixe. Es berührt die Routentabelle Ihrer Workload-Subnetze nicht, denn diese Tabellen lernen nur durch Propagation, die auf jeder einzelnen aktiviert werden muss. Bis das geschieht, weiß das VPC-Geflecht nichts von dem, was die Appliance weiß.

Die Einrichtungsschritte sind aus gutem Grund getrennt: zuordnen, den Endpunkt erstellen, peeren, dann die Propagation aktivieren.

Route Server ist eine Steuerebene, kein Tunnel

Route Server verschlüsselt, leitet und prüft kein einziges Paket. Er existiert, um BGP mit der Appliance auszutauschen und die resultierenden Präfixe an die Routentabellen zu übergeben, die für ihren Empfang konfiguriert sind. Die Datenebene bleibt unverändert: Pakete verlassen die Appliance weiterhin über ihre Netzwerkschnittstelle, reisen durch ihr VPN und kommen denselben Weg zurück.

Das heißt, die Quell- und Zielprüfung auf der weiterleitenden Instanz bleibt wichtig, denn die Instanz leitet jetzt Verkehr weiter, der an jemand anderen adressiert ist.

Sicherheitsgruppen und Subnetz-Kontrollen gelten auch für den weitergeleiteten Fluss. Route Server bringt eine Appliance, die Verkehr verwirft, nicht dazu, ihn weiterzuleiten, und er repariert keine fehlende Rückroute auf der Gegenseite.

Propagation gilt pro Routentabelle, nicht pro VPC

Den Route Server der VPC zuzuordnen und die Propagation in einer Routentabelle zu aktivieren, sind zwei Entscheidungen, und nur die zweite ändert, was ein Subnetz tut. Eine VPC mit sechs Routentabellen kann ein propagiertes Präfix in einer empfangen und in den anderen fünf nicht, was für ein Hub-Subnetz genau richtig ist und genau das verwirrende «halb funktioniert»-Ergebnis erzeugt. Selbst wo die Propagation aktiv ist, kann eine konkurrierende Route gewinnen, denn die VPC-Routenauswahl bevorzugt das längste Präfix und bei gleicher Länge eine statische Route gegenüber einer propagierten. Diese Bevorzugung wird still angewendet.

Prüfen Sie die effektive Tabelle für das konkrete Subnetz statt die Liste der Präfixe, die die Appliance annonciert. Die API beantwortet diese Frage direkt: aws ec2 associate-route-server und aws ec2 enable-route-server-propagation --route-table-id <id> sind die beiden Schritte, die Leute vergessen, und aws ec2 describe-route-tables --route-table-ids <id> zeigt, ob das Präfix überhaupt als Route-Server-Eintrag angekommen ist.

Die Appliance trägt weiterhin jedes Paket

Erreichbarkeit anzukündigen ist nicht dasselbe, sie zu haben. Eine BGP-Sitzung kann etabliert bleiben, während das VPN der Appliance ausgefallen ist, und eine statische Ankündigung, die sich nie ändert, zieht den Verkehr weiter auf einen toten Pfad. Route Server unterstützt Fehlererkennung wie BFD, aber das prüft die Lebendigkeit des Peers, nicht die Gesundheit von allem hinter dem Peer.

Binden Sie die Ankündigung an die tatsächliche entfernte Route: kündigen Sie das Präfix an, wenn der Tunnel und das entfernte Netz stehen, und ziehen Sie es zurück, wenn nicht.

Ziehen Sie ein Präfix zurück und beobachten Sie, was passiert

Testen Sie in Stufen, und machen Sie die letzte Stufe zu einer Entfernung. Bestätigen Sie, dass die Ankündigung ankommt, das Präfix in jeder vorgesehenen Tabelle erscheint, die Appliance der nächste Hop ist, die Weiterleitung den aktiven Tunnel kreuzt und das entfernte Ende antwortet. Ziehen Sie dann ein Testpräfix zurück oder schalten Sie einen genehmigten Tunnel ab, und beobachten Sie, ob der Verkehr dorthin wandert, wo der Entwurf es sagt. Halten Sie die Tabellen vorher und nachher fest, solange der Test noch läuft.

Eine Route auf eine zweite Appliance zu verschieben, verschiebt nicht die Sitzungen, die sie trug, denn NAT- und Firewall-Zustand bleiben beim ersten Gerät.

Für eine feste Menge von einem Dutzend Präfixen bleiben statische Routen in den VPC-Tabellen die günstigere Antwort. Route Server verdient seinen Platz, wenn sich die Präfixliste tatsächlich ändert und die Rückzugspolitik etwas ist, das Sie der Person im Bereitschaftsdienst erklären können.