Cette page a été traduite par l'API Cloud Translation.

Résoudre les problèmes de mise en réseau

Cette page explique comment résoudre les problèmes de mise en réseau courants.

Résoudre les problèmes d'amorçage du réseau

Cette section présente certaines des erreurs courantes que vous pouvez rencontrer lors de la procédure d'amorçage du réseau.

Erreur de génération de la configuration

Pour terminer l'installation du réseau, des fichiers de configuration réseau sont installés sur la machine du programme d'amorçage. Si vous rencontrez une erreur de génération de configuration, vérifiez les fichiers YAML situés dans /root/cellcfg pour la configuration du commutateur ayant échoué.

Ping de la phase 1 de l'amorçage bloqué

Si le processus d'amorçage du réseau est bloqué à la phase 1 du ping, suivez ces étapes pour identifier le problème :

Obtenez l'emplacement de la configuration du commutateur générée à partir du journal d'amorçage : /tmp/network-bootstrap/ID
Recherchez le commutateur bloqué en consultant le fichier de configuration du commutateur avec l'adresse IP.
Connectez-vous au commutateur et vérifiez le journal des opérations.

Ping de blocage de l'amorçage à la phase 2

Si le processus d'amorçage du réseau est bloqué à la phase 2 du ping, suivez ces étapes pour identifier le problème :

Obtenez l'emplacement de la configuration du commutateur générée à partir du journal d'amorçage : /tmp/network-bootstrap/ID
Recherchez le commutateur bloqué en examinant le fichier de configuration du commutateur avec l'adresse IP de gestion.
Vérifiez la configuration du commutateur de gestion pour détecter d'éventuels problèmes d'accès au réseau de gestion.

Résoudre les problèmes de rapprochement réseau au deuxième jour

Présentation

GDC utilise la fonctionnalité de remplacement de la configuration fournie par Cisco NX-OS lors de la réconciliation des commutateurs pour remplacer la configuration en cours d'exécution dans un commutateur par une configuration entièrement nouvelle. Voici les étapes internes de l'opération de remplacement de la configuration :

Calcule la différence entre la configuration en cours d'exécution et celle fournie par l'utilisateur.
Génère un fichier patch qui correspond à la différence entre la configuration en cours d'exécution et la configuration d'entrée.
Effectue une validation sémantique sur le fichier patch.
Applique le fichier correctif.
Vérifie que le fichier de correctif a été ajouté correctement en comparant la configuration en cours à la configuration d'entrée. Sinon, revient à la configuration précédente
Un minuteur est lancé avant l'exécution de la commande "configure replace commit" ou la restauration de la nouvelle configuration.

Un échec peut se produire à chacune des étapes précédentes, mais il est plus fréquent aux étapes 3, 4 et 1. Voici quelques conseils pour résoudre les erreurs liées à la commande "configure replace".

Étapes de dépannage courantes

Vérifier l'état général du commutateur

Sur le serveur d'administration racine, exécutez kubectl describe aggswitch/mb-ab-aggsw01 -n gpc-system (remplacez le nom du commutateur par le nom requis).

L'objet Kubernetes de commutation dans le cluster d'administrateur racine affiche les journaux d'exécution et de validation dans la description de l'objet si le dernier remplacement de configuration échoue.

Vérifier l'état de la dernière opération de remplacement de la configuration

Dans la console Switch, exécutez show config-replace status :

L'état fournit les informations suivantes :

État général (par exemple, "terminé", "échec", etc.)
Indique si le remplacement de la configuration a été effectué ou s'il est en attente.
Heure de début et de fin de la dernière opération de remplacement de la configuration

Vérifier les configurations appliquées par la dernière opération de remplacement de configuration

Exécutez show config-replace log exec dans la console Switch.

Le journal d'exécution de remplacement de la configuration affiche les journaux générés lors de l'application des configurations déterminées par l'opération de remplacement de la configuration en tant que configuration du correctif, c'est-à-dire la différence entre la configuration en cours d'exécution et la configuration d'entrée.

Notez que ces journaux contiennent parfois des erreurs qui sont ignorées par l'opération de remplacement de la configuration et qui n'entraînent pas l'échec de l'ensemble du remplacement de la configuration. Sauf si une erreur est la dernière ligne du journal d'exécution dans la section "Executing Patch" (Exécution du correctif), il est peu probable qu'elle soit à l'origine d'un échec de remplacement de la configuration.

