Beispiele für das Festlegen der Routenpriorität

• Wenn Sie eine Route mit dem Präfix /32 und der Priorität 1 und eine Route mit dem Ziel /31 und der Priorität 0 haben, wird zuerst /32 verwendet (längste Präfixübereinstimmung). Mit anderen Worten, die Priorität spielt nur dann eine Rolle, wenn mehrere Routen mit demselben Präfix vorhanden sind.
• Bei drei Routen mit 0.0.0.0/0 (Standardroute) wird nur die Route mit der höchsten Priorität verwendet. Wenn die ausgewählte Route entfernt wird (z. B. durch Automatisierung) wird die höchste Priorität von den verbleibenden zwei Routen ausgewählt.
• Wenn die benutzerdefinierte Routingtabelle nur eine Route mit einem bestimmten Präfix hat, wird immer diese eine Route verwendet, unabhängig von ihrer Priorität. Die Auswahl der besten Route wird für jedes spezifische Präfix durchgeführt und wählt die Route mit der höchsten Priorität aus.

Das ECMP-Routing (Equal-Cost Multi-Path) wird verwendet, wenn zwei Routen dasselbe Ziel und dieselbe Priorität haben (Erweiterung des aktuellen Verhaltens, bei dem ECMP für zwei Routen mit demselben Ziel verwendet wird). Höchstens zwei Routen in einer Routing-Tabelle dürfen dasselbe Ziel und dieselbe Priorität haben. Wenn die angepasste Routing-Tabelle beispielsweise drei Routen mit demselben Ziel enthält, eine Route mit Priorität 1 und die beiden anderen Routen mit Priorität 4 (ECMP), wird die Route mit Priorität 1 ausgewählt und die ECMP-Routen werden ignoriert (kein ECMP). Wenn nun die beiden Routen mit demselben Ziel und derselben Priorität die höchste Priorität haben, wählt das System diese beiden Routen aus und führt ECMP aus. Wenn dann einer dieser Leitwege gelöscht wird, wird der noch vorhandene Leitweg ausgewählt und ECMP wird nicht ausgeführt.

Informationen zu Einschränkungen für die Routenpriorität finden Sie unter Einschränkungen und Richtlinien.

Hinweise zur Werberoute

Beachten Sie beim Bekanntgeben von Routen die folgenden Hinweise:

• Sie können Routen außerhalb des Root-Adresspräfixes ankündigen, das der VPC zugewiesen ist. So können Sie Ihre externen Netzwerke oder Netzwerke außerhalb der VPC ankündigen an einen Direct Link oder Transit Gateway.

• Wenn mehrere Transit Gateways oder Direct Links an Ihre VPC angeschlossen sind, können Sie die Routenfilterung für einzelne Transit Gateway oder Direct Link Verbindungen, um genau abzustimmen, welche Routen welchen Verbindungen angekündigt werden.

• Wenn mehrere Routen mit unterschiedlichen Prioritäten zu einem Zielpräfix angekündigt werden, wird die Route mit der höheren Priorität (niedrigerer Prioritätswert) als primäre Route und die Route mit niedrigerer Priorität (höherer Prioritätswert) als Backup verwendet.

• Wenn Sie zwei verschiedene Routen anbieten, wie zum Beispiel 172.16.0.0/31 durch 10.1.1.0 Und 172.16.0.0/32 durch 10.1.2.0, die Route mit einem /32 Präfix hat immer Vorrang vor der Route mit einem /31 Präfix. Dies stimmt mit dem Regelsatz "Longest Prefix Match" überein. Ein längeres Präfix zu einem Hostziel ist einem kürzeren Präfix immer vorzuziehen.

• Derzeit gibt es keinen Mechanismus zum Markieren doppelter Routen aus einem Transit Gateway oder Direct Link. Der Transit Gateway wählt den besten Pfad aus, indem je nach Wunsch das spezifischste Präfix und der kürzeste AS-Pfad verwendet werden. Ansonsten der Transit Gateway wählt die Route aus, die es zuerst erhalten hat. Diese Route ist möglicherweise nicht die älteste Route auf der VPC-Seite und kann sich ändern, wenn Routen zum Transit Gateway werden intern aktualisiert.

