Fehlerbehebung

Die Anleitung zur Fehlerbehebung hilft Ihnen beim Lösen gängiger Probleme, die bei Verwendung von Cloud Interconnect auftreten können.

Allgemeine Fehlerbehebung
Dedicated Interconnect
Partner Interconnect
HA VPN über Cloud Interconnect
MACsec für Cloud Interconnect
Cross-Cloud Interconnect

Antworten auf häufig gestellte Fragen zur Architektur und zu den Features von Cloud Interconnect finden Sie in den FAQ zu Cloud Interconnect.

Definitionen der auf dieser Seite verwendeten Begriffe finden Sie unter Wichtige Begriffe von Cloud Interconnect.

Wichtig: BFD kann nur für bereitgestellte VLAN-Anhänge aktiviert werden, die Dataplane Version 2 verwenden. Sie können die dataplaneVersion für einen VLAN-Anhang aufrufen, indem Sie die Anhangsdetails auf eine der folgenden Arten aufrufen:

API: Verwenden Sie die Methode interconnectAttachments.get. Sie können diese Methode für VLAN-Anhänge für Dedicated Interconnect oder Partner Interconnect verwenden.
Google Cloud-CLI: Verwenden Sie den Befehl gcloud compute interconnects attachments describe ATTACHMENT-NAME, wobei ATTACHMENT-NAME der Name des VLAN-Anhangs für Dedicated Interconnect oder Partner Interconnect ist.

Suchen Sie in der Ausgabe der API oder der gcloud CLI nach dem Feld dataplaneVersion mit dem Wert 2. Wenn das Feld in der Ausgabe fehlt, verwendet der VLAN-Anhang die Version 1 und kann nicht mit BFD verwendet werden. Weitere Informationen erhalten Sie von Ihrem Account-Management-Team.

Informationen zum Logging und Monitoring sowie Cloud Interconnect-Messwerte finden Sie unter Verbindungen überwachen.

Allgemeine Fehlerbehebung

Auf Cloud Interconnect-Dienstunterbrechungen prüfen

Bekannte Störungen können Sie im Google Cloud-Status-Dashboard prüfen. Sie können auch den JSON-Feed oder den RSS-Feed abonnieren, um Push-Mitteilungen zu Cloud-Vorfällen zu erhalten.
Sie werden über Wartungsereignisse informiert, die sich auf Ihre Dedicated Interconnect-Verbindungen auswirken. Weitere Informationen finden Sie unter Infrastrukturwartungsereignisse.
Sie werden über Wartungsereignisse informiert, die sich auf Ihre Partner Interconnect-VLAN-Anhänge auswirken. Benachrichtigungen für Partner Interconnect werden auf ähnliche Weise gesendet wie die Benachrichtigungen für Dedicated Interconnect-Verbindungen mit einigen geringfügigen Unterschieden. Weitere Informationen finden Sie unter Infrastrukturwartungsereignisse.

Sie können keine Verbindung zu Ressourcen in anderen Regionen herstellen

Standardmäßig sind VPC-Netzwerke (Virtual Private Cloud) regional, was bedeutet, dass Cloud Router nur die Subnetze in seiner Region bewirbt. Zur Verbindungsherstellung mit anderen Regionen müssen Sie das dynamische Routing Ihres VPC-Netzwerks auf "Global" festlegen, sodass der Cloud Router alle Subnetze anbieten kann.

Weitere Informationen finden Sie unter Dynamischer Routingmodus in der Cloud Router-Dokumentation.

Sie können keine VMs in einem Peering-VPC-Netzwerk erreichen

In diesem Szenario haben Sie eine Cloud Interconnect-Verbindung zwischen Ihrem lokalen Netzwerk und einem VPC-Netzwerk, Netzwerk A, eingerichtet. Sie haben auch VPC-Netzwerk-Peering zwischen Netzwerk A und einem anderen VPC-Netzwerk (Netzwerk B) eingerichtet. Sie können jedoch keine VMs in Netzwerk B von Ihrem lokalen Netzwerk aus erreichen.

Diese Konfiguration wird nicht unterstützt, wie in den Einschränkungen der VPC-Netzwerk-Peering-Übersicht beschrieben.

Sie können jedoch das Advertising benutzerdefinierter IP-Bereiche durch Cloud Router in Ihrem VPC-Netzwerk dazu verwenden, Routen zu Zielen im Peering-Netzwerk freizugeben. Außerdem müssen Sie Ihre VPC-Netzwerk-Peering-Verbindungen so konfigurieren, dass benutzerdefinierte Routen importiert und exportiert werden.

Weitere Informationen zu Advertising-Routen zwischen lokalen Netzwerken und VPC-Peering-Netzwerken finden Sie in den folgenden Ressourcen:

Benutzerdefinierte IP-Bereiche bewerben
Fehlerbehebung bei Verwendung von VPC-Netzwerk-Peering

Fehlende Subnetze in einer Verbindung

Um alle verfügbaren Subnetze anzubieten, geben Sie die fehlenden Routen mit benutzerdefiniertem Routen-Advertising an und bewerben Sie alle Subnetzrouten zwischen Regionen mit globalem dynamischem Routing. Gehen Sie hierzu folgendermaßen vor:

Geben Sie benutzerdefiniertes Route Advertisement sowohl auf einem Cloud Router als auch in der BGP-Sitzung (Border Gateway Protocol) an. Legen Sie die folgenden Parameter fest, um die fehlenden Routen einzugeben:
```
--set-advertisement-groups = ADVERTISED_GROUPS
--set-advertisement-ranges = ADVERTISED_IP_RANGES
```
Dabei gilt:
- ADVERTISED_GROUPS: von Google definierte Gruppe, die Cloud Router dynamisch bewirbt; kann den Wert all_subnets haben, der das Standardverhalten eines Cloud Routers imitiert
- ADVERTISED_IP_RANGES: der Inhalt des neuen Arrays der IP-Adressbereiche; kann einen oder mehrere Werte Ihrer Wahl haben
Weitere Informationen und Beispiele finden Sie unter Benutzerdefinierte IP-Bereiche bewerben.
Aktivieren Sie den Modus für globales dynamisches Routing.

Cloud Router kann nicht angepingt werden

Wenn Sie Cloud Router nicht über Ihren lokalen Router anpingen können, suchen Sie Ihr Produkt in der folgenden Tabelle und führen Sie die Schritte zur Fehlerbehebung für dieses Produkt aus. VMs können 169.254.0.0/16 nicht erreichen.

Schritte zur Fehlerbehebung	Dedicated Interconnect	Partner Interconnect mit L3-Partner	Partner Interconnect mit L2-Partner
Bei Partner Interconnect kann Cloud Router möglicherweise nie angepingt werden, da einige Partner den Traffic für Cloud Router in den IP-Bereich (`169.254.0.0/16`) filtern. Bei L3-Partnern konfiguriert der Partner automatisch BGP. Wenn BGP nicht angezeigt wird, wenden Sie sich an Ihren Partner.	Nicht zutreffend	Ja	Nicht zutreffend
Prüfen Sie, ob Ihr lokales Gerät die richtige MAC-Adresse für die Google Cloud-Seite der Verbindung ermittelt hat. Weitere Informationen finden Sie unter Fehlerbehebung bei ARP.	Ja	Nicht zutreffend	Nicht zutreffend
Prüfen Sie, ob Ihr Cloud Router eine Schnittstelle und einen BGP-Peer hat. Cloud Router kann nicht angepingt werden, wenn die Schnittstelle und der BGP-Peer nicht vollständig konfiguriert sind. Das schließt die Remote-ASN mit ein. Informationen zu Dedicated Interconnect finden Sie unter BGP-Sitzung funktioniert nicht. Für L2 Partner Interconnect hat Google automatisch die Schnittstelle und den BGP-Peer für Cloud Router hinzugefügt. Sie müssen jedoch die Remote-ASN konfigurieren.	Ja	Nicht zutreffend	Ja

Fehlerbehebung bei ARP

Führen Sie den folgenden gcloud-Befehl aus, um die richtige MAC-Adresse zu ermitteln:

  gcloud compute interconnects get-diagnostics INTERCONNECT_NAME

Die googleSystemID enthält die MAC-Adresse, die in der ARP-Tabelle des Geräts für die Cloud Router zugewiesenen IP-Adressen vorhanden sein sollte.

  result:
    links:
    — circuitId: SAMPLE-0
      googleDemarc: sample-local-demarc-0
      lacpStatus:
        googleSystemId: ''
        neighborSystemId: ''
        state: DETACHED
      receivingOpticalPower:
        value: 0.0
      transmittingOpticalPower:
        value: 0.0
    macAddress: 00:00:00:00:00:00

Wenn das Gerät keine MAC-Adresse ermittelt hat, prüfen Sie, ob in der Subschnittstelle die richtige VLAN-ID und IP-Adresse konfiguriert wurden.

Wenn bei Partner Interconnect auf dem Gerät die falsche MAC-Adresse angezeigt wird, haben Sie möglicherweise die Layer-2-Segmente zweier VLAN-Anhänge verbunden. Die Google Cloud-Seite der Cloud Interconnect-Verbindung wurde mit ip proxy-arp konfiguriert. Ip proxy-arp antwortet auf alle ARP-Anfragen und verursacht möglicherweise, dass der lokale Router falsche ARP-Einträge speichert.

VLAN-Anhang kann nicht erstellt werden

Wenn Sie versuchen, einen VLAN-Anhang für eine Dedicated Interconnect-Verbindung oder für Partner Interconnect zu erstellen, die gegen eine Organisationsrichtlinie verstößt, erhalten Sie eine Fehlermeldung. Im Beispiel unten wird die folgende Fehlermeldung angezeigt, nachdem gcloud compute interconnects attachments partner create ausgeführt wurde:

ERROR: (gcloud.compute.interconnects.attachments.partner.create) Could not fetch resource:
- Constraint constraints/compute.restrictPartnerInterconnectUsage violated for projects/example-project. projects/example-project/global/networks/example-network is not allowed to use the Partner Interconnect.

Weitere Informationen finden Sie unter Cloud Interconnect-Nutzung einschränken. Sie können sich auch an den Administrator Ihrer Organisation wenden.

Verbindungen für andere Projekte in der Organisation freigeben

Verwenden Sie eine freigegebene VPC, um eine Verbindung wie einen VLAN-Anhang oder eine Dedicated Interconnect-Verbindung in einem Hostprojekt freizugeben.

Weitere Informationen zum Einrichten eines freigegebenen VPC-Netzwerks finden Sie unter Freigegebene VPC bereitstellen.

Weitere Informationen zum Konfigurieren von Anhängen in einem freigegebenen VPC-Netzwerk finden Sie unter Optionen zum Herstellen einer Verbindung zu mehreren VPC-Netzwerken.

