Cloud Router – Übersicht

Cloud Router ist ein vollständig verteilter und verwalteter Google Cloud-Dienst. Er skaliert entsprechend dem Netzwerkverkehr und ist kein Hardwaregerät, sodass er keinen Engpass verursachen kann.

Wenn Sie Ihr lokales Netzwerk auf Google Cloud erweitern, verwenden Sie Cloud Router zum dynamischen Austausch von Routen zwischen Ihren Google Cloud-Netzwerken und Ihrem lokalen Netzwerk. Cloud Router verbindet sich mit Ihrem lokalen VPN-Gateway oder Router. Die Router tauschen Topologieinformationen über Border Gateway Protocol (BGP) aus. Topologieänderungen werden automatisch zwischen Ihrem VPC-Netzwerk und dem lokalen Netzwerk übertragen. Sie müssen keine statischen Routen konfigurieren.

Cloud Router arbeitet sowohl mit älteren Netzwerken als auch mit VPC-Netzwerken (Virtual Private Cloud) zusammen.

Statisches und dynamisches Routing im Vergleich

Bei statischen Routen müssen Sie eine Routingtabelle erstellen oder pflegen. Bei beiden Netzwerken erfordert eine Topologieänderung, dass Sie statische Routen manuell aktualisieren. Außerdem können statische Routen den Datenverkehr nicht automatisch umleiten, wenn eine Verbindung fehlschlägt.

Das statische Routing eignet sich für kleine Netzwerke mit stabilen Topologien. Außerdem haben Sie eine genaue Kontrolle über die Routingtabellen. Router senden keine Advertisings zwischen Netzwerken.

Bei Cloud Router können Sie BGP verwenden, um zwischen den Netzwerken Informationen auszutauschen. Anstatt statische Routen manuell zu konfigurieren, erkennen Netzwerke Topologieänderungen automatisch und schnell über BGP. Änderungen werden nahtlos implementiert, ohne den Datenverkehr zu unterbrechen. Diese Methode für den Austausch von Routen über BGP wird dynamisches Routing genannt.

Dynamisches Routing eignet sich für Netzwerke von beliebiger Größe. Es nimmt Ihnen die Pflege statischer Routen ab. Wenn eine Verbindung fehlschlägt, kann dynamisches Routing den Datenverkehr automatisch umleiten, wenn dies möglich ist. Erstellen Sie einen Cloud Router, um das dynamische Routing zu aktivieren. Anschließend konfigurieren Sie eine BGP-Sitzung zwischen dem Cloud Router und dem lokalen Gateway oder Router.

Statisches Routing für VPN-Tunnel

Ohne Cloud Router können Sie Ihr VPN nur mit statischen Routen konfigurieren. Statische Routen haben folgende Nachteile:

  • Bei einer Änderung der Netzwerkkonfiguration auf einer der beiden Seiten des VPN-Tunnels müssen statische Routen entsprechend dieser Änderung manuell erstellt und gelöscht werden. Außerdem bedeutet das Konvergieren von Änderungen statischer Routen einen hohen Zeitaufwand.
  • Bevor der Tunnel erstellt wird, muss bei der Einrichtung eines VPN-Tunnels mit statischen Routen die Liste der IP-Präfixe auf beiden Seiten des Tunnels festgelegt werden. Daher muss bei jeder erforderlichen Routenänderung der VPN-Tunnel mit den neuen Routen aktualisiert (gelöscht und neu erstellt) werden. Dadurch wird der laufende Traffic unterbrochen.
  • Für die Konfiguration statischer Routen gibt es keine Standardmethode. Die Befehle unterscheiden sich je nach Anbieter.

Im folgenden Beispiel besteht Ihr kombiniertes Netzwerk aus Ihrem Google Cloud-Netzwerk und 29 Subnetzen (eines pro Rack) im lokalen Netzwerk auf der anderen Seite des VPN-Tunnels. Nehmen wir für dieses Beispiel an, dass Ihr Geschäft wächst und Sie deshalb jede Woche ein neues Subnetz mit Geräten hinzufügen müssen. In dieser Woche fügen Sie das Subnetz 10.0.30.0/24 hinzu, wie im folgenden Diagramm dargestellt:

Cloud Router für VPNs mit VPC-Netzwerk (zum Vergrößern klicken)
VPN ohne Cloud Router (zum Vergrößern klicken)

In diesem Szenario erfordert ein VPN mit statischen Routen die folgenden Änderungen:

  1. Statische Routen müssen zur Google Cloud Platform hinzugefügt werden, um das neue lokale Subnetz zu erreichen.
  2. Der VPN-Tunnel muss entfernt und neu erstellt werden, um das neue lokale Subnetz einzuschließen.

Konfigurationsänderungen an statischen Routen und VPN-Tunneln können durch die Verwendung eines Cloud Routers vermieden werden. Der Cloud Router verbindet sich per BGP mit Ihrem VPN-Gateway, um Topologieinformationen auszutauschen. In der Tat werden Änderungen der Netzwerktopologie in Ihrem Google Cloud Platform-Netzwerk automatisch auf Ihr eigenes Netzwerk und umgekehrt über BGP übertragen, sodass Sie keine statischen Routen für Ihre VPN-Tunnel konfigurieren müssen.

Dynamisches Routing für VPN-Tunnel in VPC-Netzwerken

Mithilfe von VPC-Netzwerken können Sie den IP-Bereich des Netzwerks regional in Präfixe (Subnetze) gliedern und steuern, welches Präfix der internen IP-Adresse einer VM-Instanz zugeordnet wird. Verwenden Sie Cloud Router, um das dynamische Routing für Ihren VPN-Tunnel zu aktivieren, damit Sie diese Subnetze nicht statisch verwalten müssen, was vor allem durch das Hinzufügen und Entfernen entsprechender statischer Routen für Ihr VPN Zusatzaufwand bedeutet.

