Resolver problemas de configuração, Cloud Router, autenticação e processamento de rotas

Use o guia a seguir para solucionar problemas comuns com o Cloud Router:

Para mais ajuda, consulte a seguinte documentação:

Problemas de configuração

Falha ao criar a sessão do BGP

Verifique se as configurações no roteador do BGP local e no roteador do Cloud Router estão corretas. Para ver informações detalhadas, consulte os registros do Cloud Router.

Se você estiver criando um túnel do Cloud VPN, verifique se o status do túnel é ESTABLISHED. Se não for, consulte a Solução de problemas do Cloud VPN.

Endereços IP para sessões do BGP

Os endereços IP que podem ser usados para uma sessão do BGP dependem de qual produto de conectividade de rede você usa. Para detalhes completos, consulte Endereços IP do BGP.

Valor inválido para o campo resource.bgp.asn

O seguinte erro pode ser exibido:

"Valor inválido para o campo resource.bgp.asn: ######. O ASN local entra em conflito com o ASN de peering especificado por um roteador na mesma região e rede".

O Cloud Router está tentando estabelecer uma sessão do BGP com um dispositivo local que tem o mesmo ASN que o Cloud Router. Para resolver esse problema, altere o ASN do seu dispositivo ou do Cloud Router.

O iBGP entre Cloud Routers de uma única região não funciona

Embora seja possível criar dois Cloud Routers com o mesmo ASN, o iBGP não é aceito.

Problemas do Cloud Router

As redefinições do BGP originadas do Google Cloud aparecem no seu roteador

As tarefas do Cloud Router são processos de software no plano de controle do Google Cloud que normalmente são migrados de máquina em máquina. Durante essas migrações, o Cloud Router pode ficar inativo por períodos de até 60 segundos. As migrações normais não fazem com que o tráfego fique inativo.

O Cloud Router não está localizado no caminho de dados e não está funcionando como uma chave de camada 3, mas como um gerenciador de programação de rotas. O roteamento é processado pelo anexo da VLAN ou pelo túnel do Cloud VPN.

A mensagem NOTIFICATION_RECEIVED aparece nos registros do Cloud Router

Uma mensagem NOTIFICATION_RECEIVED aparece nos registros do Cloud Router quando o Cloud Router recebe uma mensagem NOTIFICATION do peer BGP. A mensagem NOTIFICATION é um sinal para o Cloud Router de que ela precisa interromper a sessão do BGP.

Quando o Cloud Router recebe uma mensagem NOTIFICATION do peer BGP, o Cloud Router fecha a conexão do BGP com esse peering e remove todas as rotas aprendidas.

O par no nível do BGP pode enviar mensagens NOTIFICATION por vários motivos. Por exemplo, o par pode enviar uma mensagem "Timer de espera expirado".

A mensagem CONFIG_DISABLED aparece nos registros do Cloud Router

Uma mensagem CONFIG_DISABLED indica que o Cloud Router interrompeu intencionalmente a sessão do BGP. Ao interromper a sessão do BGP, o Cloud Router tenta comunicar imediatamente um estado de erro ao peering.

Essa mensagem pode aparecer por um destes motivos:

  • Um usuário desativou a sessão do BGP usando a API Cloud Router, o Console do Google Cloud ou a Google Cloud CLI. Consulte Como desativar ou remover sessões do BGP.
  • Para uma sessão do BGP configurada para o Cloud VPN, o túnel da VPN associado à sessão do BGP não estabeleceu uma associação de segurança (IKE, na sigla em inglês) e IKE. Para resolver problemas de conectividade da VPN, consulte Solução de problemas do Cloud VPN.
  • Para uma sessão do BGP configurada para o Cloud Interconnect, o anexo da VLAN não está configurado ou está em estado de administrador inativo. Para resolver o problema, consulte Solução de problemas na documentação do Cloud Interconnect.
  • Para uma sessão do BGP ativada para BFD, o temporizador de detecção de controle de BFD no Cloud Router expirou. Quando isso ocorre, a sessão do BGP é interrompida. Para saber mais sobre os estados da sessão do BFD, consulte Mensagens de diagnóstico e estados da sessão do BFD.

