Fehlerbehebung bei Konnektivitätstests

Beachten Sie die folgenden Hinweise, um häufige Probleme mit Konnektivitätstests zu beheben.

Weitere Informationen zu Konnektivitätstests finden Sie in der Übersicht.

Informationen zum Interpretieren der Zustände in Konfigurationsanalysen von Konnektivitätstests finden Sie in der Referenz zu den Zuständen der Konfigurationsanalyse.

Allgemeine Probleme

Es dauert zu lange, bis die Testergebnisse angezeigt werden.

Bei Konnektivitätstests wird der neueste Snapshot einer VPC-Netzwerkkonfiguration (Virtual Private Cloud) abgefragt. Das Abrufen der Ergebnisse kann hierbei einige Zeit dauern. Weitere Informationen finden Sie unter Erwartete Antwortzeiten für Abfragen.

Wenn beim Ausführen von Konnektivitätstests lange oder instabile Latenzen auftreten, melden Sie dem Support das Problem und beschreiben Sie, wie es reproduziert werden kann.

Bei der Konfigurationsanalyse meines Tests wird die von mir ausgeführte Konfigurationsänderung nicht übernommen.

Nachdem Sie eine Konfigurationsänderung für die Google Cloud-Ressourcen in Ihrem Testpfad vorgenommen haben, können Sie mit der Konfigurationsanalyse des Tests diese Änderung prüfen. Es dauert allerdings zwischen 20 und 120 Sekunden, bis für die Konnektivitätstests eine Änderung der Konfiguration vorgenommen wird und dies in die Analyse einfließt. Achten Sie auf ausreichend Wartezeit zwischen der Änderung der Konfiguration und der Ausführung der Tests.

Bestimmte Konfigurationstypen können länger dauern. Wenn Ihre Konfigurationsänderung nach einem längeren Zeitraum nicht von Konnektivitätstests bestätigt wird und reproduzierbar ist, melden Sie dem Support das Problem und beschreiben Sie, wie es reproduziert werden kann.

Diese Verzögerung gilt nicht für die dynamische Prüfung. Daher kann es zu einer vorübergehenden Abweichung zwischen den Ergebnissen der dynamischen Prüfung und der Konfigurationsanalyse kommen. Wenn Sie beispielsweise eine Firewallregel erstellen, reagiert die dynamische Prüfung normalerweise sofort auf die neue Regel. Möglicherweise müssen Sie aber 20 Sekunden oder länger warten, bevor die Konfigurationsanalyse die Firewallregel mit den anderen Ressourcen im Testpfad auswerten kann.

Probleme mit dem Teststatus

Ich kann nicht auf Details zu einer hierarchischen Firewallrichtlinie zugreifen.

Der Trace für Ihren Test verweist eventuell auf eine hierarchische Firewallrichtlinie, für die Sie keine Aufrufberechtigung haben.

Sie können aber auch ohne diese Berechtigung die Richtlinienregeln anzeigen lassen, die für Ihr VPC-Netzwerk gelten. Weitere Informationen finden Sie unter Effektive Firewallregeln in der Übersicht der hierarchischen Firewallrichtlinien.

Der Zugriff auf hierarchische Firewallrichtlinien wird auf Organisations- und Ordnerebene definiert. Ausführliche Informationen zu den Berechtigungen, die Sie zum Aufrufen dieser Richtlinien benötigen, finden Sie in der Übersicht der hierarchischen Firewallrichtlinien unter IAM-Rollen (Identity and Access Management).

Mein Test zeigt den endgültigen Zustand Deliver an, aber die Verbindung ist unterbrochen.

In einigen Fällen weist die Konfigurationsanalyse darauf hin, dass ein Quell- und Zielendpunkt erreichbar sind. In der Praxis kann es jedoch vorkommen, dass die Verbindung zwischen den beiden Endpunkten unterbrochen wird, oder dass die dynamische Prüfung einen Paketverlust von 100 % anzeigt.

Um diese Situation zu verstehen, beachten Sie, dass Konnektivitätstests zwei Arten von Analysen verwenden: eine Konfigurationsanalyse, die Probleme in aktiven Konfigurationen innerhalb Ihres Projekts erkennt, und die dynamische Prüfung, die Prüfungen auf der Datenebene sendet.