Ein Cloud Router gehört zu einem bestimmten VPC-Netzwerk und einer Region. Cloud Router bewirbt Subnetze aus seinem VPC-Netzwerk über BGP für das lokale Gateway. Es bewirbt die Subnetze in seiner lokalen Region oder alle Subnetze im Netzwerk basierend auf dem dynamischen Routingmodus des VPC-Netzwerks. Cloud Router erkennt außerdem die lokalen Routen über BGP und ermöglicht der Netzwerkinfrastruktur, die beste Route zum Erreichen der zugehörigen Präfixe auszuwählen.

Im folgenden Beispiel sehen Sie Cloud Router mit VPC-Netzwerken im benutzerdefinierten Modus. Für VPC-Netzwerke im automatischen Modus gibt Cloud Router automatisch das /20-Präfix der Region an.

Das folgende Diagramm zeigt zwei verschiedene regionale Subnetze in einem VPC-Netzwerk und 30 Subnetze im lokalen Netzwerk. Die beiden Netzwerke sind über einen Cloud VPN-Tunnel miteinander verbunden. In diesem Szenario werden in beiden Netzwerken neue Subnetze hinzugefügt:

  1. Ein neues Subnetz 192.168.1.0/24 in der Region us-east-1 des GCP-Netzwerks
  2. Ein neues lokales Subnetz 10.0.30.0/24 für die Verarbeitung des erhöhten Traffics in Ihrem Rechenzentrum
Cloud Router für VPNs mit VPC-Netzwerk (zum Vergrößern klicken)
Cloud Router für VPNs mit VPC-Netzwerk (zum Vergrößern klicken)

Um Änderungen an der Netzwerkkonfiguration automatisch weiterzuleiten, erstellt der VPN-Tunnel mithilfe von Cloud Router eine BGP-Sitzung zwischen dem lokalen VPN-Gateway und dem Peer-Gateway, welches BGP unterstützen muss. Die neuen Subnetze werden nahtlos zwischen Netzwerken beworben. Instanzen in den neuen Subnetzen können sofort Datenverkehr senden und empfangen.

Um das BGP einzurichten, muss beiden Enden des VPN-Tunnels eine zusätzliche IP-Adresse zugewiesen werden. Diese beiden IP-Adressen müssen Link-Local-IP-Adressen sein, die zum IP-Adressbereich 169.254.0.0/16 gehören. Diese Adressen sind nicht Teil des IP-Adressbereichs eines der Netzwerke. Diese beiden Adressen dienen ausschließlich zum Erstellen einer BGP-Sitzung. Die Adressen sind nicht routingfähig. Daher funktionieren sie nicht gut mit gängigen Tools für Netzwerktests. Traceroute funktioniert beispielsweise gar nicht und ein Ping-Test funktioniert nur dann, wenn die Anfrage von der Link-Local-Adresse stammt, die für die Link-Local-Adresse des Peers bestimmt ist.

Dynamisches Routing für VPN-Tunnel in alten Netzwerken

In Legacy-Netzwerken werden Änderungen an der Netzwerkkonfiguration automatisch weitergeleitet, ohne dass statische Routen neu konfiguriert werden müssen und der VPN-Tunnel, ähnlich wie im vorherigen Beispiel, neu gestartet werden muss.

Die BGP-Sitzung informiert jeden Router über lokale Änderungen. Um das BGP einzurichten, muss jedem Ende des VPN-Tunnels eine zusätzliche IP-Adresse zugewiesen werden. Diese beiden IP-Adressen müssen Link-Local-IP-Adressen sein, die zum IP-Adressbereich 169.254.0.0/16 gehören. Diese Adressen gehören nicht zum IP-Adressbereich auf einer der beiden Seiten des Tunnels und werden ausschließlich für die Konfiguration von BGP-Peers zum Erstellen einer BGP-Sitzung verwendet.

Sie müssen auf beiden Seiten des Tunnels zwei Link-Local-IP-Adressen, die beide aus demselben Subnetz stammen, sowie eine Netzmaske konfigurieren. Nachdem Sie diese Änderungen auf beiden Seiten des Tunnels konfiguriert haben, wird eine BGP-Sitzung erstellt.

Auch hier gilt: Wenn ein Netzwerk VPN-Tunnel in mehreren Regionen hat, muss in jeder Region, in der dynamisches Routing gewünscht wird, ein Cloud Router erstellt werden. Ein einzelner Cloud Router kann für mehrere VPN-Gateways und mehrere Tunnel in der Netzwerkregion verwendet werden, zu der der Router gehört.

Modus für dynamisches Routing

Der dynamische Routingmodus eines VPC-Netzwerks bestimmt, welche Subnetze für Cloud Router sichtbar sind. Sie können den dynamischen Routingmodus auf global oder regional festlegen:

  • Beim globalen dynamischen Routing bewirbt ein Cloud Router alle Subnetze im VPC-Netzwerk gegenüber dem lokalen Router. Cloud Router leitet alle erkannten Routen vom lokalen Router an alle Regionen weiter.
  • Beim regionalen dynamischen Routing bewirbt ein Cloud Router Routen in seiner lokalen Region und leitet sie weiter.

Der dynamische Routingmodus wird auf dem VPC-Netzwerk konfiguriert. Wenn Sie ein VPC-Netzwerk erstellen oder bearbeiten, können Sie den dynamischen Routingmodus auf global oder regional einstellen. Alle Cloud Router-Instanzen im VPC-Netzwerk verwenden den dynamischen Routingmodus des Netzwerks. Standardmäßig ist der Modus regional.

Wenn Sie den dynamischen Routingmodus für ein VPC-Netzwerk ändern, berücksichtigen Sie die Auswirkungen, z. B. die Unterbrechung bestehender Verbindungen oder die Aktivierung unbeabsichtigter Routen. Wenn Sie beispielsweise zum regionalen dynamischen Routing wechseln, könnten die Verbindungen von VM-Instanzen zu VPN-Tunneln und Interconnect-Verbindungen in eine andere Region verloren gehen. Wenn Sie zum globalen dynamischen Routing wechseln, bietet Cloud Router möglicherweise VM-Instanzen aus Regionen an, für die Sie das nicht möchten. Informationen zum Anzeigen oder Konfigurieren des dynamischen Routingmodus finden Sie unter Regionales oder globales dynamisches Routing festlegen.

