Diese Seite wurde von der Cloud Translation API übersetzt.

Fehlerbehebung bei der Netzwerkverbindung

Auf der Seite finden Sie Informationen zur Behebung häufiger Netzwerkprobleme.

Fehlerbehebung beim Netzwerk-Bootstrap

In diesem Abschnitt werden einige der häufigsten Fehler beschrieben, die beim Abschließen des Netzwerk-Bootstrapping-Prozesses auftreten können.

Fehler bei der Konfigurationsgenerierung

Zum Abschließen der Netzwerkinstallation werden Netzwerkkonfigurationsdateien auf dem Bootstrapper-Computer installiert. Wenn ein Fehler bei der Konfigurationsgenerierung auftritt, prüfen Sie die YAML-Dateien unter /root/cellcfg auf die fehlgeschlagene Switch-Konfiguration.

Bootstrap bleibt beim Ping in Phase 1 hängen

Wenn der Netzwerk-Bootstrap-Prozess beim Ping in Phase 1 hängen bleibt, führe die folgenden Schritte aus, um das Problem zu beheben:

Rufen Sie den Speicherort der generierten Switch-Konfiguration aus dem Bootstrap-Log ab: /tmp/network-bootstrap/ID
Suchen Sie in der Konfigurationsdatei des Switches mit der IP-Adresse nach dem Switch, der nicht reagiert.
Melden Sie sich am Switch an und prüfen Sie das Betriebsprotokoll.

Bootstrap bleibt beim Ping in Phase 2 hängen

Wenn der Netzwerk-Bootstrap-Prozess beim Ping in Phase 2 hängen bleibt, gehen Sie so vor, um das Problem zu beheben:

Rufen Sie den Speicherort der generierten Switch-Konfiguration aus dem Bootstrap-Log ab: /tmp/network-bootstrap/ID
Suchen Sie den blockierten Switch anhand der Management-IP-Adresse in der Switch-Konfigurationsdatei.
Prüfen Sie die Konfiguration des Verwaltungsswitch auf potenzielle Zugriffsprobleme im Verwaltungsnetzwerk.

Fehlerbehebung beim Abgleich von Netzwerkdaten an Tag 2

Übersicht

GDC verwendet die von Cisco NX-OS bereitgestellte Funktion zum Ersetzen der Konfiguration während der Switch-Abstimmung, um die aktive Konfiguration in einem Switch durch eine völlig neue Konfiguration zu ersetzen. Die Schritte, die beim Ersetzen der Konfiguration intern ausgeführt werden, sind:

Berechnet die Differenz zwischen der aktuellen Konfiguration und der vom Nutzer bereitgestellten Konfiguration.
Generiert eine Patchdatei, die den Unterschied zwischen der aktuellen Konfiguration und der Eingabekonfiguration enthält.
Führt eine semantische Validierung der Patch-Datei durch.
Wendet die Patchdatei an.
Prüft, ob die Patchdatei korrekt hinzugefügt wurde, indem die laufende Konfiguration mit der Eingabekonfiguration verglichen wird. Andernfalls wird die vorherige Konfiguration wiederhergestellt.
Es wird ein Zeitgeber gestartet, vor dessen Ablauf der Befehl „configure replace commit“ ausgeführt werden muss. Andernfalls wird die neue Konfiguration zurückgesetzt.

Ein Fehler kann in jedem der vorherigen Schritte auftreten, am häufigsten jedoch in den Schritten 3, 4 und 1. Im Folgenden finden Sie einige Möglichkeiten zur Fehlerbehebung bei der Konfiguration des Ersetzens.

Allgemeine Schritte zur Fehlerbehebung

Gesamtstatus des Schalters prüfen

Führen Sie auf dem Root-Administratorserver kubectl describe aggswitch/mb-ab-aggsw01 -n gpc-system aus (ersetzen Sie den Schalternamen durch den erforderlichen Schalternamen).

Das Kubernetes-Objekt „switch“ im Administratorcluster des Stammclusters zeigt die Ausführungs- und Überprüfungsprotokolle in der Objektbeschreibung an, wenn der letzte Konfigurationsersatz fehlschlägt.

Status des letzten Konfigurationsersetzungsvorgangs prüfen

Führen Sie in der Switch-Konsole show config-replace status aus:

