Solução de problemas

Use este guia para solucionar problemas comuns que podem ser encontrados durante a utilização do Cloud Interconnect.

Para encontrar respostas para perguntas comuns sobre a arquitetura e os recursos do Cloud Interconnect, consulte as Perguntas frequentes sobre o Cloud Interconnect.

Para definições de termos usados nesta página, consulte Termos-chave do Cloud Interconnect.

Para encontrar informações de geração de registros e monitoramento e visualizar métricas do Cloud Interconnect, consulte Como monitorar conexões.

Solução de problemas gerais

Verificar se há interrupções no serviço do Cloud Interconnect

  • É possível verificar interrupções conhecidas no Painel de status do Google Cloud. Também é possível se inscrever no Feed JSON ou no Feed RSS do Cloud Incidents para receber atualizações por push.

  • Você é notificado sobre eventos de manutenção que afetam suas conexões da Interconexão dedicada. Para detalhes, consulte Eventos de manutenção de infraestrutura.

  • Você recebe notificações de eventos de manutenção que afetam os anexos da VLAN da Interconexão por parceiro. As notificações da Interconexão por parceiro são enviadas de maneira semelhante às notificações de conexões da Interconexão dedicada, com algumas pequenas diferenças. Para detalhes, consulte Eventos de manutenção de infraestrutura.

Não é possível se conectar a recursos de outras regiões

Por padrão, as redes de nuvem privada virtual (VPC) são regionais, ou seja, o Cloud Router divulga apenas as sub-redes da região dele. Para se conectar a outras regiões, defina o modo de roteamento dinâmico da sua rede VPC como global para que o Cloud Router possa divulgar todas as sub-redes.

Para mais informações, consulte Modo de roteamento dinâmico na documentação do Cloud Router.

Não é possível acessar as VMs em uma rede VPC com peering

Neste cenário, você configurou uma conexão do Cloud Interconnect entre a rede local e a rede VPC, rede A. Você também configurou o peering de rede VPC entre a rede A e outra rede VPC, a rede B. No entanto, não é possível acessar as VMs na rede B pela rede local.

Essa configuração não é compatível, conforme descrito nas restrições da visão geral do peering de rede VPC.

No entanto, é possível usar divulgações de intervalo de IP personalizadas a partir desses roteadores na rede VPC para compartilhar rotas para destinos na rede com peering. Além disso, você precisa configurar suas conexões de peering de rede VPC para importar e exportar rotas personalizadas.

Para mais informações sobre como divulgar rotas entre redes locais e de peering da VPC, consulte os seguintes recursos:

Sub-redes ausentes em uma conexão

Para divulgar todas as sub-redes disponíveis, especifique as rotas ausentes com rotas divulgadas personalizadas e divulgue todas as rotas de sub-rede entre regiões com roteamento dinâmico global. Para isso, siga estas etapas:

  1. Especifique rotas divulgadas personalizadas em uma sessão do Cloud Router e do protocolo de gateway de borda (BGP).

    Para inserir as rotas ausentes, defina os seguintes parâmetros:

    --set-advertisement-groups = ADVERTISED_GROUPS
--set-advertisement-ranges = ADVERTISED_IP_RANGES

    Substitua:

    • ADVERTISED_GROUPS: um grupo definido pelo Google que o Cloud Router divulga dinamicamente. pode ter um valor de all_subnets, que imita o comportamento padrão de um Cloud Router
    • ADVERTISED_IP_RANGES: o conteúdo da nova matriz de intervalos de endereços IP; pode ter um ou mais valores de sua escolha.

    Para mais detalhes e exemplos, consulte Como divulgar intervalos de IP personalizados.

  2. Ative o modo de roteamento dinâmico global.

Não é possível dar um ping no Cloud Router

Se não for possível dar um ping no Cloud Router a partir do roteador local, encontre seu produto na tabela a seguir e execute as etapas de solução de problemas desse produto. As VMs não podem alcançar 169.254.0.0/16.

Etapas para solução de problemas a serem seguidas Interconexão dedicada Interconexão por parceiro com parceiro L3 Interconexão por parceiro com parceiro L2
Na Interconexão por parceiro, o Cloud Router talvez nunca seja capaz de dar ping porque alguns parceiros filtram o tráfego para o intervalo de IP (169.254.0.0/16) do Cloud Router. No caso dos parceiros L3, o BGP é configurado automaticamente pelo parceiro. Se o BGP não aparecer, entre em contato com seu parceiro. Não relevante Sim Não relevante
Verifique se o dispositivo local aprendeu o endereço MAC correto do lado do Google Cloud da conexão. Para mais informações, consulte Solução de problemas de ARP. Sim Não relevante Não relevante
Verifique se o Cloud Router tem uma interface e um par no nível de protocolo BGP. O Cloud Router não é capaz de fazer ping, a menos que a interface e o par no nível de protocolo BGP estejam totalmente configurados, incluindo o ASN remoto.
  • No caso da Interconexão dedicada, consulte A sessão do BGP não está funcionando.
  • No caso da Interconexão por parceiro L2, o Google adicionou a interface e o par no nível de protocolo BGP ao Cloud Router automaticamente, mas será preciso configurar o ASN remoto.
 Sim Não relevante Sim

