Algumas ou todas as informações nesta página podem não se aplicar à Trusted Cloud by S3NS. Consulte o artigo Diferenças em relação ao Google Cloud para mais detalhes.

Esta página foi traduzida pela API Cloud Translation.

Resolução de problemas

Este guia de resolução de problemas pode ajudar a resolver problemas comuns que pode encontrar ao usar o Cloud Interconnect:

Resolução de problemas gerais
Interligação dedicada
Interligação de parceiros
HA VPN através do Cloud Interconnect
MACsec para o Cloud Interconnect
Cross-Cloud Interconnect

Para ver as respostas a perguntas comuns sobre a arquitetura e as funcionalidades do Cloud Interconnect, consulte as Perguntas frequentes do Cloud Interconnect.

Para ver as definições dos termos usados nesta página, consulte os termos-chave do Cloud Interconnect.

Importante: o BFD só pode ser ativado em anexos de VLAN aprovisionados que usam a versão 2 do plano de dados. Pode ver o dataplaneVersion de uma associação VLAN ao ver os detalhes da associação de uma das seguintes formas:

API: use o método interconnectAttachments.get. Pode usar este método em anexos de VLAN para o Dedicated Interconnect ou o Partner Interconnect.
CLI do Google Cloud: use o comando gcloud compute interconnects attachments describe ATTACHMENT-NAME, em que ATTACHMENT-NAME é o nome da associação VLAN para a Interligação dedicada ou a Interligação de parceiro.

Na saída do comando da API ou da CLI gcloud, procure o campo dataplaneVersion com um valor de 2. Se o campo estiver ausente da saída, a associação de VLAN está a usar a versão 1 e não pode ser usada com o BFD. Para mais informações, contacte a equipa da conta de cliente.

O Dataplane v2 do Cloud Interconnect não está relacionado com o Dataplane V2 do Google Kubernetes Engine (GKE)

Para encontrar informações de registo e monitorização, e ver as métricas do Cloud Interconnect, consulte o artigo Monitorizar ligações.

Resolução de problemas gerais

Verifique se existem interrupções do serviço Cloud Interconnect

Pode verificar as interrupções conhecidas no Trusted Cloud Painel de controlo de estado. Também pode subscrever o feed JSON ou o feed RSS de incidentes na nuvem para receber atualizações push.
Recebe notificações de eventos de manutenção que afetam as suas ligações Dedicated Interconnect. Para obter detalhes, consulte o artigo Eventos de manutenção da infraestrutura.
Recebe notificações sobre eventos de manutenção que afetam as suas associações de VLANs do Partner Interconnect. As notificações do Partner Interconnect são enviadas de forma semelhante às notificações das ligações Dedicated Interconnect, com algumas pequenas diferenças. Para ver detalhes, consulte o artigo Eventos de manutenção da infraestrutura.

Não é possível estabelecer ligação a recursos noutras regiões

Por predefinição, as redes da nuvem virtual privada (VPC) são regionais, o que significa que o Cloud Router anuncia apenas as sub-redes na respetiva região. Para estabelecer ligação a outras regiões, defina o modo de encaminhamento dinâmico da sua rede VPC como global para que o Cloud Router possa anunciar todas as sub-redes.

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

Não é possível aceder às VMs numa rede VPC com intercâmbio

Neste cenário, configurou uma ligação do Cloud Interconnect entre a sua rede no local e uma rede VPC, a rede A. Também configurou o intercâmbio da rede da VPC entre a rede A e outra rede da VPC, a rede B. No entanto, não consegue alcançar as VMs na rede B a partir da sua rede no local.

Esta configuração não é suportada, conforme descrito nas restrições da vista geral do intercâmbio da rede da VPC.

No entanto, pode usar anúncios de intervalo de IP personalizados de routers na nuvem na sua rede VPC para partilhar rotas para destinos na rede de pares. Além disso, tem de configurar as ligações de interligação de redes VPC para importar e exportar rotas personalizadas.