Uma mensagem LINK_DOWN aparece nos registros do Cloud Router quando o link entre o roteador de borda de peering do Google e o anexo da VLAN para o Cloud Interconnect está inativo. O roteador de borda de peering é um equipamento de rede gerenciado pelo Google dentro da instalação de colocation em que você provisionou a conexão do Cloud Interconnect.

A mensagem LINK_DOWN é um sinal de que o status de peering do BGP correspondente está inativo. Essa mensagem se aplica apenas às sessões do BGP baseadas no Cloud Interconnect.

O roteador local apresenta oscilações do BGP

Os flaps do BGP podem ser causados por vários problemas, incluindo manutenção de software e reinicializações automáticas de tarefas do Cloud Router.

Para ver detalhes sobre eventos de manutenção concluídos, consulte Como identificar eventos de manutenção do roteador. Para ver detalhes sobre outros eventos do Cloud Router, consulte Como visualizar registros e métricas do Cloud Router.

Um evento de manutenção do Cloud Router não é indicativo de problema se o roteador local estiver configurado da seguinte maneira:

  • O roteador local pode processar notificações de reinicialização informada.
  • O timer de espera do roteador local está definido como pelo menos 60 segundos.

Para uma visão geral abrangente das configurações de timer, consulte Como gerenciar timers do BGP.

Para obter ajuda ao monitorar a conectividade, consulte Verificar a conectividade entre o roteador local e o Cloud Router.

Problemas de autenticação

As seções a seguir descrevem problemas que podem ocorrer com a autenticação do MD5.

O status do peering do BGP é MD5_AUTH_INTERNAL_PROBLEM

Às vezes, o status de um peering de BGP inclui os seguintes valores:

  • md5AuthEnabled: true
  • statusReason: MD5_AUTH_INTERNAL_PROBLEM

O primeiro valor indica que você configurou a autenticação MD5. No entanto, o segundo valor, statusReason, de MD5_AUTH_INTERNAL_PROBLEM, indica que um erro interno impediu o Cloud Router de configurar a autenticação MD5. Por isso, o status da sessão do BGP é DOWN. Nesse caso, você não precisa fazer nada. O Cloud Router tenta recuperar e reativar a sessão. Se a sessão estiver demorando mais de uma hora para fazer backup, entre em contato com o suporte do Google Cloud.

Para saber como verificar o status do peering, consulte Verificar o status da autenticação.

O Cloud Router e o terminal usam diferentes chaves MD5

Quando você configura a autenticação MD5, o Cloud Router e o roteador de peering dele precisam usar a mesma chave de autenticação secreta. Se ocorrer uma incompatibilidade, os dois roteadores não poderão se comunicar. Se você acha que houve uma incompatibilidade, uma solução é atualizar a chave usada pelo Cloud Router. Para saber mais sobre como fazer essa alteração, consulte Atualizar a chave de autenticação.

Se você não tiver certeza se houve uma incompatibilidade de chaves, procure soluções de problemas na documentação do roteador de mesmo nível. Muitos roteadores têm registros que registram se houve ou não uma incompatibilidade de chave.

A chave MD5 gerada automaticamente é mais longa do que o dispositivo local

Você pode gerar automaticamente a chave MD5 clicando em Gerar e copiar no console da IU. Para mais informações, consulte Adicionar autenticação a uma sessão existente. Se a chave MD5 gerada automaticamente for maior do que a compatibilidade com o local, é possível configurá-la manualmente por meio da IU, da gcloud ou da API.

Problemas de processamento de rota

As rotas locais sem um valor MED estão recebendo prioridade

Se o Cloud Router receber uma rota local que não tenha um valor MED, o Cloud Router seguirá o comportamento descrito no RFC 4271. O Cloud Router processa a rota com a prioridade mais alta ao adotar o valor MED mais baixo possível (0).

Não é possível enviar e aprender valores MED por meio de uma conexão de interconexão por parceiro nível 3