Solução de problemas de ARP

Na Interconexão dedicada, para encontrar o endereço MAC correto, execute o comando gcloud a seguir:

  gcloud compute interconnects get-diagnostics INTERCONNECT_NAME

O googleSystemID contém o endereço MAC que precisa estar na tabela ARP do dispositivo em endereços IP atribuídos ao Cloud Router.

  result:
    links:
    — circuitId: SAMPLE-0
      googleDemarc: sample-local-demarc-0
      lacpStatus:
        googleSystemId: ''
        neighborSystemId: ''
        state: DETACHED
      receivingOpticalPower:
        value: 0.0
      transmittingOpticalPower:
        value: 0.0
    macAddress: 00:00:00:00:00:00

Se o dispositivo não tiver aprendido um endereço MAC, verifique se o ID da VLAN e o endereço IP corretos estão configurados na subinterface.

Na Interconexão por parceiro, se o endereço MAC incorreto for exibido no dispositivo, verifique se você não conectou os segmentos da camada 2 de dois anexos da VLAN. O lado do Google Cloud da conexão do Cloud Interconnect é configurado com ip proxy-arp (em inglês), que responde a todas as solicitações ARP e pode fazer com que o roteador local aprenda entradas ARP incorretas.

Não é possível criar o anexo da VLAN

Se você tentar criar um anexo da VLAN para Interconexão dedicada ou Interconexão por parceiro que viole uma política da organização, uma mensagem de erro será exibida. Veja o exemplo de mensagem de erro a seguir na execução de gcloud compute interconnects attachments partner create:

ERROR: (gcloud.compute.interconnects.attachments.partner.create) Could not fetch resource:
- Constraint constraints/compute.restrictPartnerInterconnectUsage violated for projects/example-project. projects/example-project/global/networks/example-network is not allowed to use the Partner Interconnect.

Para mais informações, consulte Como restringir o uso do Cloud Interconnect e Usar políticas personalizadas da organização e entre em contato com o administrador da organização.

Compartilhar conexões com outros projetos na organização

Use a VPC compartilhada para compartilhar uma conexão, como um anexo da VLAN ou uma Interconexão dedicada em um projeto host.

Para saber mais sobre como configurar uma rede VPC compartilhada, consulte Como provisionar uma VPC compartilhada.

Para mais informações sobre como configurar anexos em uma rede VPC compartilhada, consulte Opções para se conectar a várias redes VPC.

Interconexão dedicada

O Google não consegue dar um ping durante o provisionamento da conexão

Verifique se você está usando a configuração correta de IP e LACP. Durante o processo de teste, o Google envia diferentes configurações de IP de teste para o roteador local, dependendo do tipo de pacote que você solicitou: de link único ou de vários links. Não configure anexos da VLAN para esses testes.

  • O primeiro conjunto de endereços IP que o Google envia é para testar a conectividade de vários circuitos em cada link individual. Configure os endereços IP de teste em todos os links físicos (sem o LACP configurado), conforme as instruções nos e-mails enviados pelo Google. O Google dá um ping em todos os endereços IP antes que esse primeiro teste seja aprovado.
  • No segundo teste, remova todos os endereços IP do primeiro. Configure o canal de portas com o LACP, mesmo que sua conexão tenha apenas um link. O Google dá um ping no endereço do canal de portas. Não modifique a configuração do LACP do seu canal de porta depois que a conexão for aprovada no teste final. No entanto, remova o endereço IP de teste da interface do canal de portas.
  • O Google envia o endereço IP de produção final para testar a conectividade de circuito único. Configure o endereço IP na interface do pacote (com o LACP configurado, no modo ativo ou passivo), conforme as instruções do e-mail que o Google enviou a você. O Google dá um ping no endereço IP da interface do pacote antes que esse teste seja aprovado. Configure o canal de portas com o LACP, mesmo que sua conexão tenha apenas um link.

Não é possível dar um ping no Cloud Router

  • Verifique se é possível dar um ping no endereço IP do canal de portas do Google. O valor do endereço IP é googleIpAddress quando você visualiza os detalhes da conexão.
  • Verifique se a VLAN correta é usada na subinterface do roteador local. As informações da VLAN precisam corresponder às informações fornecidas pelo anexo da VLAN.
  • Verifique se o endereço IP correto é usado na subinterface do roteador local. Quando você cria um anexo da VLAN, ele aloca um par de endereços IP de link local. Um é destinado a uma interface em um Cloud Router (cloudRouterIpAddress) e o outro é para uma subinterface no canal de portas do roteador local, não para o próprio canal de portas (customerRouterIpAddress).
  • Se você estiver testando o desempenho dos anexos da VLAN, não dê um ping no Cloud Router. Em vez disso, crie e use uma instância de máquina virtual (VM, na sigla em inglês) do Compute Engine na sua rede VPC. Para mais informações, consulte Teste de desempenho.