Dedicated Interconnect

Google kann Sie während der Bereitstellung der Cloud Interconnect-Verbindung nicht anpingen

Prüfen Sie, ob Sie die richtige IP- und LACP-Konfiguration verwenden. Während des Testverfahrens sendet Ihnen Google unterschiedliche IP-Konfigurationen für Ihren lokalen Router, je nachdem, ob Sie ein Paket für eine oder mehrere Verbindungen bestellen. Konfigurieren Sie für keinen dieser Tests VLAN-Anhänge.

Bei Paketen mit mehreren Verbindungen

Über das erste Set IP-Adressen, das Google Ihnen sendet, werden die einzelnen Netzwerkverbindungen getestet. Konfigurieren Sie die Test-IP-Adressen für jede physische Verbindung (ohne konfiguriertes LACP). Die Anleitung dazu haben Sie von Google per E-Mail erhalten. Damit dieser erste Test als bestanden zählt, muss Google alle IP-Adressen erfolgreich anpingen.
Entfernen Sie für den zweiten Test alle IP-Adressen aus dem ersten Test. Konfigurieren Sie den Port-Channel mit LACP, auch wenn Ihre Interconnect-Verbindung nur eine Verbindung hat. Google pingt die Adresse des Port-Channels. Ändern Sie die LACP-Konfiguration des Port-Channels nicht, nachdem die Verbindung den letzten Test bestanden hat. Entfernen Sie jedoch die Test-IP-Adresse aus der Port-Channel-Schnittstelle.

Bei Paketen mit einer einzelnen Verbindung

Google sendet die endgültige Produktions-IP-Adresse zum Testen einer einzigen Verbindung. Konfigurieren Sie die IP-Adresse an der gebündelten Schnittstelle mit aktiviertem LACP (aktiv oder passiv). Die Anleitung dazu haben Sie von Google per E-Mail erhalten. Damit dieser Test als bestanden gilt, muss Google die IP-Adresse der gebündelten Schnittstelle erfolgreich anpingen. Konfigurieren Sie den Port-Channel mit LACP, auch wenn Ihre Interconnect-Verbindung nur eine Verbindung hat.

Cloud Router kann nicht angepingt werden

Prüfen Sie, ob Sie die IP-Adresse des Port-Channels von Google anpingen können. Die IP-Adresse ist der Wert von googleIpAddress in den Verbindungsdetails.
Prüfen Sie, ob auf der Subschnittstelle Ihres lokalen Routers das richtige VLAN konfiguriert ist. Die VLAN-Informationen müssen mit den Informationen übereinstimmen, die Sie im VLAN-Anhang finden.
Prüfen Sie, ob auf der Subschnittstelle Ihres lokalen Routers die richtige IP-Adresse konfiguriert ist. Wenn Sie einen VLAN-Anhang erstellen, wird ein Paar Link-Local-IP-Adressen zugeordnet. Eine ist für eine Schnittstelle auf einem Cloud Router (cloudRouterIpAddress) und die andere ist für eine Subschnittstelle auf dem Port-Channel Ihres lokalen Routers (customerRouterIpAddress), nicht dem Port-Channel selbst.
Wenn Sie die Leistung Ihrer VLAN-Anhänge testen, dürfen Sie den Cloud Router nicht anpingen. Erstellen und verwenden Sie stattdessen eine Compute Engine-VM-Instanz in Ihrem VPC-Netzwerk. Weitere Informationen finden Sie unter Leistungstests.

BGP-Sitzung funktioniert nicht

Aktivieren Sie Multi-Hop-BGP auf Ihrem lokalen Router mit mindestens zwei Hops.
Prüfen Sie, ob Sie auf Ihrem lokalen Router die richtige benachbarte IP-Adresse konfiguriert haben. Verwenden Sie die BGP-Peer-IP-Adresse (cloudRouterIpAddress), die vom VLAN-Anhang zugewiesen wurde.
Prüfen Sie, ob die lokale ASN-Konfiguration auf Ihrem lokalen Router mit der Peer-ASN auf dem Cloud Router übereinstimmt. Prüfen Sie außerdem, ob die lokale ASN-Konfiguration auf dem Cloud Router mit der Peer-ASN auf Ihrem lokalen Router übereinstimmt.
Jedem Anhang wird in Ihrem VPC-Netzwerk ein eindeutiges "/29 CIDR"-Format von 169.254.0.0/16 zugewiesen. Eine IP-Adresse im Format "/29 CIDR" wird dem Cloud Router und die andere dem lokalen Router zugewiesen.

Prüfen Sie, ob Ihrer lokalen Router-Schnittstelle und dem BGP-Nachbarn die richtigen IP-Adressen zugewiesen sind. Ein häufiger Fehler besteht darin, statt eines "/29"- ein "/30"-Format für die Schnittstelle Ihres lokalen Routers zu konfigurieren. Google Cloud reserviert alle anderen Adressen im CIDR-Format /29.

Achten Sie darauf, dass Sie der Schnittstelle des VLAN-Anhangs auf Ihrem Router keine anderen IP-Adressen zugewiesen haben.

Sie können keine VMs in Ihrem VPC-Netzwerk erreichen

