Beachten Sie vor der Bestellung von IBM Cloud® Transit Gateway die hier aufgeführten Hinweise.
Allgemeine Aspekte
Alle Präfixe einer VPC und alle Subnetze eines klassischen Netzwerks werden mit dem Transit-Gateway verbunden, daher ist es wichtig, dass sie sich nicht überschneiden. Wenn Sie VPCs erstellen, die mit einem Transit-Gateway verbunden werden sollen,
müssen Sie sicherstellen, dass die VPCs mit VPC-Präfixen erstellt werden, die sich nicht überschneiden.
Erstellen Sie Ihr Transit-Gateway an einem Standort, der für Ihre Workload sinnvoll ist. Wenn Sie beispielsweise zwei VPCs in der Region us-south (Dallas) und eine VPC-Instanz in der Region eu-de (Frankfurt) verbinden,
wäre die Erstellung Ihres Gateways in der Region us-south die effizienteste Lösung für Ihre Workload.
Sie können eine Classic Access-VPC nicht direkt mit einem Transit-Gateway verbinden. Zum Verbinden der klassischen Ressourcen verwenden Sie die Verbindung für die
klassische IBM Cloud-Infrastruktur. So werden alle Ressourcen in Ihrer VPC mit klassischem Zugriff automatisch verbunden.
Ein Transit Gateway erfordert mindestens zwei Verbindungen, bevor Netzverkehr über das Transit Gateway fließen kann. Transit Gateways mit weniger als zwei Verbindungen über 45 Tage oder mehr müssen freigegeben (ausgesetzt und nach 30 Tagen
gelöscht) werden.
Sie können eine VPC, Direct Link oder eine klassische Infrastruktur mit mehreren lokalen Gateways und einem einzigen globalen Gateway verbinden.
Nach der Bereitstellung kann es einige Minuten dauern, bis Transit-Gateways und ihre Verbindungen verfügbar werden.
Geben Sie einen beschreibenden Namen für Ihre Transit-Gateway-Verbindungen an. Wenn Sie zu Ressourcen eine kontenübergreifende Verbindung herstellen, müssen Sie einen Verbindungsnamen angeben. Beim Herstellen von Verbindungen zu Ressourcen
in demselben Konto, zu dem auch das Transit-Gateway gehört, ist die Standardauswahl, die geändert werden kann, der VPC-Name oder der Begriff 'Klassisch'.
IBM Cloud Transit Gateway ist eine Multi-Tenant-Anwendung, bei der eine einzelne Instanz der Software und ihre unterstützende Infrastruktur mehrere Kunden bedient. Daher ist es wichtig, die Bandbreitennutzung zu überwachen. Wenn Sie zu viel
Bandbreite verwenden, wird Ihre Transit Gateway-Instanz möglicherweise ausgesetzt. Wenn Sie vermuten, dass dies der Fall ist, überprüfen Sie den Verbindungsstatus der Transit Gateway-Instanz, um festzustellen, ob sie sich im Status Suspended befindet. Ist dies der Fall, setzen Sie Unterstützung anfordern wieder ein.
Die folgenden ASNs sind in Verbindungen vom Typ Transit Gateway Generic Routing Encapsulation (GRE) und Direct Link blockiert. Vermeiden Sie die Verwendung dieser ASNs auf Appliances, damit sie nicht in den bereitgestellten Routen im AS-Pfad
enthalten sind. Die Einbeziehung dieser ASNs verhindert, dass Netze ordnungsgemäß funktionieren.
Beachten Sie bei der Planung von ECMP (Equal-Cost Multi-Path), dass der Durchsatz nicht linear mit der Anzahl der direkten Verbindungen skaliert. Wenn Sie beispielsweise zwei 10-GB-Direktverbindungen an ein ECMP-fähiges Transit-Gateway anschließen,
erhalten Sie keinen Durchsatz von 20 GB; der Durchsatz liegt zwar über 10 GB, aber unter 20 GB. Das liegt daran, dass ECMP auf Stream- oder Quellbasis funktioniert. Das bedeutet: Wenn der Datenverkehr von einem einzigen Endpunkt stammt,
wird wahrscheinlich eine Verbindung bevorzugt und nicht beide. Um einen ausgewogeneren Durchsatz zu erzielen, wird empfohlen, Datenverkehr aus mehreren Quellen zu leiten, da sich dadurch die Last gleichmäßiger auf die verfügbaren Direktverbindungen
verteilt.
Einschränkung: ECMP funktioniert nicht bei direkten Verbindungen über einen einzelnen Router. Stattdessen wird es von mehreren Routern mit direkten Verbindungen unterstützt, solange diese Router dasselbe Präfix bewerben.
Bekannte Einschränkung: Neue Transit-Gateways unterstützen 4-Wege-ECMP, aber bestehende Gateways können diese Funktion nicht nutzen, es sei denn, Sie öffnen einen Support-Fall für Hilfe.
Wenn Sie nicht möchten, dass die ECMP-Funktion auf Ihren Transit-Gateways aktiviert wird, können Sie einen Support-Fall eröffnen, um in eine Denyliste aufgenommen zu werden, wodurch diese Funktion auf Ihren Gateways deaktiviert wird.
Hinweise zur Preisgestaltung
Der Kostenvoranschlag IBM Cloud auf der Seite Transit Gateway kann keine Netzwerkverbindungstypen interpretieren. Um eine zuverlässige Kostenschätzung zu erhalten, geben Sie die geschätzte Anzahl
der Transit-Gateways und Verbindungen ein. Beachten Sie, dass bei der Erstellung einer redundanten GRE jeder Tunnel eine individuelle Verbindung ist, die auf Ihr Verbindungslimit anrechnet.
Aspekte zu Verbindungen der klassischen Infrastruktur
Wenn Sie ein Transit-Gateway verwenden möchten, um Ihre VPCs mit Ihrer klassischen IBM Cloud-Infrastruktur zu verbinden, müssen Sie Ihr klassisches Konto für das virtuelle Routing und die Weiterleitung (VRF) aktivieren und es mit Ihrem IBM
Cloud-Konto verknüpfen. Weitere Informationen zum Aktivieren Ihres Kontos für VRF finden Sie unter VRF und Serviceendpunkte aktivieren.
Wenn Sie eine VPC und die klassische Infrastruktur mit einem Transit-Gateway verbinden, werden alle Präfixe in der VPC für die VRF in der klassischen Infrastruktur sichtbar, die IP-Adressen im Bereich 10.0.0.0/8 verwendet. Um
eine erfolgreiche Anbindung an die klassische Infrastruktur zu gewährleisten, sollten Sie in Ihren VPCs keine Präfixe verwenden, die sich mit den Blöcken 10.254.0.0/1610.0.0.0/14, 10.200.0.0/14,
10.198.0.0/15, und überschneiden. Verwenden Sie ebenfalls keine Adressen aus den Teilnetzen Ihrer klassischen Infrastruktur. Informationen zum Anzeigen einer Liste Ihrer Teilnetze der klassischen Infrastruktur finden Sie unter
Alle Teilnetze anzeigen.
Klassische Virtual Server-Instanzen können sowohl eine private (eth0) als auch eine öffentliche (eth1) Netzschnittstelle besitzen. Derzeit verweisen die Routing-Tabellen für diese Schnittstellen das Standardgateway
auf die öffentliche Schnittstelle (eth1). Möglicherweise müssen Sie Routing-Einträge hinzufügen, um die Teilnetze von anderen VPCs über die private Schnittstelle weiterzuleiten.
Alle Netze Ihrer klassischen IBM Cloud-Infrastruktur über MZRs hinweg sind über diese Verbindung verfügbar, unabhängig vom Ort des Transit-Gateways oder dem angegebenen Routingtyp.
Ressourcen der klassischen Infrastruktur, die sich in diesen Rechenzentren befinden, werden über ein Transit Gateway mit VPC-Ressourcen verbunden.
Wenn die klassische Infrastruktur mit einem Transit-Gateway verbunden ist, umfasst sie auch alle mit dem Konto verknüpften Classic Access-VPCs, da die Subnetze dieser VPCs dem VRF der klassischen Infrastruktur zugeordnet
sind. Die einzige Möglichkeit, ein Transit-Gateway mit einer VPC des Typs 'Klassischer Zugriff' zu verbinden, besteht darin, eine Verbindung der gesamten klassischen Infrastruktur (und nicht nur der entsprechenden VPCs des Typs 'Klassischer
Zugriff') zum Transit-Gateway herzustellen.
Klassische Verbindungen, die sich in demselben Rechenzentrum befinden, können nicht miteinander kommunizieren, wenn sie sich in einer anderen Region als das Transit Gateway befinden.
Überlegungen zur Präfix-Filterung
Präfixfilter werden für alle Transit Gateway-Verbindungstypen unterstützt, mit Ausnahme der alten GRE-Tunnelverbindungen. Bei GRE-Verbindungen wird die Präfixfilterung sowohl für redundante GRE- als auch für ungebundene GRE-Verbindungstypen
unterstützt.
Für Nicht-GRE-Verbindungen kann der Netzeigentümer Präfixfilter hinzufügen. Bei GRE-Verbindungen kann nur der Eigentümer von Transit Gateway Präfixfilter hinzufügen oder ändern, was bei kontoübergreifenden Verbindungen wichtig ist.
Bei kontenübergreifenden Verbindungen kann nur der Kontoeigner der entsprechenden Verbindung Präfixfilter ändern. Andere Konten können die Verbindung einsehen, die Filter jedoch nicht ändern.
Sie können eingehende Präfixe aus einem anderen Konto nicht filtern.
Für redundante GRE- und VPN-Gateway-Verbindungen können Präfixfilter nur auf der obersten Verbindungsebene konfiguriert werden. Einzelne Tunnel unter diesen Verbindungen unterstützen keine separaten Präfixfilter; jeder Filter, der auf der
obersten Ebene angewendet wird, gilt für alle zugehörigen Tunnel.
Die Präfixfilter in der Liste werden nacheinander verarbeitet. Sie können die Bestellung jederzeit ändern.
Wenn Sie als Verbindungsreichweitenoption Verbindung zu einem Netzwerk in einem anderen Konto anfordern auswählen, können Sie keine Präfixfilter festlegen, da Sie nicht der Netzwerkbesitzer für diese Verbindung sind. Präfixfilter
müssen in dem Konto konfiguriert werden, das Eigentümer des Netzwerks ist. Bei GRE-Verbindungen kann nur der Eigentümer von Transit Gateway beim Erstellen der Verbindung Präfixfilter setzen.
Teilnetzmasken für Präfixfilter sind spezifisch. Beispielsweise 10.10.20.0/24 passt eine Regel, die als definiert ist, nicht zum Subnetz 10.10.20.0/28 oder zu einem anderen Subnetzpräfix.
Lesen Sie die folgenden Hinweise zu Ihrer speziellen GRE-Verbindung.
Allgemeine Hinweise zu GRE-Verbindungen
Wenn Sie einen GRE-Tunnel konfigurieren, müssen Sie eine Verfügbarkeitszone angeben, in der der Tunnel erstellt werden soll. Aus diesem Grund ist ein Netz, das über einen GRE-Tunnel in dieser Zone verbunden ist, nicht erreichbar, wenn diese
Zone aus irgendeinem Grund nicht verfügbar ist. Um einen hochverfügbaren GRE-Tunnel zu konfigurieren, müssen Sie einen GRE-Tunnel in mehreren Zonen erstellen, der die gleichen Endpunkte verbindet.
GRE-Verbindungen erfordern die Nutzung eines BGP-Service zwischen GRE-Tunnel-IP-Adressen. Das Transit Gateway konfiguriert einen BGP-Service in der Tunnelverbindung, bevor die Verbindung zum anderen Tunnelendpunkt hergestellt wird. Sobald
das BGP-Protokoll Routen zwischen dem verbundenen Endpunkt und dem Transit Gateway austauscht, wird der GRE-Tunnel zum Datenpfad für den weitergeleiteten Datenverkehr.
GRE-Tunnelrouten werden direkt über die über den Tunnel hergestellten BGP-Sitzungen erlernt. Aus diesem Grund ist die Präfixfilterung für diese Verbindungen nicht aktiviert.
Die Anzahl der GRE-Tunnel, die mit einem Transit Gateway verbunden sind, ist begrenzt. Das Standardkontingent ist 12.
Bei der Verwendung von Gleichkostenpfaden zwischen GRE und Direct Link (gleiche Pfadlänge) wird Direct Link gegenüber dem Lastausgleich zwischen GRE und Direct Link bevorzugt.
Überlegungen zur GRE-erweiterten Routenweitergabe
GRE enhanced route propagation steuert, ob GRE-Tunnel, die mit demselben Transit-Gateway verbunden sind, Routen voneinander lernen können, wenn sie zonenübergreifend oder innerhalb eines redundanten GRE-Paares (RGRE) sind.
Wenn Sie ein Transit-Gateway erstellen oder aktualisieren, sollten Sie prüfen, ob GRE-Tunnel in der Lage sein sollten, Routen gemeinsam zu nutzen. Das Aktivieren des Umschalters " GRE enhanced route propagation "
ermöglicht die Interkonnektivität zwischen GREs auf demselben Transit-Gateway und kann den Bedarf an redundanten Tunnelkonfigurationen verringern. Abhängig von Ihrer Topologie kann diese Einstellung zu bedeutenden Änderungen bei der Weiterleitung
von Routen und dem Verkehrsfluss führen.
Das Aktivieren oder Deaktivieren dieses Schalters kann zu sofortigen Änderungen der Routenausbreitung führen. Stellen Sie sicher, dass Sie die Auswirkungen verstehen, bevor Sie Änderungen in einer Produktionsumgebung vornehmen.
Wenn die Umschaltfunktion deaktiviert ist:
GRE-Tunnel, die sich im selben RGRE befinden, lernen keine Routen voneinander.
Ungebundene GRE-Tunnel, die in verschiedenen Transit-Gateway-Zonen landen, lernen die Routen nicht voneinander.
GRE-Tunnel in derselben Zone lernen weiterhin Routen voneinander.
Die Konfiguration schränkt die Routenausbreitung zwischen GRE-Tunneln ein, bietet aber keine strikte Netzwerkisolierung oder garantiert eine erzwungene Trennung.
Wenn der Schalter aktiviert ist:
GRE-Tunnel in einem RGRE-Paar lernen Routen voneinander, auch wenn sie sich in der gleichen Zone befinden.
Ungebundene GREs in verschiedenen Transit-Gateway-Zonen lernen auch Routen voneinander, was eine zonenübergreifende Routenausbreitung ermöglicht.
Diese Konfiguration ermöglicht es GREs, Routen von anderen GREs zu lernen, über Zonen hinweg oder innerhalb desselben RGREs, was die Art und Weise, wie Routen propagiert werden und wie der Verkehr durch Ihr Netzwerk fließt, verändern kann.
Hinweise zu redundanten GRE
Eine redundante GRE ist im Wesentlichen eine Gruppierung von mindestens zwei GRE-Tunneln.
Die Anzahl der Tunnel darf zwei Tunnel pro Zone nicht überschreiten.
Sie können die Tunnel innerhalb einer redundanten GRE in derselben oder in verschiedenen Zonen platzieren.
Alle Verbindungen und Tunnel auf dem Transit Gateway müssen eindeutige Namen haben.
Alle Tunnel in einem redundanten GRE zielen auf dasselbe Netz und dasselbe Konto.
Bei Verwendung des VPC-Basisnetztyps:
Sie müssen das IP-Spoofing-Flag für den VPC-Netztyp aktivieren. Informationen zum Aktivieren von IP-Spoofing-Prüfungen finden Sie unter Informationen zu IP-Spoofing.
Das Schnittstellenprofil des virtuellen Servers muss v2sein.
Die IP-Adresse des lokalen Gateways:
RFC 1918 muss eingehalten werden (andernfalls gibt es keine variablen IP-Adressen oder öffentlichen Gateways in der VPC)
Es darf sich nicht um eine IP-Adresse innerhalb des Multicast-Bereichs von 224.0.0.0 bis 239.255.255.255 handeln, und sie darf nicht in Konflikt mit bestehenden Netzwerken stehen, die mit dem Transit-Gateway
verbunden sind.
Kann nicht als local-gateway-ip für ein anderes GRE verwendet werden, das dasselbe Underlay-Netzwerk nutzt.
GRE verbesserte Routenausbreitung:
Wenn diese Funktion deaktiviert ist (Standard), werden die Routen aller Tunnel innerhalb eines redundanten GRE nicht aneinander weitergegeben und können nicht miteinander kommunizieren. Bei redundanten GRE-Tunneln können die Routen
jedoch an GRE-Tunnel außerhalb des redundanten GRE-Tunnels propagiert werden, die mit demselben Transit-Gateway verbunden sind und sich in derselben Zone befinden.
Wenn diese Option aktiviert ist, propagieren alle GRE-Tunnel ihre Routen an andere GREs, wenn sie mit demselben Transit-Gateway verbunden sind.
Hinweise zu nicht gebundenen GRE-Tunneln
Klassische Routen werden über einen ungebundenen GRE-Tunnel zugänglich gemacht.
Kann über andere nicht gebundene GRE-Tunnel kommunizieren, die mit demselben Transit Gateway in derselben Verfügbarkeitszone verbunden sind.
Ungebundene GRE-Tunnel auf demselben Transit-Gateway, die sich in verschiedenen Verfügbarkeitszonen befinden, können nicht miteinander kommunizieren, es sei denn, GRE enhanced route propagation ist aktiviert. Die Deaktivierung von GRE Enhanced
Route Propagation sollte jedoch nicht als Grundlage für die Netzwerkisolierung dienen, da die Abwesenheit von ungebundenem zonenübergreifendem GRE-Datenverkehr keine erzwungene Trennung garantiert.
Wenn Sie eine Netzisolation benötigen, ziehen Sie die Verwendung separater Transit Gateways in Betracht.
Keine klassische Verbindung auf dem Transit Gateway erforderlich. Klassische Netzwerk-Subnetze werden den Verbindungen am Transit-Gateway nicht bekannt gegeben (und umgekehrt).
Die Standardanzahl eindeutiger Basisnetze, die von nicht gebundenen GRE-Tunneln als Ziel verwendet werden können, ist auf fünf begrenzt. Sie können einen Support-Fall bei IBM eröffnen, wenn Sie eine Erweiterung dieser Service-Limits benötigen.
Klassische Routen werden nicht über einen Legacy-GRE-Tunnel weitergeleitet.
Kann nicht durch andere GRE-Tunnel auf demselben Transit-Gateway kommunizieren.
Erfordert vor der Erstellung eine klassische Verbindung auf dem Transit Gateway. Infolgedessen werden alle klassischen Teilnetze allen Verbindungen zugänglich gemacht, die dem Transit Gateway zugeordnet sind, sowie allen anderen Teilnetzen
der Verbindung im klassischen Netz.
Direct Link Hinweise zur Verbindung
Sie können direkte Verbindungsverbindungen zu einem Transit-Gateway erstellen, um lokale Netze zu ermöglichen, eine Verbindung zu anderen Netzen in IBM Cloudherzustellen. Nachdem die direkte Verbindung mit dem Transitgateway verbunden ist, erhält
das lokale Netz Zugriff auf alle anderen Transitgateway-Verbindungen. Ebenso haben alle anderen mit dem Transitgateway verbundenen Netze Zugriff auf das lokale Netz. Direct-Link-Verbindungen folgen dem gleichen Prozess für physische oder virtuelle
Querverbindungen als das Standard-Direct-Link-Angebot. Nachdem die Verbindung von einem Transitgateway gelöscht wurde, wird das Transigateway so betrieben, als ob es nie mit einer direkten Verbindung verbunden gewesen wäre.
Dieselben Teilnetzüberlegungen für Transitgateway-Verbindungen gelten auch für Direct-Link-Verbindungen. Um eine erfolgreiche Verbindung sicherzustellen, sollten Sie in Ihrem mit Direct Link verbundenen Netzwerk keine Präfixe verwenden, die
sich mit anderen Verbindungen überschneiden.
Hinweise zur Power Virtual Server-Verbindung
Sie können eine Power Virtual Server-Instanz mit einem Transit Gateway verbinden. Damit können Sie Power Virtual Server direkt an ein nachgeordnetes Transit Gateway anhängen. Nachdem das „ Power Virtual Server “ mit dem Transit-Gateway verbunden
wurde, hat Ihre „ Power Virtual Server “-Dienstinstanz Zugriff auf alle nachgelagerten Ressourcen und Dienste des Transit-Gateways. Ebenso haben alle nachgelagerten Netzwerke, die mit dem Transit-Gateway verbunden sind, Zugriff auf die Power
Virtual Server-Instanz.
Power Virtual Server-Verbindungen können lokales oder globales Routing verwenden. Nur Power Virtual Server-Instanzen in derselben Region wie das Transit Gateway können lokales Routing verwenden. Außerdem kann eine Power Virtual Server-Instanz
mit mehreren Transit Gateways mit lokalem Routing verbunden werden, aber nur ein Transit Gateway mit globalem Routing. Nachgeschaltete Services berücksichtigen die Routenvorgabe auf der Basis des Transit Gateway-Typs.
Die gleichen Überlegungen zum Netzwerk-Subnetz, die für Transit-Gateway-Verbindungen gelten, treffen auch auf Power Virtual Server-Verbindungen zu. Um eine erfolgreiche Verbindung zu gewährleisten, sollten Sie in Ihrer Power Virtual Server-Instanz
keine Präfixe verwenden, die sich mit anderen Verbindungen überschneiden. Beachten Sie, dass Transit Gateway eine Präfix-Filterung bietet, um die freizugebenden Präfixe einzuschränken, sowie einen Routing-Tabellenbericht, um etwaige Überschneidungen
nach dem Aufbau der Verbindung zu erkennen.
Überlegungen zur VPN-Gateway-Verbindung
Sie können VPN-Gateway-Verbindungen zu einem Transit-Gateway erstellen, um lokale oder externe Netzwerke mit anderen Netzwerken in IBM Cloud zu verbinden. Das VPN-Gateway fungiert als Spoke innerhalb der Transit-Gateway-Architektur und ermöglicht
ein effizientes Peering über mehrere Netze hinweg bei gleichzeitiger Reduzierung der Tunnelkomplexität. Dieses Design verwendet dynamisches Routing mit eBGP über redundante GRE-Tunnel, um eine skalierbare und robuste Konnektivität zu gewährleisten.
Jede VPN-Gateway-Verbindung stellt automatisch vier redundante GRE-Tunnel zwischen dem VPN-Gateway und dem Transit-Gateway bereit. IBM verwaltet diese Tunnel, über die eBGP-Sitzungen für dynamisches Routing laufen. Die Konnektivität vor
Ort nutzt eBGP über IPsec-Tunnel für eine sichere Kommunikation. Während Sie VPN-Gateway-Verbindungen erstellen, löschen und umbenennen können, können Sie die einzelnen GRE-Tunnel nicht ändern oder entfernen.
Die Preisgestaltung basiert auf den Kosten für 4 GRE-Tunnel pro Verbindung zuzüglich der Gebühren für den Datenverkehr.
VPN-Gateway-Verbindungen sind standardmäßig auf 4 pro Transit-Gateway und 2 pro Zone begrenzt.
VPN-Gateway-Verbindungen unterstützen keine Präfix-Filterung. Sie sind für die Verwaltung jeglicher Routenfilterung auf Ihrer Seite der BGP-Sitzung verantwortlich.
Sie können jederzeit dynamische oder statische VPN-Verbindungen aufbauen. Statische Verbindungen sind mit oder ohne Transit-Gateway-Anbindung möglich. Bei dynamischen Verbindungen muss das VPN-Gateway mit einem Transit-Gateway verbunden
sein, bevor der Verkehr fließen kann.
Nachdem ein VPN-Gateway mit einem Transit-Gateway verbunden ist, kann die lokale ASN nicht mehr geändert werden.
Um ein VPN als Backup für eine Direct Link-Verbindung zu konfigurieren, müssen Sie sicherstellen, dass die Routen von Direct Link bevorzugt werden. Zu diesem Zweck können Sie Mechanismen wie AS Path Prepending oder MED (Multi-Exit Discriminator)
auf Ihrem lokalen Gerät nutzen.
Wenn Sie eine VPN-Gateway-Verbindung erstellen, müssen Sie einen CIDR-Block für die GRE-Tunnel-IP-Adressen definieren. Es wird empfohlen, einen privaten RFC 1918-Adressbereich zu verwenden, da hierfür keine zusätzliche Delegate-VPC-Route erforderlich ist. Der CIDR-Block muss mindestens /27 lauten und darf sich nicht mit anderen auf dem Transit-Gateway konfigurierten Verbindungs-CIDRs
überschneiden.
Wenn Sie einem VPN-Gateway einen CIDR zuweisen, der außerhalb der standardmäßigen privaten IP-Bereiche (10.0.0.0/8, 172.16.0.0/12 oder 192.168.0.0/16) liegt, müssen Sie manuell Routen in der VPC-Routing-Tabelle
(in derselben Zone wie das VPN-Gateway) hinzufügen, um einen ordnungsgemäßen Verkehrsfluss zu ermöglichen. Es stehen zwei Optionen zur Auswahl:
Fügen Sie eine einzelne Route hinzu, bei der das Ziel auf die vollständige, dem VPN zugewiesene CIDR (z. B. 100.31.128.0/18) und die Aktion auf Delegate-VPC gesetzt ist.
Fügen Sie vier separate Routen hinzu, die jeweils auf die lokale Gateway-IP jedes VPN-Tunnels abzielen (z. B. 100.31.128.1/32), wobei die Aktion auf Delegate-VPC gesetzt ist.
Die erste Option ist einfacher, während die zweite Option eine detailliertere Routing-Steuerung bietet, die bei fortgeschrittenen Netzwerkdesigns oder bei der Fehlersuche bevorzugt werden kann.
Hinweise zu VPC
IBM Cloud VPC ermöglicht die Nutzung von Adressräumen im Format RFC-1918 und von bei der IANA registrierten Adressräumen im Format IPv4 – privat
innerhalb Ihrer VPC, mit einigen Ausnahmen in den IANA-Sonderbereichen sowie in ausgewählten Bereichen, die den Diensten von IBM Cloud zugewiesen sind. Bei Verwendung von bei IANA registrierten Bereichen innerhalb Ihres Unternehmens und
innerhalb von VPCs in Kombination mit IBM Cloud Transit Gateway müssen angepasste Routen in jeder Zone installiert sein. Weitere Informationen finden Sie unter Aspekte beim Routing von durch IANA registrierte IP-Zuweisungen.
Sie können ein einzelnes Transit Gateway oder mehrere Transit Gateways erstellen, um mehrere IBM Cloud -VPCs miteinander zu verbinden. Sie können Ihre klassische IBM Cloud -Infrastruktur auch mit einem Transit Gateway verbinden, um eine
nahtlose Kommunikation mit Ressourcen der klassischen Infrastruktur zu ermöglichen. Weitere Informationen hierzu finden Sie unter VPCs verbinden.
Bare Metal in VPC wird nicht unterstützt.
Aspekte zum Routing
Da alle Verbindungen zu einem Transit-Gateway miteinander verbunden sind, sollten Sie sorgfältig darauf achten, welche Ressourcen Sie miteinander verbinden möchten, bevor Sie für die einzelnen Gateways entscheiden, ob Sie für die einzelnen
Gateways lokales oder globales Routing einrichten.
Bei beiden Routing-Optionen verlässt der Datenverkehr in keinem Fall das private IBM Cloud-Netz und ist für die Leistung optimiert.
Wenn Sie vorhaben, mit Ihrem Gateway VPCs innerhalb derselben Region mit mehreren Zonen (MZR) zu verbinden, verwenden Sie lokales Routing, um Konnektivität für alle zugänglichen
Ressourcen innerhalb derselben MZR herzustellen; z. B. us-south (Dallas).
caption-side=bottom" für lokales Routing*
Falls Sie beabsichtigen, mit Ihren Transit-Gateways VPC lokal und zwischen unterschiedlichen Mehrzonenregionen (MZRs) zu verbinden, sollten Sie für VPCs in derselben Mehrzonenregion
lokale Gateways verwenden und für VPCs in mehreren Mehrzonenregionen ein globales Gateway nutzen. Sie können das Beispiel verwenden, das einem Hochverfügbarkeitsszenario (HA-Szenario) entspricht. Alle Daten in VPCs A und B können auf VPCs
C und D repliziert werden. Wenn es ein Problem in der Region 'US South' gibt, werden Verbindungen an 'US East' weitergeleitet.
![Globales](/images/2-aboutLocalAndGlobalRoutingExample.png "und globales " caption-side="bottom"} für die "){: caption="von lokalem und globalem Routing*
Ungeachtet des angegebenen Routing-Typs kann IBM Cloud Transit Gateway eine Verbindung zu klassischen Netzen herstellen, die sich in einer beliebigen MZR befinden. Hierzu müssen Sie einfach nur die klassische Verbindung zu Ihrem Transit-Gateway
hinzufügen.
Sie können den Routing-Typ eines Gateways nach der Bereitstellung noch bearbeiten. Um den Routing-Typ jedoch von Global auf Lokal umzustellen, müssen Sie zunächst alle globalen Verbindungen entfernen (d.
h. Verbindungen zu Ressourcen, die sich nicht am selben Standort wie das Gateway befinden). Beachten Sie, dass Verbindungen zur klassischen IBM Cloud-Infrastruktur immer als lokale Verbindungen gelten.
Wenn Sie vom lokalen zum globalen Routing wechseln, werden Ihnen alle damit verbundenen globalen Verbindungen in Rechnung gestellt. Die Änderung des Routing-Typs hat keine Auswirkungen auf den Netzverkehr.
Hinweise zu Routenberichten
Der in einem Routenbericht angezeigte AS-Pfad bietet eine Einzelzonenperspektive. Wenn sich Ihre Quelle oder Ihr Ziel über verschiedene Zonen erstreckt, kann die Pfadlänge variieren. Nehmen wir zum Beispiel zwei direkte Verbindungen: eine
in DAL10 und die andere in DAL12, die beide die gleiche AS-Pfadlänge in Richtung eines DAL-basierten Transit-Gateways anzeigen, das mit einer VPC oder klassischen Umgebung verbunden ist. Beim Aufruf
von einer virtuellen Serverinstanz DAL10:
Die direkte Verbindung DAL10 ist vorzuziehen.
Für Verbindungen, die von DAL12 ausgehen, wird die Direktverbindung DAL12 bevorzugt.
Im Fall von DAL13 würden Sie entweder ECMP-Routing erhalten, vorausgesetzt, Ihr Gateway ist dafür eingerichtet, oder es würde ein einzelner direkter Link verwendet werden. Bei einem BGP-Reset könnte er jedoch auf die andere Direktverbindung
wechseln.
Überlappende Routen sind ein gängiges Problem bei der Konfiguration eines Transit Gateway. Wenn sich die Routen von zwei oder mehr Verbindungen überschneiden, wird der Datenverkehr möglicherweise nicht wie vorgesehen weitergeleitet. Weitere
Informationen finden Sie unter Routenkonflikte adressieren.
Nachdem eine neue virtuelle Verbindung (VPC, klassische Infrastruktur oder Direct Link) den Status Aktiv erreicht hat, warten Sie 5 Minuten, bis die Routen von Ihrem Transit Gateway erkannt wurden. Das Generieren eines Routenberichts,
bevor alle Routen gelernt werden, führt zu einem partiellen Routenbericht.
Wenn eine Verbindung eine Route von 0.0.0.0/0 bereitstellt, wird diese Route bei der Berechnung überlappender Präfixe ignoriert.
Es ist immer nur ein einziger Bericht pro Gateway verfügbar. Wenn Sie einen neuen Bericht generieren, wird der alte Bericht gelöscht.
Ältere Routenberichte sind möglicherweise ungenau, nachdem Sie eine Verbindung hinzugefügt oder entfernt haben. Wenn Sie also Routen innerhalb dieser Verbindungen aktualisieren, empfiehlt es sich, einen neuen Routenbericht zu erstellen.
Wenn eine oder mehrere Routen durch Präfixfilter verweigert werden, erscheinen diese Routen nicht im Routenbericht.
Servicegrenzwerte
Denken Sie bei der Verwendung von IBM Cloud Transit Gateway an die folgenden Servicegrenzwerte.
Grenzen desIBM Cloud Transit Gateway
Servicegrenzwert
Standard
Anzahl der Transit-Gateways
10 Gateways pro Konto, 5 Gateways pro Region
Anzahl der Verbindungen pro Transit-Gateway
10 IBM Cloud VPC Verbindungen
5 IBM Cloud klassische Verbindungen
5 IBM Cloud Direct Link Verbindungen
5 Power Virtual Server Verbindungen
Anzahl der Präfixe pro Verbindung
50 Präfixe für VPC Verbindungen
120 Präfixe für klassische Verbindungen
120 Präfixe für GRE Verbindungen
120 Präfixe für Direct Link Verbindungen
120 Präfixe für Power Virtual Server Verbindungen
Anzahl der Verbindungen mit Präfixfiltern
2 Verbindungen mit Präfixfiltern pro Gateway
Anzahl der Präfixfilter pro Verbindung
10 Präfixfilter pro Verbindung
Anzahl der GRE-Tunnel pro Transit Gateway
12 GRE-Tunnel pro Gateway
Anzahl der eindeutigen Basisnetze, die Ziel von nicht gebundenen GRE-Tunneln pro Transit Gateway sind
5 eindeutige Basisnetze, die von nicht gebundenen GRE-Tunneln pro Gateway als Ziel ausgewählt werden
Falls Sie höhere Servicegrenzwerte benötigen, können Sie einen IBM Support-Fall öffnen.