• Die von einem VPN-Gateway angekündigten Routen hängen vom VPN-Typ ab. Richtlinienbasierte VPN-Gateways geben Routen nicht dynamisch bekannt. Es werden nur die in der VPN-Richtlinie definierten CIDR-Präfixe weitergegeben, und die Routing-Tabelle muss so konfiguriert sein, dass sie Routen vom VPN-Gateway akzeptiert. Routenbasierte VPN-Gateways mit BGP geben Routen dynamisch bekannt.

  Wenn Sie Routen aus einer Routing-Tabelle mit VPN-Konnektivität ankündigen, stellen Sie sicher, dass der VPN-Gateway-Typ das beabsichtigte Routenausbreitungsverhalten unterstützt.

Anwendungsfall 1: Edge-Proxy-Firewall

Anwendungsfall 2: Öffentliche Lastausgleichsfunktion

Anwendungsfall 3: VPN

Damit ein VPN-Gateway als nächster Hop in einer VPC-Routing-Tabelle verwendet werden kann, wird das Gateway in einem dedizierten Teilnetz erstellt. Das betreffende Teilnetz wird nur für das VPN-Gateway verwendet und dem VPN-Gateway-Teilnetz mit einer anderen Routing-Tabelle zugeordnet, wenn eine Route 0.0.0.0/0 vorhanden ist und der nächste Hop eine VPN-Verbindung ist.

Zum Beispiel:

• Teilnetz A wird als Host für die virtuellen Server verwendet und der Standard-Routing-Tabelle zugeordnet. Eine Route 0.0.0.0/0 ist vorhanden und der nächste Hop ist eine VPN-Verbindung.
• Teilnetz B wird zum Hosten des VPN-Gateways verwendet und erstellt eine neue Routing-Tabelle (Routing-Tabelle B). Teilnetz B wird der Routing-Tabelle B zugeordnet. Standardmäßig sind keine Routen in Routing-Tabelle B erforderlich.

Um bei einer Routen 0.0.0.0/0-Konfiguration und einem nächsten Hop über eine VPN-Verbindung die Konnektivität zwischen Subnetzen herzustellen, können Sie die folgenden delegierten Routen hinzufügen:

destination CIDR==zone3 VPC prefix, action==delegate, location==zone1
destination CIDR==zone1 VPC prefix, action==delegate, location==zone3

Allgemeine Einschränkungen

