IBM Cloud Docs
Informationen zu Routing-Tabellen und Routen

Informationen zu Routing-Tabellen und Routen

IBM Cloud® Virtual Private Cloud (VPC) generiert automatisch eine Standard-Routing-Tabelle für die VPC, um den Datenverkehr in der Zone zu verwalten. Diese Routing-Tabelle ist standardmäßig leer. Sie können der Standardrouting-Tabelle Routen hinzufügen oder eine oder mehrere angepasste Routing-Tabellen erstellen und diesen dann Routen hinzufügen. Wenn Sie z. B. eine besondere Routing-Richtlinie für ein bestimmtes Teilnetz verwenden möchten, können Sie eine Routing-Tabelle erstellen und diese Tabelle Teilnetzen zuordnen. Wenn Sie jedoch die Standard-Routing-Richtlinie ändern möchten, die sich auf alle Subnetze auswirkt, die die Standard-Routing-Tabelle verwenden, sollten Sie der Standard-Routing-Tabelle Routen hinzufügen.

Die Standard-Routing-Tabelle gleicht in der Funktionsweise anderen Routing-Tabellen, sie wird jedoch automatisch erstellt und verwendet, wenn Sie ein Teilnetz ohne Angabe einer Routing-Tabelle erstellen.

Sie können in jeder beliebigen Routing-Tabelle Routen definieren, um den Datenverkehr wie gewünscht zu gestalten. Jedem Subnetz ist eine Routing-Tabelle zugewiesen, die für die Verwaltung des Datenverkehrs des Subnetzes verantwortlich ist. Sie können die von einem Teilnetz verwendete Routing-Tabelle jederzeit ändern, um den zugehörigen ausgehenden Datenverkehr zu verwalten.

Dieser Service ermöglicht auch die Verwendung von Network Functions Virtualization (NFV) für erweiterte Netzservices, wie z. B. Routing-Lösungen anderer Anbieter, Firewalls, lokale/globale Lastverteilung, Firewalls für Webanwendungen etc. Angepasste Routing-Tabellen werden derzeit auch in IBM Cloud-Services integriert.

Egress- und Ingress-Routing

  • Egress-Routen steuern den Datenverkehr, der innerhalb eines Subnetzes entsteht und in das öffentliche Internet oder zu einer anderen VM in derselben oder einer anderen Zone geleitet wird.

  • Mithilfe von Ingress-Routen können Sie die Routen für den in eine VPC eingehenden Datenverkehr aus Verkehrsquellen außerhalb der Verfügbarkeitszone der VPC anpassen ( IBM Cloud Direct Link, IBM Cloud Transit Gateway, eine andere Verfügbarkeitszone in derselben VPC oder das öffentliche Internet).

    Einer bestimmten Ingress-Datenverkehrsquelle kann nur eine einzige angepasste Routing-Tabelle zugeordnet werden. Sie können jedoch unterschiedliche Routing-Tabellen für unterschiedliche Datenverkehrsquellen verwenden. Zum Beispiel könnte Routing-Tabelle A Transit Gateway und VPC Zone verwenden, während Routing-Tabelle B Direct Link verwendet.

Definieren der systemimpliziten Routing-Tabelle

Sie können eine Routing-Tabelle nicht so konfigurieren, dass sie die system-implizite Routing-Tabelle verwendet; sie wird automatisch ausgefüllt. Die system-implizite Routing-Tabelle wird verwendet, wenn in der benutzerdefinierten Routing-Tabelle, die mit dem Teilnetz verbunden ist, aus dem der Datenverkehr austritt, keine passende Route gefunden wird. Falls keine Übereinstimmung gefunden wird, wird das Paket gelöscht.

Für jeden VPC wird eine system-implizite Routing-Tabelle geführt. Ein VPC kann in mehreren Zonen präsent sein, und die systemimplizite Routing-Tabelle des VPCs ist in jeder Zone anders. Für das Ingress-Routing enthält die system-implizite Routing-Tabelle nur Routen zu jeder Netzwerkschnittstelle in der VPC-Zone.

Dieses Verhalten kann durch eine benutzerdefinierte Standardroute in der Routing-Tabelle mit der Aktion drop vermieden werden.

