GCP BYOIP: öffentliche Ankündigung ist keine private Route

Ein Teil eines öffentlichen Blocks bleibt am Standort, ein Teil wandert in Google Cloud. Dieser Satz beschreibt zwei Pläne, nicht einen: einen Plan für die Internetankündigung und einen Plan für die private Weiterleitung. Sie als ein einziges Routingproblem zu behandeln, ist der Punkt, an dem BYOIP-Designs schiefgehen.

Die beteiligten Objekte beantworten unterschiedliche Fragen, und nur eines davon betrifft den nächsten Weg der Pakete.

Drei Objekte, drei Fragen

Ein öffentlich angekündigtes Präfix ist die Einheit, die Google in Ihrem Namen im Internet ankündigt. Ein öffentlich delegiertes Präfix beschreibt, wie importierter Adressraum auf unterstützte Cloud-Ressourcen verteilt wird. Eine VPC-Route, auch eine über Cloud Router von einem VPN gelernte, wählt einen privaten nächsten Hop. Jedes hat seinen eigenen Geltungsbereich, seine eigene API und seine eigene Fehlermeldung.

Die Tabellenversion ist kürzer.

Nur die dritte Zeile betrifft die Weiterleitung innerhalb Ihres Netzwerks.

Was die BYOIP-Überlappungswarnung abdeckt

Die BYOIP-Dokumentation von Google behandelt das angekündigte Präfix als Ankündigungseinheit und warnt vor überlappenden externen Ankündigungen, einschließlich eines außerhalb von Google angekündigten Subpräfixes. Diese Warnung betrifft den Plan der öffentlichen Ankündigung. Sie ist keine Aussage über jede private Route, die Sie hinzufügen könnten.

Eine kleinere Zuweisung innerhalb eines importierten Präfixes zu delegieren, gibt Ihnen für sich genommen nicht die Erlaubnis, den Rest von einem anderen Ursprung aus anzukündigen.

Stellen Sie die Frage danach, wer was ankündigt. Wenn Google das gesamte importierte Präfix ankündigt, erzeugt ein zweiter Ursprung, der ein Subpräfix ankündigt, genau die Überlappung, vor der die Dokumentation warnt, so ordentlich Ihre VPC-Routen auch aussehen.

Was eine private Route entscheidet

Ein über ein VPN gelerntes Präfix ist keine Internetankündigung, und keine Menge an BGP macht daraus eine. Es ist ein Eintrag in einer VPC-Routentabelle, der angibt, welcher Tunnel oder welches Gateway den Verkehr für dieses Ziel tragen soll. Ob dieser Eintrag zulässig, ausgewählt oder nutzbar ist, hängt von den Routingregeln der VPC selbst ab.

Die Übereinstimmung des längsten Präfixes gilt innerhalb der Routentabelle, sodass eine längere VPN-Route lokal gewinnen kann, ohne am öffentlichen Rand etwas zu ändern.

Ein Präfix aufteilen: die Entscheidung, die zuerst kommt

Wenn die Architektur verlangt, dass die eine Hälfte des Blocks aus einem Rechenzentrum und die andere Hälfte von Google angekündigt wird, klären Sie den Ankündigungsplan, bevor Sie irgendetwas importieren. Bestätigen Sie, welche Bereiche Google ankündigen darf, welche anderswo angekündigt bleiben und ob sich beide überlappen. Entwerfen Sie dann den privaten Pfad für jedes Ziel und dessen Rückweg. Wenn die Anbieter die gewünschte Aufteilung nicht unterstützen, ändern Sie die Aufteilung, statt zu hoffen, dass ein längeres VPN-Präfix eine Entscheidung am öffentlichen Rand überstimmt.

Diese Reihenfolge zählt, weil der zweite Plan den ersten nicht reparieren kann.

Prüfen Sie beide Pläne getrennt

Prüfen Sie die öffentliche Seite mit gcloud compute public-advertised-prefixes list und bestätigen Sie die Bereiche und ihren Status. Prüfen Sie die private Seite mit gcloud compute routes list und gcloud compute routers get-status, was zeigt, was BGP tatsächlich ausgetauscht hat.

Ein Satz Ausgaben sagt Ihnen, was das Internet sieht. Der andere sagt Ihnen, wohin Ihr Verkehr geht. Keiner ersetzt den anderen.