Para mais informações sobre rotas de publicidade entre redes no local e redes com peering de VPC, consulte os seguintes recursos:

Anunciar intervalos de IP personalizados
Resolução de problemas na utilização do intercâmbio da rede da VPC

Sub-redes em falta numa ligação

Para anunciar todas as sub-redes disponíveis, especifique as rotas em falta com rotas anunciadas personalizadas e anuncie todas as rotas de sub-redes entre regiões com encaminhamento dinâmico global. Para o fazer, siga estes passos:

Especifique rotas anunciadas personalizadas num Cloud Router e na sessão do Border Gateway Protocol (BGP).

Para introduzir as rotas em falta, defina os seguintes parâmetros:
```
--set-advertisement-groups = ADVERTISED_GROUPS
--set-advertisement-ranges = ADVERTISED_IP_RANGES
```
Substitua o seguinte:
- ADVERTISED_GROUPS: um grupo definido pela Google que o Cloud Router anuncia dinamicamente; pode ter um valor de all_subnets, que imita o comportamento predefinido 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 à sua escolha
Para ver mais detalhes e exemplos, consulte o artigo Anunciar intervalos de IPs personalizados.
Ative o modo de encaminhamento dinâmico global.

Não é possível enviar um ping para o Cloud Router

Se não conseguir enviar um ping para o Cloud Router a partir do seu router no local, encontre o seu produto na tabela seguinte e execute os passos de resolução de problemas para esse produto. As VMs não conseguem aceder a 169.254.0.0/16.

Passos de resolução de problemas a seguir	Interligação dedicada	Interligação de parceiros com parceiro de Nível 3	Interligação de parceiro com parceiro de Nível 2
Para o Partner Interconnect, o Cloud Router pode nunca ser acessível através de ping porque alguns parceiros filtram o tráfego para o intervalo de IP (`169.254.0.0/16`) do Cloud Router. Para parceiros de nível 3 (L3), o parceiro configura automaticamente o BGP. Se o BGP não for apresentado, contacte o seu parceiro.	Não aplicável	Sim	Não aplicável
Verifique se o seu dispositivo local aprendeu o endereço MAC correto para o lado da ligação. Trusted Cloud by S3NS Para mais informações, consulte o artigo Resolução de problemas de ARP.	Sim	Não aplicável	Não aplicável
Verifique se o Cloud Router tem uma interface e um par BGP. Não é possível enviar um ping para o Cloud Router, a menos que a interface e o par BGP estejam totalmente configurados, incluindo o ASN remoto. Para a interligação dedicada, consulte o artigo A sessão de BGP não está a funcionar. Para a interligação de parceiros de nível 2, a Google adicionou automaticamente a interface e o par BGP para o Cloud Router, mas tem de configurar o ASN remoto.	Sim	Não aplicável	Sim

Resolução de problemas de ARP

Para o Dedicated Interconnect, para encontrar o endereço MAC correto, execute o seguinte comando gcloud:

  gcloud compute interconnects get-diagnostics INTERCONNECT_NAME

O googleSystemID contém o endereço MAC que deve estar presente na tabela ARP do dispositivo para os 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 seu dispositivo não tiver aprendido um endereço MAC, verifique se o ID da VLAN correto e o endereço IP estão configurados na subinterface.

Para o Partner Interconnect, se vir o endereço MAC errado no seu dispositivo, verifique se não criou uma ponte entre os segmentos da camada 2 de dois anexos de VLAN. O lado da ligação do Cloud Interconnect está configurado com ip proxy-arp, que responde a todos os pedidos ARP e pode fazer com que o router no local aprenda entradas ARP incorretas. Trusted Cloud

Não é possível criar a associação VLAN