• Derzeit können Sie keine angepasste Routing-Tabelle sowohl für Ingress-Datenverkehr (einer Datenverkehrsquelle zugeordnet) als auch für Egress-Datenverkehr (einem Teilnetz zugeordnet) verwenden. Darüber hinaus kann die angepasste Standard-Routing-Tabelle nicht einer Ingress-Datenverkehrsquelle zugeordnet werden.
• Momentan kann der zurückgegebene Datenverkehr aufgrund von asymmetrischem Routing fehlschlagen. Dieses Problem betrifft alle Services, die von statischen ECMP-Routen abhängig sind. Angenommen, Sie erstellen zwei ECMP-Routen in VPC A mit dem Ziel 10.134.39.64/26 und die nächsten Hops sind 192.168.2.4 bzw. 192.168.2.5. Diese nächsten Hops sind IP-Adressen von NFV-Einheiten. Wenn Sie Datenverkehr von Instanz A in der VPC senden, wird das Paket zufällig an einen der nächsten Hops weitergeleitet, und es gibt aufgrund des ECMP-Hash-Algorithmus auf der anderen Seite keine Garantie dafür, dass der Rückverkehr demselben Pfad folgt wie der Weiterleitungsverkehr. Dieses Phänomen wird als _asymmetrisches Routing_bezeichnet. Bei asymmetrischem Routing liegt das Problem nicht beim Routing selbst, sondern daran, dass die Sicherheitsgruppe den Datenverkehr blockiert, auch wenn die Regeln der Sicherheitsgruppe diesen Datenverkehr zulassen, da die Sicherheitsgruppe den Datenverkehr nur auf einem Pfad sieht. Generell ist es ratsam, die Verwendung von ECMP-Routen zu vermeiden.
• Die Möglichkeit, eine IP-Adresse für den nächsten Hop in einer angepassten Route zu erreichen, ist kein entscheidender Faktor dafür, ob die Route für den Weiterleitungsdatenverkehr verwendet wird. Dies kann zu Problemen führen, wenn mehrere Routen mit demselben Präfix (jedoch unterschiedlichen IP-Adressen für den nächsten Hop) verwendet werden, da der Datenverkehr an die nicht erreichbaren IP-Adressen für den nächsten Hop möglicherweise nicht zugestellt wird.
• IBM Cloud VPC ermöglicht die private Nutzung von Adressräumen des Typs „ RFC-1918 “ und von bei der IANA registrierten Adressräumen des Typs „ IPv4 “ innerhalb Ihrer VPC, mit einigen Ausnahmen bei den IANA-Sonderbereichen sowie bei ausgewählten Bereichen, die den Diensten von IBM Cloud zugewiesen sind. Bei Verwendung von bei der IANA registrierten Bereichen in Ihrem Unternehmen und in VPCs in Verbindung mit IBM Cloud Transit Gateway oder IBM Cloud Direct Link müssen Sie angepasste Routen in jeder Zone installieren. Weitere Informationen finden Sie unter Aspekte beim Routing von durch IANA registrierte IP-Zuweisungen.
• Falls zwei verschiedene beworbene Routen zum selben Ziel existieren, gelten die folgenden Einschränkungen:
  • Wenn der nächste Hop für beide Routen in der gleichen Zone liegt, wird die Route mit der höheren Priorität (d. h. ein niedrigerer Wert für priority ) wird als primärer Pfad verwendet und die Route mit der niedrigeren Priorität (d. h. einem höheren Wert für priority ) wird als Sicherungspfad verwendet. Wenn die Priorität für beide Routen identisch ist, wird ECMP verwendet, um den Datenverkehr gleichmäßig über die beiden Routen weiterzuleiten.
  • Wenn sich der nächste Hop für beide Routen in verschiedenen Zonen befindet, wählt der Router Transit Gateway oder Direct Link die beste Route aus. In diesem Fall ist dies die älteste beworbene Route.

Leitwegpriorität

Wenn mehrere Routen mit demselben Ziel-CIDR/Präfix vorhanden sind, wird die Route mit dem höchsten Prioritätswert verwendet. Routen mit demselben Ziel-CIDR/Präfix und derselben Priorität verwenden ECMP-Routing.

Egress-Routen

Bei angepassten Egress-Routen müssen Sie beim Hinzufügen einer Zielroute eine Zone auswählen. Der nächste Hop muss sich jedoch nicht in derselben Zone befinden. Bei angepassten Ingress-Routen muss sich der nächste Hop in derselben Zone befinden.

ECMP (Equal-Cost Multi-Path)

Der implizite Router führt das ECMP-Routing (mehrere Routen mit demselben Ziel, jedoch unterschiedlichen Adressen für den nächsten Hop) mit den folgenden Einschränkungen aus:

• Dies gilt nur für Routen mit einer Aktion deliver.
• Pro Zone sind nur zwei identische Zielrouten zulässig und jede Route muss verschiedene Adressen für den nächsten Hop beinhalten.
• Bei Verwendung von ECMP (Equal-Cost Multi-Path routing) wird für den Rückkehrpfad möglicherweise ein anderer Pfad verwendet.
• ECMP unterstützt nur IP-Adressen des Typs "Nächster Hop".

Ingress-Routen

