Probleme mit dem Network Connectivity Center beheben

Nützliche Tipps zur Behebung etwaiger Fehler bei der Verwendung von Network Connectivity Center, Hybrid-Spokes, VPC-Spokes, NCC Gateway-Spokes oder der Weitergabe von Private Service Connect-Verbindungen.

Bekannte Einschränkungen finden Sie auf der Übersichtsseite unter Überlegungen zum Network Connectivity Center.

Häufige Probleme mit der Befehlssyntax

Beim Aktualisieren eines Spoke müssen Sie den Standort angeben, an dem sich der Spoke befindet.

Ressourcen an Spokes anhängen

Ausführliche Informationen, Empfehlungen und Überlegungen zum Erstellen von Spokes und zum Anhängen von Ressourcen an Spokes finden Sie unter Mit Spokes arbeiten.

Routen werden nicht auf Regionen verteilt

Wenn Routen nicht ordnungsgemäß zwischen Regionen verteilt werden, prüfen Sie, ob der Modus für dynamisches Routing des VPC-Netzwerks auf global festgelegt ist.

Der Datenübertragungs-Traffic fließt nicht zwischen zwei Nicht-Google Cloud -Netzwerken

In diesem Zusammenhang bezieht sich ein Nicht-Google Cloud -Netzwerk auf Ihr lokales Rechenzentrum, eine Zweigstelle oder das Netzwerk eines anderen Cloud-Anbieters.

Wenn der Datentransfer zwischen zwei Standorten nicht fließt, prüfen Sie, ob die folgenden Ressourcen ordnungsgemäß konfiguriert sind und funktionieren:

Doppelte Route Advertisements aus BGP-Sitzungen

Wenn es doppelte Route Advertisements gibt – einige aus BGP-Sitzungen, die am Datentransfer teilnehmen, und einige aus Sitzungen, die nicht am Datentransfer teilnehmen –, verwendet der Datentransfer-Traffic möglicherweise ECMP, um den Traffic auf alle verfügbaren nächsten Hops zu verteilen, auch wenn diese nächsten Hops nicht explizit am Datentransfer teilnehmen.

Interconnect-Verbindung zu einem nicht unterstützten Standort (keinGoogle Cloud -Netzwerk)

Ein Beispiel für die Konfiguration von Routen-Advertisements, wenn eine Ihrer redundanten Interconnect-Verbindungen zu einem nicht unterstützten Standort führt, finden Sie unter Externen Router konfigurieren, um nicht unterstützte Standorte zu vermeiden.

Fehlerbehebung bei der Netzwerkverbindung mithilfe von Konnektivitätstests

Mit diesem Diagnosetool können Sie die Konnektivität zwischen den Endpunkten in Ihrem Netzwerk prüfen. Es analysiert Ihre Konfiguration und führt in einigen Fällen auch eine Laufzeitprüfung aus.

Zur Analyse der Netzwerkkonfigurationen simulieren Konnektivitätstests den erwarteten Weiterleitungspfad eines Pakets über Ihr VPC-Netzwerk (Virtual Private Cloud), Cloud VPN-Tunnel, VLAN-Anhänge oder

Sie können die Konfigurationsanalyse für Konnektivitätstests verwenden, um die Erreichbarkeit für die folgenden Netzwerke zu bewerten:

Da Konnektivitätstests keinen Zugriff auf Ihre lokale Netzwerkkonfiguration haben, kann die Konfiguration der Routen und Firewallregeln auf Ihrem lokalen Router nicht geprüft werden. Daher betrachtet die Konfigurationsanalyse der Konnektivitätstests den Traffic von Ihrem lokalen Netzwerk zu Ihrem VPC-Netzwerk immer als gültig und es werden nur Konfigurationen in Google Cloud verifiziert.

Informationen zum Ausführen von Konnektivitätstests zwischen zwei lokalen Netzwerken, die über Network Connectivity Center verbunden sind, finden Sie unter Von einem Nicht-Google Cloud -Netzwerk zu einem Nicht-Google Cloud -Netzwerk testen.

Weitere Informationen finden Sie unter Konnektivitätstests – Übersicht.

Fehlerbehebung bei Hybrid-Spokes

Das folgende Problem kann in Router-Appliance-, VLAN-Anhang- und VPN-Spokes auftreten.

Konfigurierte Hub-Subnetze werden nicht für ein lokales Netzwerk beworben