Se tentar criar um anexo de VLAN para o Dedicated Interconnect ou o Partner Interconnect que viole uma política da organização, é apresentada uma mensagem de erro. Veja a seguinte mensagem de erro de exemplo da 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 os artigos Restrinja a utilização do Cloud Interconnect e Use políticas da organização personalizadas e contacte o administrador da sua organização.

Partilhe associações com outros projetos na minha organização

Use a VPC partilhada para partilhar uma ligação, como uma associação de VLAN ou uma ligação Dedicated Interconnect num projeto anfitrião.

Para mais informações sobre a configuração de uma rede de VPC partilhada, consulte o artigo Aprovisionamento de VPC partilhada.

Para mais informações sobre a configuração de anexos numa rede VPC partilhada, consulte o artigo Opções para estabelecer ligação a várias redes VPC.

Interligação dedicada

O Google não consegue enviar-lhe um ping durante o processo de aprovisionamento da ligação

Verifique se está a usar a configuração de IP e LACP correta. Durante o processo de teste, a Google envia-lhe diferentes configurações de IP de teste para o seu router no local, consoante encomende um pacote de vários links ou um pacote de um único link. Não configure associações VLAN para nenhum destes testes.

Para pacotes com vários links

O primeiro conjunto de endereços IP que a Google envia destina-se a testar a conetividade de vários circuitos em cada associação individual. Configure os endereços IP de teste em todos os links físicos (sem o LACP configurado), conforme indicado nos emails que a Google lhe enviou. O Google tem de enviar um ping a todos os endereços IP com êxito antes de este primeiro teste ser aprovado.
Para o segundo teste, remova todos os endereços IP do primeiro teste. Configure o canal de porta com LACP, mesmo que a sua ligação tenha apenas um link. A Google envia um ping para o endereço do canal de porta. Não modifique a configuração do LACP do seu canal de porta depois de a ligação ter passado no teste final. No entanto, tem de remover o endereço IP de teste da interface do canal da porta.

Para pacotes de um único link

A Google envia o endereço IP de produção final para testar a conetividade de circuito único. Configure o endereço IP na interface do pacote (com o LACP configurado, no modo ativo ou passivo), conforme indicado no email que a Google lhe enviou. O Google tem de enviar um ping com êxito para o endereço IP da interface do pacote antes de este teste ser aprovado. Configure o canal de porta com LACP, mesmo que a sua ligação tenha apenas um link.

Não é possível enviar um ping para o Cloud Router

Verifique se consegue enviar um ping para o endereço IP do canal da porta da Google. O endereço IP é o valor googleIpAddress quando vê os detalhes da ligação.
Verifique se tem a VLAN correta na subinterface do router no local. As informações da VLAN devem corresponder às informações fornecidas pela associação VLAN.
Verifique se tem o endereço IP correto na subinterface do router no local. Quando cria uma associação de VLAN, esta atribui um par de endereços IP locais de ligação. Uma é para uma interface num router na nuvem (cloudRouterIpAddress) e a outra é para uma subinterface no canal de porta do router no local, e não o canal de porta em si (customerRouterIpAddress).
Se estiver a testar o desempenho das suas associações de VLAN, não faça ping ao Cloud Router. Em alternativa, crie e, em seguida, use uma instância de máquina virtual (VM) do Compute Engine na sua rede VPC. Para mais informações, consulte o artigo Testes de desempenho.

A sessão BGP não está a funcionar

Ative o BGP de vários saltos no seu router no local com, pelo menos, dois saltos.
Verifique se tem o endereço IP do vizinho correto configurado no seu router no local. Use o endereço IP do par BGP (cloudRouterIpAddress) que a associação VLAN atribuiu.
Verifique se a configuração do ASN local no seu router no local corresponde ao ASN do par no Cloud Router. Além disso, verifique se a configuração do ASN local no Cloud Router corresponde ao ASN do par no seu router no local.
A cada anexo é atribuído um CIDR /29 exclusivo de 169.254.0.0/16 na sua rede VPC. Um endereço IP no CIDR /29 é atribuído ao Cloud Router e o outro ao seu router no local.

