Dynamische Routinggateways

Mit DRGs und DRG-Anhängen arbeiten

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 vielen DRG-Anhängen 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 Standardroutentabelle 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-Routingtabelle definiert ist, bietet eine verborgene implizite Tabelle immer Konnektivität zu allen Subnetzen im VCN.

Dynamische Import-/Exportroutenverteilungen

DRG-Routentabellen enthalten sowohl statische als auch dynamische Routen. Statische Routen werden mit der API in Tabellen eingefügt, während dynamische Routen aus Anhängen importiert und mit einer Routenverteilung eingefügt werden, eine Liste deklarativer Anweisungen, die Übereinstimmungskriterien (wie eine OCID oder ein 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 für nur VCN-Routen und eine für alle Routen. Sie können andere Importroutenverteilungen erstellen, aber keine neuen Exportroutenverteilungen erstellen.

Wenn die Übereinstimmungskriterien einer Routenverteilung einen Anhangstyp enthalten, werden dem Anhang zugeordnete Routen dynamisch in die DRG-Routentabelle importiert, die vom Anhang verwendet wird. Wenn eine Anweisung aus der Routenverteilung entfernt wird, werden die übereinstimmenden Routen aus den DRG-Routentabellen entfernt. 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 Suchkriterienkriterium auf eine leere Liste setzen.

Wie gelangen dynamische Routen zu einem Anhang?

Routen zu On-Premise-Netzwerken werden über BGP vom CPE in Tunnel- und Virtual-Circuit-Anhänge IPSec veröffentlicht. 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-CIDR's oder alle VCN-CIDRs und alle statischen Routen-CIDR's, die in dem mit dem DRG-Anhang verknüpften VCN-Routentabelle konfiguriert ist. Die Eigenschaft vcnRouteType des VCN-Anhangs legt fest, ob die Subnetz-CIDR- oder VCN-CIDRs an den VCN-Anhang propagiert werden. Standardmäßig wird das Subnetz-CIDR importiert. Dieses Verhalten kann jedoch beim Erstellen oder Aktualisieren des VCN-Anhangs verändert werden. 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 Rout Exporte in einen Anhang zu deaktivieren, verwenden Sie den API-Vorgang removeExportDrgRouteDistribution, um das Feld exportDrgRouteDistributionId des Anhangs auf NULL zu setzen. Dynamischer Routenexport in VCN-Anhänge wird nicht unterstützt.

Für jedes DRG wird eine automatisch generierte Exportroutenverteilung erstellt. Sie können keine Exportroutenkontierungen erstellen.

Einschränkungen der Routenpropagierung

Routen, die aus einem IPSec-Tunnel oder einer virtuellen Schaltung importiert wurden, werden niemals in andere IPSec-Tunnel- oder virtuelle Schaltung-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

Mit Equal-Cost Multi-Path Routing (ECMP) kann flussbasiertes Load Balancing des Netzwerkverkehrs über FastConnect Virtual Circuits oder IPSec-Tunnel (aber nicht eine Mischung aus Circuit-Typen) mit BGP durchgeführt werden. 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 für die Nutzung der gesamten verfügbaren Bandbreite mehrere Flüsse erforderlich.

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 leitet ursprinieren entweder als statische Routen oder als dynamische Routen von VCN, IPSec-Tunnel, FastConnect-Virtual Circuit oder RPC-Anhängen weiter. Dieser Ursprung definiert ihre Quelle, die ein unverzichtbares 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 IPSec-Tunnel- oder Virtual Circuit-Anhänge 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 eine Regel in der Routentabelle des Subnetzes 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 mit einer RPC an ein anderes DRG für Remote-VCN-Peering angehängt 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 upgradendes DRG.
• Kann an On Premise mit 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. Informationen zum Remote-Peering mit einem upgegradeten DRG finden Sie unter Remote-VCN-Peering über ein upgegradetes 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 Start des Upgradeprozesses gibt es keine Möglichkeit, zu einem Legacy-DRG zurückzukehren.

Erwarten Sie, dass alle Anhänge des DRG ihrerseits aktualisiert werden, sodass jeder Upgradeanhang in einen Provisioning-Status versetzt wird. Virtual Circuit- und VPN-Tunnelanhänge können Traffic im Provisioning-Status nicht mehr weiterleiten. Wenn Sie nur einen Virtual Circuit haben, kann er etwa 20 Minuten ausfallen. Alle vorhandenen BGP-Sessions für On-Premise-Verbindungen werden ebenfalls zurückgesetzt, während der Anhang und die Verbindungen ebenfalls offline gesetzt werden.

Wenn redundante Verbindungen vorhanden sind, erwarten Sie, dass Datenverkehr ein Failover auf andere Schaltungen durchführt, während eine Verbindung aktualisiert wird. Mit einer redundanten Konfiguration wird die gesamte Verbindung zwischen On-Premise und OCI während des DRG-Upgrades aufrechterhalten. Beispiel: Wenn ein DRG zwei FastConnect Virtual Circuit-Anhänge an ein On-Premise-Netzwerk mit einem als primär konfigurierten Netzwerk aufweist, während der primäre Virtual Circuit upgegradet wird, wird die Konnektivität unterbrochen, der Traffic kann jedoch weiterhin über den sekundären Virtual Circuit geleitet werden. Nachdem das erste Update abgeschlossen und der Datenverkehr über den primären Virtual Circuit wiederhergestellt wurde, aktualisiert der Prozess den sekundären Virtual Circuit-Anhang und schließlich sind beide Virtual Circuits wieder online. Der Upgradeprozess kann bis zu 30 Minuten je On-Premise-Anhang dauern. Wenn der Upgradeprozess zuerst den Anschluss des sekundären Virtual Circuits aktualisiert, stoppt der Traffic auf diesem Circuit, kann aber dennoch den primären Virtual Circuit durchlaufen, bis die Sekundärschaltung wiederhergestellt ist.

Remote-Peering-Verbindungen und VCN-Anhänge müssen nicht durch ein BGP die Art und Weise zurücksetzen, wie Virtual Circuit- oder IPSec-Tunnelverbindungen funktionieren, und das Upgrade ist schneller. VCN-Verbindungen zu einem LPG oder anderen Gateways sind davon nicht betroffen, da sie Anhänge im VCN und nicht im DRG sind.

Nachdem der DRG-Upgradeprozess abgeschlossen ist, werden alle Site-to-Site-VPN-IPSec-Tunnel wieder online gesetzt, und alle BGP-Sessions für FastConnect und Site-to-Site-VPN werden wiederhergestellt. Im upgegradeten DRG sind standardmäßig zwei automatisch erstellte 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 eine Wiederaufnahme der gesamten vorherigen Kommunikation auf dieselbe Weise wie vor dem Upgrade ohne weitere Benutzereingriffe.

Schrittweise Anweisungen zum Upgraden eines DRG finden Sie unter DRG upgraden.

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.

Routenkonflikte

Wenn zwei Routen mit identischen CIDRs von derselben DRG-Routentabelle beobachtet werden, löst das DRG den Konflikt anhand der folgenden Kriterien:

1. Statische Routen werden immer gegenüber dynamischen Routen bevorzugt.

   Hinweis
   
   Sie können zwei statische Routen mit demselben CIDR nicht manuell in derselben DRG-Routentabelle angeben. Es ist jedoch möglich, mehrere Routen mit demselben CIDR dynamisch zu importieren.
2. 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 zum On-Premise-Netzwerk).
3. Andernfalls wird der Anhangstyp, der die Route importiert hat, anhand der folgenden Priorität basierend auf dem Anhangstyp ausgewertet:
   1. VCN: Das DRG trifft eine willkürliche, aber stabile Auswahl.
   2. 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 mit ECMP aus. Die maximal unterstützte ECMP-Breite innerhalb eines DRG beträgt 8.
   3. IPSEC_TUNNEL: Wenn ECMP deaktiviert ist, macht das DRG ein willkürliches, aber stabiles selection.If-ECMP aktiviert, alle Routen werden der Routentabelle hinzugefügt, und das DRG wählt das Routing mit ECMP aus. Die maximal unterstützte ECMP-Breite innerhalb eines DRG beträgt 8.

   4. REMOTE_PEERING_CONNECTION: Das DRG wählt die Route mit der niedrigsten 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.