Wenn die konfigurierten Hub-Subnetze nicht für das lokale Netzwerk beworben werden, prüfen Sie die Hub-Routingtabelle der Gruppe des Hybrid-Spoke auf die folgenden Probleme:

  • Wenn die Subnetze in der Hub-Routingtabelle angezeigt werden, gehen Sie so vor:

  • Wenn die Subnetze nicht in der Hub-Routingtabelle enthalten sind, gehen Sie so vor:

    • Prüfen Sie die IP-Adressbereiche für Ein- und Ausfuhr im VPC-Spoke der Subnetze. Wenn das Subnetz nach Ein- oder Ausschlussbereichen für den Export gefiltert wird, können Sie den VPC-Spoke aktualisieren.

Fehlerbehebung bei Router-Appliance

Die im Folgenden aufgeführten Probleme und Lösungen gelten nur für die Router-Appliance.

Die Dokumentation zur Fehlerbehebung für Cloud Router gilt auch für die Router-Appliance sowie die in den folgenden Abschnitten beschriebenen Probleme.

Hier finden Sie weitere Informationen:

Fehler beim Erstellen von BGP-Sitzungen

Wenn die BGP-Sitzungen zwischen dem Cloud Router und der Router-Appliance nicht hergestellt werden, prüfen Sie, ob folgende Probleme vorliegen:

  • Prüfen Sie, ob eine VM, die als Router-Appliance-Instanz fungiert, im Rahmen eines Spoke im Network Connectivity Center konfiguriert ist. Informationen zum Konfigurieren einer Router-Appliance-Instanz als Teil eines Spoke finden Sie unter Mit Spokes arbeiten.
  • Prüfen Sie die Firewalleinstellungen. Achten Sie dabei darauf, dass der TCP-Port 179 zugelassen wird. Informationen zum Konfigurieren von Firewalleinstellungen für die Router-Appliance finden Sie unter Router Appliance-Instanzen erstellen.
  • Achten Sie darauf, dass weder der Cloud Router noch die Router-Appliance-Instanz Link-Local-Adressen (d. h. 169.254.x.x) für das gegenseitige Peering verwenden. Weitere Informationen finden Sie unter IP-Adressen und Router-Appliance-Instanzen.
  • Vergewissern Sie sich, dass Cloud Router zwei separate BGP-Sitzungen zu Ihrer Router-Appliance-Instanz aufgebaut hat, eine von jeder Cloud Router-Schnittstelle. Die Router-Appliance-Instanz muss in beiden BGP-Sitzungen dieselben Routen bereitstellen. Wenn eine Ihrer BGP-Sitzungen ausfällt und Ihre Router-Appliance-VM die Verbindung zum Cloud Router verliert, überprüfen Sie die Konfiguration Ihrer Cloud Router-Schnittstellen. Weitere Informationen finden Sie unter Router-Appliance-Instanzen erstellen.

Probleme mit internen IP-Adressen für BGP-Sitzungen auf Router-Appliance-Instanzen

Wenn Sie Probleme mit Ihrer IP-Adresskonfiguration für Router-Appliance-Instanzen feststellen, müssen Sie interne RFC 1918-IP-Adressen für BGP-Sitzungen zwischen Cloud Router und den VMs konfigurieren, die als Router-Appliance-Instanzen fungieren.

Router-Appliance-Instanzen verwenden keine 169.254.x.x-Adressen für BGP-Sitzungen. Stattdessen müssen sie IP-Adressen im selben VPC-Subnetz wie Cloud Router verwenden. Weitere Informationen finden Sie unter Router-Appliance-Instanzen erstellen.

Fehlerbehebung bei VPC-Spokes

Berechtigungen

Wenn die Berechtigung beim Erstellen eines Spoke in einem anderen Projekt als dem Projekt des Hubs verweigert wird, fragen Sie den Hub-Administrator, ob Ihnen die erforderliche Berechtigung networkconnectivity.groups.use für den Hub erteilt wurde.

Fehler bei VPC-Spoke-Erstellung

Wenn die Erstellung des VPC-Spoke fehlgeschlagen ist, kann dies einen der folgenden Gründe haben:

  • Das VPC-Netzwerk ist bereits über VPC-Peering mit einem oder mehreren der vorhandenen Spokes verbunden.
  • Subnetze überschneiden sich mit vorhandenen VPC-Spokes.
  • Subnetze überschneiden sich mit Peers vorhandener VPC-Spokes.
  • Sie haben das Kontingent für VPC-Spokes überschritten.
  • Sie haben das Kontingent für Routen pro Hub-Routingtabelle überschritten.
  • Es sind mehr als 16 Exportfilter angegeben.
  • Subnetze im VPC-Netzwerk sind größer als ein oder mehrere angegebene Filter.

