Resolução de problemas de rede

A página contém detalhes sobre como resolver problemas de rede comuns.

Resolução de problemas de arranque da rede

Esta secção mostra alguns dos erros comuns que pode encontrar quando conclui o processo de arranque da rede.

Erro de geração da configuração

Para concluir a instalação de rede, os ficheiros de configuração de rede são instalados no computador de arranque. Se tiver um erro de geração de configuração, verifique os ficheiros YAML localizados em /root/cellcfg para a configuração de comutador com falha.

O arranque está parado no ping da fase 1

Se o processo de arranque da rede ficar parado na fase 1 de ping, siga estes passos para encontrar o problema:

  1. Obtenha a localização da configuração do comutador gerada a partir do registo de arranque: /tmp/network-bootstrap/ID
  2. Encontre o comutador parado consultando o ficheiro de configuração do comutador com o endereço IP.
  3. Inicie sessão no comutador e verifique o registo de funcionamento.

O arranque está parado no ping da fase 2

Se o processo de arranque da rede ficar parado na fase 2 de ping, siga estes passos para encontrar o problema:

  1. Obtenha a localização da configuração do comutador gerada a partir do registo de arranque: /tmp/network-bootstrap/ID
  2. Procure o comutador parado consultando o ficheiro de configuração do comutador com o endereço IP de gestão.
  3. Verifique a configuração do comutador de gestão quanto a potenciais problemas de acesso na rede de gestão.

Resolução de problemas de conciliação do dia 2 da rede

Vista geral

O GDC usa a funcionalidade de substituição da configuração fornecida pelo Cisco NX-OS durante a reconciliação do comutador para substituir a configuração em execução num comutador por uma configuração completamente nova. Os passos que a operação de substituição da configuração executa internamente são:

  1. Calcula a diferença entre a configuração de execução atual e a configuração fornecida pelo utilizador.
  2. Gera um ficheiro de patch que é a diferença entre a configuração em execução e a configuração de entrada.
  3. Faz a validação semântica no ficheiro de patch.
  4. Aplica o ficheiro de patch.
  5. Verifica se o ficheiro de patch foi adicionado corretamente comparando a configuração em execução com a configuração de entrada. Caso contrário, reverte para a configuração anterior
  6. É iniciado um temporizador antes do qual o comando configure replace commit tem de ser executado ou a nova configuração é revertida.

A falha pode ocorrer em cada um dos passos anteriores, mas ocorre mais frequentemente nos passos 3, 4 e 1. Seguem-se algumas formas de resolver problemas com a opção configure replace.

Passos de resolução de problemas comuns

Verifique o estado geral do interruptor

No servidor de administração raiz, execute kubectl describe aggswitch/mb-ab-aggsw01 -n gpc-system (substitua o nome do comutador pelo nome do comutador necessário)

O objeto Kubernetes do comutador no cluster de administrador raiz mostra o exec e verifica os registos na descrição do objeto se a substituição da última configuração falhar.

Verifique o estado da última operação de substituição da configuração

Na consola do comutador, execute show config-replace status:

O estado fornece as seguintes informações

  • Estado geral, como "concluído", "falha", etc.
  • Se a substituição da configuração foi confirmada ou está a aguardar confirmação.
  • Hora de início e de fim da última operação de substituição da configuração

Verifique que configurações foram aplicadas pela última operação de substituição da configuração

Na consola do comutador, execute show config-replace log exec.

O registo de execução da substituição da configuração mostra os registos gerados durante a aplicação das configurações determinadas pela operação de substituição da configuração como a configuração de patch, ou seja, a diferença entre a configuração em execução e a configuração de entrada.

Tenha em atenção que, por vezes, estes registos têm erros que são ignorados pela operação de substituição da configuração e não fazem com que a substituição da configuração falhe como um todo. A menos que um erro seja a última linha do registo de execução na secção "Executing Patch" (A executar patch), é provável que não seja a causa de uma falha na substituição da configuração.

Verifique se a validação da última operação de substituição da configuração foi bem-sucedida

Na consola do comutador, execute show config-replace log verify.

Após o passo de execução da substituição da configuração, a operação de substituição da configuração compara a nova configuração em execução do comutador com a configuração de entrada. Estas configurações têm de corresponder. Se não o fizer, a substituição da configuração falha e reverte a configuração para a configuração anterior.

Existem duas secções no registo de validação.

  • Configuration To Be Added Missing in Running-config: esta lista as configurações presentes na configuração de entrada, mas não na nova configuração em execução
  • Configuration To Be Removed Present in Running-config: esta lista as configurações presentes na nova configuração em execução, mas não na configuração de entrada

Verifique todos os comandos que foram executados no interruptor

Na consola do comutador, execute show accounting log start-time 2022 Sep 13 20:00:00 (substituindo a hora de início por uma hora de início necessária)

Os registos de contabilidade mostram todos os comandos executados no comutador. Estes registos podem ser úteis para ver que comandos foram executados no comutador através da NXAPI ou manualmente. Também podem dar-lhe uma ideia de quando exatamente cada operação de substituição de configuração foi executada e quantas vezes foi executada.

Verifique que chamadas NX-API foram feitas ao comutador e a partir de onde

Na consola do comutador, execute show nxapi-server logs

Os registos da NX-API mostram os registos relacionados com as chamadas da NXAPI feitas ao comutador. Uma vez que a nossa pilha de automação faz chamadas NXAPI para os comutadores por vários motivos, incluindo para executar a substituição da configuração, isto é útil para ver que chamadas NXAPI foram feitas e de onde vieram.

Resolução de problemas de interligação

Vista geral da API Interconnect