Ein letzter Konfigurationsstatus für Deliver bedeutet, dass Verbindungstests keine Konfigurationsprobleme erkannt haben. Es können jedoch immer noch Datenpfadprobleme vorhanden sein, die möglicherweise zu Konnektivitätsproblemen führen. Beachten Sie bei der Fehlerbehebung Folgendes:

  • Bei der Quell- oder Ziel-VM gibt es Probleme mit dem Betriebssystem des Gasts, z. B. Gast-OS-Plastik, einen nicht initialisierten Netzwerkschnittstellen-Controller (NIC), oder nicht kompatible Netzwerktreiber. Prüfen Sie den VM-Status und die NIC-Konfiguration.
  • Ein weit verbreitetes Problem betrifft die Datenebene des Netzwerks. Prüfen Sie das Leistungsdashboard Ihres Projekts und achten Sie insbesondere auf den Paketverlust für das entsprechende Zonenpaar. Prüfen Sie außerdem das Google Cloud-Status-Dashboard.
  • In Ihrem Netzwerk sind sporadische Netzwerkprobleme aufgetreten, z. B. Probleme mit der Weitergabe von Netzwerkkonfigurationen an bestimmte Google Cloud-Entitäten. Führen Sie den Test nach einer Verzögerung von fünf Minuten noch einmal aus. Wenn das Problem weiterhin besteht, beenden Sie die Quell- oder Ziel-VM, wie unter Instanz starten und beenden erläutert, und führen Sie den Test dann noch einmal aus.

Mein Test hat bei der Konfigurationsanalyse das Gesamtergebnis Undetermined zurückgegeben.

Ein Gesamtergebnis von Undetermined bedeutet, dass die Konfigurationsanalyse die Konnektivität nicht bestimmen konnte. Dieses Ergebnis kann aus einem der folgenden Gründe angezeigt werden:

  • Ein Berechtigungsfehler ist aufgetreten. Beispielsweise hat der Nutzer möglicherweise keinen Lesezugriff auf alle im Test benannten Ressourcen.
  • Ein interner Fehler ist aufgetreten.
  • Das Analysetool hat ein ungültiges oder nicht unterstütztes Argument erhalten oder konnte keinen bekannten Endpunkt identifizieren.
  • Sie versuchen, eine Route zu bestätigen, die über Google Cloud hinaus erweitert wird. Konnektivitätstests haben keinen Zugriff auf Netzwerkkonfigurationen außerhalb von Google Cloud.

Mein Test hat bei der Konfigurationsanalyse das Gesamtergebnis Ambiguous zurückgegeben.

Das Gesamtergebnis zur Erreichbarkeit Ambiguous bedeutet, dass die Konnektivitätstests mehrere Traces zurückgegeben haben und ein gemischter endgültiger Zustand vorliegt.

In der folgenden Tabelle sind einige häufige Gründe für diesen Zustand sowie entsprechende Korrekturen aufgeführt.

Grund Beispiel Lösung
Der Quellspeicherort ist nicht eindeutig. Sie haben eine interne Quell-IP-Adresse, aber nicht das VPC-Netzwerk angegeben, in dem sich die IP-Adresse befindet. Eine interne Quell-IP-Adresse ist eine Adresse, auf die Sie nicht über das Internet zugreifen können. Da auf diese Adresse von mehreren VPC-Netzwerken aus zugegriffen werden kann, können Konnektivitätstests von jedem Standort aus einen Trace starten. Aktualisieren Sie den Test mit dem VPC-Netzwerk, in dem sich diese IP-Adresse befindet.
Der Trace hat mehrere mögliche Ziele. Sie haben das Trace-Ziel als Load-Balancer-VIP festgelegt, die mehrere Back-Ends hat und bei der nicht alle Back-Ends erreichbar sind. Finden Sie heraus, warum dieser Fehler auftritt, und beheben Sie die Probleme wie erforderlich, bevor Sie den Test noch einmal ausführen.

Mein Test hat bei der Konfigurationsanalyse das Gesamtergebnis Abort mit der Meldung Invalid Argument zurückgegeben.

Einige häufige Gründe für eine Invalid Argument-Nachricht sind die folgenden:

  • Die von Ihnen angegebene IP-Adresse wird nicht unterstützt. Beispiele sind eine Loopback-Adresse, eine Multicast-IP-Adresse oder eine IPv6-Adresse zu einer VM-Instanz, der nur eine IPv4-Adresse zugewiesen ist.
  • Die VM-Instanz oder das angegebene Netzwerk ist nicht vorhanden. Dies kann der Fall sein, wenn die VM-Instanz oder das VPC-Netzwerk beim Erstellen des Tests gelöscht wurde.