A sessão do BGP não funciona

  • Ative o BGP de vários saltos no roteador local com pelo menos dois saltos.
  • Verifique se você tem o endereço IP vizinho correto configurado no roteador local. Use o endereço IP de peering do BGP (cloudRouterIpAddress) que foi alocado pelo anexo da VLAN.
  • Verifique se a configuração do ASN no roteador local corresponde ao ASN de peering no Cloud Router. Além disso, verifique se a configuração do ASN local no Cloud Router corresponde ao ASN de mesmo nível no roteador local.

  • Cada anexo recebe um CIDR /29 exclusivo de 169.254.0.0/16 na sua rede VPC. Um endereço IP no CIDR /29 está alocado para o Cloud Router e o outro para seu roteador local.

    Verifique se os endereços IP corretos estão alocados para a interface do roteador local e para o vizinho do BGP. Um erro comum é configurar um /30 na interface de roteador local, em vez de um /29. O Google Cloud reserva todos os outros endereços no CIDR /29.

    Verifique que você não alocou nenhum outro IP desse CIDR à interface de anexo da VLAN no seu roteador.

Não é possível acessar as VMs na rede VPC

  • Verifique se é possível executar o ping no canal da portas e no anexo da VLAN.
  • Verifique se a sessão BGP está ativa.
  • Verifique se o roteador local está divulgando e recebendo rotas.
  • Verifique se não há sobreposições entre suas divulgações de rota locais e os intervalos de rede do Google Cloud.
  • Defina o tamanho da MTU com os mesmos valores para o roteador local, a VPC e o anexo da VLAN.

O tráfego IPv6 não está passando pelo anexo da VLAN

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

  1. Verifique se as rotas IPv6 estão sendo divulgadas corretamente. Se as rotas IPv6 não estiverem sendo divulgadas, consulte Resolver problemas de rotas do BGP e seleção de rota.
  2. Inspecione as regras de firewall para garantir a permissão de tráfego IPv6.
  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. Determine se você excedeu as cotas e os limites das rotas aprendidas no Cloud Router. 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 relacionados à configuração do IPv6 foram definidos corretamente.

    • A rede VPC permitiu o uso de endereços IPv6 internos com a sinalização --enable-ula-internal-ipv6.
    • 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 anexo da VLAN está configurado para usar o tipo de pilha IPV4_IPV6.

    • O peering do BGP ativou o IPv6 e os endereços corretos do próximo salto do IPv6 estão configurados para a sessão do BGP.

Não é possível criar um anexo da VLAN com o tipo de pilha dupla (IPv4 e IPv6)

A criação de um anexo da VLAN com o tipo de pilha IPv4 e IPv6 (pilha dupla) falha com a seguinte mensagem de erro:

Cannot create a dual stack interconnect attachment. Dual stack attachment can only be used
with a provisioned interconnect attachments that have Dataplane version 2.

Para corrigir esse problema:

  1. Confira a tabela Todas as instalações de colocation para ver quais regiões aceitam a criação de anexos no Dataplane v2.

  2. Se a região não estiver na lista, recrie o anexo em uma região aceita.

Não é possível modificar um anexo da VLAN que já existe para usar o tipo de pilha dupla (IPv4 e IPv6)

A atualização de um anexo da VLAN atual para usar o tipo de pilha IPv4 e IPv6 (pilha dupla) falha com a seguinte mensagem de erro:

Cannot create a dual stack interconnect attachment. Dual stack attachment can only
be used with a provisioned interconnect attachments that have Dataplane version 2.

Para corrigir esse problema:

  1. Verifique a versão do Dataplane do anexo e se ele está usando o Dataplane versão 1. Consulte Verificar a versão do Dataplane de um anexo.

  2. Recrie o anexo em uma região compatível com a criação de todos os novos anexos no Dataplane v2. Para ver uma lista de regiões, consulte Todas as instalações de colocation.

Teste de desempenho nos anexos da VLAN

Se for preciso testar o desempenho dos anexos da VLAN, use uma VM na sua rede VPC. Adicione as ferramentas de desempenho necessárias na VM. Não use o endereço IP de link local do Cloud Router para testar a latência, como o ping ICMP ou MTU do caminho. O uso do Cloud Router pode gerar resultados imprevisíveis.

Receber diagnósticos

Para informações técnicas atualizadas e detalhadas sobre o lado do Google Cloud de uma conexão de Interconexão dedicada sob demanda, consulte Receber diagnósticos.

Interconexão por parceiro