Se você estiver usando uma Interconexão por parceiro em que um provedor de serviços da Camada 3 gerencia o BGP para você, o Cloud Router não aprende valores MED do seu roteador local nem envia valores MED a esse roteador. Isso ocorre porque os valores MED não são transmitidos por meio de sistemas autônomos. Nesse tipo de conexão, não é possível definir prioridades de rota anunciadas pelo Cloud Router para seu roteador local. Além disso, não é possível definir prioridades para rota divulgadas pelo roteador local para sua rede VPC.

Alguns prefixos de IP locais não estão disponíveis

Se alguns prefixos de IP locais não estiverem disponíveis, verifique as cotas e os limites ou os intervalos de sub-rede sobrepostos.

As rotas aprendidas estão inativas

Se você configurou uma rota aprendida personalizada, mas está com perda de tráfego, erros de ping ou outros problemas relacionados à rota, faça o seguinte:

  • Verifique se a rota está configurada corretamente na sessão do BGP.

  • Verifique se a sessão do BGP está ativa.

Para mais informações, consulte Verificar o status de rotas aprendidas.

Verificar cotas e limites

Verifique se os Cloud Routers não excederam os limites para rotas aprendidas. Para ver o número de rotas aprendidas, confira o status do Cloud Router.

Para informações sobre os limites, as mensagens de registro relacionadas e as métricas e como resolver problemas, consulte a tabela a seguir.

Limites Orientação
Sobre os limites

Há dois limites para as rotas aprendidas. Esses limites não definem diretamente um número máximo de rotas aprendidas. Em vez disso, eles definem o número máximo de prefixos de destino exclusivos:

  • Número máximo de destinos exclusivos para rotas aprendidas que podem ser aplicados a sub-redes em uma determinada região por todos os Cloud Routers na mesma região
  • Número máximo de destinos exclusivos para rotas aprendidas que podem ser aplicados a sub-redes em uma determinada região por todos os Cloud Routers em regiões diferentes

O primeiro limite é relevante, independentemente do modo de roteamento dinâmico usado pela rede VPC. O segundo limite só faz sentido se a rede VPC usar o modo de roteamento dinâmico global. Para ver detalhes sobre os limites do Cloud Router, consulte Limites.
Registros Quando você encontrar um desses limites, verá uma mensagem limit-exceeded no Cloud Logging. Para informações sobre como criar uma consulta avançada para visualizar esta mensagem, veja a consulta relacionada na documentação de geração de registros do Cloud Router.
Métrica

Você também pode usar as métricas a seguir para entender seus limites e uso atuais. Essas métricas são precedidas por router.googleapis.com/dynamic_routes/learned_routes/:

  • used_unique_destinations

    Número de destinos exclusivos que estão atualmente em uso nesta rede VPC. Se o roteamento dinâmico global estiver ativado, essa métrica mostrará uso global e regional.

  • unique_destinations_limit

    Número de destinos exclusivos que podem anunciar nessa rede VPC. Se o roteamento dinâmico global estiver ativado, esta métrica mostrará limites globais e regionais.

  • any_dropped_unique_destinations

    Indica se essa rede VPC tem destinos que foram descartados devido a um ou ambos os limites da cota de rota.

Essas métricas estão disponíveis por meio do recurso monitorado gce_network_region. Para mais informações sobre as métricas do Cloud Router e como visualizá-las, consulte a seção Métricas em Como ver registros e métricas.
Como resolver problemas

Faça o seguinte para resolver problemas de limite de rota. Nas situações em que o número de rotas excede muito os limites, faz sentido fazer as duas coisas:

  • Configurar os roteadores locais para agregar as rotas que você exporta, para que essas rotas divulguem menos destinos (CIDRs).
  • Entrar em contato com o suporte. O suporte pode trabalhar com você para redefinir seus Cloud Routers, se necessário, ou para aumentar os limites.

Verificar intervalos de sub-rede sobrepostos

