Solução de problemas de rede

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

Solução de problemas de inicialização da rede

Esta seção mostra alguns dos erros comuns que podem ocorrer ao concluir o processo de bootstrap de rede.

Erro de geração de configuração

Para concluir a instalação da rede, os arquivos de configuração de rede são instalados na máquina bootstrap. Se você encontrar um erro de geração de configuração, verifique os arquivos YAML localizados em /root/cellcfg para a configuração de chave com falha.

A inicialização ficou travada no ping da fase 1.

Se o processo de bootstrap da rede ficar parado no ping da fase 1, siga estas etapas para encontrar o problema:

  1. Extraia o local da configuração de switch gerada do registro de inicialização: /tmp/network-bootstrap/ID
  2. Encontre o switch parado analisando o arquivo de configuração dele com o endereço IP.
  3. Faça login no switch e verifique o registro de operações.

A inicialização foi interrompida no ping da fase 2

Se o processo de bootstrap da rede ficar parado no ping da fase 2, siga estas etapas para encontrar o problema:

  1. Extraia o local da configuração de switch gerada do registro de inicialização: /tmp/network-bootstrap/ID
  2. Encontre o switch parado analisando o arquivo de configuração dele com o endereço IP de gerenciamento.
  3. Verifique a configuração do switch de gerenciamento para identificar possíveis problemas de acesso na rede de gerenciamento.

Solução de problemas de reconciliação do dia 2 da rede

Visão geral

O GDC usa o recurso de substituição de configuração fornecido pelo Cisco NX-OS durante a reconciliação do switch para substituir a configuração em execução em um switch por uma configuração completamente nova. As etapas que a operação de substituição de configuração realiza internamente são:

  1. Calcula a diferença entre a configuração em execução atual e a configuração fornecida pelo usuário.
  2. Gera um arquivo 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 arquivo de patch.
  4. Aplica o arquivo de patch.
  5. Verifica se o arquivo de patch foi adicionado corretamente comparando o running-config com a configuração de entrada. Caso contrário, reverte para a configuração anterior
  6. Um timer é iniciado antes da execução do comando "configure replace commit" ou da reversão da nova configuração.

A falha pode ocorrer em cada uma das etapas anteriores, mas geralmente acontece durante as etapas 3, 4 e 1. Confira a seguir algumas maneiras de resolver erros com configure replace.

Etapas comuns de solução de problemas

Verificar o status geral da troca

No servidor administrador raiz, execute kubectl describe aggswitch/mb-ab-aggsw01 -n gpc-system (substitua o nome da chave pelo nome necessário).

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

Verificar o status da última operação de substituição de configuração

No console de troca, execute show config-replace status:

O status vai fornecer as seguintes informações:

  • Status geral, como "concluído", "falha" etc.
  • Se a substituição de configuração foi confirmada ou está aguardando confirmação.
  • Horário de início e término da última operação de substituição de configuração

Verificar quais configurações foram aplicadas pela última operação de substituição de configuração

No console do switch, execute show config-replace log exec.

O registro de execução da substituição de configuração mostra os registros gerados ao aplicar as configurações determinadas pela operação de substituição de 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.

Esses registros às vezes têm erros que são ignorados pela operação de substituição de configuração e não causam falha na substituição de configuração como um todo. A menos que um erro seja a última linha do registro de execução na seção "Executando patch", ele provavelmente não é a causa de uma falha na substituição da configuração.

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

No console do switch, execute show config-replace log verify.

Após a etapa de execução da substituição de configuração, a operação compara a nova configuração em execução do switch com a configuração de entrada. Essas configurações precisam ser iguais. Caso contrário, a substituição da configuração vai falhar e reverter para a configuração anterior.

O registro de verificação tem duas seções.

  • Configuration To Be Added Missing in Running-config: 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: lista as configurações presentes na nova configuração em execução, mas não na configuração de entrada.

Verificar todos os comandos executados no switch

No console de troca, execute show accounting log start-time 2022 Sep 13 20:00:00 (substituindo o horário de início por um horário necessário).

Os registros de contabilidade mostram todos os comandos executados no switch. Esses registros podem ser úteis para ver quais comandos foram executados no switch via NXAPI ou manualmente. Eles também podem dar uma ideia de quando exatamente cada operação de substituição de configuração foi executada e quantas vezes ela foi executada.

Verificar quais chamadas da NX-API foram feitas para o switch e de onde

No console do switch, execute show nxapi-server logs

Os registros da NX-API mostram os registros relacionados às chamadas da NXAPI feitas para o switch. Como nossa pilha de automação faz chamadas NXAPI para os switches por vários motivos, incluindo a execução da substituição de configuração, isso é útil para ver quais chamadas NXAPI foram feitas e de onde elas vieram.