Der Status enthält die folgenden Informationen:

Gesamtstatus wie „Abgeschlossen“ oder „Fehler“
Gibt an, ob die Konfigurationsersetzung übernommen wurde oder noch darauf wartet.
Start- und Endzeit des letzten Vorgangs zum Ersetzen der Konfiguration

Prüfen, welche Konfigurationen durch den letzten Konfigurationsersetzungsvorgang angewendet wurden

Führen Sie in der Switch-Konsole show config-replace log exec aus.

Das Ausführungsprotokoll für den Konfigurationsersatz enthält die Protokolle, die beim Anwenden der Konfigurationen generiert wurden, die durch den Konfigurationsersatzvorgang als Patchkonfiguration bestimmt wurden, d.h. die Differenz zwischen der laufenden Konfiguration und der Eingabekonfiguration.

Beachten Sie, dass diese Logs manchmal Fehler enthalten, die vom Vorgang zum Ersetzen der Konfiguration ignoriert werden und nicht dazu führen, dass das Ersetzen der Konfiguration insgesamt fehlschlägt. Sofern ein Fehler nicht die letzte Zeile des Ausführungsprotokolls im Abschnitt „Patch wird ausgeführt“ ist, ist er wahrscheinlich nicht die Ursache für einen fehlgeschlagenen Konfigurationsersatz.

Prüfen, ob die Überprüfung des letzten Konfigurationsersetzungsvorgangs erfolgreich war

Führen Sie in der Switch-Konsole show config-replace log verify aus.

Nach dem Ausführungsschritt „Konfigurationsersetzung“ vergleicht der Vorgang „Konfigurationsersetzung“ die neue aktive Konfiguration des Switches mit der Eingabekonfiguration. Diese Konfigurationen müssen übereinstimmen. Wenn nicht, schlägt der Konfigurationsersatz fehl und die Konfiguration wird auf die vorherige Konfiguration zurückgesetzt.

Das Überprüfungsprotokoll besteht aus zwei Abschnitten.

Configuration To Be Added Missing in Running-config: Hier werden die Konfigurationen aufgeführt, die in der Eingabekonfiguration, aber nicht in der neuen laufenden Konfiguration vorhanden sind.
Configuration To Be Removed Present in Running-config: Hier werden die Konfigurationen aufgeführt, die in der neuen laufenden Konfiguration, aber nicht in der Eingabekonfiguration vorhanden sind.

Alle auf dem Switch ausgeführten Befehle prüfen

Führen Sie in der Switch-Konsole show accounting log start-time 2022 Sep 13 20:00:00 aus und ersetzen Sie die Startzeit durch die gewünschte Startzeit.

In den Abrechnungsprotokollen wird jeder Befehl angezeigt, der auf dem Switch ausgeführt wird. Diese Protokolle können hilfreich sein, um zu sehen, welche Befehle über NXAPI oder manuell auf dem Switch ausgeführt wurden. Außerdem können Sie sehen, wann genau die einzelnen Konfigurationsersetzungsvorgänge ausgeführt wurden und wie oft sie ausgeführt wurden.

Prüfen, welche NX-API-Aufrufe an den Switch gesendet wurden und von wo

Führen Sie in der Switch-Konsole show nxapi-server logs aus.

NX-API-Logs enthalten die Logs zu NXAPI-Aufrufen, die an den Switch gesendet wurden. Da unser Automatisierungs-Stack aus vielen Gründen NXAPI-Aufrufe an die Switches sendet, unter anderem um die Konfiguration zu ersetzen, ist es nützlich zu sehen, welche NXAPI-Aufrufe gesendet wurden und woher sie kamen.

Fehlerbehebung bei Interconnect

Interconnect API – Übersicht

Mit der Interconnect API werden die externen Verbindungen für eine GDC-Rechenzentrumszelle konfiguriert. Es gibt drei Arten von Interconnect-Verbindungen:

Data Center Interconnect (DCI): Verbindung von einem GDC-Rechenzentrum zu einem anderen GDC-Rechenzentrum über die Border-Leaf-Switches der Datenebene.
Customer Peering Interconnect (CPI): Interconnect von einem GDC-Rechenzentrum zum ORG-Netzwerk über die Border-Leaf-Switches der Datenebene.
Network Operation Center (NOC): Verbindung von einem GDC-Rechenzentrum zum Network Operation Center über die Border-Leaf-Switches der Datenebene und die Management-Aggregations-Switches.