Informationen zu kontingentbezogenen Fehlern finden Sie unter Kontingente und Limits.

Fehler beim Erstellen von VPC-Spokes nach dem Löschen eines Spoke

Nachdem Sie einen Spoke gelöscht haben, müssen Sie mindestens zehn Minuten warten, bevor Sie einen neuen Spoke für dasselbe VPC-Netzwerk erstellen können, das mit einem anderen Hub verbunden ist. Diese Abkühlphase ist nicht erforderlich, wenn das VPC-Netzwerk als Spoke zum selben Hub hinzugefügt wird.

Fehler bei der Subnetzerstellung in einem VPC-Spoke

Wenn bei einem VPC-Spoke ein Fehler bei der Subnetzerstellung auftritt, kann dies einen der folgenden Gründe haben:

  • Es sind sich überschneidende Subnetze in anderen VPC-Spokes oder Peers von VPC-Spokes vorhanden.
  • Sie haben das Kontingent für Routen pro Hub-Routingtabelle überschritten.
  • Subnetze im VPC-Netzwerk sind größer als ein oder mehrere angegebene Filter.

Der VPC-Spoke wird erstellt, aber die Verbindung zur Datenebene fehlt

Wenn der VPC-Spoke als erstellt angezeigt wird, die Verbindung der Datenebene jedoch fehlt, kann dies einen der folgenden Gründe haben:

  • Der Spoke befindet sich in einem anderen Projekt als der Hub und der Hub-Administrator hat den Spoke-Vorschlag nicht angenommen.
  • Alle Subnetze im VPC-Netzwerk werden gefiltert und von der Verbindung ausgeschlossen.
  • Zielsubnetze werden nach den entsprechenden VPC-Spoke-Filtern gefiltert.

In der Hub-Routingtabelle werden einige Subnetze in VPC-Spokes nicht angezeigt

Wenn in der Hub-Routingtabelle einige der Subnetze in den VPC-Spokes nicht angezeigt werden, kann dies einen der folgenden Gründe haben:

  • Die Subnetze werden mit Exportfiltern gefiltert.
  • Die Subnetze wurden innerhalb der letzten 5–10 Minuten erstellt und die Hub-Routingtabelle wurde noch nicht aktualisiert.

Das VPC-Spoke-Update ist fehlgeschlagen

Achten Sie darauf, dass Ihre Spoke-Updates allen Kontingenten und Limits für Network Connectivity Center entsprechen. Andernfalls schlägt das Spoke-Update fehl.

Wenn sich ein VPC-Spoke oder ein Ersteller-VPC-Spoke in einem anderen Projekt als dem Projekt befindet, das den Hub enthält, und ein Hub-Administrator die automatische Annahme von Vorschlägen aus dem Spoke-Projekt nicht aktiviert hat, muss ein Hub-Administrator ein vorgeschlagenes Update annehmen oder ablehnen. Ausführliche Informationen zum Prüfen des Status des Vorschlags zur Aktualisierung des Spoke finden Sie unter Status eines VPC-Spoke prüfen.

Fehler bei der Weitergabe von Private Service Connect-Verbindungen beheben

Machen Sie sich vor der Untersuchung von Problemen mit den folgenden Seiten vertraut:

VM in einem Spoke kann nicht auf die Private Service Connect-Verbindung in einem anderen Spoke zugreifen