Verifique se os intervalos de endereços IP de uma sub-rede VPC não se sobrepõem completamente às divulgações de rota da rede local. Intervalos IP sobrepostos fazem com que as rotas sejam descartadas. Isso também se aplica a rotas estáticas personalizadas que se sobrepõem a uma rota dinâmica aprendida pelo Cloud Router. Os prefixos recebidos pelos Cloud Routers são ignorados (rotas dinâmicas personalizadas não são criadas) nos seguintes cenários:

  • Quando o prefixo aprendido corresponde exatamente a um intervalo de endereços IP primário ou secundário de uma sub-rede na sua rede VPC.
  • Quando o prefixo aprendido corresponde exatamente ao destino de uma rota estática personalizada na rede VPC.
  • Quando o prefixo aprendido é mais específico (tem uma máscara de sub-rede mais longa) do que o intervalo de endereços IP primário ou secundário de uma sub-rede na sua rede VPC.
  • Quando o prefixo aprendido é mais específico (tem uma máscara de sub-rede mais longa) do que o destino de uma rota estática personalizada na sua rede VPC.

Para mais informações, consulte Aplicabilidade e ordem das rotas na visão geral de Rotas da VPC.

Rotas aprendidas de uma rede local não são propagadas para outras redes VPC

Um único Cloud Router não pode divulgar novamente as rotas aprendidas de um peering do BGP para outros, inclusive para Cloud Routers em outras redes VPC.

Por exemplo, na topologia de hub e spoke a seguir, o Cloud Router não é compatível com a divulgação de rota entre várias redes VPC.

"Hub and spoke" do Cloud Router.
"Hub and spoke" do Cloud Router (clique para ampliar)

Para analisar as recomendações de topologias de rede no Google Cloud, consulte Práticas recomendadas e arquiteturas de referência para o design da VPC.

Além disso, é possível usar o Network Connectivity Center para criar e gerenciar topologias de hub e spoke no Google Cloud.

Os prefixos não estão sendo importados para as sessões do BGP (prefixo de caminho AS)

A inclusão de caminho AS é irrelevante para o plano de controle e a rede VPC. O tamanho do caminho AS é considerado apenas em cada tarefa de software do Cloud Router, conforme descrito nos cenários a seguir.

Se uma única tarefa do software do Cloud Router aprender o mesmo destino em duas ou mais sessões do BGP:

  • A tarefa de software escolhe uma sessão do BGP do próximo salto com o tamanho do caminho AS mais curto.
  • A tarefa de software envia informações de destino, próximo salto e MED para o plano de controle do Cloud Router.
  • O plano de controle usa as informações para criar uma ou mais rotas candidatas. A prioridade básica de cada candidato é definida como MED recebida.

Se duas ou mais tarefas de software do Cloud Router aprenderem o mesmo destino em duas ou mais sessões do BGP:

  • cada tarefa de software escolhe uma sessão do BGP de próximo salto com o tamanho do caminho AS mais curto;
  • cada tarefa de software envia informações de destino, próximo salto e MED para o plano de controle do Cloud Router;
  • o plano de controle usa as informações para criar dois ou mais trajetos possíveis. A prioridade básica de cada candidato é definida como MED recebida.

Em seguida, o plano de controle do Cloud Router instala uma ou mais rotas dinâmicas na rede VPC, de acordo com o modo de roteamento dinâmico da rede VPC. No modo de roteamento dinâmico global, a prioridade de cada rota dinâmica regional é ajustada em regiões diferentes da região do Cloud Router. Para detalhes sobre como o Google Cloud seleciona uma rota, consulte Ordem de roteamento na documentação da VPC.

Em uma VM com várias NICs, cada NIC recebe rotas diferentes

Esse é o comportamento esperado. É preciso configurar cada controlador de interface de rede (placa de rede) para uma VM com várias placas de rede em uma rede VPC exclusiva. Cada Cloud Router cria rotas dinâmicas personalizadas em uma rede VPC. Portanto, as rotas aprendidas por um Cloud Router são aplicáveis apenas a uma interface de rede de uma VM com várias placas de rede. Pacotes enviados da interface de rede de uma VM usam apenas as rotas aplicáveis à rede VPC dessa interface.

