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 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.

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.

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 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.
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 zu Ihrem 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 über 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, 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.

   4. 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.

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, 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