Wenn eine VM in einem VPC-Spoke nicht auf den Private Service Connect-Endpunkt in einem anderen Spoke zugreifen kann, prüfen Sie, ob die folgenden Bedingungen erfüllt sind:

  • Das Feld --export_psc ist im Hub aktiviert.

    Mit dem gcloud network-connectivity hubs describe-Befehl können Sie prüfen, ob das Feld --export_psc im Hub aktiviert ist.

    gcloud 

    gcloud network-connectivity hubs describe HUB_NAME \
    --project=PROJECT_ID \
    --format='get(export_psc)'

    Ersetzen Sie die folgenden Werte:

    • HUB_NAME: Name des Hubs
    • PROJECT_ID: die Projekt-ID, in der sich der Hub befindet

  • Die IP-Adresse des Private Service Connect-Endpunkts befindet sich nicht in einem Ausschlussbereich für den Export des Hosting-Spoke. Private Service Connect-Endpunkte, die sich im Ausschlussbereich für den Export befinden, werden nicht weitergegeben.

    Verwenden Sie den Befehl gcloud network-connectivity spokes describe, um die angegebenen Ausschlussbereiche für den Export eines Spoke zu prüfen.

    gcloud 

    gcloud network-connectivity spokes describe SPOKE_NAME \
    --global \
    --project=PROJECT_ID \
    --format='get(linked_vpc_network.exclude_export_ranges)'

    Ersetzen Sie die folgenden Werte:

    • SPOKE_NAME: Name des Spoke
    • PROJECT_ID: die Projekt-ID, in der sich der Spoke befindet

  • Sie haben das Kontingent für die Network Connectivity Center-Nutzung nicht überschritten.

  • Der psc_connection_status des Endpunkts hat den Status ACCEPTED. Informationen zu Verbindungsstatus finden Sie unter Verbindungsstatus.

  • Der weitergegebene Verbindungsstatus des Endpunkts im Spoke mit der VM ist READY. Wenn kein Status angezeigt wird, sehen Sie auf dieser Seite im Abschnitt Status einiger Ziel-Spokes wird nicht angezeigt nach, welche Gründe dafür infrage kommen. Sie können den weitergegebenen Verbindungsstatus mit dem Befehl gcloud network-connectivity hubs query-status prüfen:

    gcloud 

    gcloud network-connectivity hubs query-status HUB_NAME\
    --filter='psc_propagation_status.source_spoke="SOURCE_SPOKE_NAME" AND psc_propagation_status.target_spoke="TARGET_SPOKE_NAME" AND psc_propagation_status.source_forwarding_rule="ENDPOINT_NAME"

    Ersetzen Sie die folgenden Werte:

    • HUB_NAME: der Name des Hubs, für den Sie den Status der Verbindungsweitergabe prüfen möchten
    • SOURCE_SPOKE_NAME: Name des Quell-Spoke
    • TARGET_SPOKE_NAME: Name des Ziel-Spoke
    • ENDPOINT_NAME: der Name des Endpunkts.

    Ausführliche Informationen zur Verwendung dieser Flags finden Sie auf der Seite zum Befehl gcloud network-connectivity hubs query-status.

  • Das Host-VPC-Netzwerk des Private Service Connect-Endpunkts (Quelle) ist ein VPC-Spoke im Hub.

  • Die IP-Adresse des Private Service Connect-Endpunkts ist eine RFC 1918-Adresse.

Das Erstellerkontingent ist ausgeschöpft

Wenn Sie die Fehlermeldung PRODUCER_QUOTA_EXHAUSTED sehen, können Sie den Dienstproduzenten bitten, eine PSC_ILB_CONSUMER_FORWARDING_RULES_PER_PRODUCER_NETWORK-Kontingenterhöhung anzufordern. Weitere Informationen finden Sie in der VPC-Dokumentation im Abschnitt Pro Netzwerk.

Sie haben das Limit für weitergegebene Verbindungen des Erstellers überschritten

Wenn Sie einen Fehler bezüglich der Überschreitung des Limits für weitergegebene Verbindungen eines Dienstanhangs sehen, können Sie den Dienstersteller bitten, das Limit zu erhöhen. Wenn ein Dienstersteller das Limit für weitergegebene Verbindungen aktualisiert, wird in Google Cloud automatisch geprüft, ob ausstehende weitergegebene Verbindungen erstellt werden können.

Der NAT-IP-Adressbereich des Erstellers ist erschöpft

Wenn die Fehlermeldung PRODUCER_NAT_IP_SPACE_EXHAUSTED angezeigt wird, müssen Sie den Dienstersteller möglicherweise bitten, NAT-Subnetze hinzuzufügen. Informationen zum Hinzufügen von Subnetzen finden Sie unter Subnetze zu einem veröffentlichten Dienst hinzufügen oder daraus entfernen.

Sie haben das Nutzerkontingent ausgeschöpft

Wenn Sie eine CONSUMER_QUOTA_EXHAUSTED-Fehlermeldung sehen, wenden Sie sich an den Inhaber des Nutzer-VPC-Netzwerks und bitten Sie ihn, eine PSC_PROPAGATED_CONNECTIONS_PER_VPC_NETWORK-Kontingenterhöhung zu beantragen.

Der Status einiger Ziel-Spokes wird nicht angezeigt