Die systemimplizite Routing-Tabelle enthält Folgendes:

  • Routen zum CIDR-Wert jedes Teilnetzes in VPC

  • Routen zu Teilnetzen innerhalb der Zone (statisch verwaltet)

  • Routen zu Teilnetzen in anderen Zonen, die über BGP gebahnt werden

  • Dynamische Routen, die über BGP gelernt wurden (z. B. Direct Link und Transit Gateway )

  • Standardroute für den Datenverkehr im Internet (wird verwendet, wenn der VPC ein öffentliches Gateway oder eine variable IP-Adresse zugeordnet ist)

  • Routen zu den Netz-CIDRs für Services der klassischen Infrastruktur (werden verwendet, wenn der VPC ein Service-Gateway zugeordnet ist). Beispiel:

    10.0.0.0/14, 10.200.0.0/14, 10.198.0.0/15 und 10.254.0.0/16 sind Netz-CIDRs für Services der klassischen Infrastruktur.

Routenvorgabe festlegen

Sie können die Routenpriorität festlegen (0-4 ) von VPC-Routen, um zu bestimmen, welche Routen eine höhere Priorität haben, wenn mehrere Routen für ein bestimmtes Ziel vorhanden sind. Vorhandene Routen und neue Routen, die ohne Prioritätswert erstellt werden, werden automatisch auf die Standardpriorität gesetzt (2 ).

Die Routenpriorität wird nur an identischen Zielen berücksichtigt und ähnelt jeder dynamisch erlernten Route.

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.

Werberouten

In der Vergangenheit wurden Adresspräfixe im Stammadresspräfix der VPC für Direct Link und Transit Gatewayzugänglich gemacht. Sie konnten Ihre Adresspräfixe jedoch nicht außerhalb des Stammpräfix der VPC zugänglich machen. Die Weiterleitungsmitteilung fügt diese Funktion hinzu. Beispiel: Abbildung 1 macht die Route 0.0.0.0/0 in allen Zonen für einen zonenspezifischen nächsten Hop zugänglich.

caption-side=bottom
Anwendungsfall

Weitere Informationen finden Sie unter Erstellen einer Routingtabelle Und Aktualisieren einer Routingtabelle.

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.

Anwendungsfälle

Die folgenden Anwendungsfälle veranschaulichen unterschiedliche Routing-Szenarios.

Anwendungsfall 1: Edge-Proxy-Firewall

Edge-Proxy-Firewall Anwendungsfall
Edge-Proxy-Firewall Anwendungsfall

Edge-Proxy-Firewall-Egress-Routing-Tabelle
Ziel Aktion Nächster Hop Standort
10.10.0.0/16 Delegierter Dallas DC 1
10.11.0.0/16 Delegierter Dallas DC 1
0.0.0.0/0 Zustellen 10.10.1.5 Dallas DC 1

Ziel: Edge-Proxy-Firewall

Sicherer Datenfluss in das öffentliche Internet aus einem vom Client definierten Gateway, Proxy oder einer Firewall-Appliance. Zugleich können Ressourcen aus den anderen Teilnetzen über das von der VPC verwaltete, öffentliche Gateway übertragen werden.

Durch die Verwendung von benutzerdefinierten VPC-Routen mit Egress-Routing pro Subnetz können Sie eine Tabelle erstellen, die das systemimplizite Routing innerhalb des VPC-Netzwerks außer Kraft setzt. In diesem Beispiel bleibt die vom System erstellte Standardtabelle, in der alle Subnetze bei der Erstellung zugewiesen werden, unverändert. Es wird auch eine Tabelle erstellt, um den Datenverkehr vom Subnetz 10.10.1.0/24 über einen Edge-Proxy (NFV Proxy) zu leiten.

Da das Ziel für die Proxydatenströme das öffentliche Internet ist und in der Regel der Standardroute (0.0.0.0/0) folgt, müssen Sie zunächst Datenströme in Richtung intern erreichbarer privater Netzwerke ausnehmen, indem Sie die Delegate-Funktion der benutzerdefinierten Routen verwenden. Ressourcen im Subnetz 10.10.3.0/24 verwenden weiterhin das öffentliche Gateway, das mit diesem Subnetz verbunden ist.

Im vorliegenden Beispiel nutzen die Instanzen, die den Proxy verwenden, ein gemeinsames Teilnetz mit dem Proxy. Dies ist jedoch nicht zwingend erforderlich. Mit benutzerdefinierten Routen können Sie die Next-Hop-IP einer Instanz angeben, die mit einem anderen Subnetz verbunden ist. Auf diese Weise können Sie horizontal skalieren, ohne sich um die Größe der Subnetze der Edge-Dienste kümmern zu müssen. So kann beispielsweise eine Proxy-Routing-Tabelle an das Subnetz 10.10.3.0/24 angehängt werden, die alle öffentlichen Ströme an den NFV-Proxy leitet.

In einer Edge-Proxy-Firewall verwendete Funktionen