Solução de problemas de interconexão

Visão geral da API Interconnect

A API Interconnect configura as conexões externas de uma célula do data center do GDC. Há três tipos de interconexões

  • Interconexão de data center (DCI): interconexão de um data center do GDC com outro data center do GDC usando os switches de borda de plano de dados.
  • Interconexão de peering do cliente (CPI, na sigla em inglês): interconexão de um data center do GDC com a rede da organização usando os switches de borda de folha do plano de dados.
  • Centro de operações de rede (NOC): interconexão de um data center do GDC com o centro de operações de rede usando os switches de borda de plano de dados e os switches de agregação de gerenciamento.

Os seguintes objetos de API estão presentes:

  • InterconnectLink: esse objeto de API define as portas físicas que se conectam a switches externos.

  • InterconnectAttachment: esse objeto de API define os anexos que existem além do InterconnectLink configurado. As informações contidas em cada anexo definem o seguinte:

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

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

Solução de problemas

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

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

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

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

    1. BGPStatus: status da sessão do BGP, por exemplo, "Up" ou "Down".
    2. UpTime: carimbo de data/hora da última vez que a sessão do BGP foi iniciada.
    3. PrefixCounters: contadores que mostram o total de prefixos Received, Sent e Withdrawn.

Verificar políticas de roteamento

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

Verificar prefixos de rota/tráfego do BGP em switches de borda em firewalls

O caminho de dados de interconexão também atravessa dois firewalls da PANW: o firewall do sistema de detecção e prevenção de intrusões (IDPS) e o firewall de perímetro. Mesmo que os prefixos de rota sejam aprendidos na sessão do BGP, é possível que os firewalls os descartem.

Verificar os prefixos de rota aprendidos em vários VRFs

O tráfego externo passa por várias VRFs nos switches de agregação ao transitar pelos diferentes firewalls. A verificação dos prefixos de rota do BGP aprendidos nesses pontos de VRF indica que os prefixos de rota/tráfego foram descartados nos firewalls.

Todo o tráfego externo é colocado nas VRFs externas *-external-vrf dependendo do cluster de origem ou destino do tráfego nos switches de borda. Exemplo: root-external-vrf tem tráfego com origem ou destino para o cluster de administrador raiz.

Depois que o tráfego passa pelo firewall do IDPS, ele é colocado em uma das seguintes VRFs de interconexão:

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

Para o tráfego destinado ao NOC, há um firewall de perímetro adicional. Depois disso, o tráfego chega a octransit-vrf.

Faça login nos switches de borda e use o comando a seguir para mostrar os prefixos de rota aprendidos em várias VRFs:

show bgp vrf <vrf_name> all

Em que vrf_name pode ser uma das VRFs.

Solução de problemas do BGP do ANG

Arquivo kubeconfig do cluster

Verifique se você tem os seguintes valores de KUBECONFIG_FILE para verificar os objetos:

  • ROOT_ADMIN_KUBECONFIG: o arquivo kubeconfig do cluster de administrador raiz.
  • ORG_ADMIN_KUBECONFIG: o arquivo kubeconfig do cluster de administrador da organização.
  • ORG_SYSTEM_KUBECONFIG: o arquivo kubeconfig do cluster do sistema da organização.
  • ORG_USER_KUBECONFIG: o arquivo kubeconfig do cluster de usuário da organização.

Cluster travado no estado de provisionamento

  1. Verifique se o objeto NodePool está pronto.

    kubectl --kubeconfig KUBECONFIG_FILE \
    get nodepools -A

    Se os objetos do pool de nós não forem criados ou não estiverem prontos, verifique NodePoolClaim e a conectividade do nó.

  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 BGPSessions estão funcionando.

    kubectl --kubeconfig KUBECONFIG_FILE \
    get bgpsessions -A

    Se as sessões do BGP não estiverem ativas, consulte Sessões do BGP não estabelecidas.

A sessão do BGP não foi estabelecida

Confira EBGPNeighbor em TORSwitchInternal

  1. Verifique ClusterBGPRouter para conferir a chave TOR pareada de cada interface.

    As interfaces de ORG_NAME ClusterBGPRouter são usadas para fazer peering com 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 saber se todos os objetos ClusterBGPPeer estão configurados.

Depurar sessões do BGP em switches TOR

  1. Use SSH em um dos switches TOR pareados.

  2. Verifique os vizinhos do 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 status da sessão do BGP:

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

  4. Ver registros do BGP:

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

  5. Mova a depuração usando bash:

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