Risoluzione dei problemi di networking

La pagina contiene dettagli su come risolvere i problemi di networking più comuni.

Risoluzione dei problemi di bootstrap di rete

Questa sezione mostra alcuni degli errori comuni che potresti riscontrare durante il completamento del processo di bootstrap della rete.

Errore di generazione della configurazione

Per completare l'installazione di rete, i file di configurazione di rete vengono installati sul computer bootstrapper. Se si verifica un errore di generazione della configurazione, controlla i file YAML che si trovano in /root/cellcfg per la configurazione dello switch non riuscita.

Bootstrap bloccato al ping della fase 1

Se il processo di bootstrap della rete si blocca alla fase 1 di ping, segui questi passaggi per trovare il problema:

  1. Recupera la posizione della configurazione dello switch generata dal log di bootstrap: /tmp/network-bootstrap/ID
  2. Trova lo switch bloccato esaminando il file di configurazione dello switch con l'indirizzo IP.
  3. Accedi allo switch e controlla il log delle operazioni.

Il bootstrap si è bloccato al ping della fase 2

Se il processo di bootstrap della rete si blocca alla fase 2 ping, segui questi passaggi per trovare il problema:

  1. Recupera la posizione della configurazione dello switch generata dal log di bootstrap: /tmp/network-bootstrap/ID
  2. Trova lo switch bloccato esaminando il file di configurazione dello switch con l'indirizzo IP di gestione.
  3. Controlla la configurazione dello switch di gestione per individuare potenziali problemi di accesso nella rete di gestione.

Risoluzione dei problemi di riconciliazione del giorno 2 della rete

Panoramica

GDC utilizza la funzionalità di sostituzione della configurazione fornita da Cisco NX-OS durante la riconciliazione degli switch per sostituire la configurazione in esecuzione in uno switch con una configurazione completamente nuova. I passaggi eseguiti internamente dall'operazione di sostituzione della configurazione sono:

  1. Calcola la differenza tra la configurazione di esecuzione corrente e quella fornita dall'utente.
  2. Genera un file patch che rappresenta la differenza tra la configurazione in esecuzione e la configurazione di input.
  3. Esegue la convalida semantica sul file patch.
  4. Applica il file patch.
  5. Verifica che il file patch sia stato aggiunto correttamente confrontando running-config con la configurazione di input. In caso contrario, viene ripristinata la configurazione precedente
  6. Viene avviato un timer prima del quale deve essere eseguito il comando configure replace commit o viene ripristinata la nuova configurazione.

L'errore può verificarsi in ognuno dei passaggi precedenti, ma più spesso durante i passaggi 3, 4 e 1. Di seguito sono riportati alcuni modi per risolvere gli errori relativi a configure replace.

Procedure comuni di risoluzione dei problemi

Controllare lo stato generale dell'interruttore

Nel server di amministrazione principale esegui kubectl describe aggswitch/mb-ab-aggsw01 -n gpc-system (sostituisci il nome dello switch con il nome dello switch richiesto)

L'oggetto di commutazione Kubernetes nel cluster amministrativo principale mostra i log di esecuzione e verifica nella descrizione dell'oggetto se l'ultima sostituzione della configurazione non riesce.

Controlla lo stato dell'ultima operazione di sostituzione della configurazione

Nella console dello switch, esegui show config-replace status:

Lo stato fornirà le seguenti informazioni:

  • Stato generale come "completato", "non riuscito" e così via.
  • Indica se la sostituzione della configurazione è stata eseguita o è in attesa di esecuzione.
  • Ora di inizio e di fine dell'ultima operazione di sostituzione della configurazione

Controlla quali configurazioni sono state applicate dall'ultima operazione di sostituzione della configurazione

Nella console dello switch, esegui show config-replace log exec.

Il log di esecuzione della sostituzione della configurazione mostra i log generati durante l'applicazione delle configurazioni determinate dall'operazione di sostituzione della configurazione come configurazione della patch, ovvero la differenza tra la configurazione in esecuzione e la configurazione di input.