Verifique se os endereços IP corretos estão atribuídos à interface do router no local e ao respetivo vizinho BGP. Um erro comum é configurar um /30 na interface do router no local em vez de um /29. Trusted Cloud reserva todos os outros endereços no CIDR /29.

Certifique-se de que não atribuiu outros endereços IP deste CIDR à interface de anexo de VLAN no seu router.

Não é possível aceder às VMs na sua rede VPC

Verifique se consegue enviar um ping para o canal de porta e a associação de VLAN.
Verifique se a sessão BGP está ativa.
Verifique se o router no local está a anunciar e a receber rotas.
Verifique se não existem sobreposições entre os anúncios de rotas no local e os Trusted Cloud intervalos de rede.
Defina o tamanho da MTU com os mesmos valores para o router no local, o VPC e a ligação VLAN.

O tráfego IPv6 não está a passar pela associação VLAN

Se tiver dificuldades em estabelecer ligação a anfitriões IPv6, faça o seguinte:

Verifique se as rotas IPv6 estão a ser anunciadas corretamente. Se os caminhos IPv6 não estiverem a ser anunciados, consulte o artigo Resolva problemas de caminhos BGP e de seleção de caminhos.
Inspeccione as regras da firewall para garantir que está a permitir tráfego IPv6.
Verifique se não tem intervalos de sub-redes IPv6 sobrepostos na sua rede VPC e na sua rede no local. Consulte o artigo Verifique os intervalos de sub-redes sobrepostos.
Determine se excedeu alguma quota e limite para as suas rotas aprendidas no Cloud Router. Se excedeu a quota de rotas aprendidas, os prefixos IPv6 são ignorados antes dos prefixos IPv4. Consulte o artigo Verificar quotas e limites.
Verifique se todos os componentes relacionados com a configuração do IPv6 foram configurados corretamente.
- A rede VPC ativou a utilização de endereços IPv6 internos com a flag --enable-ula-internal-ipv6.
- A sub-rede da VPC está configurada para usar o tipo de pilha IPV4_IPV6.
- A sub-rede da VPC tem o valor --ipv6-access-type definido como INTERNAL.
- As VMs do Compute Engine na sub-rede estão configuradas com endereços IPv6.
- A associação VLAN está configurada para usar o tipo de pilha IPV4_IPV6.
- O ponto de troca BGP ativou o IPv6 e os endereços de próximo salto IPv6 corretos estão configurados para a sessão BGP.
  - Para ver o estado e os trajetos do Cloud Router, consulte o artigo Veja o estado e os trajetos do Cloud Router.
  - Para ver a configuração da sessão BGP, consulte o artigo Veja a configuração da sessão BGP.

Testes de desempenho nas suas associações VLAN

Se precisar de testar o desempenho das suas associações de VLAN, use uma VM na sua rede VPC. Adicione as ferramentas de desempenho de que precisa na VM. Não use o endereço IP local do link do router na nuvem para testar a latência, como o ping ICMP ou o MTU do caminho. A utilização do Cloud Router pode dar resultados imprevisíveis.

Obtenha diagnósticos

Para obter informações técnicas atuais e detalhadas sobre o Trusted Cloud lado de uma ligação de interconexão dedicada a pedido, consulte Obtenha diagnósticos.

Interligação de parceiro

A sessão de BGP não está a funcionar (associações da camada 2)

Verifique se o router no local foi configurado com uma sessão BGP para os seus Cloud Routers. Para mais informações, consulte o artigo Configurar routers no local para o Partner Interconnect.
Ative o BGP de vários saltos no seu router no local com, pelo menos, dois saltos.
Verifique se tem o endereço IP do vizinho correto configurado no seu router no local. Use o endereço IP do par BGP (cloudRouterIpAddress) que a associação VLAN atribuiu.
Verifique se a configuração do ASN local no seu router no local corresponde ao ASN do par no Cloud Router (16550). Além disso, verifique se a configuração do ASN local no Cloud Router corresponde ao ASN do par no seu router no local.

