Warum eine AWS-VGW-Subnetzroute keinen einzelnen VPN-Tunnel wählen kann

Zwei Site-to-Site-VPN-Verbindungen enden an einem virtuellen privaten Gateway und kündigen dasselbe Filialpräfix an. Die Subnetzroutentabelle enthält einen Eintrag für dieses Präfix, der auf das Gateway zeigt, und kein Feld, das einen Tunnel benennt. Die Präferenz zwischen den Verbindungen entsteht daher an einer Stelle, die die Konsole nicht als Routing bezeichnet. Zu wissen, welche Schicht die Entscheidung besitzt, ist der Unterschied zwischen einem funktionierenden Standby und einer Änderung, die nichts bewirkt.

Zwei Schichten sind im Spiel: die VPC-Route, die das Gateway benennt, und die eigene Tunnelwahl des Gateways. Wer sie verwechselt, erzeugt Änderungen, die in der Routentabelle korrekt aussehen und nie ein Paket bewegen.

Zwei Schichten, die wie eine aussehen

Die Subnetzroute beantwortet eine einzige Frage: für dieses Ziel, welcher Anhang? Ihr Ziel ist das virtuelle private Gateway, und ihre Metrik konkurriert nur mit anderen Routen derselben Tabelle. Nichts in diesem Eintrag unterscheidet Tunnel eins von Tunnel zwei oder Verbindung A von Verbindung B. Ein spezifischeres Präfix ist eine andere Zielübereinstimmung, keine feinere Pfadwahl.

Das Gateway beantwortet die nächste Frage: unter den Tunneln, die es für dieses Präfix hält, welcher trägt jetzt Verkehr. Diese Entscheidung stammt aus dem Tunnelzustand und den vom Kundengateway empfangenen BGP-Attributen, und sie erscheint nie in der Subnetzroutentabelle.

Was das VGW tatsächlich vergleicht

Der Zustand kommt zuerst. Ein Tunnel, der ausgefallen ist, oder eine BGP-Sitzung, die nicht hochgekommen ist, verliert, bevor irgendein Attribut geprüft wird. Deshalb ändert ein vorangestellter Pfad auf einer ohnehin scheiternden Verbindung nichts.

Unter den zulässigen Pfaden für dasselbe Präfix bevorzugt AWS den kürzeren AS_PATH. Sind zwei Pfade gleich lang, vergleicht es MED, vorbehaltlich der dokumentierten Bedingung zum ersten AS im Pfad. Lesen Sie die veröffentlichte Reihenfolge statt der Folklore-Version, denn die Folklore lässt meist den Zustandsschritt und die Ausnahme für statische Routen weg. Eine Konsequenz: drei Voranstellungen auf der Backup-Verbindung machen die primäre strikt kürzer, und das ist die übliche Art, die Präferenz auszudrücken.

Voranstellen, und wann es nichts bewirkt

Voranstellen geschieht in den ausgehenden Ankündigungen des Kundengateways, nicht innerhalb von AWS. Sie hängen Ihre eigene ASN zwei- oder dreimal an das Präfix, das AWS meiden soll, und AWS sieht dann einen längeren Pfad für diese Verbindung. Die primäre Verbindung behält die Ankündigung ohne Voranstellung. Kündigen beide Verbindungen aus derselben ASN mit derselben Anzahl von Voranstellungen an, haben Sie keine Präferenz ausgedrückt.

Prüfen Sie nach der Änderung den empfangenen Pfad auf der AWS-Seite. Eine Voranstellung, die das Kundengerät nie verlassen hat, sieht genau so aus wie eine, die AWS ignoriert hat.

Statische Routen ignorieren das ganze Argument

Nutzt die Verbindung statisches Routing, gibt es keinen AS_PATH zu verlängern. AWS dokumentiert statische VPN-Routen als vorrangig gegenüber über BGP gelernten Routen für dasselbe Präfix, ein gemischtes Design verhält sich also nicht wie ein vollständig dynamisches. Entscheiden Sie zuerst über den Routingtyp und wählen Sie dann den Präferenzmechanismus, den es dafür gibt.

Bei zwei statischen Verbindungen, die dasselbe Präfix ankündigen, ist der nützliche Hebel das Präfix: kündigen Sie einen spezifischeren Bereich auf der gewünschten Verbindung an, und akzeptieren Sie, dass Sie geändert haben, welches Ziel übereinstimmt, nicht welcher Pfad gewinnt.

Warum ein Transit-Gateway eine andere Antwort ist

Ein Transit-Gateway unterstützt Equal-Cost-Multipath über VPN-Anhänge, sodass zwei Verbindungen Verkehr teilen können, statt dass eine im Standby steht. Dieses Design hat eine andere Fehlerfläche: Flows verteilen sich über Tunnel, und ein ausfallender Tunnel verschiebt nur einen Teil der Last. Ein VGW-Rezept auf ein Transit-Gateway zu kopieren, oder umgekehrt, erzeugt Erwartungen, die keine der beiden Plattformen erfüllt.

Wählen Sie das Modell vor dem Mechanismus: aktiv und Standby mit festgelegter Präferenz, oder aktiv und aktiv mit ECMP.

Was nach der Einrichtung zu prüfen ist

Bestätigen Sie vier Dinge der Reihe nach. Die Subnetztabelle löst das Präfix weiterhin auf das beabsichtigte Gateway auf. Das Gateway führt beide Tunnel als aktiv. Der empfangene AS_PATH auf der Verbindung, die Sie meiden wollen, ist länger als der andere. Und ein echter Flow von einer Instanz in diesem Subnetz nimmt den erwarteten Tunnel, an beiden Enden beobachtet statt aus einem grünen Status abgeleitet.

Führen Sie dann den freigegebenen Failover-Test aus und beobachten Sie, wie der überlebende Pfad den Dienst trägt. Eine Präferenz, die nur in einem Konfigurationsdiff existiert, ist noch keine Präferenz.