A sessão do BGP não está funcionando (conexões da camada 2)

  • Verifique se o roteador local foi configurado com uma sessão do BGP para os Cloud Routers. Para mais informações, consulte Como configurar roteadores locais para a Interconexão por parceiro.
  • Ative o BGP de vários saltos no roteador local com pelo menos dois saltos.
  • Verifique se você tem o endereço IP vizinho correto configurado no roteador local. Use o endereço IP de peering do BGP (cloudRouterIpAddress) que foi alocado pelo anexo da VLAN.
  • Verifique se a configuração do ASN no roteador local corresponde ao ASN de peering no Cloud Router (16550). Além disso, verifique se a configuração do ASN local no Cloud Router corresponde ao ASN de perring no roteador local.

A sessão do BGP não está funcionando (conexões da camada 3)

  • O Cloud Router precisa ser configurado com o ASN do seu provedor de serviços. Entre em contato com seu provedor de serviços para receber ajuda.

Anexo da VLAN desativado para uma conexão da Interconexão por parceiro

O status de um anexo da VLAN pode aparecer como inativo, mesmo se não houver problemas com a configuração do Google Cloud e com a conexão da Interconexão por parceiro.

Verifique se você configurou o EBGP de vários saltos no roteador local para ter pelo menos quatro saltos. Veja uma configuração de amostra em Como configurar roteadores locais.

Problema de pareamento de chave em uma conexão da Interconexão por parceiro

Ao tentar configurar uma conexão da Interconexão por parceiro, é possível encontrar uma mensagem de erro como "Google - Status do provedor não disponível". Para corrigir esse problema, siga estas etapas:

  1. Verifique se a chave de pareamento foi gerada pelo anexo da VLAN do lado do cliente (tipo PARTNER). A chave é uma string longa e aleatória usada pelo Google para identificar o anexo. A região de destino do Google Cloud e o domínio de disponibilidade de borda são codificados na chave de pareamento no seguinte formato:

    <random_string>/<region_name>/<domain>

    O campo domain conterá a string any se o anexo da VLAN não for restrito a um domínio específico ou se você não especificar o domínio de disponibilidade de borda. Para mais informações sobre as chaves de pareamento, consulte chave de pareamento.

  2. Verifique se o domínio de disponibilidade de borda da conexão da Interconexão por parceiro corresponde ao domínio especificado pela chave de pareamento.

Não é possível dar um ping no Cloud Router (conexões da camada 2)

  • Verifique se está usando o anexo da VLAN correto na subinterface do roteador local. As informações do anexo da VLAN precisam corresponder às informações fornecidas pelo provedor de serviços.
  • Verifique se o endereço IP correto é usado na subinterface do roteador local. Depois que o provedor de serviços configura o anexo da VLAN, o anexo aloca um par de endereços IP de link local. Um é destinado a uma interface no Cloud Router associado (cloudRouterIpAddress) e o outro é para uma subinterface no canal de portas do roteador local, não ao próprio canal de portas (customerRouterIpAddress).
  • Se você estiver testando o desempenho dos anexos, não dê um ping no Cloud Router. Em vez disso, crie e use uma VM na rede VPC. Para mais informações, consulte Teste de desempenho.

Perda de energia ótica na porta da conexão da Interconexão por parceiro

Se houver perda de energia ótica em uma porta, talvez haja um dos seguintes problemas:

  • Perda de conectividade da camada 3 (perda de uma sessão do BGP) ou incapacidade de acessar suas instâncias de VM do Google Cloud.
  • Desempenho degradado do seu pacote de links. Esse problema ocorrerá se várias portas de 10 GE forem agrupadas e apenas alguns dos links em um pacote estiverem funcionando.

A perda de potência óptica em uma porta significa que o hardware não consegue detectar um sinal da outra extremidade. Isso pode ser causado por um dos seguintes problemas:

  • Um transceptor com defeito
  • Um sistema de transporte com defeito
  • Um problema de fibra física

Para corrigir esse problema, entre em contato com seu parceiro de interconexão e/ou provedor de circuito. Eles podem executar as seguintes etapas:

  1. Verifique se o transceptor está funcionando.
  2. Execute um loop rígido para a Meet-Me Room (MMR) para verificar se os níveis de iluminação no dispositivo estão funcionando como esperado.
  3. Verifique se os problemas estão do lado deles ou do Google. A melhor maneira de isolar a interface é colocar um loop bidirecional no demarc. As interfaces de cada lado transmitirão a luz para o demarc, onde ele voltará para si mesmo. O lado defeituoso será o lado do demarc que não aparece de maneira limpa.
  4. Limpe e recoloque toda a fibra no lado dele.

Não é possível enviar e aprender valores MED por meio de uma Interconexão por parceiro L3

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.

O tráfego IPv6 não está funcionando após alterar o tipo de pilha de um anexo para pilha dupla

  1. Confira o status do Cloud Router e verifique se status: UP é exibido.

    Se o BGP não estiver ativo, faça o seguinte:

    1. Confirme se o roteador local (ou o roteador do seu parceiro, se você estiver usando um parceiro de camada 3) está configurado com uma sessão IPv6 do BGP e se a sessão está usando os endereços IPv6 corretos.

    2. Visualize a configuração da sessão do BGP e verifique se bgpPeers.enable exibe 'TRUE' para seu Cloud Router.

    Se o BGP estiver ativo, confira as rotas do Cloud Router para verificar se os best_routes do IPv6 esperados são exibidos.

    Se os best_routes esperados não forem exibidos, confirme se o roteador local (ou o roteador do seu parceiro, se você estiver usando um parceiro de camada 3) está configurado com as rotas IPv6 corretas.

