Solução de problemas

Saiba mais sobre as etapas de solução de problemas que podem ser úteis se você tiver problemas ao usar a Central de conectividade de rede.

Para problemas conhecidos, consulte Considerações na página "Visão geral".

Problemas comuns com a sintaxe do comando

Ao atualizar um spoke, não é necessário especificar o hub, mas você precisa especificar a região em que ele está localizado.

Os hubs são recursos globais, mas os microfones são recursos regionais.

Como anexar recursos aos microfones

Para ver requisitos detalhados, recomendações e considerações para criar spokes e anexar recursos a eles, consulte Como criar uma fala.

O tráfego da transferência de dados não flui entre dois locais

Se o tráfego de transferência de dados não estiver fluindo entre dois locais, confirme se os seguintes recursos estão configurados e funcionando corretamente:

Como atribuir ASNs aos microfones

Para simplificar sua configuração, recomendamos que você atribua ASNs aos microfones da seguinte maneira:

  • Use um único número de sistema autônomo do Google (ASN, na sigla em inglês) (router.bgp.asn) no Cloud Router para todos os recursos falados anexados a um único hub. Por exemplo, os túneis de VPN de alta disponibilidade anexados a um spray usam esse ASN do Google no Cloud Router para peering. Siga as recomendações para numeração de ASNs na documentação para criação de um Cloud Router.
  • Atribua um ASN de peer único a cada spoke anexado ao mesmo hub (router.bgpPeers.asn). Em cada microfone, verifique se todos os ASNs de mesmo nível são iguais. Como dois pares divulgam o mesmo prefixo com caminhos ASN ou AS diferentes, apenas o caminho ASN e AS de um par é anunciado para esse prefixo.
  • Recomendamos a configuração da detecção de loop de caminho AS nos roteadores de peering, embora esse recurso esteja quase sempre ativado por padrão. Em alguns casos, não é possível desativá-lo. Por exemplo, quando o roteador de mesmo nível é o Cloud Router ou possivelmente ao usar recursos de roteamento de outros provedores de nuvems

    Quando a detecção de loop do caminho do AS está ativada, quando dois microfones são configurados com o mesmo ASN de mesmo nível, a detecção de loop do caminho AS em um roteador de mesmo nível para um spray ignora todo o prefixo. anúncios da outra falas

No exemplo a seguir, os roteadores de peering dos seguintes discursos anunciam os seguintes prefixos e ASNs diferentess

  • Procurou A; roteador de peering 1, ASN 65001, anuncia prefixos 10.1.0.0/16 e 10.2.0.0/16
  • Spoke A: roteador de peering 2, ASN 65002, anuncia prefixos 10.1.0.0/16 e 10.3.0.0/16
  • Procurou B; roteador de peering 3, ASN 65003, anuncia prefixos 10.1.0.0/16 e 10.4.0.0/16

Em seguida, o Cloud Router divulga os seguintes prefixos para um par no C Spoke:

  • 10.1.0.0/16, mas o caminho AS pode começar com qualquer um destes ASNs: 65001 ou 65002 ou 65003.
  • 10.2.0.0/16 com um caminho de AS que começa com 65001
  • 10.3.0.0/16 com um caminho de AS que começa com 65002
  • 10.4.0.0/16 com um caminho de AS que começa com 65003

Garantindo que cada prefixo seja anunciado por apenas um único spoke e que todos os pares em um spoke tenham o mesmo ASN, essa ambiguidade é evitada.

Divulgações de rota duplicadas de sessões do BGP

Se houver divulgações de rota duplicadas (algumas de sessões do BGP participantes na transferência de dados e algumas das sessões que não participam da transferência de dados), o tráfego de transferência de dados poderá usar o ECMP para distribuir o tráfego para todos os próximos saltos disponíveis, mesmo se esses próximos saltos não estiverem explicitamente participando da transferência de dados. Esse comportamento será corrigido pela disponibilidade geral.

Conexão de interconexão a um local não compatível