• Derzeit ist das öffentliche Ingress Routing (public internet traffic choice) nur in der Konsole verfügbar. CLI und API sind in Kürze verfügbar.
• Jeder Ingress-Quellentyp kann bis zu einer Ingress-Routing-Tabelle pro VPC zugeordnet werden. Eine VPC kann jedoch mehrere Ingress-Routing-Tabellen haben und jeder Ingress-Routing-Tabelle kann mindestens ein Ingress-Typ zugeordnet sein.
• Der Ingress-Datenverkehr einer bestimmten Datenverkehrsquelle wird unter Verwendung der Routen in der angepassten Routing-Tabelle weitergeleitet, die der betreffenden Datenverkehrsquelle zugeordnet ist.
• Für angepasste Routen in einer angepassten Routing-Tabelle, die einer Quelle für Ingress-Datenverkehr zugeordnet ist, und mit einer Aktion deliver muss eine IP-Adresse für den nächsten Hop in einem der Adresspräfixe der VPC in der Verfügbarkeitszone enthalten sein, in der die Route hinzugefügt wird. Darüber hinaus muss die IP-Adresse des nächsten Hops in einer Schnittstelle eines virtuellen Servers in der VPC und der Verfügbarkeitszone konfiguriert sein, in der sich das Ziel der Route befindet.
• Der Ingress-Datenverkehr einer bestimmten Datenverkehrsquelle wird unter Verwendung der Routen in der angepassten Routing-Tabelle weitergeleitet, die der betreffenden Datenverkehrsquelle zugeordnet ist. Wird in einer angepassten Routing-Tabelle keine passende Route gefunden, wird die Weiterleitung mit der System-Routing-Tabelle der VPC fortgesetzt. Sie können dieses Verhalten verhindern, indem Sie eine Standardroute in einer angepassten Routing-Tabelle mit der Aktion Löschen verwenden.
• Eine angepasste Ingress-Routing-Tabelle, die angepasste Routen mit Ziel-IP (FIP) enthält, sollte in derselben Zone definiert werden wie die virtuelle Serverinstanz, der eine FIP zugeordnet ist.
• Floating IPs, die an ein IBM Cloud VPN gebunden sind, können nicht als Ziel für eine benutzerdefinierte Route in einer Ingress-Routing-Tabelle verwendet werden, wenn der Quelltyp Öffentliches Internet route_internet_ingress) aktiviert ist.

Eindeutige Präfixlängen

Für jede angepasste Routing-Tabelle können maximal 14 eindeutige Präfixlängen verwendet werden. Sie können über mehrere Routen mit demselben Präfix verfügen, die als ein einzelnes eindeutiges Präfix gelten. Sie können z. B. über mehrere Routen mit dem Präfix /28 verfügen. Diese Präfixlänge zählt als ein eindeutiges Präfix.

VPN

• Wenn Sie eine Route für eine statische, routenbasierte VPN-Verbindung erstellen, müssen Sie die VPN-Verbindungs-ID für den nächsten Hop eingeben. Das VPN-Gateway muss in derselben Zone enthalten sein wie das Teilnetz, dem die Routing-Tabelle zugeordnet ist. Es wird nicht empfohlen, ein VPN-Gateway als nächsten Hop in einer Zone zu definieren, die sich von dem Teilnetz unterscheidet, das der Routing-Tabelle zugeordnet ist.
• Vermeiden Sie bei routenbasierten VPNs die Verwendung einer privaten IP-Adresse als nächster Hop für VPN-Routen. Wenn das VPN neu gestartet wird oder sich seine IP ändert, können Routen, die auf eine IP-Adresse verweisen, unterbrochen werden und die Konnektivität kann ausfallen. Verwenden Sie immer den Namen der VPN-Verbindung (ID) als nächsten Hop, damit die Routen automatisch aktualisiert werden, wenn die VPN-Verbindung wiederhergestellt wird.
• Eine Route mit einer VPN-Verbindung als nächstem Hop wird nur wirksam, wenn die VPN-Verbindung aktiv ist. Diese Route wird bei der Routing-Suche übersprungen, wenn die VPN-Verbindung inaktiv ist.
• Eine angepasste Routing-Tabelle, die angepasste Routen mit einem nächsten Hop enthält, der einer VPN-Verbindung zugeordnet ist, kann nicht einer Ingress-Datenverkehrsquelle zugeordnet werden.
• Angepasste Routen werden nur für routenbasierte VPNs unterstützt. Wenn Sie richtlinienbasierte VPNs verwenden, werden die Routen automatisch vom VPN-Service in der Standard-Routing-Tabelle erstellt.