A sessão de BGP não está a funcionar (associações da camada 3)

O router na nuvem tem de ser configurado com o ASN do seu fornecedor de serviços. Contacte o seu fornecedor de serviços para receber assistência.

Associação VLAN inativa para uma ligação de interligação de parceiros

O estado de uma associação de VLAN pode ser apresentado como inativo, mesmo que não existam problemas com a Trusted Cloud configuração e a ligação de interconexão de parceiros.

Certifique-se de que configurou o multihop EBGP no seu router no local para ter, pelo menos, quatro saltos. Pode ver um exemplo de configuração em Configurar routers no local.

Problema de chave de sincronização numa ligação de interligação de parceiros

Quando tenta configurar uma ligação Partner Interconnect, pode encontrar uma mensagem de erro, como "Google: estado do fornecedor não disponível". Para corrigir este problema, siga estes passos:

Certifique-se de que a chave de sincronização foi gerada pela associação VLAN do lado do cliente (tipo PARTNER). A chave é uma longa string aleatória que a Google usa para identificar o anexo. A região de destino Trusted Cloud e o domínio de disponibilidade da extremidade estão codificados na chave de sincronização no seguinte formato:
```
<random_string>/<region_name>/<domain>
```
O campo domain contém a string any se a associação de VLAN não estiver restrita a um domínio específico ou se não especificar o domínio de disponibilidade na periferia. Para mais informações sobre as chaves de sincronização, consulte o artigo Chave de sincronização.
Certifique-se de que o domínio de disponibilidade de limite da ligação do Partner Interconnect corresponde ao domínio especificado pela chave de sincronização.

Não é possível enviar um ping para o Cloud Router (associações da camada 2)

Verifique se tem a associação de VLAN correta na subinterface do router no local. As informações da associação de VLAN devem corresponder às informações fornecidas pelo seu fornecedor de serviços.
Verifique se tem o endereço IP correto na subinterface do router no local. Depois de o fornecedor de serviços configurar a associação de VLAN, a associação atribui um par de endereços IP locais de ligação. Uma é para uma interface no Cloud Router associado (cloudRouterIpAddress) e a outra é para uma subinterface no canal de porta do seu router no local, não para o próprio canal de porta (customerRouterIpAddress).
Se estiver a testar o desempenho dos seus anexos, não faça ping ao Cloud Router. Em alternativa, crie e, em seguida, use uma VM na sua rede VPC. Para mais informações, consulte o artigo Testes de desempenho.

Perda de energia ótica na porta da ligação de interligação de parceiros

Se houver uma perda de energia ótica numa porta, pode deparar-se com um dos seguintes problemas:

Perda da conetividade da camada 3 (perda de uma sessão BGP) ou incapacidade de aceder às suas instâncias de VM Trusted Cloud .
Desempenho degradado do seu conjunto de links. Este problema ocorre se várias portas 10GE estiverem agrupadas e apenas alguns dos links num pacote estiverem a funcionar.

A perda de energia ótica numa porta significa que o hardware não consegue detetar um sinal da outra extremidade. Isto pode dever-se a um dos seguintes problemas:

Um transrecetor com defeito
Um sistema de transporte com defeito
Um problema físico de fibra

Para corrigir este problema, contacte o seu fornecedor de interconexão de parceiros e/ou de circuito. Podem realizar os seguintes passos:

Verifique se o transrecetor está a funcionar.
Execute um ciclo rígido para a sala de reuniões (MMR) para verificar se os níveis de luz no respetivo dispositivo estão a funcionar como esperado.
Verifique se os problemas são do lado do cliente ou do lado da Google. A melhor forma de isolar a interface é colocar um ciclo bidirecional no ponto de demarcação. As interfaces de cada lado transmitem luz até ao ponto de demarcação, onde é devolvida a si própria. O lado com defeito é o lado do ponto de demarcação que não se destaca facilmente.
Limpe e volte a encaixar toda a fibra do lado do cliente.