Tieni presente che a volte questi log contengono errori ignorati dall'operazione di sostituzione della configurazione e non causano il mancato completamento della sostituzione della configurazione nel suo complesso. A meno che un errore non sia l'ultima riga del log di esecuzione nella sezione "Executing Patch" (Esecuzione patch), probabilmente non è la causa di un errore di sostituzione della configurazione.

Controlla se la verifica dell'ultima operazione di sostituzione della configurazione è riuscita

Nella console dello switch, esegui show config-replace log verify.

Dopo il passaggio di esecuzione della sostituzione della configurazione, l'operazione di sostituzione della configurazione confronta la nuova configurazione in esecuzione dello switch con la configurazione di input. Queste configurazioni devono corrispondere. In caso contrario, la sostituzione della configurazione non riesce e viene eseguito il rollback alla configurazione precedente.

Il log di verifica è suddiviso in due sezioni.

  • Configuration To Be Added Missing in Running-config: Elenca le configurazioni presenti nella configurazione di input, ma non nella nuova configurazione in esecuzione.
  • Configuration To Be Removed Present in Running-config: Elenca le configurazioni presenti nella nuova configurazione in esecuzione, ma non nella configurazione di input.

Controlla tutti i comandi eseguiti sullo switch

Nella console dello switch esegui show accounting log start-time 2022 Sep 13 20:00:00 (sostituendo l'ora di inizio con l'ora di inizio richiesta)

I log di contabilità mostrano ogni comando eseguito sullo switch. Questi log possono essere utili per vedere quali comandi sono stati eseguiti sullo switch tramite NXAPI o manualmente. Possono anche darti un'idea di quando è stata eseguita esattamente ogni operazione di sostituzione della configurazione e quante volte è stata eseguita.

Controlla quali chiamate NX-API sono state effettuate allo switch e da dove

Nella console di commutazione, esegui show nxapi-server logs

I log NX-API mostrano i log relativi alle chiamate NXAPI effettuate allo switch. Poiché il nostro stack di automazione effettua chiamate NXAPI agli switch per molti motivi, tra cui l'esecuzione della sostituzione della configurazione, è utile vedere quali chiamate NXAPI sono state effettuate e da dove provengono.

Risoluzione dei problemi di interconnessione

Panoramica dell'API Interconnect

L'API Interconnect configura le connessioni esterne per una cella del data center GDC. Esistono tre tipi di interconnessioni

  • Interconnessione data center (DCI): interconnessione da un data center GDC a un altro data center GDC tramite gli switch leaf di confine del data plane.
  • Customer Peering Interconnect (CPI): interconnessione da un data center GDC alla rete ORG tramite gli switch leaf di confine del piano dati.
  • Network Operation Center (NOC): interconnessione da un data center GDC al Network Operation Center tramite gli switch leaf di confine del data plane e gli switch di aggregazione di gestione.

Sono presenti i seguenti oggetti API:

  • InterconnectLink: questo oggetto API definisce le porte fisiche che si connettono agli switch esterni.

  • InterconnectAttachment: questo oggetto API definisce gli allegati esistenti in aggiunta a InterconnectLink configurato. Le informazioni contenute in ogni allegato definiscono quanto segue:

    1. Tipo di interconnessione
    2. Informazioni BGP
    3. Informazioni sull'ID VLAN
    4. Criteri di route configurati

  • RoutePolicy: questo oggetto API modella le policy utilizzate per la condivisione delle route con i peer BGP di interconnessione.

Risoluzione dei problemi

Gli oggetti API InterconnectLink e InterconnectAttachment espongono una grande quantità di informazioni che possono fare luce sullo stato attuale.

  • InterconnectLink: Per ogni porta fisica che si connette a switch esterni vengono esposte le seguenti informazioni.

    1. Up: informazioni sullo stato che indicano se la porta è attiva o inattiva.
    2. DownReason: Il motivo per cui la porta non è attiva.

  • InterconnectAttachment: vengono esposte le seguenti informazioni per ciascuno degli allegati di interconnessione configurati.

    1. BGPStatus: stato della sessione BGP, ad esempio Attiva o Non attiva.
    2. UpTime: timestamp dell'ultima volta che la sessione BGP è stata attivata.
    3. PrefixCounters: contatori che mostrano i prefissi totali Received, Sent e Withdrawn.

