Resolver problemas do Network Connectivity Center

Saiba mais sobre as etapas de solução de problemas que podem ser úteis se você tiver problemas ao usar o Network Connectivity Center, spokes híbridos, spokes de VPC e propagação de conexão do Private Service Connect.

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

Problemas comuns com a sintaxe do comando

Ao atualizar um spoke, é preciso especificar o local em que ele está.

Anexar recursos a spokes

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

As rotas não são distribuídas entre as regiões

Se as rotas não estiverem sendo distribuídas corretamente entre as regiões, verifique se o modo de roteamento dinâmico da rede VPC está definido como global.

O tráfego de transferência de dados não flui entre duas redes que não são do Google Cloud

Nesse contexto, uma rede que não é do Google Cloud refere-se ao seu data center local, a uma filial ou à rede de outro provedor de nuvem.

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:

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.

Conexão de interconexão com um local sem suporte (rede que não seja do Google Cloud)

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:

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. Assim, o tráfego da rede local para a rede VPC é sempre considerado válido pela análise de configuração dos Testes de conectividade, e somente as configurações no 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.

Resolver problemas de spokes híbridos

O problema a seguir pode ocorrer em spokes de dispositivo roteador, anexo da VLAN e VPN.

As sub-redes configuradas do hub não são divulgadas para uma rede local

Se as sub-redes configuradas do hub não forem divulgadas para a rede local (pré-lançamento), verifique a tabela de rotas do hub do grupo de spokes híbridos em relação aos os seguintes problemas:

  • Se as sub-redes forem exibidas na tabela de rotas do hub, faça isto:

  • Se as sub-redes não estiverem na tabela de rotas do hub, faça isto:

    • Verifique os intervalos de endereços IP de inclusão/exportação e exclusão/exportação no spoke do VPC das sub-redes. Se a sub-rede for filtrada por intervalos de inclusão/exportação ou exclusão/exportação, será possível atualizar o spoke da VPC.

Resolver problemas do dispositivo 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.

Para ver mais informações, consulte os seguintes tópicos:

Falha ao estabelecer sessões do BGP

Se as sessões do BGP entre o Cloud Router e o dispositivo roteador não forem estabelecidas, verifique se há 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 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 Criar instâncias de dispositivo do roteador.

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.

Resolver problemas de spokes VPC

Permissões

Se a permissão for negada ao criar um spoke em um projeto diferente do hub, verifique com o administrador do hub se você recebeu a permissão networkconnectivity.groups.use necessária no hub.

Falhas na criação de spoke VPC

Se a criação do spoke da VPC falhou, pode ser por um dos seguintes motivos:

  • A rede VPC já faz peering com um ou mais spokes atuais usando o peering de VPC.
  • As sub-redes se sobrepõem a spokes VPC.
  • As sub-redes se sobrepõem a pares de spokes VPC.
  • Você excedeu a cota de spokes VPC.
  • Você excedeu a cota da tabela de rotas por rota hub.
  • Mais de 16 filtros de exportação foram especificados.
  • As sub-redes na rede VPC são maiores que um ou mais filtros especificados.

Para erros relacionados à cota, consulte Cotas e limites.

Falhas na criação de spokes VPC após a exclusão de um spoke

Depois de excluir um spoke, aguarde um período de espera de pelo menos 10 minutos antes de criar um novo spoke para a mesma rede VPC anexada a um hub diferente. Esse período de espera não será necessário se a rede VPC for adicionada como spoke ao mesmo hub.

Falhas na criação de sub-rede em um spoke VPC

Se você encontrar uma falha de criação de sub-rede em um spoke VPC, pode ser devido a um dos seguintes motivos:

  • Há sub-redes sobrepostas em outros spokes VPC ou pares de spokes VPC.
  • Você excedeu a cota da tabela de rotas por rota hub.
  • As sub-redes na rede VPC são maiores que um ou mais filtros especificados.

O spoke VPC foi criado, mas a conectividade do plano de dados está ausente

Se o spoke VPC estiver aparecendo como criado, mas a conectividade do plano de dados estiver ausente, isso pode ser devido a um dos seguintes motivos:

  • O spoke está em um projeto diferente do hub e o administrador do hub não aceitou a proposta do spoke.
  • Todas as sub-redes na rede VPC são filtradas e excluídas da conectividade.
  • As sub-redes de destino são filtradas pelos filtros de spoke VPC correspondentes.

A tabela de rota de hub não mostra algumas sub-redes em spokes VPC