Beispiel für regionales dynamisches Routing

Beim regionalen dynamischen Routing haben Sie möglicherweise einen Cloud VPN-Tunnel und VM-Instanzen in einer einzigen GCP-Region. Der Tunnel erweitert Ihr lokales Netzwerk auf ein VPC-Netzwerk. VM-Instanzen in anderen Regionen müssen möglicherweise eine Verbindung zum lokalen Netzwerk herstellen, können den Tunnel jedoch nicht erreichen. Um diese Einschränkung zu umgehen, können Sie statische Routen erstellen. Das Beibehalten statischer Routen kann jedoch fehleranfällig sein und den Datenverkehr stören.

Im folgenden Beispiel sind nur Ressourcen in der Region us-west1 für den Cloud Router sichtbar. VM-Instanzen in anderen Regionen, z. B. us-central1, können den Cloud VPN-Tunnel nicht erreichen.

Cloud Router – regionales dynamisches Routing (zum Vergrößern klicken)
Cloud Router – regionales dynamisches Routing (zum Vergrößern klicken)

Beispiele für globales dynamisches Routing

Beim globalen dynamischen Routing sind Ressourcen in allen Regionen für den Cloud Router sichtbar. Wenn Sie beispielsweise VM-Instanzen in einer Region haben, können diese automatisch einen Cloud VPN-Tunnel in einer anderen Region erreichen, ohne statische Routen beizubehalten.

Das folgende Beispiel zeigt ein VPC-Netzwerk mit globalem dynamischen Routing. Der Cloud Router in us-west1 bietet Subnetze in zwei verschiedenen Regionen an: us-west1 und us-central1. VM-Instanzen in beiden Regionen erkennen dynamisch lokale Hosts.

Cloud Router – globales dynamisches Routing (zum Vergrößern klicken)
Cloud Router – globales dynamisches Routing (zum Vergrößern klicken)

Für redundante Topologien stellt das dynamische Routing (BGP) dem VPC und den lokalen Netzwerken genügend Informationen bereit, sodass bei einem Ausfall eines Pfads der Datenverkehr umgeleitet wird. Wenn eine Verbindung in einer Region ein Problem hat, kann der Datenverkehr in einem Failover in eine andere Region übertragen werden.

Das folgende Beispiel zeigt zwei Cloud VPN-Tunnel in zwei unterschiedlichen Regionen. Die VM-Instanzen (10.128.0.0/20) verwenden den tunnel-us-west1 in der Region us-west1, um beide Subnetze im lokalen Netzwerk zu erreichen. In ähnlicher Weise verwenden die VM-Instanzen (10.138.0.0/20) in us-central1 den tunnel-us-central1.

Cloud Router – globales dynamisches Routing (zum Vergrößern klicken)
Cloud Router – globales dynamisches Routing (zum Vergrößern klicken)

Die Routen sind so konfiguriert, dass VM-Instanzen ihre lokalen Tunnel (die Tunnel in ihrer Region) bevorzugen. Cloud Router legt verschiedene Gewichtungen für lokale und entfernte Routen mit gleichem Ziel fest. Wenn ein Tunnel fehlerhaft ist, kann Cloud Router den Datenverkehr entsprechend umleiten.

Im folgenden Beispiel fällt tunnel-us-west1 aus. Der Verkehr zu und von den VM-Instanzen (10.128.0.0/20) wird durch tunnel-us-central1 umgeleitet, statt gelöscht zu werden.

Cloud Router – globales dynamisches Routing (zum Vergrößern klicken)
Cloud Router – globales dynamisches Routing (zum Vergrößern klicken)

Routen-Advertising

Cloud Router bietet über BGP die IP-Adressen an, die die Clients in Ihrem lokalen Netzwerk erreichen können. Ihr lokales Netzwerk sendet Pakete an Ihr VPC-Netzwerk mit einer Ziel-IP-Adresse, die einem angegebenen IP-Bereich entspricht. Nach dem Erreichen von GCP bestimmen die Firewallregeln und -routen Ihres VPC-Netzwerks, wie GCP die Pakete verarbeitet.

Sie können das Standard-Advertising von Cloud Router verwenden oder explizit angeben, welche CIDR-Bereiche angeboten werden sollen. Wenn Sie kein Advertising angeben, verwendet der Cloud Router den Standardwert.

Standard

Standardmäßig bietet Cloud Router Subnetze in seiner Region für regionales dynamisches Routing oder alle Subnetze in einem VPC-Netzwerk für globales dynamisches Routing an. Neue Subnetze werden automatisch vom Cloud Router angeboten. Wenn ein Subnetz über einen sekundären IP-Bereich zum Konfigurieren von Alias-IP-Adressen verfügt, werden von Cloud Router sowohl die primären als auch die sekundären IP-Adressen angeboten.

Jede BGP-Sitzung für einen Cloud Router verfügt außerdem über ein Standard-Advertising. Standardmäßig leitet Cloud Router sein Routen-Advertising an alle BGP-Sitzungen weiter. Wenn Sie ein benutzerdefiniertes Routen-Advertising auf einem Cloud Router konfigurieren, übernehmen die BGP-Sitzungen dieses benutzerdefinierte Advertising.

Um IP-Adressen außerhalb des Bereichs eines Subnetzes, wie reservierte externe IP-Adressen, anzubieten, müssen Sie ein benutzerdefiniertes Advertising angeben. Wenn Sie ein benutzerdefiniertes Advertising verwenden, können Sie außerdem selektiv Subnetze oder Teile eines Subnetzes anbieten. Auf diese Weise können Sie verhindern, dass bestimmte Subnetze angeboten werden. Wenn Sie diese Funktionen nicht benötigen, verwenden Sie das Standard-Advertising.

Benutzerdefiniert