Todos os outros problemas

Para receber mais assistência, entre em contato com seu provedor de serviços. Se necessário, seu provedor de serviços entrará em contato com o Google para corrigir problemas relacionados à rede do Google.

VPN de alta disponibilidade pelo Cloud Interconnect

Ao implantar a VPN de alta disponibilidade pelo Cloud Interconnect, você cria dois níveis operacionais:

  • O nível do Cloud Interconnect, que inclui os anexos da VLAN e o Cloud Router para Cloud Interconnect.
  • O nível da VPN de alta disponibilidade, que inclui gateways e túneis de VPN de alta disponibilidade e o Cloud Router para VPN de alta disponibilidade.

Cada nível requer um Cloud Router próprio:

  • O Cloud Router do Cloud Interconnect é usado exclusivamente para trocar prefixos de gateway da VPN entre os anexos da VLAN. Esse Cloud Router é usado apenas pelos anexos da VLAN do nível do Cloud Interconnect. Ele não pode ser usado no nível da VPN de alta disponibilidade.
  • O Cloud Router para VPN de alta disponibilidade troca prefixos entre a rede VPC e a rede local. Você configura o Cloud Router para VPN de alta disponibilidade e suas sessões do BGP da mesma forma que para uma implantação regular de VPN de alta disponibilidade.

Crie o nível de VPN de alta disponibilidade com base no nível do Cloud Interconnect. Portanto, o nível da VPN de alta disponibilidade exige que o nível do Cloud Interconnect, baseado em uma Interconexão dedicada ou em uma Interconexão por parceiro, esteja configurado e operacional corretamente.

Para resolver problemas de uma VPN de alta disponibilidade na implantação do Cloud Interconnect, primeiro resolva o nível do Cloud Interconnect. Depois de verificar se o Cloud Interconnect está funcionando corretamente, solucione os problemas do nível da VPN de alta disponibilidade.

Não é possível criar um anexo da VLAN criptografado

A criação do anexo da VLAN criptografado falha com a seguinte mensagem de erro:

  Cannot create an interconnect attachment with IPSEC encryption.
  IPSEC encryption can only be used with a provisioned interconnect attachments
  that have Dataplane version 2.

Para corrigir esse problema, siga estas etapas:

  1. Confira a tabela Todas as instalações de colocation para ver quais regiões são compatíveis com a criação de anexos no Dataplane v2.

  2. Se a região não estiver na lista, recrie o anexo em uma região aceita.

Não foi possível estabelecer uma sessão BGP para o Cloud Router do Cloud Interconnect

Para detectar se a sessão do BGP associada ao anexo da VLAN está inativa, execute o seguinte comando:

   gcloud compute routers get-status INTERCONNECT_ROUTER_NAME

Substitua INTERCONNECT_ROUTER_NAME pelo nome do Cloud Router criado para o nível do Cloud Interconnect da VPN de alta disponibilidade na implantação do Cloud Interconnect.

Para corrigir esse problema, siga estas etapas:

  1. Siga as etapas em Como testar conexões e Receber diagnósticos para garantir que a conexão do Cloud Interconnect subjacente esteja íntegra.
  2. Verifique se a interface da sessão do BGP está apontando para o anexo correto.
  3. Verifique os endereços IP configurados para a interface da sessão do BGP no Cloud Router e no roteador local.
  4. Verifique se os números de ASN estão configurados corretamente no Cloud Router e no roteador local.
  5. Verifique se a conexão do Cloud Interconnect e o anexo da VLAN estão no estado admin-enabled.

Não foi possível estabelecer um túnel de VPN de alta disponibilidade

Para verificar o estado do túnel, execute o comando:

gcloud compute vpn-tunnels describe VPN_TUNNEL_NAME

Substitua VPN_TUNNEL_NAME pelo nome do túnel da VPN de alta disponibilidade.