Para ver um exemplo de como configurar divulgações de rota quando uma das suas conexões de interconexão redundantes é de um local não compatível, consulte Divulgação de rota ideal para o centro de conectividade de rede.

Resolver problemas de conectividade de rede usando testes de conectividade

Os testes de conectividade são uma ferramenta de diagnóstico que permite verificar a conectividade entre os endpoints na sua rede. Eles analisam a configuração e, em alguns casos, executam a verificação de ambiente de execução.

Para analisar as configurações de rede, os testes de conectividade simulam o caminho de encaminhamento esperado de um pacote pela rede de nuvem privada virtual (VPC, na sigla em inglês), túneis do Cloud VPN, anexos da VLAN ou instâncias de dispositivo do roteador.

É possível usar a análise de configuração dos testes de conectividade para avaliar a acessibilidade entre duas redes que não são do Google Cloud e que estão conectadas pelo Network Connectivity Center. Nesse contexto, uma rede que não é do Google Cloud normalmente é o data center local, uma filial ou a rede de outro provedor de nuvem.

Como os testes de conectividade não têm acesso à configuração de rede local, eles não podem verificar a configuração de rotas e regras de firewall no roteador local. Portanto, o tráfego da rede local para a rede VPC sempre é considerado válido pela análise da configuração dos testes de conectividade, e apenas as configurações do Google Cloud são verificadas.

Para executar testes de conectividade entre duas redes locais conectadas pelo Network Connectivity Center, consulte Como executar testes de conectividade.

Para mais informações, consulte a visão geral dos testes de conectividade.

Solução de problemas do dispositivo do roteador

Os problemas e soluções a seguir são exclusivos do dispositivo Router.

A documentação para solucionar problemas do Cloud Router também se aplica ao dispositivo do roteador, junto com os problemas descritos nas seções a seguir.

Falha ao estabelecer sessões do BGP

Se as sessões do BGP entre o Cloud Router e o roteador do roteador não forem estabelecidas, verifique os seguintes problemas:

  • Certifique-se de que uma VM atuando como uma instância de dispositivo do roteador esteja configurada como parte de uma fala do Network Connectivity Center. Para configurar uma instância do dispositivo do roteador como parte de um fone de ouvido, consulte Como trabalhar com fones de ouvido.
  • Verifique as configurações do firewall para garantir que a porta TCP 179 seja permitida. Para definir as configurações de firewall para o roteador do roteador, consulte Como criar instâncias do dispositivo do roteador.
  • Certifique-se de que nem o Cloud Router nem a instância do dispositivo do roteador estejam usando endereços link-local (ou seja, 169.254.x.x) para fazer peering entre si. Para mais orientações, consulte Recomendações para alocar endereços IP.
  • Certifique-se de que o Cloud Router tenha estabelecido duas sessões do BGP separadas para a instância do dispositivo do roteador, uma de cada interface do Cloud Router. A instância do dispositivo do roteador precisa anunciar as mesmas rotas nas duas sessões do BGP. Se uma das sessões do BGP ficar inativa e a VM do dispositivo de roteador perder a comunicação com o Cloud Router, verifique a configuração das interfaces do Cloud Router. Para mais informações, consulte Como criar instâncias de dispositivo do roteador.
  • Se a implantação incluir mais de mil VMs, talvez não seja possível estabelecer sessões do BGP entre a instância do dispositivo de roteador e o Cloud Router. Esse limite de mil VMs inclui qualquer VM acessível por meio do peering de rede VPC.

Problemas com endereços IP internos para sessões do BGP em instâncias de dispositivo do roteador

Se você descobrir problemas relacionados à configuração do seu endereço IP para instâncias de dispositivo do roteador, verifique se configurou endereços IP internos RFC 1918 para sessões do BGP entre o Cloud Router e as VMs atuando como instâncias do dispositivo do roteador.

As instâncias do dispositivo do roteador não usam endereços 169.254.x.x para sessões do BGP. Em vez disso, eles precisam usar endereços IP na mesma sub-rede VPC que o Cloud Router. Para mais informações, consulte Como criar instâncias de dispositivo do roteador.