Se a tabela de rota de hub não mostra algumas das sub-redes nos spokes VPC, pode ser devido a um dos seguintes motivos:

  • As sub-redes são filtradas usando filtros de exportação.
  • As sub-redes foram criadas nos últimos 5 a 10 minutos e a tabela de rotas de hub ainda não foi atualizada.

A VM em um spoke não pode acessar a conexão do Private Service Connect em outro spoke

Se uma VM em um spoke VPC não puder acessar o endpoint do Private Service Connect (Visualização) em outro spoke, verifique os seguintes problemas:

  • Verifique se a conexão do Private Service Connect segmenta um anexo de serviço com base em um endpoint do balanceador de carga de rede de passagem interna. Para mais informações, consulte Sobre como acessar serviços publicados por meio de endpoints.

    Para receber dados associados a uma regra de encaminhamento em um projeto, use o comando gcloud compute forwarding-rules describe.

    gcloud

    gcloud compute forwarding-rules describe FORWARDING_RULE_NAME \
  --region=REGION_ID
  --project=PROJECT_ID
  --format='get(target)'

    Substitua os seguintes valores:

    • FORWARDING_RULE_NAME: o nome da regra de encaminhamento
    • REGION_ID: o ID da região
    • PROJECT_ID: o ID do projeto em que a regra reside

  • Verifique se o campo --export_psc está ativado no hub.

    Para verificar se o campo --export_psc está ativado no hub, use o comando gcloud network-connectivity hubs describe.

    gcloud

    gcloud network-connectivity hubs describe HUB_NAME \
  --project=PROJECT_ID
  --format='get(export_psc)'

    Substitua os seguintes valores:

    • HUB_NAME: o nome do hub
    • PROJECT_ID: o ID do projeto em que o hub reside.

  • Verifique se o endereço do endpoint do Private Service Connect não está em nenhum intervalo de exclusão de exportação do spoke de hospedagem. Os endpoints do Private Service Connect que residem no intervalo de exclusão de exportação não são propagados.

    Para verificar os intervalos de exportação de exclusão especificados de um spoke, use o comando gcloud network-connectivity spokes describe.

    gcloud

    gcloud network-connectivity spokes describe SPOKE_NAME \
  --global \
  --project=PROJECT_ID \
  --format='get(linked_vpc_network.exclude_export_ranges)'

    Substitua os seguintes valores:

    • SPOKE_NAME: o nome do spoke
    • PROJECT_ID: o ID do projeto em que o spoke reside.

  • Verifique se você não excedeu a cota de uso do Network Connectivity Center.

Resolver problemas na troca de rotas de spokes de VPC

Os spokes de VPC e os spokes híbridos estão anexados ao mesmo hub, mas a conectividade do plano de dados está ausente

Se os spokes de VPC e os spokes híbridos estiverem anexados ao mesmo hub mas a conectividade do plano de dados estiver ausente, pode ser devido a um dos seguintes motivos:

  • O spoke é um spoke entre projetos, e o administrador do hub não aceitou a proposta spoke.
  • Todas as sub-redes na rede VPC são filtradas e excluídas da conectividade.
  • A propagação automática de sub-redes de VPC não está ativada ou a divulgação de rotas personalizadas não está configurada.
  • A cota de rotas dinâmicas foi excedida.

A tabela de rotas do hub não mostra algumas rotas dinâmicas ou mostra rotas dinâmicas falsas

A tabela de rotas do hub pode não mostrar as rotas dinâmicas corretamente devido a um dos motivos a seguir:

  • As rotas do BGP foram anunciadas ou retiradas nos últimos 5 a 10 minutos, e a tabela de rotas do hub ainda não foi atualizada.
  • A cota de rotas dinâmicas foi excedida.

Falha na criação do spoke híbrido

Se a criação de um spoke híbrido falhar, pode ser devido a um dos seguintes motivos:

  • A rede VPC de roteamento pode ser um spoke de VPC com o mesmo hub ou com um hub diferente.
  • A rede VPC de roteamento pode estar implicitamente associada a um hub diferente devido a um spoke híbrido conectado a ele. Anexos híbridos de uma rede VPC podem se tornar spokes de apenas um hub.

Falha na criação do spoke de VPC

A criação do spoke de VPC poderá falhar se ele estiver implicitamente associada a um hub como uma rede VPC de roteamento.

Mensagem de erro

Se você tentar criar um spoke e receber a mensagem de erro An internal error occurred, entre em contato com o Suporte do Google Cloud para resolver o problema.