O tráfego está sendo roteado de maneira assimétrica

O tráfego é roteado de maneira assimétrica quando os tráfegos de entrada e saída usam caminhos diferentes. Por exemplo, é possível ter dois túneis do Cloud VPN. O tráfego de saída da sua rede VPC usa o primeiro túnel, enquanto que o tráfego de entrada na sua rede VPC usa o segundo túnel.

O roteamento assimétrico acontece quando o caminho preferido divulgado pelo roteador local e pelo Cloud Router não se alinha. Para o tráfego de entrada na sua rede VPC, use o Cloud Router para configurar prioridades de rota divulgadas. Para mais informações, consulte Rotas aprendidas.

Verifique a documentação do dispositivo para saber como funciona a seleção do melhor caminho do BGP, já que outros atributos, como ID do roteador ou ASN de origem, podem afetar o processo. Por exemplo, consulte os seguintes recursos:

Para o tráfego de saída da sua rede VPC, verifique o valor MED do roteador local.

A rota padrão (0.0.0.0/0 ou ::/0) está enviando tráfego para o gateway da Internet

Quando você cria uma rede VPC, o Google Cloud cria automaticamente uma rota padrão com prioridade 1000, em que próximo salto é o gateway da Internet padrão.

Rotas com um próximo salto do gateway padrão da Internet só podem ser usadas por VMs que atendem aos requisitos de acesso à Internet.

O uso de rotas com um próximo salto do gateway da Internet padrão também é necessário para acessar as APIs e os serviços do Google, por exemplo, ao usar o Acesso privado do Google.

Os exemplos a seguir descrevem situações que podem fazer com que o tráfego na Internet ou nas APIs e serviços do Google seja bloqueado:

  • Se você excluir a rota padrão criada automaticamente, isto é, a rota com um próximo salto do gateway da Internet padrão.
  • Se você substituir a rota padrão criada automaticamente e o próximo salto da rota de substituição for diferente do gateway da Internet padrão.
  • Se um Cloud Router aprender uma rota com destino 0.0.0.0/0 ou ::/0 que tenha uma prioridade mais alta do que a rota padrão criada automaticamente.

O próximo salto não está claro

Para saber como funciona o algoritmo de seleção de rotas do Google Cloud, consulte Aplicabilidade e pedido na documentação de Rotas da VPC.

O tráfego IPv6 não está sendo roteado

Se você estiver com dificuldade para se conectar a hosts IPv6, faça o seguinte:

  1. Verifique se as rotas IPv4 estão sendo anunciadas corretamente. Se as rotas IPv4 não estiverem sendo divulgadas, execute os procedimentos gerais de solução de problemas listados neste documento.
  2. Inspecione as regras de firewall para garantir que você permita o tráfego IPv6 entre a rede VPC e a rede local.
  3. Verifique se não há intervalos de sub-rede IPv6 sobrepostos na rede VPC e na rede local. Consulte Verificar a sobreposição de intervalos de sub-redes.
  4. Verifique se você excedeu as cotas e os limites das rotas aprendidas. Se você exceder a cota das rotas aprendidas, os prefixos IPv6 serão descartados antes dos prefixos IPv4. Consulte Verificar cotas e limites.
  5. Verifique se todos os componentes que exigem a configuração do IPv6 foram configurados corretamente.
    • A sub-rede VPC é configurada para usar o tipo de pilha IPV4_IPV6.
    • A sub-rede VPC tem --ipv6-access-type definido como INTERNAL.
    • As VMs do Compute Engine na sub-rede são configuradas com endereços IPv6.
    • O gateway da VPN de alta disponibilidade ou o anexo da VLAN para a Interconexão dedicada está configurado para usar o tipo de pilha IPV4_IPV6.
    • O peering do BGP está ativado para usar IPv6, e os endereços corretos do próximo salto do IPv6 são configurados para a sessão do BGP.

A seguir