A API Interconnect configura as ligações externas para uma célula do centro de dados do GDC. Existem 3 tipos de interconexões

  • Interligação de centros de dados (DCI): interligação de um centro de dados do GDC a outro centro de dados do GDC através dos comutadores de folha de fronteira do plano de dados.
  • Interligação de pares de clientes (CPI): interligação de um centro de dados do GDC à rede da organização através dos comutadores de folha de limite do plano de dados.
  • Centro de operações de rede (NOC): interligação a partir de um centro de dados da GDC para o centro de operações de rede através dos comutadores de folha de limite do plano de dados e dos comutadores de agregação de gestão.

Os seguintes objetos da API estão presentes:

  • InterconnectLink: este objeto da API define as portas físicas que se ligam a comutadores externos.

  • InterconnectAttachment: este objeto API define os anexos existentes além do InterconnectLink configurado. As informações contidas por anexo definem o seguinte:

    1. Tipo de interligação
    2. Informações de BGP
    3. Informações do ID da VLAN
    4. Políticas de encaminhamento configuradas

  • RoutePolicy: este objeto API modela as políticas usadas para partilhar rotas com pares BGP de interconexão.

Resolução de problemas

Os objetos da API InterconnectLink e InterconnectAttachment expõem muitas informações que podem esclarecer o estado atual.

  • InterconnectLink: as seguintes informações são expostas para cada porta física que se liga a comutadores externos.

    1. Up: informações de estado sobre se a porta está ativa ou inativa.
    2. DownReason: motivo da porta estar inativa.

  • InterconnectAttachment: as seguintes informações são expostas para cada um dos anexos de interconexão configurados.

    1. BGPStatus: estado da sessão de BGP, por exemplo, Ativa ou Inativa.
    2. UpTime: data/hora da última vez que a sessão de BGP foi iniciada.
    3. PrefixCounters: contadores que mostram os prefixos totais Received, Sent e Withdrawn.

Valide as políticas de rotas

RoutePolicy define uma lista de prefixos e a ação a realizar, por exemplo, Permitir ou Recusar. Liste todas as políticas de encaminhamento associadas ao recurso InterconnectAttachment para verificar se os endereços IP fazem parte de RoutePolicy válidos.

Valide os prefixos/tráfego de rotas BGP em comutadores leaf de fronteira através de firewalls

O caminho de dados de interligação também atravessa duas firewalls PANW: a firewall do sistema de deteção e prevenção de intrusões (IDPS) e a firewall de perímetro. Mesmo que os prefixos de trajeto sejam aprendidos a partir da sessão de BGP, é possível que as firewalls os rejeitem.

Valide os prefixos de trajeto aprendidos em vários VRFs

O tráfego externo atravessa vários VRFs nos comutadores de agregação à medida que transita pelos diferentes firewalls. Verificar se existem prefixos de rotas BGP aprendidos nestes pontos VRF para encaminhar prefixos/tráfego rejeitado nas firewalls.

Todo o tráfego externo é colocado nos VRFs externos *-external-vrf consoante o cluster de origem ou destino do tráfego nos comutadores de folha de limite. Exemplo: root-external-vrf tem tráfego com origem ou destino no cluster de administrador principal.

Assim que o tráfego atravessa a firewall IDPS, é colocado numa das seguintes VRFs de interconexão:

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

Para o tráfego destinado ao NOC, existe uma firewall de perímetro adicional após a qual o tráfego é encaminhado para octransit-vrf.

Inicie sessão nos comutadores de folhas de limite e use o seguinte comando para apresentar os prefixos de rotas aprendidos em várias VRFs:

show bgp vrf <vrf_name> all

Em que vrf_name pode ser um dos VRFs.

Resolução de problemas de BGP da ANG

Ficheiro kubeconfig do cluster

Certifique-se de que tem os seguintes valores de KUBECONFIG_FILE para verificar os objetos:

  • ROOT_ADMIN_KUBECONFIG: o ficheiro kubeconfig para o cluster de administrador raiz.
  • ORG_ADMIN_KUBECONFIG: o ficheiro kubeconfig para o cluster de administrador da organização.
  • ORG_SYSTEM_KUBECONFIG: o ficheiro kubeconfig para o cluster do sistema org.
  • ORG_USER_KUBECONFIG: o ficheiro kubeconfig para o cluster de utilizadores da organização.

O cluster está bloqueado no estado de aprovisionamento

  1. Verifique se o objeto NodePool está pronto.

    kubectl --kubeconfig KUBECONFIG_FILE \
    get nodepools -A

    Se os objetos nodepool não forem criados ou não estiverem prontos, verifique NodePoolClaim e a conetividade dos nós.

  2. Verifique se o objeto ClusterBGPPeer está pronto.

    Verifique se os objetos ClusterBGPPeer foram criados para 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 os objetos não forem criados, verifique os objetos NetworkGatewayGroup e BGPPeer.

  3. Verifique se os BGPSession estão ativados.

    kubectl --kubeconfig KUBECONFIG_FILE \
    get bgpsessions -A

    Se as sessões de BGP não estiverem ativas, consulte o artigo As sessões de BGP não foram estabelecidas.

Sessão de BGP não estabelecida

Verifique EBGPNeighbor às TORSwitchInternal

  1. Selecione ClusterBGPRouter para obter o comutador TOR com peering de cada interface.

    As interfaces de ORG_NAME ClusterBGPRouter são usadas para estabelecer a interligação de todos os 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

  2. Para cada TORSwitchInternal, verifique spec.ebgpNeighbors para ver se todos os objetos ClusterBGPPeer estão configurados.

Depure sessões de BGP em comutadores TOR

  1. SSH para um dos comutadores TOR com peering.

  2. Valide os vizinhos BGP da ANG para 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. Verifique o estado da sessão de BGP:

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

  4. Ver registos de BGP:

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

  5. Mova a depuração através do bash:

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