Não é possível enviar nem aprender valores MED através de uma ligação de interconexão de parceiros de nível 3

Se estiver a usar uma ligação Partner Interconnect em que um fornecedor de serviços de camada 3 processa o BGP por si, o Cloud Router não consegue aprender valores MED do seu router no local nem enviar valores MED para esse router. Isto deve-se ao facto de os valores MED não poderem ser transmitidos através de sistemas autónomos. Neste tipo de ligação, não pode definir prioridades de trajetos para trajetos anunciados pelo Cloud Router ao seu router no local. Além disso, não pode definir prioridades de caminho para caminhos anunciados pelo seu router no local para a sua rede VPC.

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

Veja o estado do Cloud Router e verifique se status: UP é apresentado.

Se o BGP não estiver ativo, faça o seguinte:
1. Confirme se o seu router no local (ou o router do seu parceiro, se estiver a usar um parceiro de camada 3) está configurado com uma sessão BGP IPv6 e se a sessão está a usar os endereços IPv6 corretos.
2. Veja a configuração da sessão BGP e verifique se bgpPeers.enable apresenta 'TRUE' para o seu Cloud Router.
Se o BGP estiver ativo, veja as rotas do Cloud Router para verificar se os prefixos IPv6 esperados são apresentados.best_routes

Se os best_routes esperados não forem apresentados, confirme se o seu router no local (ou o router do parceiro, se estiver a usar um parceiro de camada 3) está configurado com as rotas IPv6 corretas.

Todos os outros problemas

Para obter assistência adicional, contacte o seu fornecedor de serviços. Se necessário, o seu fornecedor de serviços contacta a Google para corrigir problemas relacionados com o lado da rede da Google.

HA VPN através do Cloud Interconnect

Quando implementa a VPN de alta disponibilidade através do Cloud Interconnect, cria dois níveis operacionais:

O nível do Cloud Interconnect, que inclui as associações de VLAN e o Cloud Router para o Cloud Interconnect.
O nível da HA VPN, que inclui os gateways e os túneis da HA VPN, bem como o Cloud Router para a HA VPN.

Cada nível requer o seu próprio Cloud Router:

O Cloud Router para o Cloud Interconnect é usado exclusivamente para trocar prefixos de gateway de VPN entre os anexos de VLAN. Este Cloud Router é usado apenas pelos anexos de VLAN do nível do Cloud Interconnect. Não pode ser usado no nível de VPN de alta disponibilidade.
O Cloud Router para a VPN de HA troca prefixos entre a sua rede da VPC e a sua rede nas instalações. Configura o Cloud Router para a VPN de alta disponibilidade e as respetivas sessões BGP da mesma forma que faria para uma implementação de VPN de alta disponibilidade normal.

Cria o nível de VPN de HA com base no nível do Cloud Interconnect. Por conseguinte, o nível de VPN de alta disponibilidade requer que o nível do Cloud Interconnect, baseado no Dedicated Interconnect ou no Partner Interconnect, esteja configurado e operacional corretamente.

Para resolver problemas de uma implementação de VPN de alta disponibilidade através do Cloud Interconnect, resolva primeiro os problemas do nível do Cloud Interconnect. Depois de verificar se o Cloud Interconnect está a funcionar corretamente, resolva problemas do nível de VPN de alta disponibilidade.

Não é possível estabelecer uma sessão de BGP para o Cloud Router para o Cloud Interconnect

Para detetar se a sessão BGP associada à associação de VLAN está inativa, execute o seguinte comando:

   gcloud compute routers get-status INTERCONNECT_ROUTER_NAME

Substitua INTERCONNECT_ROUTER_NAME pelo nome do Cloud Router que criou para o nível do Cloud Interconnect da implementação de VPN de alta disponibilidade através do Cloud Interconnect.