4. Wenn widersprüchliche Routen aus Anhängen desselben Typs importiert werden, wird der Konflikt je nach Anhangstyp unterschiedlich gelöst:
   1. 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.
   2. 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.
   3. RPC-Anhänge: Wenn identische CIDRs aus zwei RPC-Anhängen importiert werden, wird eines davon mit einem willkürlichen, 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 in der Routenaggregation RFC-1338 beschrieben, können Sie "eine einzelne aggregierte Route bewerben, die alle darin enthaltenen Ziele beschreibt", anstatt für jeden Client eine separate Route zu veröffentlichen. Das primäre Beispiel dafür in OCI Networking findet statt, wenn Sie den VCN-Anhang eines DRG für den Import von VCN-CIDRs anstelle von Subnetz-CIDRs konfigurieren, wodurch die von BGP angebotenen Routen vereinfacht 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 ist auf diesen spezifischen Anhang beschränkt)
• Aggregieren Sie mehrere Anhänge, indem Sie ein zweites DRG einführen und die aggregierten Anhänge nur über eine RPC in einem anderen DRG verfügbar machen

Andere Formen der Routenaggregation sind nicht verfügbar.

Einschränkungen

Möglicherweise sind einige Funktionen möglich, die folgenden Routingfunktionen sind jedoch 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 anderer Exportroutenverteilungen als der Standardwerte
• Export dynamischer Routen in VCN-Anhänge
• Propagierung von Routen über RPC über mehr als 4 DRGs