Wenn Sie benutzerdefiniertes Routen-Advertising konfigurieren, geben Sie explizit die Routen an, die ein Cloud Router anbietet. In den meisten Fällen ist benutzerdefiniertes Advertising nützlich, um das Standard-Subnetz-Advertising durch benutzerdefinierte IP-Adressen zu ergänzen. Benutzerdefinierte IP-Adressen sind Adressen außerhalb des IP-Bereichs eines Subnetzes, z. B. reservierte externe IP-Adressen. Ohne benutzerdefiniertes Routen-Advertising müssten Sie statische Routen für benutzerdefinierte IP-Adressen erstellen und verwalten.

Wenn Sie benutzerdefiniertes Routen-Advertising konfigurieren, können Sie alle Subnetze anbieten, was dem Standardverhalten entspricht. Sie können festlegen, dass nicht alle Subnetze angeboten werden. Stattdessen werden nur bestimmte Subnetze oder bestimmte CIDR-Blöcke innerhalb eines Subnetzes angeboten. Beispielsweise möchten Sie möglicherweise verhindern, dass Cloud Router bestimmte Subnetze anbietet. Zu diesem Zweck bieten Sie nur diejenigen an, die Sie veröffentlichen möchten. Wenn Sie jedoch selektiv Subnetze anbieten, müssen neue Subnetze manuell dem benutzerdefinierten Routen-Advertising hinzugefügt werden. Cloud Router bietet neue Subnetze nicht automatisch an.

Sie können benutzerdefiniertes Routen-Advertising auf einem Cloud Router oder in einer BGP-Sitzung angeben. Benutzerdefiniertes Routen-Advertising auf dem Cloud Router gilt für alle BGP-Sitzungen. Wenn Sie jedoch ein benutzerdefiniertes Routen-Advertising in einer BGP-Sitzung angeben, wird das Advertising des Cloud Routers ignoriert und mit dem Advertising der Sitzung überschrieben.

Für jeden Cloud Router können Sie maximal 200 CIDR-Bereiche angeben. Außerdem hat jede BGP-Sitzung ebenfalls das Limit 200.

Beispiele

Die folgenden Beispiele zeigen das Standardverhalten des Cloud Routers und Szenarien, in denen benutzerdefiniertes Routen-Advertising nützlich sein kann. In den Beispielen wird eine vorhandene Verbindung zwischen dem VPC und lokalen Netzwerken wie ein IPsec-VPN-Tunnel oder Dedicated Interconnect vorausgesetzt.

Standardmäßiges Routen-Advertising

Beim regionalen dynamischen Routing bietet Cloud Router Subnetze in seiner Region an. Im folgenden Beispiel bietet Cloud Router Subnetze in der Region us-central1 an. Außerdem wird der sekundäre IP-Bereich des alias-subnet angeboten. Wenn Sie neue Subnetze in us-central1 erstellen, bietet der Cloud Router diese automatisch an. Cloud Router bietet keine IP-Adressen an, die nicht im IP-Bereich eines Subnetzes enthalten sind, z. B. externe IP-Adressen.

Cloud Router Standard-Routen-Advertising (zum Vergrößern klicken)
Cloud Router Standard-Routen-Advertising (zum Vergrößern klicken)

Sie können eine externe statische IP-Adresse für eine GCP-Anwendung verwenden, die Clients in Ihrem lokalen Netzwerk bedient. Wenn Sie Wartungsarbeiten an der Anwendung durchführen, können Sie die statische IP-Adresse einer anderen VM-Instanz neu zuordnen, um Ausfallzeiten zu minimieren. Wenn Sie das Standard-Advertising von Cloud Router verwenden, müssen Sie eine statische Route konfigurieren und verwalten. Stattdessen können Sie benutzerdefiniertes Advertising verwenden, um die externe IP-Adresse über BGP anzubieten.

Im folgenden Beispiel bietet der Cloud Router die externe IP-Adresse des Proxyservers 1.2.3.4 an. Die externe IP-Adresse wird der internen IP-Adresse 10.20.0.2 des Servers zugeordnet. Cloud Router bietet die interne IP-Adresse des Proxyservers oder VM-Instanzen nicht im Subnetz my-subnet an. Lokale Clients kennen nur die externe IP-Adresse des Proxy-Servers.

Externes IP-Adressen-Advertising (zum Vergrößern klicken)
Externes IP-Adressen-Advertising (zum Vergrößern klicken)

Weitere Informationen finden Sie unter Benutzerdefinierte IP-Bereiche anbieten.

Subnetz-Advertising einschränken

Sie können verhindern, dass Instanzen angeboten werden, sodass sie verborgen bleiben. Im folgenden Beispiel bietet Cloud Router subnet-1 und subnet-2 an. Clients im Netzwerk können VM-Instanzen in diesen Subnetzen erreichen, jedoch keine Instanzen im Subnetz unadvertised-subnet.

Bestimmte Subnetze auf dem Cloud Router anbieten (zum Vergrößern klicken)
Bestimmte Subnetze auf dem Cloud Router anbieten (zum Vergrößern klicken)

Weitere Informationen finden Sie unter Bestimmte VPC-Subnetze anbieten.

Routen-Advertising gemäß BGP-Sitzung

Angenommen, Sie verfügen über Produktions- und Testressourcen in Ihrem VPC und in Ihren lokalen Netzwerken und haben diese Ressourcen in verschiedenen Subnetzen organisiert. Dementsprechend richten Sie zwei BGP-Sitzungen ein, die unterschiedliche IP-Adressbereiche anbieten. Indem zwei verschiedene BGP-Sitzungen verwendet werden, wird der Datenverkehr für ein Subnetz nicht versehentlich in ein anderes Subnetz geleitet. Das folgende Beispiel zeigt zwei BGP-Sitzungen: prod-bgp, die nur das prod-subnet anbietet, und test-bgp, die nur das test-subnet anbietet.

Bestimmte Subnetze in einer BGP-Sitzung anbieten (zum Vergrößern klicken)
Bestimmte Subnetze in einer BGP-Sitzung anbieten (zum Vergrößern klicken)