Prüfen Sie, ob Sie den Port-Channel und den VLAN-Anhang pingen können.
Prüfen Sie, ob Ihre BGP-Sitzung aktiv ist.
Prüfen Sie, ob Ihr lokaler Router Routen bewirbt und empfängt.
Achten Sie darauf, dass es keine Überschneidungen zwischen Ihrem lokalen Route Advertisement und den Google Cloud-Netzwerkbereichen gibt.
Legen Sie für die MTU-Größe die gleichen Werte für Ihren lokalen Router, Ihre VPC und Ihren VLAN-Anhang fest.

IPv6-Traffic wird nicht über den VLAN-Anhang weitergeleitet

Wenn Sie Probleme beim Herstellen einer Verbindung zu IPv6-Hosts haben, gehen Sie so vor:

Prüfen Sie, ob IPv6-Routen ordnungsgemäß beworben werden. Wenn IPv6-Routen nicht beworben werden, lesen Sie die Informationen unter Fehlerbehebung bei BGP-Routen und Routenauswahl.
Prüfen Sie die Firewallregeln, um sicherzugehen, dass IPv6-Traffic zugelassen wird.
Achten Sie darauf, dass sich in Ihrem VPC-Netzwerk und im lokalen Netzwerk keine überlappenden IPv6-Subnetzbereiche befinden. Siehe Überlappende Subnetzbereiche prüfen.
Prüfen Sie, ob Sie Kontingente und Limits für Ihre erkannten Routen in Cloud Router überschritten haben. Wenn Sie Ihr Kontingent für erkannte Routen überschritten haben, werden IPv6-Präfixe vor IPv4-Präfixen gelöscht. Siehe Kontingente und Limits prüfen.
Prüfen Sie, ob alle Komponenten im Zusammenhang mit der IPv6-Konfiguration korrekt konfiguriert sind.
- Das VPC-Netzwerk hat die Verwendung interner IPv6-Adressen mit dem Flag --enable-ula-internal-ipv6 aktiviert.
- Das VPC-Subnetz ist für die Verwendung des Stack-Typs IPV4_IPV6 konfiguriert.
- Im VPC-Subnetz ist --ipv6-access-type auf INTERNAL festgelegt.
- Die Compute Engine-VMs im Subnetz sind mit IPv6-Adressen konfiguriert.
- Der VLAN-Anhang ist für die Verwendung des Stack-Typs IPV4_IPV6 konfiguriert.
- Der BGP-Peer hat IPv6 aktiviert und die richtigen IPv6-Adressen des nächsten Hops sind für die BGP-Sitzung konfiguriert.
  - Informationen zum Aufrufen des Status und der Routen von Cloud Router finden Sie unter Status und Routen von Cloud Router ansehen.
  - Informationen zum Konfigurieren der BGP-Sitzung finden Sie unter BGP-Sitzungskonfiguration ansehen.

VLAN-Anhang mit IPv4- und IPv6-Stacktyp (Dual-Stack) kann nicht erstellt werden

Das Erstellen eines VLAN-Anhangs mit dem IPv4- und IPv6-Stacktyp (Dual-Stack) schlägt mit der folgenden Fehlermeldung fehl:

Cannot create a dual stack interconnect attachment. Dual stack attachment can only be used
with a provisioned interconnect attachments that have Dataplane version 2.

So beheben Sie das Problem:

In der Tabelle Alle Colocations-Einrichtungen sehen Sie, in welchen Regionen das Erstellen von Anhängen in Dataplane v2 unterstützt wird.
Wenn die Region nicht aufgeführt ist, erstellen Sie den Anhang in einer unterstützten Region neu.

Vorhandener VLAN-Anhang kann nicht für die Verwendung des IPv4- und IPv6-Stacktyps (Dual-Stack) geändert werden

Das Aktualisieren eines vorhandenen VLAN-Anhangs zur Verwendung des IPv4- und IPv6-Stacktyps (Dual-Stack) schlägt mit der folgenden Fehlermeldung fehl:

Cannot create a dual stack interconnect attachment. Dual stack attachment can only
be used with a provisioned interconnect attachments that have Dataplane version 2.

So beheben Sie das Problem:

Prüfen Sie die Dataplane-Version des Anhangs und stellen Sie sicher, dass der Anhang die Dataplane-Version 1 verwendet. Siehe Dataplane-Version eines Anhangs prüfen
Erstellen Sie den Anhang in einer Region neu, die die Erstellung aller neuen Anhänge in Dataplane v2 unterstützt. Eine Liste der Regionen finden Sie unter Alle Colocations-Einrichtungen.

Leistungstests für Ihre VLAN-Anhänge

Verwenden Sie eine VM in Ihrem VPC-Netzwerk, wenn Sie die Leistung Ihrer VLAN-Anhänge testen müssen. Fügen Sie der VM die erforderlichen Leistungstools hinzu. Verwenden Sie nicht die Link-Local-IP-Adresse des Cloud Routers, um die Latenz beispielsweise über den ICMP-Ping oder die Pfad-MTU zu testen. Die Verwendung des Cloud Routers kann zu unvorhersehbaren Ergebnissen führen.

Diagnose abrufen

Aktuelle, detaillierte technische Informationen zur Google Cloud-Seite der Dedicated Interconnect-Verbindung erhalten Sie bei Bedarf unter Diagnosedaten abrufen.

Partner Interconnect

BGP-Sitzung funktioniert nicht (Ebene-2-Verbindungen)