Die folgenden API-Objekte sind vorhanden:

InterconnectLink: Dieses API-Objekt definiert die physischen Ports, die mit externen Switches verbunden sind.
InterconnectAttachment: Dieses API-Objekt definiert die Anhänge, die zusätzlich zur konfigurierten InterconnectLink vorhanden sind. Die Informationen in den Anhängen definieren Folgendes:
1. Interconnect-Typ
2. BGP-Informationen
3. Informationen zur VLAN-ID
4. Konfigurierte Routenrichtlinien
RoutePolicy: Dieses API-Objekt modelliert die Richtlinien, die zum Freigeben von Routen für BGP-Peers für Interconnect verwendet werden.

Fehlerbehebung

Status von InterconnectLink und InterconnectAttachment prüfen

Die API-Objekte InterconnectLink und InterconnectAttachment enthalten viele Informationen, die Aufschluss über den aktuellen Status geben können.

InterconnectLink: Die folgenden Informationen werden für jeden physischen Port bereitgestellt, der mit externen Switches verbunden ist.
1. Up: Statusinformationen dazu, ob der Port aktiv oder inaktiv ist.
2. DownReason: Grund für den Ausfall des Ports.
InterconnectAttachment: Die folgenden Informationen werden für jede der konfigurierten Interconnect-Anhängen bereitgestellt.
1. BGPStatus: Status der BGP-Sitzung, z. B. „Up“ oder „Down“.
2. UpTime: Zeitstempel der letzten Aktivierung der BGP-Sitzung.
3. PrefixCounters: Zähler, die die Gesamtzahl der Präfixe Received, Sent und Withdrawn anzeigen.

Routenrichtlinien prüfen

RoutePolicy definiert eine Liste von Präfixen und die auszuführende Aktion, z. B. „Zulassen“ oder „Ablehnen“. Listen Sie alle Routenrichtlinien auf, die der InterconnectAttachment-Ressource zugeordnet sind, um zu prüfen, ob die IP-Adressen Teil gültiger RoutePolicy sind.

BGP-Routenpräfixe/Traffic auf Border-Leaf-Switches über Firewalls prüfen

Der Interconnect-Datenpfad durchläuft auch zwei PANW-Firewalls: die IDPS-Firewall (Intrusion Detection and Prevention System) und die Perimeter-Firewall. Auch wenn die Routenpräfixe aus der BGP-Sitzung stammen, können sie von den Firewalls verworfen werden.

Überprüfen Sie die Routenpräfixe, die auf verschiedenen `VRFs` gelernt wurden.

Externer Traffic durchläuft mehrere VRFs an den Aggregations-Switches, wenn er die verschiedenen Firewalls durchläuft. Wenn Sie nach BGP-Routenpräfixen suchen, die über diese VRF-Punkte gelernt wurden, können Sie auf Routenpräfixe/Traffic schließen, die an den Firewalls verworfen wurden.

Der gesamte externe Traffic wird in die externen VRFs *-external-vrf eingeordnet, je nach Quell- oder Zielcluster des Traffics auf den Border-Leaf-Switches. Beispiel: root-external-vrf hat Traffic mit Quelle oder Ziel im Administratorcluster.

Nachdem der Traffic die IDPS-Firewall durchlaufen hat, wird er in eines der folgenden Interconnect-VRFs eingeordnet:

oc-vrf
dci-vrf
cp-vrf

Für Traffic, der für das NOC bestimmt ist, gibt es eine zusätzliche Perimeter-Firewall, nach der der Traffic auf octransit-vrf landet.

Melden Sie sich bei den Border-Leaf-Switches an und verwenden Sie den folgenden Befehl, um die Routenpräfixe anzuzeigen, die in verschiedenen VRFs gelernt wurden:

show bgp vrf <vrf_name> all

Dabei kann „vrf_name“ einer der VRFs sein.

Fehlerbehebung bei ANG-BGP

kubeconfig-Datei des Clusters

Sie benötigen die folgenden Werte für KUBECONFIG_FILE, um die Objekte zu prüfen:

ROOT_ADMIN_KUBECONFIG: die kubeconfig-Datei für den Administratorcluster auf Stammebene.
ORG_ADMIN_KUBECONFIG: die kubeconfig-Datei für den Administratorcluster der Organisation.
ORG_SYSTEM_KUBECONFIG: die kubeconfig-Datei für den Organisationssystemcluster.
ORG_USER_KUBECONFIG: die kubeconfig-Datei für den Organisationsnutzercluster.

Cluster hängt im Bereitstellungsstatus fest

Prüfen Sie, ob das NodePool-Objekt bereit ist.
```
kubectl --kubeconfig KUBECONFIG_FILE \
    get nodepools -A
```
Wenn die Knotenpoolobjekte nicht erstellt oder bereit sind, prüfen Sie NodePoolClaim und die Knotenkonnektivität.

Prüfen Sie, ob das ClusterBGPPeer-Objekt bereit ist.

Prüfen Sie, ob die ClusterBGPPeer-Objekte für flat-ip-bgp-x, lb-bgp-x und node-x erstellt wurden:

kubectl --kubeconfig KUBECONFIG_FILE \
    get clusterbgppeers -A
...
ORG_NAME-system-cluster   flat-ip-bgp-peer-0                   16h
ORG_NAME-system-cluster   lb-bgp-peer-0                        21h
ORG_NAME-system-cluster   node-10.251.100.10-peer-10.0.224.0   21h

Wenn keine Objekte erstellt werden, prüfen Sie die Objekte NetworkGatewayGroup und BGPPeer.

Prüfen Sie, ob die BGPSessions aktiv sind.
```
kubectl --kubeconfig KUBECONFIG_FILE \
    get bgpsessions -A
```
Wenn BGP-Sitzungen nicht aktiv sind, lesen Sie den Abschnitt BGP-Sitzungen nicht erstellt.

BGP-Sitzung nicht hergestellt

`EBGPNeighbor` auf `TORSwitchInternal` prüfen

Prüfen Sie ClusterBGPRouter, um den TOR-Switch der Peer-Schnittstelle jeder Schnittstelle zu ermitteln.

Die Schnittstellen von ORG_NAME ClusterBGPRouter werden verwendet, um alle Cluster von ORG_NAME zu verbinden.

 apiVersion: network.private.gdc.goog/v1alpha1
 kind: ClusterBGPRouter
 metadata:
 labels:
     clusterbgpreconciler.system.private.gdc.goog/overlay-network: external
 name: external-vrf-cluster-bgp-router
 namespace: ORG_NAME
 spec:
 clusterASN: 64513
 interfaces:
 - ip: 10.0.252.48
   switchMetadata:
   rackName: alatl14-aa
   switchRef:
       kind: TORSwitch
       name: alatl14-aa-torsw01
 - ip: 10.0.252.49
   switchMetadata:
   rackName: alatl14-aa
   switchRef:
       kind: TORSwitch
       name: alatl14-aa-torsw02
 networkASN: 65014

Prüfen Sie für jede TORSwitchInternal in spec.ebgpNeighbors, ob alle ClusterBGPPeer-Objekte konfiguriert sind.

Fehlerbehebung bei BGP-Sitzungen an TOR-Switches

Stellen Sie eine SSH-Verbindung zu einem der Peering-ToR-Switches her.

Überprüfen Sie die ANG-BGP-Nachbarn für ORG_NAME:

> sh run bgp
router bgp 65014
...
  vrf ORG_NAME-external-vrf
    ...
    neighbor 10.251.100.3
      inherit peer ANG
      update-source loopback200
    neighbor 10.251.100.4
      inherit peer ANG
      update-source loopback200
    ...
  vrf ORG_NAME-internal-vrf
    ...
    neighbor 172.20.128.5
      inherit peer ANG
      update-source loopback100
    neighbor 172.20.128.6
      inherit peer ANG
      update-source loopback100
  ...

BGP-Sitzungsstatus prüfen:

> sh bgp ses vrf ORG_NAME-external-vrf
> sh bgp ses vrf ORG_NAME-internal-vrf

BGP-Logs ansehen:

> debug ip bgp all
> no debug ip bgp all (disable log mode)

Debugging mit Bash verschieben:

> run bash
> sudo tcpdmp -i any port 179 -vvv

Fehlerbehebung bei der Netzwerkverbindung Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.