Weitere Informationen finden Sie unter Benutzerdefinierte IP-Bereiche bewerben und Bestimmte VPC-Subnetze bewerben.

Bester Pfad für ausgehenden Traffic von GCP zu Ihrem lokalen Netzwerk

Wenn Cloud Router mehrere Routen für dasselbe Ziel erhält, verwendet GCP Routenmesswerte und in einigen Fällen die AS-Pfadlänge, um den besten Pfad zu bestimmen. In der folgenden Liste wird der Algorithmus beschrieben, der für den ausgehenden Traffic mit einem oder mehreren Cloud Routern verwendet wird, um die dynamischen Routen für ein VPC-Netzwerk zu verwalten.

  1. Bei mehreren BGP-Sitzungen an einem einzelnen Cloud Router wird der ausgehende Traffic durch die erste erfüllte Bedingung bestimmt:
    1. Der gesamte ausgehende Traffic wird an die Route mit der kürzesten AS-Pfadlänge gesendet.
    2. Wenn Routen dieselbe AS-Pfadlänge haben, wird der gesamte ausgehende Traffic an die Route mit dem niedrigsten MED-Wert (Multi-Exit Discriminator), also dem niedrigsten Routenmesswert, gesendet.
    3. Wenn Routen dieselbe AS-Pfadlänge und dieselben MED-Werte (dieselben Routenmesswerte) haben, wird der ausgehende Traffic für alle Routen durch Equal Cost Multi Path (ECMP) ausgeglichen.
  2. Bei mehreren Cloud Routern in der gleichen Region verwendet die GCP Routenmesswerte nur, um den besten Pfad zu bestimmen. Die AS-Pfadlänge wird nicht verwendet. Der ausgehende Traffic wird ermittelt, indem die erste Bedingung erfüllt ist:
    1. Jeglicher ausgehende Traffic wird an die Route mit dem niedrigsten MED-Wert, also dem niedrigsten Routenmesswert, gesendet.
    2. Wenn Routen dieselben MED-Werte (dieselben Routenmesswerte) haben, wird der ausgehende Traffic auf allen Routen durch ECMP ausgeglichen.
  3. Statische Routen haben im Konfliktfall Vorrang vor den dynamischen Routen von Cloud Router. Eine statische Route mit demselben Präfix und Routenmesswert einer dynamischen Route hat immer Priorität. In Konflikt stehende dynamische Routen werden also ignoriert.

Überlappende IP-Bereiche zwischen einem VPC-Subnetz und einem lokalen Routen-Advertising

In Fällen, in denen Sie ein VPC-Subnetz und ein lokales Routen-Advertising mit sich überlappenden IP-Bereichen haben, leitet GCP den ausgehenden Verkehr abhängig von deren IP-Bereichen.

Wenn der IP-Bereich des Subnetzes breiter oder gleich dem lokalen Routen-Advertising ist, ignoriert GCP das lokale Advertising. Der gesamte ausgehende GCP-Verkehr, der für den IP-Bereich des Subnetzes bestimmt ist, wird an das VPC-Subnetz geleitet. Wenn Sie z. B. ein Subnetz mit einem IP-Bereich von 10.2.0.0/16 und einen lokalen Router haben, der 10.2.1.0/24 anbietet, ignoriert GCP das lokale Advertising und leitet den Traffic aus 10.2.0.0/16 an das VPC-Subnetz weiter.

Ist der IP-Bereich des Subnetzes schmaler als das lokale Routen-Advertising, wird der ausgehende GCP-Verkehr an das VPC-Subnetz geleitet, wenn sich die Ziel-IP im IP-Bereich des Subnetzes befindet. Der gesamte andere ausgehende Verkehr, der mit dem lokalen Advertising übereinstimmt, wird an das lokale Netzwerk weitergeleitet. Wenn Sie z. B. ein Subnetz mit einem IP-Bereich von 10.2.0.0/16 und einen lokalen Router haben, der 10.0.0.0/8 anbietet, leitet GCP den für 10.0.0.0/8 bestimmten Verkehr an das lokale Netzwerk weiter, es sei denn, das Ziel entspricht 10.2.0.0/16, woraufhin GCP den Verkehr zum Subnetz leitet.

Routenmesswerte

Wenn Cloud Router Routen bewirbt oder weiterleitet, verwendet er Routenmesswerte, um die Routenprioritäten anzugeben. Wenn Sie mehrere Pfade zwischen dem VPC-Netzwerk und dem lokalen Netzwerk haben, wird durch die Routenmesswerte ein bevorzugter Pfad bestimmt. Dieser Wert entspricht dem MED-Wert (Multi-Exit Discriminator). Ein niedrigerer Routenmesswert (MED) zeigt eine höhere Priorität an.

Ein Routenmesswert setzt sich aus der Basispriorität der beworbenen Route und den regionalen Kosten zusammen. Die Basispriorität der beworbenen Route ist ein benutzerdefinierter Wert, während die regionalen Kosten einen von Google generierten Wert darstellen, den Sie nicht ändern können. Die regionalen Kosten stellen die Kosten der Kommunikation zwischen zwei Regionen in einem VPC-Netzwerk dar. Cloud Router addiert diese beiden Werte, um einen Routenmesswert zu erhalten.

Beim regionalen dynamischen Routing werden die regionalen Kosten nicht zu den Routenmesswerten hinzugefügt, weil Cloud Router nur Routen in der eigenen Region behandelt. Cloud Router verwendet nur die Basispriorität der beworbenen Route.

Beim globalen dynamischen Routing bieten alle Cloud Router die gleichen Routen an und leiten sie weiter. Jeder Cloud Router verwendet jedoch aufgrund regionaler Kosten möglicherweise unterschiedliche Routenmesswerte.

Basispriorität der beworbenen Route