Überprüfen Sie, ob Ihr lokaler Router mit einer BGP-Sitzung für Ihre Cloud Router konfiguriert wurde. Weitere Informationen finden Sie unter Lokale Router für Partner Interconnect konfigurieren.
Aktivieren Sie Multi-Hop-BGP auf Ihrem lokalen Router mit mindestens zwei Hops.
Prüfen Sie, ob Sie auf Ihrem lokalen Router die richtige benachbarte IP-Adresse konfiguriert haben. Verwenden Sie die BGP-Peer-IP-Adresse (cloudRouterIpAddress), die vom VLAN-Anhang zugewiesen wurde.
Prüfen Sie, ob die lokale ASN-Konfiguration auf Ihrem lokalen Router mit der Peer-ASN auf dem Cloud Router (16550) übereinstimmt. Prüfen Sie außerdem, ob die lokale ASN-Konfiguration auf dem Cloud Router mit der Peer-ASN auf Ihrem lokalen Router übereinstimmt.

BGP-Sitzung funktioniert nicht (Ebene-3-Verbindungen)

Ihr Cloud Router muss mit der ASN Ihres Dienstanbieters konfiguriert werden. Wenden Sie sich an Ihren Dienstanbieter, um Unterstützung zu erhalten.

VLAN-Anhang ausgefallen für eine Partner Interconnect-Verbindung

Der Status eines VLAN-Anhangs kann als ausgefallen angezeigt werden, selbst wenn keine Probleme mit der Google Cloud-Konfiguration und der Partner Interconnect-Verbindung vorliegen.

Auf Ihrem lokalen Router muss EBGP mit mehreren Hops für mindestens vier Hops konfiguriert sein. Eine Beispielkonfiguration finden Sie unter Lokale Router konfigurieren.

Problem mit Kopplungsschlüssel in einer Partner Interconnect-Verbindung

Wenn Sie versuchen, eine Partner Interconnect-Verbindung einzurichten, wird möglicherweise eine Fehlermeldung wie „Google – Anbieterstatus nicht verfügbar“ angezeigt. Gehen Sie folgendermaßen vor, um dieses Problem zu beheben:

Prüfen Sie, ob der Kopplungsschlüssel vom clientseitigen VLAN-Anhang (Typ PARTNER) generiert wurde. Der Schlüssel ist ein langer, zufälliger String, anhand dessen Google den Anhang identifiziert. Die Google Cloud-Zielregion und die Edge-Verfügbarkeitsdomain werden im Kopplungsschlüssel in folgendem Format codiert:
```
<random_string>/<region_name>/<domain>
```
Das Feld domain enthält den String any, wenn der VLAN-Anhang nicht auf eine bestimmte Domain beschränkt ist oder Sie die Edge-Verfügbarkeitsdomain nicht angeben. Weitere Informationen zu den Kopplungsschlüsseln finden Sie unter Kopplungsschlüssel.
Achten Sie darauf, dass die Edge-Verfügbarkeitsdomain der Partner Interconnect-Verbindung mit der Domain übereinstimmt, die durch den Kopplungsschlüssel angegeben wird.

Sie können den Cloud Router nicht anpingen (Ebene-2-Verbindungen)

Prüfen Sie, ob auf der Subschnittstelle Ihres lokalen Routers der richtige VLAN-Anhang konfiguriert ist. Die Informationen zum VLAN-Anhang müssen mit den Daten übereinstimmen, die Sie von Ihrem Dienstanbieter erhalten haben.
Prüfen Sie, ob auf der Subschnittstelle Ihres lokalen Routers die richtige IP-Adresse konfiguriert ist. Nachdem Ihr Dienstanbieter Ihren VLAN-Anhang konfiguriert hat, ordnet der Anhang zwei Link-Local-IP-Adressen zu. Eine ist für eine Schnittstelle auf dem zugehörigen Cloud Router (cloudRouterIpAddress) und die andere für eine Subschnittstelle auf dem Port-Channel Ihres lokalen Routers (customerRouterIpAddress), nicht dem Port-Channel selbst.
Wenn Sie die Leistung Ihrer Anhänge testen, dürfen Sie den Cloud Router nicht anpingen. Erstellen und verwenden Sie stattdessen eine VM in Ihrem VPC-Netzwerk. Weitere Informationen finden Sie unter Leistungstests.

Verlust der optischen Leistung am Port der Partner Interconnect-Verbindung

Wenn die optische Leistung an einem Port unterbrochen wird, kann eines der folgenden Probleme auftreten:

Verlust der Ebene-3-Verbindung (Verlust einer BGP-Sitzung) oder Unfähigkeit, auf Ihre Google Cloud-VM-Instanzen zuzugreifen.
Die Leistung des Verbindungspakets ist beeinträchtigt. Dieses Problem tritt auf, wenn mehrere 10GE-Ports gebündelt sind und nur einige der Verbindungen in einem Paket funktionieren.

Verlust der optischen Leistung an einem Port bedeutet, dass die Hardware kein Signal vom anderen Ende erkennen kann. Dies kann folgende Ursachen haben:

Fehlerhafter Transceiver
Fehlerhaftes Transportsystem
Problem mit Glasfaser

Wenden Sie sich an Ihren Partner Interconnect- und/oder Verbindungsanbieter, um dieses Problem zu beheben. Sie können die folgenden Schritte ausführen:

