Dynamische Routinggateways
In diesem Thema wird beschrieben, wie ein dynamisches Routinggateway (DRG) verwaltet wird. In diesem Thema werden die Begriffe Dynamisches Routinggateway und DRG synonym verwendet. In der Konsole wird der Begriff Dynamisches Routinggateway verwendet, während die API die Kurzform DRG verwendet.
Ein DRG ist ein virtueller Router, an den Sie die folgenden Ressourcen anhängen können:
- VCNs
- Remote-Peering-Verbindungen
- Site-to-Site-VPN-IPSec-Tunnel
- Oracle Cloud Infrastructure FastConnect virtuelle Verbindungen
Ein DRG kann viele Netzwerkanhänge der folgenden Typen haben:
- VCN-Anhänge: Sie können viele VCNs an ein einzelnes DRG anhängen. Jedes VCN kann sich in demselben Mandanten wie das DRG oder in einem anderen Mandanten befinden (vorausgesetzt, die entsprechenden Policys sind festgelegt). Ein VCN kann nur an ein DRG angehängt sein.
- RPC-Anhänge: Mit Remote-Peering-Verbindungen können Sie ein Peering mit einem DRG zu anderen DRGs durchführen. Das andere DRG kann sich in anderen Regionen oder Mandanten oder in derselben Region befinden.
- IPSEC_TUNNEL-Anhänge: Mit Site-to-Site-VPN können Sie zwei oder mehr IPsec-Tunnel an ein DRG anhängen, um eine Verbindung zu On-Premise-Netzwerken herzustellen. Dies ist auch mandantenübergreifend zulässig.
- VIRTUAL_CIRCUIT-Anhänge: Sie können mindestens einen FastConnect-Virtual Circuit an das DRG anhängen, um eine Verbindung zu On-Premise-Netzwerken herzustellen.
- LOOPBACK-Anhänge: Mit Site-to-Site-VPN können Sie FastConnect-Virtual Circuits verschlüsseln. Weitere Informationen finden Sie unter Loopback-Anhänge.
Durch das Erstellen von DRG-Routentabellen und DRG-Routenverteilungen können Sie Routing-Policys definieren, die den Traffic zwischen Anhängen weiterleiten. Routen können über diese Anhänge dynamisch importiert und exportiert werden. Eine Routentabelle muss mit einem Anhang verknüpft sein, damit die Konfiguration dieser Tabelle angewendet werden kann. Es kann jedoch eine nicht verknüpfte Routingtabelle vorhanden sein. DRG-Routenverteilungen haben einen expliziten Typ (Import oder Export). Sie erben keine Aktion, die davon abhängt, wo sie verknüpft sind.
Dynamische Routinggateways - Überblick
Ein DRG fungiert als virtueller Router, der einen Pfad für Traffic zwischen On-Premise-Netzwerken und VCNs bereitstellt. Es kann auch zur Weiterleitung von Traffic zwischen VCNs verwendet werden. Mit verschiedenen Anhangstypen können benutzerdefinierte Netzwerktopologien erstellt werden, die sich aus Komponenten aus verschiedenen Regionen und Mandanten zusammensetzen. Jeder DRG-Anhang verfügt über eine verknüpfte Routentabelle, mit der im DRG eingehende Pakete an ihren nächsten Hop weitergeleitet werden. Neben statischen Routen werden Routen aus den angehängten Netzwerken dynamisch mit optionalen Importroutenverteilungen in DRG-Routentabellen importiert.
Mit DRGs und DRG-Anhängen arbeiten
Ein vor April 2021 erstelltes DRG kann kein Transitrouting zwischen On-Premise-Netzwerken und VCNs ausführen oder Peering zwischen VCNs bereitstellen. Wenn Sie diese Funktionalität benötigen und in der Konsole die Schaltfläche Upgrade für DRG durchführen angezeigt wird, klicken Sie darauf. Durch ein Upgrade des DRG werden alle vorhandenen BGP-Sessions zurückgesetzt, und der Traffic vom On-Premise-Netzwerk wird vorübergehend unterbrochen. Nach dem Start des Upgrades ist ein Rollback nicht mehr möglich. Siehe DRG upgraden.
Beim Erstellen eines DRG müssen Sie das Compartment angeben, in dem das DRG gespeichert werden soll. Durch das Platzieren des DRG in einem Compartment kann die Zugriffskontrolle eingeschränkt werden. Wenn Sie nicht sicher sind, welches Compartment Sie verwenden sollen, legen Sie das DRG im selben Compartment wie das von Ihnen regelmäßig verwendete VCN ab. Weitere Informationen finden Sie unter Zugriffskontrolle.
Sie können dem DRG optional einen Anzeigenamen zuweisen. Er muss nicht eindeutig sein und kann später geändert werden. Oracle weist dem DRG automatisch eine eindeutige ID zu, die als Oracle Cloud-ID (OCID) bezeichnet wird. Weitere Informationen finden Sie unter Ressourcen-IDs.
Ein DRG muss an andere Netzwerkressourcen angehängt sein, damit es verwendet werden kann. In der API wird beim Anhängen ein DrgAttachment
-Objekt mit einer eigenen OCID erstellt. DrgAttachment
enthält ein Typfeld mit dem Typ des Objekts, das an das DRG angehängt wird. Das Typfeld kann auf einen der folgenden Werte gesetzt werden:
- VCN
- VIRTUAL_CIRCUIT
- IPSEC_TUNNEL
- REMOTE_PEERING_CONNECTION
- LOOPBACK (Weitere Informationen finden Sie unter LOOPBACK-Anhänge.)
Verwenden Sie zum Anhängen eines VCN an ein DRG den Vorgang CreateDrgAttachment
oder die Konsole, um das DRG-Anhangsobjekt explizit zu erstellen. Anhänge für Virtual Circuits, IPSec-Tunnel und Remote-Peering-Verbindungen werden automatisch für Sie erstellt (und gelöscht), wenn Sie das Netzwerkobjekt erstellen (oder löschen).
Mit DRG-Routentabellen und -Routenverteilungen arbeiten
Ein Paket tritt über einen Anhang in ein DRG ein und wird anhand von Regeln in der DRG-Routentabelle, die diesem Anhang zugewiesen ist, weitergeleitet. Sie können mehrere DRG-Anhänge dieselbe Routentabelle zuweisen oder je nach den gewünschten Routing-Policys eine dedizierte Routentabelle für jeden Anhang erstellen.
Wenn Sie ein DRG erstellen, werden zwei Standardroutentabellen für Sie erstellt: eine für VCN-Anhänge und eine für alle anderen Anhänge. Wenn eine Routentabelle als Standardroutentabelle für einen Anhangstyp festgelegt wird, wird die Tabelle neu erstellten Anhängen dieses Typs zugewiesen, es sei denn, es wird explizit eine alternative Tabelle angegeben. Routentabellen, die als Standard für einen beliebigen Typ angegeben sind, können nicht gelöscht werden. Stellen Sie sicher, dass eine Routing-Tabelle nicht als Standard-Routentabelle für einen Anhangstyp festgelegt ist, bevor Sie versuchen, sie zu löschen.
Ein VCN-Anhang verfügt über zwei Routentabellen: eine DRG-Routingtabelle für Traffic, der im DRG eingeht, und eine VCN-Routingtabelle für Traffic, der im VCN eingeht. Die DRG-Routentabelle ist im DRG vorhanden und wird verwendet, um Pakete, die im DRG eingehen, über den Anhang weiterzuleiten. Mit der VCN-Routentabelle werden Pakete, die im VCN eingehen, über den Anhang weitergeleitet. Wenn keine VCN-Routentabelle definiert ist, bietet eine verborgene implizite Tabelle immer Konnektivität zu allen Subnetzen im VCN.
Dynamische Importroutenverteilungen
Eine Verteilung ist eine Liste deklarativer Anweisungen, die ein Übereinstimmungskriterium (wie eine OCID oder einen Anhangstyp) und eine Aktion enthalten. Mit Routenverteilungen können Sie angeben, wie Routen aus einem DRG-Anhang importiert oder in einen DRG-Anhang exportiert werden. Für jedes DRG werden zwei automatisch generierte Importroutenverteilungen erstellt: eine nur für VCN-Routen und eine für alle Routen. Sie können weitere Importroutenverteilungen erstellen.
DRG-Routentabellen enthalten sowohl statische als auch dynamische Routen. Statische Routen werden mit der API in Tabellen eingefügt. Dynamische Routen werden aus Anhängen importiert und anhand einer Importroutenverteilung eingefügt. Wenn das Kriterium einer Anweisung mit einem Anhang übereinstimmt, werden die Routen, die mit dem an das DRG angehängten Netzwerkobjekt verknüpft sind, dynamisch in die DRG-Routentabelle importiert, die der entsprechenden Verteilung zugewiesen ist. Wenn die Anweisung aus der Verteilung entfernt wird, werden die Routen aus den DRG-Routentabellen zurückgezogen. Anweisungen in einer Routenverteilung werden in einer Prioritätsreihenfolge ausgewertet: Die niedrigste Zahl hat die höchste Priorität. Die Reihenfolge, in der Anweisungen ausgewertet werden, wirkt sich nicht auf das Voreinstellungsset für die von ihnen importierten Routen aus.
Beim Erstellen von Routenverteilungsanweisungen in der Konsole können Sie eine Anweisung mit dem Übereinstimmungstyp "Alle entsprechen" erstellen. Codieren Sie in der API eine "match all"-Anweisung, indem Sie das Übereinstimmungskriterium auf die leere Liste setzen.
Wie gelangen dynamische Routen zu einem Anhang?
Routen zu Ihren On-Premise-Netzwerken werden vom CPE mithilfe des BGP IPsec-Tunneln und Virtual-Circuit-Anhängen angeboten. Routen werden dynamisch von einem RPC-Anhang an einem DRG zu einem RPC-Anhang an einem anderen DRG über verbundene RPCs propagiert. Dynamische Routen in einem VCN umfassen entweder alle Subnetz-CIDRs oder alle VCN-CIDRs und alle statischen Routen-CIDRs, die in der mit dem DRG-Anhang verknüpften VCN-Routentabelle konfiguriert sind. Die Eigenschaft vcnRouteType des VCN-Anhangs bestimmt, ob die Subnetz-CIDRs oder VCN-CIDRs an den VCN-Anhang propagiert werden. Standardmäßig werden die Subnetz-CIDRs importiert. Dieses Verhalten kann jedoch geändert werden, wenn Sie den VCN-Anhang erstellen oder aktualisieren. Weitere Informationen finden Sie unter Routenaggregation.
Dynamische Exportroutenverteilungen
Wenn ein Anhang einer DRG-Routentabelle zugewiesen wird, kann der Inhalt dieser Tabelle dynamisch in den Anhang exportiert werden. Wenn die standardmäßige Exportroutenverteilung einem Anhang zugewiesen wird, wird der gesamte Inhalt der DRG-Routentabelle, die dem Anhang zugewiesen ist, dynamisch in den Anhang exportiert. Um dynamische Routenexporte in einen Anhang zu deaktivieren, verwenden Sie den API-Vorgang removeExportDrgRouteDistribution
, um das Feld exportDrgRouteDistributionId
des Anhangs auf NULL zu setzen. Der Export dynamischer Routen in VCN-Anhänge wird nicht unterstützt.
Für jedes DRG wird eine automatisch generierte Exportroutenverteilung erstellt. Sie können andere Exportroutenverteilungen mit der CLI und API erstellen und anhängen.
Einschränkungen der Routenpropagierung
Von einem IPsec-Tunnel oder Virtual Circuit importierte Routen werden niemals in andere IPsec-Tunnel oder Virtual Circuit-Anhänge exportiert, unabhängig davon, wie die Exportroutenverteilung konfiguriert ist. Ähnlich können Pakete, die über einen IPsec-Tunnel oder Virtual Circuit-Anhang im DRG eingehen, das DRG niemals über einen IPsec-Tunnel oder Virtual Circuit-Anhang verlassen. Pakete werden gelöscht, wenn das Routing so konfiguriert ist, dass Pakete aus dem IPsec-Tunnel oder aus Virtual-Circuit-Anhängen an den IPsec-Tunnel oder an Virtual-Circuit-Anhänge gesendet werden.
ECMP
Kostengünstiges Multi-Path-Routing (ECMP) ermöglicht ein flussbasiertes Load Balancing des Netzwerkverkehrs über FastConnect-Virtual Circuits oder IPSec-Tunnel (aber keine Mischung aus Circuit-Typen) mit BGP. ECMP ermöglicht Aktiv-Aktiv-Load Balancing und Failover des Netzwerktraffics zwischen maximal acht Circuits.
Oracle verwendet das Protokoll, die Ziel-IP, die Quell-IP, den Zielport und den Quellport zur Unterscheidung von Flüssen zu Load Balancing- Zwecken mit einem konsistenten und deterministischen Algorithmus. Daher sind mehrere Flüsse erforderlich, um die gesamte verfügbare Bandbreite zu verwenden.
ECMP ist standardmäßig deaktiviert und kann pro Routentabelle aktiviert werden. Nur Routen mit identischer Routenvoreinstellung werden von Oracle für die ECMP-Weiterleitung in Betracht gezogen. Weitere Informationen finden Sie unter Routenkonflikte.
Routenquelle
DRG-Routen sind ursprünglich statische Routen oder dynamische Routen aus dem VCN, IPsec-Tunnel, FastConnect-Virtual Circuit oder aus RPC-Anhängen. Dieser Ursprung definiert ihre Quelle, die ein unveränderliches Merkmal der Route ist. In der API wird die Quelle als routeProvenance
einer DrgRouteRule bezeichnet.
Routen werden mithilfe von RPC-Anhängen zwischen DRGs propagiert.
Routen mit der Quelle IPSEC_TUNNEL oder VIRTUAL_CIRCUIT werden unabhängig von der Exportverteilung des Anhangs nicht in Tunnel- oder Virtual-Circuit-Anhänge vom Typ IPSec exportiert.
Traffic eines Subnetzes an ein DRG weiterleiten
Im grundlegenden Routingszenario wird Traffic von einem Subnetz im VCN an das DRG gesendet. Beispiel: Wenn Sie Traffic vom Subnetz in ein On-Premise-Netzwerk senden, müssen Sie in der Routentabelle des Subnetzes eine Regel einrichten. Das Ziel-CIDR der Regel ist das CIDR für das On-Premise-Netzwerk (oder ein Subnetz darin), und das Ziel der Regel ist das DRG. Weitere Informationen finden Sie unter VCN-Routentabellen.
Erforderliche IAM Policy
Für das Peering von VCNs mit einem DRG sind bestimmte IAM-Berechtigungen erforderlich. Einzelheiten zu den erforderlichen Berechtigungen finden Sie unter IAM-Policys für Routing zwischen VCNs.
DRG-Versionen
DRGs, die vor dem 17. Mai 2021 erstellt wurden, verwenden die Legacy-Software und können auf die neueste Version upgegradet werden. DRGs, die danach erstellt wurden, verfügen standardmäßig über die upgegradeten Features.
Im Folgenden finden Sie eine Übersicht über die Unterschiede zwischen einem upgegradeten DRG und einem Legacy-DRG:
Legacy-DRG:
- Hat keine programmierbaren Routentabellen. Weist ein Standardroutingverhalten auf, bei dem der gesamte Traffic von On Premise an ein zugehöriges VCN und vom VCN an On Premise weitergeleitet wird.
- Kann an ein einzelnes VCN angehängt werden. Das DRG kann nur für Remote-VCN-Peering mit einer RPC verwendet werden.
- Kann FastConnect, Site-to-Site-VPN oder beides anhängen. Mit diesen Verbindungen können Sie nur auf Ressourcen in der lokalen Region zugreifen.
- Kann eine RPC-Verbindung mit einem Remote-DRG-VCN-Paar in demselben Mandanten unterstützen. Informationen zum Remote-Peering mit einem Legacy-DRG finden Sie unter Remote-VCN-Peering mit einem Legacy-DRG.
Upgegradetes DRG:
- Verfügt standardmäßig über zwei Routentabellen, und weitere können später hinzugefügt werden.
- Kann viele VCN-Anhänge in derselben Region aufweisen. Lokaler VCN-zu-VCN-Traffic kann über ein gegenseitig verbundenes DRG statt über ein LPG geleitet werden. Weitere Informationen finden Sie unter Lokales VCN-Peering über ein upgegradetes DRG.
- Kann an On Premise mit dem FastConnect orSite-to-Site-VPN oder beidem angehängt werden. Mit diesen Verbindungen können Sie auf Ressourcen in lokalen Regionen und Remoteregionen zugreifen.
- Unterstützt eine RPC-Verbindung mit einem DRG-/VCN-Paar in demselben oder einem anderen Mandanten. Unter Remote-VCN-Peering über ein upgegradetes DRG finden Sie Informationen zu Remote-Peering mit einem upgegradeten DRG.
Der Rest dieses Artikels wurde kürzlich aktualisiert, um die Funktionen eines upgegradeten DRG widerzuspiegeln. Das Gleiche gilt für die allgemeinen Netzwerkszenarios. Remote-VCN-Peering mit einem Legacy-DRG ist das einzige Routing- oder Peering-Szenario, das für ein Legacy-DRG spezifisch ist.
Vor dem Upgrade eines DRG
Um erweiterte DRG-Features nutzen zu können, müssen Sie für das DRG ein Upgrade ausführen. Der DRG-Upgradeprozess ist zwar automatisiert, aber Sie müssen über die erforderlichen Berechtigungen zum Starten eines Upgrades verfügen.
Das Upgrade eines DRG ist ein unidirektionaler Prozess. Nach dem Starten des Upgradeprozesses gibt es keine Möglichkeit, zu einem Legacy-DRG zurückzukehren.
Während des Upgradeprozesses müssen Sie mit einem Trafficausfall bei allen Anhängen des DRG rechnen. Jeder Anhang wird nacheinander aktualisiert. Dabei wird jedes Upgrade des Anhangs in einen Provisioning-Status erzwungen, in dem er keinen Traffic mehr weiterleiten kann. Wenn redundante Verbindungen vorhanden sind, achten Sie darauf, dass der Traffic während eines Upgrades ein Failover zu anderen Schaltungen durchführt. Wenn Sie nur einen Circuit haben, kann er etwa 20 Minuten ausfallen. Alle vorhandenen BGP-Sessions für On-Premise-Verbindungen (FastConnect oder Site-to-Site-VPN) werden ebenfalls zurückgesetzt, während der Anhang und alle Site-to-Site-VPN-IPSec-Tunnel ebenfalls offline gesetzt werden.
Beispiel: Wenn ein DRG über zwei FastConnect Virtual Circuit-Anhänge verfügt, wird zuerst ein Virtual Circuit upgegradet. Dadurch wird die Verbindung unterbrochen, während der Traffic über den anderen Virtual Circuit geleitet werden kann. Wenn dieses Update abgeschlossen ist, fährt der Upgradeprozess mit dem zweiten Virtual-Circuit-Anhang fort, und der bereits upgegradete Virtual Circuit wird wieder online gesetzt. Der Upgradeprozess kann bis zu 30 Minuten je On-Premise-Anhang dauern.
Remote-Peering-Verbindungen müssen nicht wie Virtual Circuit- oder IPSec-Tunnelverbindungen zurückgesetzt werden, und das Upgrade dauert nicht die gleiche Zeit.
Beim Upgradeprozess müssen Sie bei allen Komponenten, die an das DRG angehängt sind, mit einem Trafficausfall rechnen. Es wird empfohlen, ein DRG während eines Wartungsfensters zu aktualisieren.
Nach Abschluss des DRG-Upgradeprozesses werden alle IPsec-Tunnel für Site-to-Site-VPN wieder online gesetzt, und alle BGP-Sessions für FastConnect und Site-to-Site-VPN werden wiederhergestellt. Im aktualisierten DRG sind standardmäßig zwei automatisch generierte DRG-Routentabellen und Importroutenverteilungen für die Anhänge aktiviert. Diese Ressourcen wurden für die Abwärtskompatibilität mit einem Legacy-DRG konzipiert und ermöglichen die gesamte vorherige Kommunikation auf dieselbe Weise wie vor dem Upgrade ohne weitere Benutzereingriffe.
Schrittweise Anweisungen zum Upgrade eines DRG finden Sie unter DRG aktualisieren.
Wenn der DRG-Upgradeprozess aus irgendeinem Grund hängen geblieben ist, erstellen Sie eine Serviceanfrage in My Oracle Support, und weisen Sie einen hohen Schweregrad für das Ticket zu.
Szenarios
Wir haben einige detaillierte Netzwerkszenarios bereitgestellt, die Ihnen die Rolle eines DRG im Networking-Service und die Zusammenarbeit der Komponenten im Allgemeinen näherbringen sollen.
DRG-Routing
Weitere Informationen zum DRG-Routing finden Sie in der technischen Kurzübersicht Routing in OCI Networking mit Beispielen (PDF).
Routenkonflikte
Wenn zwei Routen mit identischen CIDRs von derselben DRG-Routentabelle beobachtet werden, löst das DRG den Konflikt anhand der folgenden Kriterien:
-
Statische Routen werden immer gegenüber dynamischen Routen bevorzugt.
Hinweis
Sie können nicht manuell zwei statische Routen mit demselben CIDR in derselben DRG-Routentabelle angeben. Es ist jedoch möglich, mehrere Routen mit demselben CIDR dynamisch zu importieren. - Bei der Lösung von Konflikten zwischen dynamischen Routen wird zuerst der AS-Pfad der Route analysiert:
- Routen mit der Routenquelle VCN oder STATIC weisen immer einen leeren AS-Pfad auf.
- Für Routen mit der Routenquelle IPSEC_TUNNEL oder VIRTUAL_CIRCUIT sind AS-Pfaddaten angegeben (weitere Informationen finden Sie unter Routingdetails für Verbindungen zu Ihrem On-Premise-Netzwerk).
- Andernfalls wird der Anhangstyp, der die Route importiert hat, anhand der folgenden Priorität basierend auf dem Anhangstyp ausgewertet:
- VCN: Das DRG trifft eine willkürliche, aber stabile Auswahl.
- VIRTUAL_CIRCUIT: Wenn ECMP deaktiviert ist, trifft das DRG eine willkürliche, aber stabile Auswahl. Wenn ECMP aktiviert ist, werden alle Routen zur Routentabelle hinzugefügt, und das DRG wählt das Routing über ECMP aus. Die maximal unterstützte ECMP-Breite innerhalb eines DRG beträgt 8.
- IPSEC_TUNNEL: Wenn ECMP deaktiviert ist, macht das DRG ein willkürliches, aber stabiles selection.If-ECMP aktiviert, werden alle Routen zur Routentabelle hinzugefügt, und das DRG trifft Routingoptionen mit ECMP. Die maximal unterstützte ECMP-Breite innerhalb eines DRG beträgt 8.
-
REMOTE_PEERING_CONNECTION: Das DRG wählt die Route mit der geringsten Netzwerkentfernung aus.
Wenn zwei Routen identische Netzwerkentfernungen aufweisen, wählt das DRG die Route mit der Routenquelle mit der höchsten Priorität (STATIC > VCN > VIRTUAL_CIRCUIT > IPSEC_TUNNEL > RPC).
Wenn zwei Routen dieselbe Routenquelle aufweisen, trifft das DRG eine willkürliche, aber stabile Auswahl.
- Wenn widersprüchliche Routen aus Anhängen desselben Typs importiert werden, wird der Konflikt je nach Anhangstyp unterschiedlich gelöst:
- VCN-Anhänge: Wenn identische CIDRs aus zwei VCN-Anhängen importiert werden, wird nur eines mit einem willkürlichen, aber stabilen Entscheidungsverfahren ausgewählt.
- VIRTUAL_CIRCUIT- und IPSEC_TUNNEL-Anhänge: Wenn mehrere Routen mit demselben CIDR und verschiedenen AS_PATH-Längen in eine DRG-Routentabelle importiert werden, wird die Route mit der geringsten AS_PATH-Länge ausgewählt. Andernfalls wird eine Route mit einem willkürlichen, aber stabilen Entscheidungsverfahren gewählt.
- RPC-Anhänge: Wenn identische CIDRs aus zwei RPC-Anhängen importiert werden, wird eines davon mit einem willkürlichen, aber stabilen Entscheidungsverfahren ausgewählt.
Sie können die Ergebnisse der Konfliktauflösung anzeigen, indem Sie den Inhalt der Routentabelle auflisten. Veraltete Routen werden mit dem Status "Konflikt" gekennzeichnet.
Routenaggregation
Wie unter RFC-1338 beschrieben, können Sie mit der Routenaggregation "eine einzelne aggregierte Route bewerben, die alle darin enthaltenen Ziele beschreibt", anstatt eine separate Route für jeden Client zu veröffentlichen. Das primäre Beispiel dafür in OCI Networking liegt vor, wenn Sie den VCN-Anhang eines DRG an VCN-CIDRs anstelle von Subnetz-CIDRs importieren konfigurieren. Dadurch wird vereinfacht, welche Routen von BGP angeboten werden. Je nach Netzwerkarchitektur können Sie auch folgende Aktionen ausführen:
- Verwenden Sie statische Routen anstelle von Importverteilungen im DRG, um noch enger zusammenzufassen (der Geltungsbereich hierfür ist auf diesen spezifischen Anhang beschränkt).
- Aggregieren Sie über mehrere Anhänge hinweg, indem Sie ein zweites DRG einführen und die aggregierten Anhänge nur über eine RPC für ein anderes DRG verfügbar machen
Andere Formen der Routenaggregation sind nicht verfügbar.
Einschränkungen
Einige Funktionen scheinen möglich zu sein, aber die folgenden Routingfunktionen sind nicht zulässig:
- Explizite Erstellung oder Löschung von RPC-, IPsec-Tunnel- oder Virtual-Circuit-Anhängen
- Statische Routen in DRG-Routentabellen mit nächstem Hop für IPsec-Tunnel- oder Virtual-Circuit-Anhängen
- Verwendung von nicht standardmäßigen Exportroutenverteilungen
- Export dynamischer Routen in VCN-Anhänge
- Propagierung von Routen über RPC über mehr als 4 DRGs
Mit BGP Routen von Oracle zu Ihrem On-Premise-Netzwerk bevorzugen
In diesem Abschnitt wird ausführlicher beschrieben, wie die Routenauswahl mit dem BGP-Attribut AS_PATH im Kontext einer einzelnen DRG-Routentabelle beeinflusst werden kann.
Wenn die Routen für die verschiedenen Wege identisch sind, verwendet Oracle den kürzesten AS-Pfad beim Senden von Traffic an ein On-Premise-Netzwerk, unabhängig davon, welcher Pfad zum Starten der Verbindung zu Oracle verwendet wurde. Daher ist asymmetrisches Routing zulässig. Asymmetrisches Routing bedeutet hier, dass die Antwort von Oracle auf eine Anforderung einem anderen Pfad als die Anforderung folgen kann. Beispiel: Je nachdem, wie ein Edge-Gerät (auch als Customer-Premise-Equipment oder CPE bezeichnet) konfiguriert ist, können Sie eine Anforderung über Site-to-Site-VPN senden, die Oracle-Antwort kann jedoch über FastConnect zurückgehen. Um symmetrisches Routing zu erzwingen, wird empfohlen, den BGP- und AS-Pfad vor den Routen zu verwenden, um zu beeinflussen, welchen Pfad Oracle beim Beantworten und Starten von Verbindungen verwendet.
Oracle implementiert das AS Path Prepending, um festzulegen, welcher Pfad bevorzugt verwendet werden soll, wenn ein Edge-Gerät dieselbe Route und dieselben Routingattribute über verschiedene Verbindungstypen zwischen einem On-Premise-Netzwerk und einem VCN anbietet. Die Details werden in der folgenden Tabelle zusammengefasst. Sofern Sie das Routing nicht anderweitig beeinflussen, bevorzugt Oracle die Pfade in der folgenden Reihenfolge, wenn Sie dieselbe Route über mehrere Pfade zum DRG auf der Oracle-Seite der Verbindungen anbieten:
Oracle-Voreinstellung | Pfad | Details zur Vorgabe des Pfades durch Oracle | Resultierender AS-Pfad für die Route |
---|---|---|---|
1 | FastConnect | Oracle stellt den Routen, die das Edge-Gerät anbietet, keine ASNs voran, sodass die AS-Pfadlänge insgesamt 1 beträgt. | Ihre ASN |
2 | Site-to-Site-VPN mit BGP-Routing | Oracle stellt allen Routen, die Ihr Edge-Gerät über Site-to-Site-VPN mit BGP anbietet, eine einzelne private ASN voran, sodass die AS-Pfadlänge insgesamt 2 beträgt. | Private ASN, Ihre ASN |
3 | Site-to-Site-VPN mit statischem Routing | Oracle stellt den statischen Routen, die Sie angegeben haben, drei private ASNs voran (Oracle bietet diese Routen dem dynamischen Routinggateway (DRG) auf der Oracle-Seite des Site-to-Site-VPN an). Dies führt zu einer AS-Pfadlänge von insgesamt 3. | Private ASN, Private ASN, Private ASN |
In der obigen Tabelle wird vorausgesetzt, dass Sie eine einzelne AS-Nummer in Ihrem AS-Pfad senden. Oracle berücksichtigt den kompletten AS-Pfad, den Sie senden. Wenn Sie statisches Routing verwenden und außerdem einen AS-Pfad mit "Ihrer ASN" plus zwei oder mehr anderen ASNs senden, kann dies zu unerwartetem Verhalten führen, weil sich die Routingvoreinstellung von Oracle ändern könnte.
Während das Policy-basierte statische VPN-Routingverhalten früher dokumentiert wurde, empfiehlt Oracle auch, dass Sie BGP für das routenbasierte VPN IPSec verwenden, wenn Sie FastConnect-Verbindungen mit VPN-Backups verwenden. Mit dieser Strategie können Sie das Failover-Verhalten vollständig kontrollieren.