Para corrigir este problema, siga estes passos:

Siga os passos em Testar associações e Obter diagnósticos para se certificar de que a associação do Cloud Interconnect subjacente está em bom estado.
Verifique se a interface da sessão BGP está a apontar para a associação correta.
Verifique os endereços IP configurados para a interface da sessão BGP no Cloud Router e no router no local.
Verifique se os números ASN estão configurados corretamente no Cloud Router e no router no local.
Verifique se a ligação do Cloud Interconnect e a associação de VLAN estão no estado admin-enabled.

Não é possível estabelecer um túnel de HA VPN

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 de VPN de HA.

Para corrigir este problema, siga estes passos:

Uma vez que o túnel VPN é encaminhado através de uma associação de VLAN, verifique se a sessão BGP associada à associação de VLAN está estabelecida. Caso contrário, consulte o artigo Não é possível estabelecer uma sessão BGP para o Cloud Router para o Cloud Interconnect.
Verifique se a PSK e as cifras do túnel estão configuradas corretamente nos gateways da Cloud VPN e nos gateways da VPN no local.
Verifique se o anúncio BGP do router no local inclui os endereços do gateway de VPN no local. Caso contrário, ajuste a configuração do BGP do router no local para anunciar os endereços.
Verifique se os encaminhamentos para gateways de VPN no local não foram eliminados devido a conflitos com os encaminhamentos BGP existentes. Se existirem conflitos, ajuste os endereços do gateway de VPN ou as rotas anunciadas.
Verifique se o anúncio BGP do Cloud Router inclui os endereços do gateway de VPN de alta disponibilidade. Verifique esta situação no router no local ou inspecionando o campo advertisedRoutes do par 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 que criou para o nível do Cloud Interconnect da implementação de VPN de alta disponibilidade através do Cloud Interconnect.

Se os endereços do gateway de VPN de HA não forem anunciados, certifique-se de que as associações de VLAN estão associadas ao router do Cloud Interconnect encriptado. Verifique se cada associação VLAN está configurada com os endereços IPv4 internos regionais esperados (--ipsec-internal-addresses).

Não é possível estabelecer uma sessão de BGP para o Cloud Router para a VPN de HA

Para verificar se a sessão BGP associada à associação de VLAN está inativa, execute o comando:

gcloud compute routers get-status VPN_ROUTER_NAME

Substitua VPN_ROUTER_NAME pelo nome do Cloud Router que criou para o nível de VPN de alta disponibilidade da sua implementação de VPN de alta disponibilidade através do Cloud Interconnect.

Para corrigir este problema, siga estes passos:

Uma vez que o tráfego BGP é encaminhado através do túnel de VPN, verifique se o túnel de VPN está estabelecido. Caso contrário, siga os passos em Não é possível estabelecer um túnel de VPN de HA.
Verifique se a interface da sessão BGP para o Cloud Router está a apontar para o túnel de VPN correto.
Verifique se os endereços IP da interface da sessão BGP estão configurados corretamente no Cloud Router e no dispositivo VPN no local.
Verifique se os números ASN estão configurados corretamente no Cloud Router e no router no local.

O tráfego da VPC não está a chegar às redes no local ou vice-versa

O tráfego gerado a partir de uma VM, como de ping ou iperf, não consegue alcançar a rede no local, ou a rede no local não consegue alcançar o tráfego gerado a partir de uma VM.

Para corrigir este problema, siga estes passos:

Uma vez que o tráfego da VM é encaminhado através do túnel da VPN, certifique-se de que o Cloud Router está a enviar o trajeto da VM para o túnel da VPN.
Verifique se a sessão do Cloud Router para a VPN de alta disponibilidade está estabelecida. Caso contrário, consulte o artigo Não é possível estabelecer uma sessão BGP para o Cloud Router para a VPN de HA.