Prüfen Sie, ob sein Transceiver funktioniert.
Führen Sie eine harte Schleife im Meet-Meroom (MMR) aus, um zu prüfen, ob die Lichtintensität auf seinem Gerät wie erwartet funktioniert.
Prüfen Sie, ob die Probleme auf seiner Seite oder auf der Google-Seite liegen. Die beste Möglichkeit zum Isolieren der Schnittstelle ist die Platzierung einer bidirektionalen Schleife am Abschlusspunkt. Die Schnittstellen auf jeder Seite übertragen das Licht zum Abschlusspunkt, wo es in einer Schleife zu sich selbst zurückgeführt wird. Die fehlerhafte Seite ist die Seite des Abschlusspunkts, die nicht sauber ist.
Säubern Sie die Fasern auf seiner Seite und platzieren Sie sie wieder.

Sie können keine MED-Werte über eine Ebene-3-Partner Interconnect-Verbindung senden und abrufen

Wenn Sie eine Partner Interconnect-Verbindung verwenden, bei der sich ein Ebene-3-Dienstanbieter um das BGP kümmert, kann Cloud Router weder MED-Werte von Ihrem lokalen Router abrufen noch an diesen senden. Dies liegt daran, dass MED-Werte keine autonomen Systeme durchlaufen können. Sie können bei dieser Verbindungsart keine Routenprioritäten für Routen festlegen, die von Cloud Router für Ihren lokalen Router beworben werden. Darüber hinaus können Sie keine Routenprioritäten für Routen festlegen, die vom lokalen Router für Ihr VPC-Netzwerk beworben werden.

IPv6-Traffic funktioniert nicht, nachdem der Stacktyp eines Anhangs in Dual-Stack geändert wurde

Rufen Sie den Status des Cloud Routers auf und prüfen Sie, ob status: UP angezeigt wird.

Wenn BGP nicht aktiv ist, gehen Sie so vor:
1. Prüfen Sie, ob Ihr lokaler Router (oder der Router Ihres Partners, wenn Sie einen Ebene-3-Partner verwenden) mit einer IPv6-BGP-Sitzung konfiguriert ist und dass die Sitzung die richtigen IPv6-Adressen verwendet.
2. Rufen Sie die BGP-Sitzungskonfiguration auf und prüfen Sie, ob bgpPeers.enable für Ihren Cloud Router 'TRUE' anzeigt.
Wenn BGP aktiv ist, rufen Sie die Cloud Router-Routen auf, um zu prüfen, ob die erwarteten IPv6-best_routes angezeigt werden.

Wenn die erwartete best_routes nicht angezeigt wird, prüfen Sie, ob Ihr lokaler Router (oder der Router Ihres Partners, wenn Sie einen Ebene-3-Partner verwenden) mit den richtigen IPv6-Routen konfiguriert ist.

Alle anderen Probleme

Weitere Unterstützung erhalten Sie von Ihrem Dienstanbieter. Ihr Dienstanbieter kontaktiert gegebenenfalls Google, um Probleme im Zusammenhang mit der Google-Seite des Netzwerks zu beheben.

HA VPN über Cloud Interconnect

Wenn Sie HA VPN über Cloud Interconnect bereitstellen, müssen Sie zwei Betriebsebenen erstellen:

Die Cloud Interconnect-Ebene mit den VLAN-Anhängen und dem Cloud Router für Cloud Interconnect.
Die HA VPN-Ebene, die die HA VPN-Gateways und -Tunnel sowie den Cloud Router für HA VPN umfasst.

Jede Ebene benötigt einen eigenen Cloud Router:

Der Cloud Router für Cloud Interconnect wird ausschließlich zum Austausch von VPN-Gateway-Präfixen zwischen den VLAN-Anhängen verwendet. Dieser Cloud Router wird nur von den VLAN-Anhängen der Cloud Interconnect-Ebene genutzt. Er kann nicht auf der HA VPN-Ebene angewendet werden.
Der Cloud Router für HA VPN tauscht Präfixe zwischen Ihrem VPC-Netzwerk und Ihrem lokalen Netzwerk aus. Sie konfigurieren den Cloud Router für HA VPN und seine BGP-Sitzungen auf die gleiche Weise wie für eine reguläre HA VPN-Bereitstellung.

Sie erstellen die HA VPN-Ebene zusätzlich zur Cloud Interconnect-Ebene. Daher muss für die HA VPN-Ebene die Cloud Interconnect-Ebene, die entweder auf Dedicated Interconnect oder Partner Interconnect basiert, ordnungsgemäß konfiguriert und betriebsbereit sein.

Fehlerbehebung bei einer HA VPN über die Cloud Interconnect-Bereitstellung Nachdem Sie geprüft haben, ob Cloud Interconnect ordnungsgemäß funktioniert, beheben Sie Fehler in der HA VPN-Ebene.

Verschlüsselter VLAN-Anhang kann nicht erstellt werden

Die Erstellung des verschlüsselten VLAN-Anhangs schlägt mit der folgenden Fehlermeldung fehl:

  Cannot create an interconnect attachment with IPSEC encryption.
  IPSEC encryption can only be used with a provisioned interconnect attachments
  that have Dataplane version 2.

Gehen Sie folgendermaßen vor, um dieses Problem zu beheben:

In der Tabelle Alle Colocations-Einrichtungen sehen Sie, in welchen Regionen das Erstellen von Anhängen in Dataplane v2 unterstützt wird.
Wenn die Region nicht aufgeführt ist, erstellen Sie den Anhang in einer unterstützten Region neu.

BGP-Sitzung für den Cloud Router für Cloud Interconnect kann nicht eingerichtet werden

