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:
- Verifique a funcionalidade dos túneis de VPN de alta disponibilidade ou anexos da VLAN que são adicionados como spokes.
- Verifique as rotas programadas entre os dois locais.
- Verifique se as atribuições de ASN estão configuradas conforme descrito em Requisitos do ASN para recursos spoke.
- Verifique se cada spoke tem o campo de transferência de dados site a site definido como
true
.
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:
- Duas redes que não são do Google Cloud conectadas por meio do 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.
- Duas redes VPC conectadas por um hub do Network Connectivity Center.
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 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:
- Resolver problemas de sessões do BGP
- Resolver problemas de peering do BGP
- Resolver problemas de rotas do BGP e seleção de rota
- Resolver problemas de mensagens de registro do Cloud Router
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 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 que você exclui um spoke, os seguintes períodos de espera são aplicados:
- Aguarde um período de espera de pelo menos 10 minutos antes de criar um novo spoke para a mesma rede VPC conectada ao mesmo hub.
- Para um novo spoke para a mesma rede VPC anexado a um hub diferente, aguarde o período de espera de pelo menos 24 horas.
- É possível que a criação do spoke para a mesma rede VPC não tenha os filtros aplicados corretamente. A solução alternativa é excluir o spoke, aguardar um período mais longo e recriá-lo.
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 encaminhamentoREGION_ID
: o ID da regiãoPROJECT_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 comandogcloud 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 hubPROJECT_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 spokePROJECT_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 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.