Perda de pacotes ou débito baixo

O tráfego de VMs em redes da VPC para redes no local ou o tráfego de redes no local para redes da VPC é rejeitado.

Observa perda de pacotes ou débito baixo através do ping, do iperf e de outras ferramentas de monitorização de rede.

Para corrigir este problema, siga estes passos:

Verifique se a associação de VLAN está sobrecarregada com tráfego. Se for o caso, distribua o tráfego por mais anexos de VLAN ou atualize a capacidade do anexo.
Verifique se a VPN de HA está sobrecarregada com tráfego. Se for o caso, crie túneis VPN adicionais através da associação de VLAN para redistribuir o tráfego.
Certifique-se de que não existem picos inesperados ou súbitos no tráfego ou tráfego intermitente. As streams TCP podem ser afetadas por outras streams, como o tráfego UDP intermitente.
Verifique se os pacotes que excedem a MTU do túnel estão fragmentados. Certifique-se de que a MTU está definida corretamente com as associações de VLAN e verifique se o tráfego UDP não está a ser restrito pela MSS.

As métricas de associação VLAN mostram quedas devido a `BANDWIDTH_THROTTLE`

Quando vê métricas de associação de VLANs quando monitoriza as ligações, pode ver quedas devido a BANDWIDTH_THROTTLE. Isto ocorre quando o tráfego está a ser enviado a uma taxa demasiado elevada através do anexo, pelo que algum tráfego é limitado.

No entanto, quando vê os gráficos de utilização de entrada e saída correspondentes, não são apresentados picos de tráfego. Isto deve-se ao facto de as métricas serem captadas a um intervalo de amostragem de 60 segundos, o que pode ocultar picos ou aumentos rápidos de tráfego.

Para resolver este problema, diminua a utilização desta associação, aumente a capacidade da associação ou use mais associações VLAN.

Não é possível eliminar uma associação VLAN encriptada

Recebe o seguinte erro quando tenta eliminar uma associação de VLAN encriptada para o Dedicated Interconnect ou o Partner Interconnect:

ResourceInUseByAnotherResourceException

Para corrigir este problema, certifique-se de que eliminou primeiro todos os gateways e túneis de VPN de HA associados ao anexo de VLAN encriptado. Para mais informações, consulte o artigo Elimine a VPN de alta disponibilidade através do Cloud Interconnect.

Tipos de endereços IP não correspondentes em associações VLAN encriptadas

Quando tenta criar um gateway de VPN de alta disponibilidade para utilização numa implementação de VPN de alta disponibilidade através do Cloud Interconnect, 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.

Este erro ocorre quando especifica dois anexos de VLAN encriptados para um gateway de VPN de HA e estes têm esquemas de endereçamento IP diferentes para as interfaces de túnel de VPN de HA. Os tipos de endereços IP têm de corresponder em ambas as associações VLAN.

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

Associação VLAN em falta na interface do gateway de VPN de HA

Se for implementado para a VPN de alta disponibilidade através do Cloud Interconnect, um gateway de VPN de alta disponibilidade tem de ter um anexo de VLAN encriptado especificado para ambas as interfaces.

Se especificar apenas uma associação VLAN, é apresentado o seguinte erro:

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

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

Tipo de associação VLAN inválido

As associações VLAN encriptadas têm de ter o tipo DEDICATED ou PARTNER.

Se especificar um tipo inválido para uma associação de VLAN encriptada, é apresentada a seguinte mensagem de erro:

VLAN attachment should have type DEDICATED or PARTNER.

Para corrigir este problema, crie apenas associações VLAN encriptadas com o tipo DEDICATED ou PARTNER.

Valor de MTU incorreto para a associação VLAN

Quando cria uma associação VLAN encriptada para o Dedicated Interconnect, é apresentada a seguinte mensagem de erro:

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

Para corrigir este problema, recrie o anexo com o valor correto de 1440, que é o valor predefinido.