Vérifier si la validation de la dernière opération de remplacement de la configuration a réussi

Exécutez show config-replace log verify dans la console Switch.

Après l'étape d'exécution de remplacement de la configuration, l'opération de remplacement de la configuration compare la nouvelle configuration en cours d'exécution du commutateur à la configuration d'entrée. Ces configurations doivent correspondre. Si ce n'est pas le cas, le remplacement de la configuration échoue et la configuration est rétablie à la configuration précédente.

Le journal de validation comporte deux sections.

Configuration To Be Added Missing in Running-config : liste les configurations présentes dans la configuration d'entrée, mais pas dans la nouvelle configuration en cours d'exécution.
Configuration To Be Removed Present in Running-config : liste les configurations présentes dans la nouvelle configuration en cours d'exécution, mais pas dans la configuration d'entrée.

Vérifier toutes les commandes qui ont été exécutées sur le commutateur

Dans la console Switch, exécutez show accounting log start-time 2022 Sep 13 20:00:00 (en remplaçant l'heure de début par l'heure de début requise).

Les journaux de comptabilité affichent toutes les commandes exécutées sur le commutateur. Ces journaux peuvent être utiles pour voir les commandes exécutées sur le commutateur via NXAPI ou manuellement. Ils peuvent également vous donner une idée du moment exact où chaque opération de remplacement de configuration a été exécutée et du nombre de fois où elle a été exécutée.

Vérifier les appels NX-API effectués vers le commutateur et leur origine

Dans la console Switch, exécutez show nxapi-server logs.

Les journaux NX-API affichent les journaux liés aux appels NXAPI effectués vers le commutateur. Étant donné que notre pile d'automatisation effectue des appels NXAPI aux commutateurs pour de nombreuses raisons, y compris pour exécuter le remplacement de la configuration, il est utile de voir quels appels NXAPI ont été effectués et d'où ils proviennent.

Résoudre les problèmes d'interconnexion

Présentation de l'API Interconnect

L'API Interconnect configure les connexions externes pour une cellule de centre de données GDC. Il existe trois types d'interconnexions :

Interconnexion de centres de données (DCI, Data Center Interconnect) : interconnexion d'un centre de données GDC à un autre centre de données GDC via les commutateurs leaf de bordure du plan de données.
Interconnectivité pour l'appairage client (CPI, Customer Peering Interconnect) : interconnectivité d'un centre de données GDC au réseau ORG via les commutateurs leaf de bordure du plan de données.
Centre d'opérations réseau (NOC, Network Operation Center) : interconnectez-vous depuis un centre de données GDC au centre d'opérations réseau via les commutateurs leaf de bordure du plan de données et les commutateurs d'agrégation de gestion.

Les objets d'API suivants sont présents :

InterconnectLink : cet objet API définit les ports physiques qui se connectent aux commutateurs externes.
InterconnectAttachment : cet objet API définit les pièces jointes qui existent en plus de l'InterconnectLink configuré. Les informations contenues dans chaque pièce jointe définissent les éléments suivants :
1. Type d'interconnexion
2. Informations BGP
3. Informations sur l'ID de VLAN
4. Règles de routage configurées
RoutePolicy : cet objet API modélise les règles utilisées pour partager des routes avec des pairs BGP d'interconnexion.

Dépannage

Vérifier l'état d'InterconnectLink et d'InterconnectAttachment

Les objets d'API InterconnectLink et InterconnectAttachment exposent une multitude d'informations qui peuvent éclairer l'état actuel.

InterconnectLink : les informations suivantes sont exposées pour chaque port physique connecté à des commutateurs externes.
1. Up : informations sur l'état du port (actif ou inactif).
2. DownReason : raison pour laquelle le port est hors service.
InterconnectAttachment : les informations suivantes sont exposées pour chacune des pièces jointes d'interconnexion configurées.
1. BGPStatus : état de la session BGP (par exemple, "Up" ou "Down").
2. UpTime : code temporel de la dernière activation de la session BGP.
3. PrefixCounters : compteurs qui affichent le nombre total de préfixes Received, Sent et Withdrawn.