Wenn der Status einiger Ziel-Spokes nicht angezeigt wird, kann dies einen der folgenden Gründe haben:

  • Der Ziel-Spoke ist kein VPC-Spoke. Nur VPC-Spokes, einschließlich VPC-Netzwerke, die VPC-Spokes sind und auch Hybrid-Spokes enthalten, können weitergeleitete Verbindungen empfangen. Ein Hybrid-Spoke in einem Routing-VPC-Netzwerk, das nicht auch ein VPC-Spoke ist, kann keine weitergeleiteten Verbindungen empfangen.

  • Das Network Connectivity Center zeigt nur den Weiterleitungsstatus für jeden VPC-Spoke an. Wenn ein VPC-Netzwerk sowohl ein VPC-Spoke ist als auch Hybrid-Spokes enthält, prüfen Sie den Weiterleitungsstatus des VPC-Spoke, um festzustellen, ob die enthaltenen Hybrid-Spokes eine Verbindung zu weitergeleiteten Private Service Connect-Endpunkten haben.

  • Wenn ein VPC-Netzwerk sowohl das Private Service Connect-Ersteller-VPC-Netzwerk als auch ein VPC-Spoke in einem Hub ist, der seine Endpunkte weiterleitet, leitet Network Connectivity Center seine Endpunkte nicht zurück an das Ersteller-VPC-Netzwerk selbst weiter.

  • Die Weiterleitung ist aufgrund der Topologie des Hubs nicht zulässig. Wenn der Hub beispielsweise für die Verwendung der Sterntopologie konfiguriert ist, gelten auch die folgenden Bedingungen:

    • Private Service Connect-Endpunkte in der Center-Gruppe werden an alle anderen VPC-Spokes weitergeleitet.
    • Private Service Connect-Endpunkte in der Edge-Gruppe werden nur an VPC-Spokes in der Center-Gruppe weitergegeben.

Fehlerbehebung beim Routenaustausch von VPC-Spokes

VPC-Spokes und Hybrid-Spokes sind mit demselben Hub verbunden, aber die Verbindung zur Datenebene fehlt

Wenn die VPC-Spokes und Hybrid-Spokes mit demselben Hub verbunden sind, aber die Verbindung zur Datenebene fehlt, kann dies einen der folgenden Gründe haben:

  • Der Spoke ist ein projektübergreifender Spoke und der Hub-Administrator hat den Spoke-Vorschlag nicht angenommen.
  • Alle Subnetze im VPC-Netzwerk werden gefiltert und von der Verbindung ausgeschlossen.
  • Die automatische Weitergabe von VPC-Subnetzen ist nicht aktiviert oder die Ankündigung benutzerdefinierter Routen ist nicht eingerichtet.
  • Das Kontingent für dynamische Routen ist erschöpft.

In der Hub-Routingtabelle werden einige dynamische Routen nicht angezeigt oder es werden fälschlicherweise dynamische Routen angezeigt

Die dynamischen Routen werden in der Hub-Routingtabelle möglicherweise aus einem der folgenden Gründe nicht richtig angezeigt:

  • BGP-Routen wurden innerhalb der letzten fünf bis zehn Minuten beworben oder zurückgezogen und die Hub-Routingtabelle wurde noch nicht aktualisiert.
  • Das Kontingent für dynamische Routen ist erschöpft.

Fehler beim Erstellen von Hybrid-Spokes

Wenn die Erstellung eines Hybrid-Spoke fehlschlägt, kann dies einen der folgenden Gründe haben:

  • Das Routing-VPC-Netzwerk kann ein vorhandener VPC-Spoke für denselben oder einen anderen Hub sein.
  • Das VPC-Routingnetzwerk ist möglicherweise implizit einem anderen Hub zugeordnet, da ein vorhandener Hybrid-Spoke mit diesem Hub verbunden ist. Hybrid-Anhänge aus einem VPC-Netzwerk können nur Spokes für einen Hub werden.

Erstellung von VPC-Spokes schlägt fehl

Die Erstellung von VPC-Spokes kann fehlschlagen, wenn der VPC-Spoke implizit mit einem Hub als Routing-VPC-Netzwerk verknüpft ist.

Fehlermeldung

Wenn Sie versuchen, einen Spoke zu erstellen, und eine Fehlermeldung mit dem Text An internal error occurred erhalten, wenden Sie sich zur Fehlerbehebung an den Google Cloud -Support.

Fehlerbehebung bei NCC-Gateway-Spokes