Bei Verwendung der Network Management API wird die Meldung Invalid Argument in der Regel aus einem der folgenden Gründe zurückgegeben:

  • Ein falsch geschriebener Name oder falscher Speicherort für die VM oder den Netzwerk-URI.
  • Eine falsch angegebene Projekt-ID. Dieser Fehler tritt auf, wenn Sie den Projektnamen anstelle der Projekt-ID verwendet haben.
  • Eine fehlende Übereinstimmung zwischen der angegebenen internen IP-Adresse und dem ausgewählten Netzwerk. Obwohl die Google Cloud Console für Konnektivitätstests eine strenge Validierung der angegebenen Compute Engine-Instanz, des Netzwerks und des Projekts durchführt, kann dieser Typ von fehlender Übereinstimmung dennoch auftreten.

Das Ergebnis der Konfigurationsanalyse ist Packet could not be delivered, aber bei der dynamischen Prüfung wird angezeigt, dass alle Pakete zugestellt wurden.

Diese vermeintliche Diskrepanz kann aus verschiedenen Gründen auftreten. Beachten Sie die folgenden möglichen Ursachen und Lösungen:

  • Die neuesten Änderungen an der VPC-Netzwerkkonfiguration haben Inkonsistenzen zwischen der Konfigurationsanalyse und aktiven Tests ergeben. Führen Sie den Test noch einmal aus. Achten Sie dabei darauf, dass sich die Netzwerkkonfiguration nicht direkt vor dem Test oder während des Tests ändert.

  • Es gibt Probleme mit der sporadischen Netzwerkprogrammierung. Beenden und starten Sie die Quell- oder Ziel-VM (siehe Instanz beenden und starten) und führen Sie den Test noch einmal aus.

Das Ergebnis der Konfigurationsanalyse ist Packet could be delivered, die dynamische Prüfung gibt jedoch einen teilweisen Paketverlust an.

Diese vermeintliche Diskrepanz kann aus verschiedenen Gründen auftreten. Mögliche Ursachen und Lösungen:

  • Die Quell- oder Ziel-VM wird gedrosselt und die maximal zulässige Bandbreite für ausgehenden Traffic überschritten. Analysieren Sie das VM-Trafficvolumen, indem Sie die Seite VM-Instanzdetails aufrufen und sich die Details auf dem Tab Monitoring ansehen. Sehen Sie sich den Messwert Netzwerk-Bytes an und vergleichen Sie ihn mit den für den Maschinentyp unter Netzwerkbandbreite beschriebenen Bandbreitenlimits.

  • Ein weit verbreitetes Problem betrifft die Datenebene des Netzwerks. Prüfen Sie das Dashboard zur Leistungsüberwachung Ihres Projekts und achten Sie insbesondere auf das relevante Zonenpaar. Prüfen Sie außerdem das Google Cloud-Status-Dashboard.

Das Konfigurationsanalyseergebnis lautet Packet could be delivered und die dynamische Überprüfung zeigt die vollständige Bereitstellung, aber bei meiner Anwendung geht der Verlust verloren

Diese vermeintliche Diskrepanz kann aus verschiedenen Gründen auftreten. Mögliche Ursachen und Lösungen:

  • Traffic wird vom Gastbetriebssystem möglicherweise blockiert (z. B. durch interne Firewallregeln). Achten Sie darauf, dass der Traffic nicht blockiert wird, und versuchen Sie es dann noch einmal.
  • Datenquellpakete durchlaufen möglicherweise einen anderen Netzwerkpfad als die dynamischen Überprüfungsprüfungen. Prüfen Sie, ob die Netzwerkverbindung wiederhergestellt wird. Versuchen Sie es beispielsweise mit einem anderen Quellport.
  • Bei der dynamischen Überprüfung wird ein unidirektionaler Paketverlust erkannt. In Ihrem Fall könnten beim Rückgabepfad Paketverluste auftreten. Führen Sie gegebenenfalls einen Test in die entgegengesetzte Richtung durch.

Die Testergebnisse enthalten kein Ergebnis der dynamischen Prüfung.

Nicht alle Konfigurationen, die von Konnektivitätstests unterstützt werden, können dynamisch geprüft werden. Sorgen Sie dafür, dass der Test die für dynamische Prüfungen erforderlichen Bedingungen erfüllt, wie in der Übersicht beschrieben.

Die Network Management API hat INTERNAL_ERROR zurückgegeben.

Das sollte normalerweise nicht passieren. Wenn dies geschieht, melden Sie dem Support das Problem und beschreiben Sie, wie es reproduziert werden kann.

Probleme mit der Google Cloud Console

Die Google Cloud Console für Konnektivitätstests ist abgestürzt.

Die Google Cloud Console sollte normalerweise nicht abstürzen. Wenn dies geschieht, melden Sie dem Support das Problem und beschreiben Sie, wie es reproduziert werden kann.

Nächste Schritte