Vérifier les règles de routage

RoutePolicy définit une liste de préfixes et l'action à effectuer (par exemple, "Autoriser" ou "Refuser"). Répertoriez toutes les règles de route associées à la ressource InterconnectAttachment pour vérifier si les adresses IP font partie de RoutePolicy valides.

Vérifier les préfixes de route/le trafic BGP sur les commutateurs leaf de bordure via les pare-feu

Le chemin de données d'interconnexion traverse également deux pare-feu PANW : le pare-feu du système de détection et de prévention des intrusions (IDPS) et le pare-feu de périmètre. Même si les préfixes de route sont appris à partir de la session BGP, il est possible que les pare-feu les abandonnent.

Vérifier les préfixes de route appris sur différents `VRFs`

Le trafic externe traverse plusieurs VRF au niveau des commutateurs d'agrégation lorsqu'il transite par les différents pare-feu. La vérification des préfixes de route BGP appris sur ces VRF indique que les préfixes/le trafic de route sont abandonnés au niveau des pare-feu.

Tout le trafic externe est placé dans les VRF externes *-external-vrf en fonction du cluster source ou de destination du trafic sur les commutateurs leaf de bordure. Exemple : root-external-vrf a du trafic avec une source ou une destination vers le cluster d'administrateur racine.

Une fois le trafic traversé par le pare-feu IDPS, il est placé dans l'un des VRF d'interconnexion suivants :

oc-vrf
dci-vrf
cp-vrf

Pour le trafic destiné au NOC, un pare-feu de périmètre supplémentaire est utilisé avant que le trafic n'arrive sur octransit-vrf.

Connectez-vous aux commutateurs de feuille de bordure et utilisez la commande suivante pour afficher les préfixes de route appris sur différents VRF :

show bgp vrf <vrf_name> all

où vrf_name peut être l'un des VRF.

Dépannage BGP ANG

Fichier kubeconfig du cluster

Assurez-vous d'avoir les valeurs suivantes de KUBECONFIG_FILE pour vérifier les objets :

ROOT_ADMIN_KUBECONFIG : fichier kubeconfig du cluster d'administrateur racine.
ORG_ADMIN_KUBECONFIG : fichier kubeconfig pour le cluster d'administrateur de l'organisation.
ORG_SYSTEM_KUBECONFIG : fichier kubeconfig pour le cluster système de l'organisation.
ORG_USER_KUBECONFIG : fichier kubeconfig pour le cluster d'utilisateur de l'organisation.

Cluster bloqué à l'état de provisionnement

Vérifiez que l'objet NodePool est prêt.
```
kubectl --kubeconfig KUBECONFIG_FILE \
    get nodepools -A
```
Si les objets du pool de nœuds ne sont pas créés ni prêts, vérifiez NodePoolClaim et la connectivité des nœuds.

Vérifiez que l'objet ClusterBGPPeer est prêt.

Vérifiez que les objets ClusterBGPPeer sont créés pour flat-ip-bgp-x, lb-bgp-x et node-x :

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

Si les objets ne sont pas créés, vérifiez les objets NetworkGatewayGroup et BGPPeer.

Vérifiez que les BGPSession sont opérationnels.
```
kubectl --kubeconfig KUBECONFIG_FILE \
    get bgpsessions -A
```
Si les sessions BGP ne sont pas en cours, consultez Sessions BGP non établies.

Session BGP non établie

Consultez `EBGPNeighbor` sur `TORSwitchInternal`

Cochez ClusterBGPRouter pour obtenir le commutateur TOR appairé de chaque interface.

Les interfaces de ORG_NAME ClusterBGPRouter sont utilisées pour associer tous les clusters de ORG_NAME.

 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

Pour chaque TORSwitchInternal, vérifiez spec.ebgpNeighbors pour voir si tous les objets ClusterBGPPeer sont configurés.

Déboguer les sessions BGP au niveau des commutateurs TOR

Connectez-vous en SSH à l'un des commutateurs TOR appairés.

Vérifiez les voisins BGP de l'ANG pour 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
  ...

Vérifiez l'état de la session BGP :

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

Affichez les journaux BGP :

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

Déboguer le déplacement à l'aide de bash :

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

Résoudre les problèmes de mise en réseau Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.