Sie können die Dienste und Router, die mit Ihrem NCC-Gateway verbunden sind, mit dem gcloud network-connectivity spokes describe-Befehl für die NCC-Gateway-Spoke-Ressource aufrufen.

gcloud 

  gcloud network-connectivity spokes describe SPOKE_NAME \
      --region REGION

Ersetzen Sie Folgendes:

  • SPOKE_NAME: Name des NCC-Gateway-Spoke
  • REGION: die Region, in der sich der Spoke befindet

Die Ausgabe sieht etwa so aus:

createTime: '2022-11-25T06:06:11.572019860Z'
hub: projects/PROJECT/locations/REGION/hubs/HUB
gateway:
  ipRangeReservation: 10.1.2.0/24
  asn: 65123
  routers:
    projects/PROJECT/locations/REGION/routers/ROUTER

name: projects/PROJECT/locations/REGION/spokes/SPOKE
state: ACTIVE
uniqueId: 8ca10af0-ee69-43c2-b0b4-61e8f53d410b
updateTime: '2023-12-27T21:26:47.786506888Z'

Mit dem gcloud compute routes list-Befehl können Sie die Routingtabelle der Anwendungs-VPC und die erstellte Hub-Routingtabellenroute ansehen, die mit dem nächsten Hop als Hub in Ihre VPC-Routingtabelle übertragen wird:

gcloud 

  gcloud compute routes list \
      --filter="network=NETWORK"

Ersetzen Sie NETWORK durch den Namen des VPC-Netzwerk.

Die Ausgabe sieht etwa so aus:

NAME                                                  NETWORK  DEST_RANGE    NEXT_HOP  PRIORITY
ncc-static-route-7296f3a4-cdc2-4560-a905-95cdb1d6833e  vpc-1    17.0.0.0/8   hub       0

Mit dem gcloud network-connectivity hubs route-tables routes list-Befehl können Sie die Hub-Routingtabelle für die Spoke-Gruppe aufrufen und dieselbe erstellte Route sehen, die auf den NCC Gateway-Spoke verweist:

gcloud 

  gcloud network-connectivity hubs route-tables routes list --hub=HUB_NAME \
      --route_table

Ersetzen Sie HUB_NAME durch den Namen des Hubs.

In der Hub-Routingtabelle werden vom Gateway beworbene Routen nicht angezeigt

Wenn in der Hub-Routingtabelle einige der vom Gateway beworbenen Routen mit dem Gateway-Spoke als Next Hop nicht angezeigt werden, kann dies daran liegen, dass die Routen nicht in der Datenebene installiert sind. Dies kann zu Verbindungsproblemen zwischen VPC-Spokes und lokalen Anwendungen führen, die über den NCC-Gateway-Spoke verbunden sind. Versuchen Sie, die beworbenen Routen des Gateways zu löschen und neu zu erstellen. Gehen Sie dazu so vor:

  1. Beworbene Route löschen
  2. Vom NCC-Gateway beworbene Route erstellen

  3. Sehen Sie sich die beworbene Route an, die dem NCC-Gateway zugeordnet ist, indem Sie den gcloud beta network-connectivity spokes gateways advertised-routes list-Befehl verwenden:

    gcloud 

    gcloud beta network-connectivity spokes gateways advertised-routes list
    --region=REGION

    Ersetzen Sie REGION durch die Region, in der sich der Spoke befindet.

  4. Prüfen Sie die vom Gateway beworbene Route in der Hub-Routingtabelle mit dem Befehl gcloud network-connectivity hubs route-tables list:

    gcloud 

    gcloud network-connectivity hubs route-tables list \
    --hub=HUB_NAME

    Ersetzen Sie HUB_NAME durch den Namen des Hubs, für den Sie die Routentabelle auflisten möchten.

    Die entsprechende Ausgabe sieht etwa so aus: In der Ausgabe muss ein Eintrag für die vom Gateway angekündigte Route vorhanden sein.

    gcloud  network-connectivity hubs route-tables routes list --hub=HUB_NAME --route_table PROD
IP_CIDR_RANGE  STATE    TYPE      NEXT_HOP   HUB       ROUTE_TABLE     PRIORITY
10.0.0.0/8     ACTIVE   NCC_GW    NCC-GW-1   HUB_NAME  PROD            100

Informationen zu Problemen mit Cloud Router finden Sie unter Fehlerbehebung: Cloud Router-Logmeldungen.

Informationen zur Fehlerbehebung bei Cloud Interconnect finden Sie auf der Seite Fehlerbehebung bei Cloud Interconnect.