Para corrigir esse problema, siga estas etapas:

  1. Como o túnel VPN é roteado por um anexo da VLAN, verifique se a sessão do BGP associada ao anexo da VLAN foi estabelecida. Caso contrário, consulte Não é possível estabelecer a sessão do BGP para o Cloud Router para o Cloud Interconnect.
  2. Verifique se as criptografias PSK e PSK do túnel estão configuradas corretamente nos gateways da VPN do Cloud e nos gateways da VPN local.
  3. Verifique se o anúncio do BGP do roteador local inclui os endereços de gateway da VPN local. Caso contrário, ajuste a configuração do BGP do roteador local para divulgar os endereços.
  4. Verifique se as rotas para gateways da VPN local não foram descartadas por causa de conflitos com as rotas atuais do BGP. Se houver conflitos, ajuste os endereços do gateway da VPN ou as rotas divulgadas.

  5. Verifique se o anúncio do BGP do Cloud Router inclui os endereços de gateway da VPN de alta disponibilidade. Verifique isso no roteador local ou inspecionando o campo advertisedRoutes do peering do BGP. Para ver o campo advertisedRoutes, execute o seguinte comando:

    gcloud compute routers get-status INTERCONNECT_ROUTER_NAME

    Substitua INTERCONNECT_ROUTER_NAME pelo nome do Cloud Router criado para o nível do Cloud Interconnect da VPN de alta disponibilidade na implantação do Cloud Interconnect.

    Se os endereços do gateway da VPN de alta disponibilidade não forem anunciados, verifique se os anexos da VLAN estão associados ao roteador criptografado do Cloud Interconnect. Verifique se cada anexo da VLAN está configurado com os endereços IPv4 internos regionais esperados (--ipsec-internal-addresses).

Não foi possível estabelecer uma sessão do BGP para o Cloud Router de VPN de alta disponibilidade

Para verificar se a sessão do BGP associada ao anexo da VLAN está inativa, execute o comando:

gcloud compute routers get-status VPN_ROUTER_NAME

Substitua VPN_ROUTER_NAME pelo nome do Cloud Router criado para o nível da VPN de alta disponibilidade na implantação do Cloud Interconnect.

Para corrigir esse problema, siga estas etapas:

  1. Como o tráfego do BGP é roteado pelo túnel da VPN, verifique se o túnel da VPN está estabelecido. Caso contrário, siga as etapas em Não é possível estabelecer um túnel de VPN de alta disponibilidade.
  2. Verifique se a interface da sessão do BGP do Cloud Router está apontando para o túnel de VPN correto.
  3. Verifique se os endereços IP da interface da sessão do BGP estão configurados corretamente no Cloud Router e no dispositivo da VPN local.
  4. Verifique se os números de ASN estão configurados corretamente no Cloud Router e no roteador local.

O tráfego VPC não está alcançando redes locais ou vice-versa

O tráfego gerado por uma VM, como ping ou iperf, não alcança a rede local ou a rede local não alcança o tráfego gerado uma VM.

Para corrigir esse problema, siga estas etapas:

  1. Como o tráfego da VM é roteado pelo túnel da VPN, verifique se a rota da VM para o túnel da VPN está sendo enviada pelo Cloud Router.

  2. Verifique se a sessão do Cloud Router para VPN de alta disponibilidade foi estabelecida. Caso contrário, consulte Não é possível estabelecer uma sessão do BGP para o Cloud Router de VPN de alta disponibilidade.

Perda de pacotes ou baixa capacidade de processamento

O tráfego de VMs em redes VPC para redes locais ou o tráfego de redes locais para redes VPC é descartado.

Você observa a perda de pacotes ou a baixa capacidade de processamento com ping, iperf e outras ferramentas de monitoramento de rede.

Para corrigir esse problema, siga estas etapas:

  1. Verifique se o anexo da VLAN está sobrecarregado com o tráfego. Nesse caso, espalhe o tráfego por mais anexos da VLAN ou atualize a capacidade do anexo.
  2. Verifique se a VPN de alta disponibilidade está sobrecarregada com o tráfego. Se for o caso, crie mais túneis de VPN no anexo da VLAN para redistribuir o tráfego.
  3. Verifique se não há picos inesperados ou repentinos no tráfego ou tráfego intenso. Os streams TCP podem ser afetados por outros fluxos, como tráfego UDP intenso.
  4. Verifique se os pacotes que excedem a MTU do túnel estão fragmentados. Verifique se a MTU está configurada corretamente com seus anexos da VLAN e verifique se o tráfego UDP não está sendo fixado no MSS.

As métricas de anexo da VLAN mostram quedas devido a BANDWIDTH_THROTTLE

Ao conferir as métricas de anexo da VLAN ao monitorar conexões, você pode notar quedas devido a BANDWIDTH_THROTTLE. Isso ocorre quando o tráfego é enviado em uma taxa muito alta pelo anexo, de modo que parte dele é limitado.

No entanto, ao visualizar os gráficos de utilização de entrada e saída correspondentes, não há picos de tráfego. Isso ocorre porque as métricas são capturadas em um intervalo de amostragem de 60 segundos, o que pode mascarar picos ou bursts curtos de tráfego.

Para resolver esse problema, reduza o uso desse anexo, aumente a capacidade dele ou utilize mais anexos da VLAN.

Não foi possível excluir um anexo da VLAN criptografado

Você recebe o seguinte erro ao tentar excluir um anexo da VLAN criptografado para Interconexão dedicada ou Interconexão por parceiro:

ResourceInUseByAnotherResourceException