Führen Sie den folgenden Befehl aus, um festzustellen, ob die mit dem VLAN-Anhang verknüpfte BGP-Sitzung ausgefallen ist:

   gcloud compute routers get-status INTERCONNECT_ROUTER_NAME

Ersetzen Sie INTERCONNECT_ROUTER_NAME durch den Namen des Cloud Routers, den Sie für die Cloud Interconnect-Ebene Ihrer HA VPN über Cloud Interconnect-Bereitstellung erstellt haben.

Gehen Sie folgendermaßen vor, um dieses Problem zu beheben:

Führen Sie die Schritte unter Verbindungen testen und Diagnose abrufen aus, um zu prüfen, ob die zugrunde liegende Cloud Interconnect-Verbindung fehlerfrei ist.
Prüfen Sie, ob die BGP-Sitzungsschnittstelle auf den richtigen Anhang verweist.
Prüfen Sie die IP-Adressen, die für die BGP-Sitzungsschnittstelle sowohl auf dem Cloud Router als auch auf dem lokalen Router konfiguriert sind.
Überprüfen Sie, ob die ASN-Nummern sowohl auf dem Cloud Router als auch auf dem lokalen Router ordnungsgemäß konfiguriert sind.
Prüfen Sie, ob die Cloud Interconnect-Verbindung und der VLAN-Anhang den Status admin-enabled haben.

HA VPN-Tunnel kann nicht eingerichtet werden

Führen Sie den folgenden Befehl aus, um den Tunnelstatus zu prüfen:

gcloud compute vpn-tunnels describe VPN_TUNNEL_NAME

Ersetzen Sie VPN_TUNNEL_NAME durch den Namen des HA VPN-Tunnels.

Gehen Sie folgendermaßen vor, um dieses Problem zu beheben:

Da der VPN-Tunnel über einen VLAN-Anhang weitergeleitet wird, prüfen Sie, ob die mit dem VLAN-Anhang verknüpfte BGP-Sitzung eingerichtet ist. Wenn nicht, finden Sie weitere Informationen unter BGP-Sitzung für den Cloud Router für Cloud Interconnect kann nicht eingerichtet werden.
Prüfen Sie, ob die Tunnel-PSK und -Chiffren sowohl auf den Cloud VPN-Gateways als auch auf den lokalen VPN-Gateways korrekt konfiguriert sind.
Prüfen Sie, ob die BGP-Ankündigung des lokalen Routers die Adressen des lokalen VPN-Gateways enthält. Ist dies nicht der Fall, passen Sie die BGP-Konfiguration des lokalen Routers an, um die Adressen zu bewerben.
Prüfen Sie, ob die Routen zu lokalen VPN-Gateways aufgrund von Konflikten mit vorhandenen BGP-Routen nicht gelöscht wurden. Wenn Konflikte auftreten, passen Sie die VPN-Gateway-Adressen oder beworbenen Routen an.
Prüfen Sie, ob die BGP-Ankündigung von Cloud Router die HA VPN-Gateway-Adressen enthält. Prüfen Sie dies vom lokalen Router oder im Feld advertisedRoutes des BGP-Peers. Führen Sie den folgenden Befehl aus, um das Feld advertisedRoutes aufzurufen:
```
gcloud compute routers get-status INTERCONNECT_ROUTER_NAME
```
Ersetzen Sie INTERCONNECT_ROUTER_NAME durch den Namen des Cloud Routers, den Sie für die Cloud Interconnect-Ebene Ihrer HA VPN über Cloud Interconnect-Bereitstellung erstellt haben.

Wenn die HA VPN-Gateway-Adressen nicht beworben werden, achten Sie darauf, dass die VLAN-Anhänge dem verschlüsselten Cloud Interconnect-Router zugeordnet sind. Prüfen Sie, ob jeder VLAN-Anhang mit den erwarteten regionalen internen IPv4-Adressen (--ipsec-internal-addresses) konfiguriert ist.

BGP-Sitzung für den Cloud Router für HA VPN kann nicht eingerichtet werden

Führen Sie den folgenden Befehl aus, um zu prüfen, ob die mit dem VLAN-Anhang verknüpfte BGP-Sitzung ausgefallen ist:

gcloud compute routers get-status VPN_ROUTER_NAME

Ersetzen Sie VPN_ROUTER_NAME durch den Namen des Cloud Routers, den Sie für die HA VPN-Ebene Ihrer HA VPN über Cloud Interconnect-Bereitstellung erstellt haben.

Gehen Sie folgendermaßen vor, um dieses Problem zu beheben:

Da der BGP-Traffic über den VPN-Tunnel weitergeleitet wird, prüfen Sie, ob der VPN-Tunnel eingerichtet ist. Wenn nicht, folgen Sie der Anleitung unter HA VPN-Tunnel kann nicht eingerichtet werden.
Prüfen Sie, ob die BGP-Sitzungsschnittstelle für den Cloud Router auf den richtigen VPN-Tunnel verweist.
Überprüfen Sie, ob die IP-Adressen der BGP-Sitzungsschnittstelle sowohl auf dem Cloud Router als auch auf dem lokalen VPN-Gerät korrekt konfiguriert sind.
Prüfen Sie, ob die ASN-Nummern sowohl auf dem Cloud Router als auch auf dem lokalen Router ordnungsgemäß konfiguriert sind.

VPC-Traffic erreicht keine lokalen Netzwerke oder umgekehrt