Cloud Router beginnt die Berechnung von Routenmesswerten mit dem Basiswert der beworbenen Route und fügt dann die entsprechenden regionalen Kosten hinzu. Dieser Basiswert ist der minimale Routenmesswert für beworbene Routen. Wenn Sie eine BGP-Sitzung auf einem Cloud Router konfigurieren, können Sie eine Basispriorität der angebotenen Route angeben, die für alle Routen für diese Sitzung gilt. Standardmäßig ist die Basispriorität auf den Wert 100 festgelegt.

Mit der Basispriorität der beworbenen Route können Sie Prioritäten für Routen festlegen. Angenommen, Sie haben einen VPN-Tunnel und eine dedizierte Interconnect-Verbindung, die Ihre VPC- und lokalen Netzwerke verbinden. Sie können die Basispriorität der beworbenen Route so festlegen, dass der Datenverkehr die dedizierte Interconnect-Verbindung bevorzugt. Wenn die Interconnect-Verbindung nicht verfügbar ist, durchquert der Datenverkehr den Tunnel. Weitere Informationen finden Sie in den Beispieltopologien.

Regionale Kosten

Wenn ein Cloud Router Routen aus anderen als seiner eigenen Region (d. h. aus entfernten GCP-Regionen) anbietet oder Routen an entfernte Regionen weiterleitet, erhöht das die regionalen Kosten.

Die regionalen Kosten können von 201 bis (einschließlich) 9.999 reichen. Der Wert hängt von der Entfernung, der Latenz und anderen Faktoren zwischen zwei Regionen ab. Google generiert den Wert der regionalen Kosten – Sie können ihn nicht ändern. Weitere Informationen zu regionalen Kosten finden Sie unter Beispieltopologien.

Regionale Kosten helfen bei der Priorisierung von Pfaden basierend auf der regionalen Nähe. Stellen Sie sich beispielsweise vor, dass Sie zwei Verbindungen zwischen Ihrem VPC und dem lokalen Netzwerk haben, z. B. zwei VPN-Tunnel mit eigenen Cloud Routern. Eine Verbindung befindet sich in us-central1 und eine andere in europe-west1. Durch das Hinzufügen regionaler Kosten zu den Routenmesswerten wird beim Datenverkehr zwischen Netzwerken in us-central1 der us-central1-Tunnel priorisiert. In ähnlicher Weise wird beim Datenverkehr zwischen den Netzwerken in europe-west1 der europe-west1-Tunnel priorisiert. Ohne regionale Kosten wird der Traffic gleichmäßig über beide Verbindungen geleitet, was zu einer inkonsistenten Netzwerkleistung führt.

Bei erkannten Routen fügt Cloud Router regionale Kosten hinzu, wenn er die erkannten Routen an entfernte GCP-Regionen weiterleitet. Dadurch wird die Symmetrie zwischen dem eingehenden und dem ausgehenden Datenverkehr zwischen VPC- und lokalen Netzwerken gewahrt. Cloud Router fügt dem MED-Wert, der von Ihrem lokalen Router beworben wird, regionale Kosten hinzu.

Vorgeschlagene Basisprioritätswerte

Verwenden Sie Werte kleiner als 201, um Prioritäten zwischen Routen in einer einzelnen Region anzupassen. Dadurch wird gewährleistet, dass die regionalen Kosten keine Auswirkung auf die globalen Routenprioritäten haben. Eine Route aus einer anderen Region (einer entfernten Region) darf keine Priorität unter 201 haben. Wenn Sie höhere Werte verwenden, können sich die regionalen Kosten auf Ihre Routenprioritäten auswirken. Angenommen, Sie haben eine primäre Verbindung und eine Ersatzverbindung. Wenn Sie die Basispriorität der Ersatzverbindung zu hoch festlegen, könnten Sie unbeabsichtigt Routen aus anderen Regionen anstelle der Ersatzverbindung bevorzugen.

Verwenden Sie Werte größer als 10.200, um die Priorisierung einer Route in einem VPC-Netzwerk global aufzuheben. Dadurch wird sichergestellt, dass alle anderen Routen unter 201 unabhängig von den regionalen Kosten Priorität haben.

In Fällen, in denen alle Routen in einer Region gleichermaßen bevorzugt werden, können Sie den Standardwert 100 verwenden.

Beispieltopologien

In den folgenden Beispielen wird erläutert, wie sich regionale Kosten auf Routenmesswerte auswirken, wenn Sie das globale dynamische Routing verwenden.

Angenommen, Sie haben ein VPC-Netzwerk mit zwei VPN-Tunneln mit eigenen Cloud Routern. Ein Tunnel befindet sich in us-central1 und der andere in us-west1. Standardmäßig werden bei dem in diesen Regionen eingehenden Datenverkehr die entsprechenden Tunnel in ihren jeweiligen Regionen verwendet. Was passiert aber, wenn Sie VM-Instanzen erreichen möchten, die sich nicht in diesen Regionen befinden, z. B. Instanzen in europe-west1? Das folgende Diagramm zeigt, wie sich die regionalen Kosten auf die Routenmesswerte auswirken.

Cloud Router – Routenmesswerte für beworbene Routen (zum Vergrößern klicken)
Cloud Router – Routenmesswerte für beworbene Routen (zum Vergrößern klicken)

Beide Cloud Router bewerben Routen nach europe-west1, doch mit unterschiedlichen Routenmesswerten. Der Cloud Router in us-central1 bietet Routen nach europe-west1 aufgrund von Entfernung, Latenz und anderen Faktoren mit einem anderen Routenmesswert als Routen nach us-west1 an. Im Beispiel wird davon ausgegangen, dass die regionalen Kosten der Route nach europe-west1 über us-central1 den Wert 300 und über us-west1 den Wert 350 haben. Beim eingehenden Datenverkehr wird der us-central1-Tunnel verwendet, der einen niedrigeren Routenmesswert hat. Er hat einen Routenmesswert von 350 im Vergleich zu 400 für den us-west1-Tunnel.