Para corrigir esse problema, primeiro exclua todos os gateways e túneis de VPN de alta disponibilidade associados ao anexo da VLAN criptografado. Para mais informações, consulte Excluir VPN de alta disponibilidade pelo Cloud Interconnect.

Tipos de endereço IP incompatíveis em anexos da VLAN criptografados

Ao tentar criar um gateway de VPN de alta disponibilidade para uso em uma VPN de alta disponibilidade pela implantação do Cloud Interconnect, você recebe o seguinte erro:

One of the VLAN attachments has private IP address type, while the other one
has public IP address type; they must have same IP address type.

Esse erro ocorre quando você especifica dois anexos da VLAN criptografados para um gateway de VPN de alta disponibilidade e eles têm esquemas de endereçamento diferentes para as interfaces do túnel de VPN de alta disponibilidade. Os tipos de endereço IP precisam corresponder aos dois anexos da VLAN.

Durante a criação do gateway da VPN, especifique os anexos da VLAN que usam endereços IP privados ou públicos. Se você receber esse erro ao criar um gateway de VPN, tente recriar o anexo da VLAN com o tipo de endereço correto.

Anexo da VLAN ausente da interface do gateway de VPN de alta disponibilidade

Se estiver sendo implantado para VPN de alta disponibilidade pelo Cloud Interconnect, um gateway de VPN de alta disponibilidade precisa ter um anexo da VLAN criptografado especificado para as duas interfaces.

Se você especificar apenas um anexo da VLAN, o seguinte erro vai aparecer:

VPN Gateway should have VLAN attachment specified in both interfaces or in none.

Para corrigir esse problema, crie o gateway da VPN de alta disponibilidade e especifique dois anexos da VLAN.

Tipo de anexo da VLAN inválido

Os anexos da VLAN criptografados precisam ter o tipo DEDICATED ou PARTNER.

Se você especificar um tipo inválido para um anexo da VLAN criptografado, a seguinte mensagem de erro será exibida:

VLAN attachment should have type DEDICATED or PARTNER.

Para corrigir esse problema, crie apenas anexos da VLAN criptografados com o tipo DEDICATED ou PARTNER.

Valor de MTU incorreto para anexo da VLAN

Ao criar um anexo da VLAN criptografado para Interconexão dedicada, a seguinte mensagem de erro é exibida:

Wrong MTU value [mtuValue] for VLAN attachment.
The supported MTU for IPsec packets for HA VPN over Cloud Interconnect is 1440.

Para corrigir esse problema, recrie o anexo com o valor correto de 1440, que é o valor padrão.

Os anexos da VLAN têm um tipo diferente

Ao especificar anexos da VLAN criptografados para suas interfaces de gateway de VPN de alta disponibilidade, a seguinte mensagem de erro é exibida:

VLAN attachments should both have same type DEDICATED or PARTNER.
But found one DEDICATED and one PARTNER.

Para corrigir esse problema, especifique dois anexos da VLAN do mesmo tipo, DEDICATED ou PARTNER.

Anexos da VLAN dedicados não estão na mesma área metropolitana

Ao especificar anexos da VLAN criptografados para suas interfaces de gateway de VPN de alta disponibilidade, a seguinte mensagem de erro é exibida:

Dedicated VLAN attachments should be in the same metropolitan area.

Para corrigir esse problema, crie dois anexos da VLAN criptografados para a Interconexão dedicada na mesma área metropolitana.

O gateway da VPN de alta disponibilidade não está na mesma rede do anexo da VLAN

Ao especificar anexos da VLAN criptografados para suas interfaces de gateway de VPN de alta disponibilidade, a seguinte mensagem de erro é exibida:

VPN Gateway should be in the same network as VLAN attachment.
VLAN attachment network: [networkName], VPN gateway network: [networkName]

Para corrigir esse problema, crie o gateway da VPN de alta disponibilidade na mesma rede dos anexos da VLAN criptografados.

Tipo de criptografia incorreto para anexos da VLAN

Ao especificar anexos da VLAN criptografados para suas interfaces de gateway de VPN de alta disponibilidade, a seguinte mensagem de erro é exibida:

Wrong encryption type for VLAN attachment [interconnectAttachmentName],
required IPSEC.

Para corrigir esse problema, especifique apenas anexos da VLAN criptografados configurados com o tipo de criptografia IPSEC. Se necessário, crie anexos da VLAN criptografados.

A zona do anexo da VLAN não corresponde ao interfaceId

Ao especificar anexos da VLAN criptografados para suas interfaces de gateway de VPN de alta disponibilidade, a seguinte mensagem de erro é exibida:

VLAN attachment zone should match interfaceId: interface 0 - zone1,
interface 1 - zone2, but found interface [interfaceId] - [zone] for
[interconnectAttachmentName].

A primeira interface do gateway da VPN de alta disponibilidade (interface 0) precisa corresponder ao anexo da VLAN criptografado da zona 1, e a segunda interface (interface 1) precisa corresponder ao anexo da VLAN criptografado da zona 2.