Der von einer VM generierte Traffic, z. B. von ping oder iperf, kann das lokale Netzwerk nicht erreichen, oder das lokale Netzwerk kann den von einer VM generierten Traffic nicht erreichen.

Gehen Sie folgendermaßen vor, um dieses Problem zu beheben:

Da der VM-Traffic über den VPN-Tunnel weitergeleitet wird, muss die Route von der VM zum VPN-Tunnel vom Cloud Router gesendet werden.
Prüfen Sie, ob die Cloud Router-Sitzung für HA VPN eingerichtet ist. Wenn nicht, finden Sie weitere Informationen unter BGP-Sitzung für Cloud Router für HA VPN kann nicht eingerichtet werden.

Paketverlust oder geringer Durchsatz

Traffic von VMs in VPC-Netzwerken zu lokalen Netzwerken oder Traffic von lokalen Netzwerken zu VPC-Netzwerken wird unterbrochen.

Sie beobachten Paketverluste oder einen niedrigen Durchsatz über ping, iperf und andere Netzwerkmonitoringtools.

Gehen Sie folgendermaßen vor, um dieses Problem zu beheben:

Prüfen Sie, ob der VLAN-Anhang mit Traffic überlastet ist. Ist dies der Fall, verteilen Sie den Traffic auf mehr VLAN-Anhänge oder aktualisieren Sie die Kapazität des Anhangs.
Prüfen Sie, ob HA VPN mit Traffic überlastet ist Erstellen Sie in diesem Fall zusätzliche VPN-Tunnel über den VLAN-Anhang, um den Traffic neu zu verteilen.
Achten Sie darauf, dass es keine unerwarteten oder plötzlichen Trafficspitzen oder stoßweisen Traffic gibt. TCP-Streams können von anderen Streams betroffen sein, z. B. stoßweisem UDP-Traffic.
Prüfen Sie, ob Pakete, die den Tunnel-MTU überschreiten, fragmentiert sind. Achten Sie darauf, dass die MTU mit Ihren VLAN-Anhängen korrekt festgelegt ist und dass der UDP-Traffic kein MSS-Clamping hat.

Verschlüsselten VLAN-Anhang kann nicht gelöscht werden

Sie erhalten die folgende Fehlermeldung, wenn Sie versuchen, einen verschlüsselten VLAN-Anhang für Dedicated Interconnect oder Partner Interconnect zu löschen:

ResourceInUseByAnotherResourceException

Achten Sie zur Behebung dieses Problems darauf, dass Sie zuerst alle HA VPN-Gateways und -Tunnel gelöscht haben, die dem verschlüsselten VLAN-Anhang zugeordnet sind. Weitere Informationen finden Sie unter HA VPN über Cloud Interconnect löschen.

Nicht übereinstimmende IP-Adresstypen für verschlüsselte VLAN-Anhänge

Wenn Sie versuchen, ein HA VPN-Gateway zur Verwendung in einer HA VPN über Cloud Interconnect-Bereitstellung zu erstellen, wird der folgende Fehler angezeigt:

One of the VLAN attachments has private IP address type, while the other one
has public IP address type; they must have same IP address type.

Dieser Fehler tritt auf, wenn Sie zwei verschlüsselte VLAN-Anhänge für ein HA VPN-Gateway angeben. Diese haben unterschiedliche IP-Adressierungsschemas für die HA VPN-Tunnelschnittstellen. Die IP-Adresstypen müssen in beiden VLAN-Anhängen übereinstimmen.

Geben Sie während der VPN-Gateway-Erstellung VLAN-Anhänge an, die entweder private IP-Adressen oder beide öffentliche IP-Adressen verwenden. Wenn dieser Fehler beim Erstellen eines VPN-Gateways auftritt, versuchen Sie, den VLAN-Anhang mit dem richtigen Adresstyp neu zu erstellen.

Fehlender VLAN-Anhang von HA VPN-Gateway-Schnittstelle

Bei der Bereitstellung für HA VPN über Cloud Interconnect muss das HA VPN-Gateway einen verschlüsselter VLAN-Anhang für seine beide Schnittstellen haben.

Wenn Sie nur einen VLAN-Anhang angeben, wird der folgende Fehler angezeigt:

VPN Gateway should have VLAN attachment specified in both interfaces or in none.

Erstellen Sie das HA VPN-Gateway und geben Sie zwei VLAN-Anhänge an, um dieses Problem zu beheben.

Ungültiger VLAN-Anhangstyp

Verschlüsselte VLAN-Anhänge müssen den Typ DEDICATED oder PARTNER haben.

Wenn Sie für einen verschlüsselten VLAN-Anhang einen ungültigen Typ angeben, wird folgende Fehlermeldung angezeigt:

VLAN attachment should have type DEDICATED or PARTNER.

Um dieses Problem zu beheben, erstellen Sie nur verschlüsselte VLAN-Anhänge mit dem Typ DEDICATED oder PARTNER.

Falscher MTU-Wert für VLAN-Anhang

Beim Erstellen eines verschlüsselten VLAN-Anhangs für Dedicated Interconnect wird die folgende Fehlermeldung angezeigt:

Wrong MTU value [mtuValue] for VLAN attachment.
The supported MTU for IPsec packets for HA VPN over Cloud Interconnect is 1440.

Erstellen Sie den Anhang mit dem richtigen Wert 1440 (Standardwert) neu, um dieses Problem zu beheben.