Verifica i criteri di route

RoutePolicy definisce un elenco di prefissi e l'azione da intraprendere, ad esempio Consenti o Nega. Elenca tutte le norme di routing associate alla risorsa InterconnectAttachment per verificare se gli indirizzi IP fanno parte di RoutePolicy validi.

Verifica i prefissi di route BGP/il traffico sugli switch leaf di confine tramite i firewall

Il percorso dei dati di interconnessione attraversa anche due firewall PANW: il firewall del sistema di rilevamento e prevenzione delle intrusioni (IDPS) e il firewall perimetrale. Anche se i prefissi di route vengono appresi dalla sessione BGP, è possibile che i firewall li eliminino.

Verifica i prefissi di route appresi su vari VRFs

Il traffico esterno attraversa più VRF sugli switch di aggregazione mentre transita attraverso i diversi firewall. Il controllo dei prefissi di route BGP appresi su questi punti VRF porta a prefissi di route/traffico eliminati dai firewall.

Tutto il traffico esterno viene inserito nei VRF esterni *-external-vrf a seconda del cluster di origine o di destinazione del traffico sugli switch leaf di confine. Esempio: root-external-vrf ha traffico con origine o destinazione al cluster di amministrazione principale.

Una volta che il traffico attraversa il firewall IDPS, viene inserito in uno dei seguenti VRF di interconnessione:

  • oc-vrf
  • dci-vrf
  • cp-vrf

Per il traffico destinato al NOC, è presente un firewall perimetrale aggiuntivo dopo il quale il traffico arriva su octransit-vrf.

Accedi agli switch leaf di confine e utilizza il comando seguente per visualizzare i prefissi di route appresi su vari VRF:

show bgp vrf <vrf_name> all

dove vrf_name può essere uno dei VRF.

Risoluzione dei problemi relativi a BGP ANG

File kubeconfig del cluster

Assicurati di avere i seguenti valori di KUBECONFIG_FILE per controllare gli oggetti:

  • ROOT_ADMIN_KUBECONFIG: il file kubeconfig per il cluster di amministrazione principale.
  • ORG_ADMIN_KUBECONFIG: il file kubeconfig per il cluster di amministrazione dell'organizzazione.
  • ORG_SYSTEM_KUBECONFIG: il file kubeconfig per il cluster di sistema dell'organizzazione.
  • ORG_USER_KUBECONFIG: il file kubeconfig per il cluster utente dell'organizzazione.

Il cluster è bloccato nello stato di provisioning

  1. Verifica che l'oggetto NodePool sia pronto.

    kubectl --kubeconfig KUBECONFIG_FILE \
    get nodepools -A

    Se gli oggetti del pool di nodi non vengono creati o non sono pronti, controlla NodePoolClaim e la connettività dei nodi.

  2. Verifica che l'oggetto ClusterBGPPeer sia pronto.

    Verifica che gli oggetti ClusterBGPPeer siano creati per flat-ip-bgp-x, lb-bgp-x e 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

    Se gli oggetti non vengono creati, controlla gli oggetti NetworkGatewayGroup e BGPPeer.

  3. Verifica che i BGPSession siano attivi.

    kubectl --kubeconfig KUBECONFIG_FILE \
    get bgpsessions -A

    Se le sessioni BGP non sono attive, consulta Sessioni BGP non stabilite.

Sessione BGP non stabilita

Controlla EBGPNeighbor su TORSwitchInternal

  1. Controlla ClusterBGPRouter per ottenere l'interruttore TOR sottoposto a peering di ogni interfaccia.

    Le interfacce di ORG_NAME ClusterBGPRouter vengono utilizzate per il peering di tutti i cluster di 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

  2. Per ogni TORSwitchInternal, controlla spec.ebgpNeighbors per verificare se tutti gli oggetti ClusterBGPPeer sono configurati.

Eseguire il debug delle sessioni BGP sugli switch TOR

  1. Accedi tramite SSH a uno degli switch TOR con peering.

  2. Verifica i vicini BGP ANG per 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
  ...

  3. Controlla lo stato della sessione BGP:

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

  4. Visualizza i log BGP:

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

  5. Sposta il debug utilizzando bash:

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