In diesem Anwendungsfall werden die folgenden Funktionen von Edge-Proxy-Firewalls verwendet:

  • Inaktivieren der IP-Spoofing-Prüfung in 10.10.0.5- und 10.10.1.5-Schnittstellen, um die Beibehaltung der Quellenadresse zu ermöglichen. Für diese Aktion sind erweiterte IAM-Berechtigungen für die Instanz erforderlich.
  • Ein öffentliches Gateway für ausgehende Datenflüsse mit Ressourcen, die nicht über den NFV-Proxy geleitet werden.
  • Die variable IP-Adresse wird der Schnittstelle 10.10.0.5 zugeordnet, um eingehende und ausgehende öffentliche Datenflüsse direkt zum NFV-Proxy zu ermöglichen.
  • Statusabhängige Sicherheitsgruppen und Zugriffssteuerungslisten (Access Control Lists, ACLs) zu den Instanzschnittstellen bzw. VPC-Teilnetzen hinzufügen, um zusätzliche Isolationsressourcen innerhalb der VPC bereitzustellen.

Anwendungsfall 2: Öffentliche Lastausgleichsfunktion

Öffentlicher Load Balancer
Load Balancer

Öffentlicher Load Balancer Web-Egress-Routing-Tabelle
Ziel Aktion Nächster Hop Standort
10.10.0.0/16 Delegierter Dallas DC 1
10.11.0.0/16 Delegierter Dallas DC 1
161.26.0.0/16 * Delegierter Dallas DC 1
166.8.0.0/14 * Delegierter Dallas DC 1
0.0.0.0/0 Zustellen 10.10.1.5 Dallas DC 1

Ziel: öffentliche Lastausgleichsfunktion

Hosting von Webanwendungen, die einen vom Kunden definierten Anwendungs- oder Netzwerk-Loadbalancer verwenden.

Durch die Verwendung von benutzerdefinierten VPC-Routen mit Egress-Routing pro Subnetz können Sie eine Tabelle erstellen, um das systemimplizite Routing mit dem VPC-Netzwerk außer Kraft zu setzen, ohne die Routing-Informationen auf jeder Instanz zu aktualisieren. In diesem Beispiel wird die IP-Adresse der Quelle von den Internetbenutzern zur Webschicht beibehalten. Die Schichten Web-zu-Anwendung und Anwendung-zu-Datenbank kommunizieren über implizites VPC-Routing und verwenden weiterhin das öffentliche Gateway für den Internet-Egress.

Die Routendelegierung ist für interne/private Netze in der VPC und für IBM Servicenetze über den privaten Backbone erforderlich. Um eine Delegierung zu vermeiden, können Server der Web-Schicht an das Teilnetz der App-Schicht angebunden und das Routing für die Webinstanzen so geändert werden, dass das Gateway des App-Teilnetzes als nächster Hop für die internen VPC-und Cloud-Servicenetze verwendet wird.

In öffentlichen Lastausgleichsfunktionen verwendete Funktionen

In diesem Anwendungsfall werden die folgenden Funktionen öffentlicher Lastausgleichsfunktionen verwendet:

  • Inaktivieren der IP-Spoofing-Prüfung in 10.10.0.5- und 10.10.1.5-Schnittstellen, um die Beibehaltung der Quellenadresse zu ermöglichen. Für diese Aktion sind erweiterte IAM-Berechtigungen für die Instanz erforderlich.
  • Ein öffentliches Gateway für ausgehende Datenflüsse mit Ressourcen, die nicht über den NFV-Proxy geleitet werden.
  • Die zugeordnete variable IP-Adresse der 10.10.0.5-Schnittstelle, um eingehende und ausgehende öffentliche Datenflüsse direkt zur NFV-Lastausgleichsfunktion zu ermöglichen.
  • Statusabhängige Sicherheitsgruppen und Zugriffssteuerungslisten (Access Control Lists, ACLs) zu den Instanzschnittstellen bzw. VPC-Teilnetzen hinzufügen, um zusätzliche Isolationsressourcen innerhalb der VPC bereitzustellen.

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.

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.

Damit Konnektivität zwischen den Teilnetzen besteht, wenn die Route 0.0.0.0/0 vorhanden und der nächste Hop eine VPN-Verbindung ist, können Sie die folgenden Delegierungsrouten hinzufügen:

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

Einschränkungen und Richtlinien

Die folgenden Einschränkungen und Richtlinien gelten für IBM Cloud Custom Routes for VPC.

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 Verwendung von bei IANA registrierten IPv4-Adressräumen nach RFC-1918 innerhalb Ihrer VPC, vorbehaltlich einiger Ausnahmen in den IANA-Sonderbereichen und ausgewählten Bereichen, die IBM Cloud-Services zugeordnet 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. Dies zählt als ein einziges 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.
  • 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.