In ähnlicher Weise fügt Cloud Router dem MED-Wert der erkannten Routen (die von Ihrem lokalen Router angegeben werden) regionale Kosten hinzu. Standardmäßig wird beim ausgehenden Datenverkehr aus der europa-west1-Region ebenfalls der us-central1-Tunnel verwendet, da er einen niedrigeren Routenmesswert hat. So wird die Symmetrie zwischen dem eingehenden und dem ausgehenden Datenverkehr gewahrt.

Cloud Router – Routenmesswerte für erkannte Routen (zum Vergrößern klicken)
Cloud Router – Routenmesswerte für erkannte Routen (zum Vergrößern klicken)

Routenprioritäten innerhalb einer Region

Angenommen, Sie erstellen aus Gründen der Redundanz in us-west1 einen Sicherungstunnel. Sie geben eine höhere Basispriorität für den Sicherungstunnel an, damit der in us-west1 eingehende Datenverkehr den primären Tunnel bevorzugt, wie im folgenden Beispiel gezeigt:

Basisprioritäten für Routen innerhalb einer Region (zum Vergrößern klicken)
Basisprioritäten für Routen innerhalb einer Region (zum Vergrößern klicken)

Wenn der primäre Tunnel ausfällt, bevorzugt der in us-west1 eingehende Datenverkehr den Sicherungstunnel mit einem Routenmesswert von 51 gegenüber dem us-central1-Tunnel, dessen Routenmesswert 400 ist:

Basisprioritäten für Routen innerhalb einer Region (zum Vergrößern klicken)
Basisprioritäten für Routen innerhalb einer Region (zum Vergrößern klicken)

Verwenden Sie in ähnlicher Weise für den ausgehenden Datenverkehr vom VPC-Netzwerk zu Ihrem lokalen Netzwerk MED-Werte unter 201, um einen Pfad gegenüber einem anderen zu priorisieren. Andernfalls ist der ausgehende Datenverkehr vom VPC-Netzwerk zu Ihrem lokalen Netzwerk möglicherweise nicht mit dem eingehenden Datenverkehr symmetrisch.

In Fällen, in denen alle Tunnel oder Interconnect-Verbindungen in einer Region die gleiche Priorität haben, können Sie die standardmäßige Basisroutenpriorität 100 verwenden.

Global bevorzugte Route

Angenommen, Sie haben eine dedizierte Interconnect-Verbindung und einen VPN-Tunnel in verschiedenen Regionen. Sie möchten die dedizierte Interconnect-Verbindung priorisieren, weil sie für Ihre Arbeitslasten kostengünstiger ist als der VPN-Tunnel. Geben Sie eine Basispriorität von 10.051 für die VPN-Tunnelrouten an, um deren Priorisierung aufzuheben. Infolgedessen verwendet der gesamte eingehende Datenverkehr die dedizierte Interconnect-Verbindung, unabhängig von den regionalen Kosten. Routenmesswerte für die dedizierte Interconnect-Verbindung überschreiten 10.051 nicht. Der VPN-Tunnel wird vom Datenverkehr nur dann verwendet, wenn die Interconnect-Verbindung fehlschlägt.

Basisprioritäten für globale Routen (zum Vergrößern klicken)
Basisprioritäten für globale Routen (zum Vergrößern klicken)

Sie müssen außerdem die gleichen Anpassungen an Ihrem lokalen Router vornehmen, damit der ausgehende Datenverkehr vom VPC-Netzwerk zum lokalen Netzwerk immer die dedizierte Interconnect-Verbindung verwendet.

Weitere Informationen zum Festlegen einer Basispriorität finden Sie unter BGP-Sitzungen erstellen oder Basispriorität der beworbenen Route aktualisieren.

Standardroute

Wenn für ein bestimmtes IP-Ziel keine Route angegeben ist, wird der Traffic an eine Standardroute gesendet, die als letzte Möglichkeit dient, wenn keine anderen Optionen vorhanden sind. GCP-VPC-Netzwerke haben beispielsweise automatisch eine Standardroute (0.0.0.0/0), über die Traffic an das Internetgateway gesendet wird.

Sie können Traffic auch standardmäßig an Ihr lokales Netzwerk weiterleiten. Dafür bieten Sie eine Standardroute von Ihrem lokalen Router zu Cloud Router an. Mit Cloud Router müssen Sie keine statischen Routen erstellen und verwalten. Wenn Sie eine Standardroute von Ihrem lokalen Netzwerk anbieten, achten Sie darauf, dass diese Vorrang vor anderen automatisch erstellten Standardrouten hat. Dies ist am niedrigeren MED-Wert (Multi-Exit Discriminator) erkennbar. Auf der Seite "Routen" können Sie sich die Priorität von Routen mit dem Wert 0.0.0.0/0 als Ziel-IP-Bereich und Default internet gateway als Nächsten Hop ansehen.

Ordnungsgemäßer Neustart

Bei Cloud Router ist der ordnungsgemäße Neustart aktiviert. Damit kann das lokale BGP-Gerät offline geschaltet und dann innerhalb des Zeitraums für den ordnungsgemäßen Neustart wiederhergestellt werden, ohne dass der Traffic unterbrochen wird. Diese Funktion schützt vor Unterbrechungen, wenn BGP-Agents ein Software-Upgrade oder eine andere Art von Wartung benötigen oder vorübergehend ausfallen.

Aktivieren Sie den ordnungsgemäßen Neustart auf Ihrem BGP-Gerät, sofern diese Funktion unterstützt wird.

Cloud VPN-Tunnel mit ordnungsgemäßem Neustart

Wenn Cloud Router im folgenden Beispiel eine Wartungsaktualisierung benötigt, kann er aktualisiert werden, ohne den Datenverkehr zu unterbrechen, solange er innerhalb des Zeitraums für den ordnungsgemäßen Neustart wieder online ist.

Ordnungsgemäßer Neustart und Cloud Router (zum Vergrößern klicken)
Ordnungsgemäßer Neustart und Cloud Router (zum Vergrößern klicken)

BGP-Timereinstellungen

Cloud Router und Ihr lokaler Router steuern die Kommunikation mit den folgenden Timereinstellungen:

Keepalive-Timer: Dieser Timer legt das Intervall zwischen den periodischen BGP-Herzschlägen fest, die zwischen Cloud Router und dem entsprechenden lokalen Peer-Router ausgetauscht werden. In Verbindung mit dem Hold-Timer gibt der Keepalive-Timer die Verfügbarkeit aller Router füreinander an. Google empfiehlt, den Keepalive-Timer auf dem lokalen Router auf 20 Sekunden einzustellen.

Hold-Timer: Dieser Timer gibt die Mindestzeit seit dem letzten erfolgreichen Keepalive-Herzschlag an. Diese Mindestzeit legt fest, wie lange Cloud Router oder der lokaler Router warten muss, bevor er die vom anderen Router ermittelten Routen entfernt. Google empfiehlt, den Hold-Timer auf dem lokalen Router auf 60 Sekunden festzulegen.

Timer für ordnungsgemäßen Neustart: Damit wird der Zeitraum festgelegt, die der lokale Router ohne periodische Keepalive-Herzschläge wartet, bis er neue Keepalive-Herzschläge erwartet, nachdem er eine Benachrichtigung über den Neustart des entsprechenden Cloud Routers erhalten hat. Wenn keine neuen Keepalive-Herzschläge empfangen werden, entfernt der lokale Router die vom Cloud Router ermittelten Routen. Google empfiehlt, diesen Timer auf 60 Sekunden einzustellen.

Timer für veraltete Pfade: Dieser Timer legt fest, wie lange ein Router wartet, bevor er ermittelte Routen löscht, nachdem er eine EOR-Nachricht vom anderen Router empfangen hat. Er wird gestartet, wenn die BGP-Sitzung nach einem ordnungsgemäßen Neustart wieder initialisiert wird, das betreffende Präfix jedoch nicht durch eine UPDATE-Nachricht adressiert wurde. Google empfiehlt, diesen Timer entsprechend der Einstellung für Cloud Router auf 300 Sekunden festzulegen.

Redundante Cloud VPN-Tunnel

Wenn das lokale Gateway keinen ordnungsgemäßen Neustart unterstützt, führt ein Fehler auf einer der beiden Seiten der BGP-Sitzung zum Abbruch der Sitzung und zu einer Unterbrechung des Traffics. Bei Überschreiten des BGP-Zeitlimits, das bei Cloud Router 60 Sekunden beträgt, werden die Routen auf beiden Seiten abgebaut. Dynamisch weitergeleiteter VPN-Traffic gelangt daraufhin nicht mehr in den Tunnel. Statische Routen für den Tunnel werden weiterhin bedient.

Wenn ein ordnungsgemäßer Neustart nicht unterstützt wird, bietet die Bereitstellung von zwei lokalen Gateways mit je einem Tunnel Redundanz und Failover. Mit dieser Konfiguration können ein Tunnel und seine Geräte für Software-Upgrades oder Wartungen offline geschaltet werden, ohne den Traffic zu unterbrechen. Wenn ein Tunnel ausfällt, kann der andere Tunnel die Aktivität der Routen beibehalten und den Datenverkehr weiterleiten.

Das folgende Beispiel zeigt ein einzelnes Feld als den Cloud Router, aber mit zwei IP-Adressen. Diese beiden Adressen sind separate Ethernet-Schnittstellen innerhalb derselben Cloud Router-Aufgabe. Jede Schnittstelle wird für eine separate BGP-Sitzung mit einem separaten lokalen Gateway verwendet. Da diese VPN-Tunnel zu Redundanzzwecken eingerichtet wurden, tauschen in diesem speziellen Anwendungsfall beide BGP-Sitzungen exakt denselben Satz von Routenpräfixen aus, jedoch mit unterschiedlichen nächsten Hops, die auf unterschiedliche VPN-Tunnel verweisen.

Redundanz ohne ordnungsgemäßen Neustart (zum Vergrößern klicken)
Redundanz ohne ordnungsgemäßen Neustart (zum Vergrößern klicken)

Upgrade-Zyklen

Cloud Router wird regelmäßig aktualisiert, was weniger als 60 Sekunden dauert. Cloud Router ist während des Upgrades nicht verfügbar. Der BGP-Haltezeitgeber legt fest, wie lange erkannte Routen erhalten bleiben sollen, wenn der Peering-BGP-Router nicht verfügbar ist. Der BGP-Haltezeitgeber wird auf den kleineren Wert der beiden Seiten eingestellt. Cloud Router verwendet einen Wert von 60 Sekunden für den BGP-Haltezeitgeber. Wir empfehlen, dass Sie den Peer-BGP-Haltezeitgeber auf mindestens 60 Sekunden festlegen (der Standardwert ist 3 Minuten). Dadurch erhalten beide Router ihre Routen während dieser Upgrades aufrecht und der Traffic fließt weiter.

Während der VPN-Gateway-Wartungszyklen bei einem einzelnen VPN-Gateway wird durch die Verwendung von Cloud Router die Dauer der Tunnelwiederherstellung um ca. 20 Sekunden verlängert, da die BGP-Sitzung zurückgesetzt wird und die Routen neu erkannt werden müssen. Die Wiederherstellung eines VPN-Gateways dauert in der Regel ca. eine Minute. Wenn redundante VPN-Gateways vorhanden sind, ist der Traffic nicht beeinträchtigt, da immer nur ein VPN-Gateway heruntergefahren wird.

Weitere Informationen

Weitere Informationen zur Verwendung von statischem und dynamischem Routing mit einem unterstützten Dienst finden Sie in der folgenden Dokumentation:

Produkt Routing Dokumentation
Dedizierte Interconnect-Verbindung Statisch Nicht unterstützt
Dedizierte Interconnect-Verbindung Dynamisch VLAN-Anhänge erstellen
Cloud VPN Richtlinienbasiert VPN-Tunnel mit richtlinienbasierten Routen erstellen
Cloud VPN Statisch VPN-Tunnel mit statischen Routen erstellen
Cloud VPN Dynamisch VPN-Tunnel mit dynamischen Routen erstellen
Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...