Para corrigir esse problema, especifique anexos da VLAN criptografados das zonas correspondentes corretamente às interfaces do gateway da VPN de alta disponibilidade.

O gateway da VPN não está na mesma região do anexo da VLAN

Ao especificar anexos da VLAN criptografados para suas interfaces de gateway de VPN de alta disponibilidade, a seguinte mensagem de erro é exibida:

VPN Gateway should be in the same region as VLAN attachment.
VLAN attachment region: [region], VPN gateway region: [region].

Para corrigir esse problema, crie gateways da VPN de alta disponibilidade e anexos da VLAN criptografados na mesma região.

O anexo da VLAN do parceiro não está no estado ativo

Ao especificar anexos da VLAN criptografados para Interconexão por parceiro para suas interfaces de gateway de VPN de alta disponibilidade, a seguinte mensagem de erro é exibida:

Interconnect Attachments [name] must be in active state.

Ative os anexos da VLAN para a Interconexão por parceiro antes de associá-los às interfaces de gateway da VPN de alta disponibilidade.

Veja mais informações em Ativar conexões.

Tipo incorreto de Cloud Router especificado para anexo da VLAN

Quando você tenta criar um anexo da VLAN criptografado, a seguinte mensagem de erro é exibida:

Router must be an encrypted interconnect router.

Para corrigir esse problema, crie um Cloud Router com a sinalização --encrypted-interconnect-router. Esse Cloud Router é usado exclusivamente para VPN de alta disponibilidade no Cloud Interconnect.

Em seguida, crie o anexo da VLAN e forneça o Cloud Router criptografado.

Interconexão entre nuvens

Nesta seção, descrevemos problemas que podem surgir com o Cross-Cloud Interconnect.

O Google aceita a conexão até o ponto em que ela chega à rede do outro provedor de serviços de nuvem. O Google não garante o tempo de atividade do outro provedor de serviços de nuvem e não pode criar um tíquete de suporte em seu nome. No entanto, com sua permissão, o suporte do Google Cloud pode se comunicar diretamente com a equipe de suporte do seu outro provedor de nuvem para agilizar a resolução do problema.

Incompatibilidade entre portas redundantes

Depois de solicitar portas do Cross-Cloud Interconnect, você fornece ao Google informações sobre como você quer que as portas sejam conectadas às portas remotas da nuvem. Você também usará essas informações posteriormente, quando configurar seus recursos. Se você tiver problemas de conectividade, é possível que não tenha usado os detalhes de conectividade corretos.

Por exemplo, você pode fornecer instruções como as seguintes:

  • Conectar gcp-1 a azure-1.

  • Conectar gcp-2 a azure-2.

No entanto, ao configurar seus recursos, suponha que as portas estejam conectadas da seguinte maneira:

  • Conectar gcp-1 a azure-2.

  • Conectar gcp-2 a azure-1.

Essa condição pode ser detectada por meio da análise do cache do ARP. No entanto, uma solução mais simples é acessar a nuvem remota e trocar os intervalos de endereços IP atribuídos aos dois pares do BGP.

Por exemplo, suponha que azure-1 tenha um peering de anexo da VLAN em 169.254.0.2 e azure-2 tenha um peering de anexo da VLAN em 169.254.99.2. Troque os intervalos de endereços IP para que o anexo azure-1 use 169.254.99.2 e o anexo azure-2 use 169.254.0.2.

Se você usou códigos da VLAN diferentes para o anexo em cada porta, também será necessário trocar os códigos da VLAN usados pelos anexos. Para o Azure, esse cenário é impossível porque requer o uso do mesmo ID da VLAN em ambas as portas para cada anexo.

IDs da VLAN

Às vezes, problemas de conectividade podem ser rastreados em erros com valores de ID da VLAN. O ID da VLAN é um campo no anexo da VLAN do Cross-Cloud Interconnect.

Azure

O Azure exige que os códigos da VLAN sejam alocados de maneira idêntica nas duas portas de um par. Quando você cria o anexo da VLAN, o console do Google Cloud aplica esse requisito. No entanto, se você configurar os anexos usando a Google Cloud CLI ou a API, é possível alocar IDs de VLAN diferentes. Esse risco é especialmente grande se você permitir que os códigos da VLAN sejam atribuídos automaticamente ao criar o anexo. Se você não definir explicitamente o código, ele será atribuído automaticamente.

AWS

Ao se conectar à AWS, não há problema em usar a atribuição automática de IDs da VLAN. No entanto, ao configurar seus recursos da AWS, você precisa configurar manualmente os IDs da VLAN para que correspondam aos que o Google Cloud atribuiu automaticamente. Além disso, é importante não confundir o código da VLAN que deve ser usado para cada porta. Se o ID da VLAN incorreto estiver configurado em uma porta, os roteadores virtuais não poderão se comunicar.

Verificar a conectividade

Siga as etapas para verificar a conectividade entre o Google Cloud e sua rede de nuvem remota, caso ainda não tenha feito isso: