A carga de trabalho nos EUA chega ao prefixo do escritório pela HA VPN sem problema, enquanto a carga europeia na mesma VPC não recebe nada. A sua tabela de rotas não contém qualquer entrada para o prefixo, nenhum túnel está em baixo e nenhuma regra de firewall mudou. O túnel e a sua sessão BGP estão saudáveis nos dois sentidos. Uma VPC que abrange regiões não é o mesmo que as suas rotas aprendidas que abrangem regiões, e é essa lacuna que explica todo o sintoma.

Aqui confundem-se duas propriedades: onde vivem as sub-redes e onde pode ser usado um próximo salto aprendido.

De onde vem o âmbito regional

O Cloud Router instala as rotas aprendidas com um âmbito que segue o modo de roteamento dinâmico da VPC. Em modo regional, uma rota aprendida numa região só pode ser usada pelos recursos dessa região, e é por isso que a tabela europeia está vazia em vez de mostrar um próximo salto quebrado. Em modo global, as rotas aprendidas elegíveis ficam disponíveis para recursos em todas as regiões da VPC. Leia o valor atual antes de mudar seja o que for, porque o regional é a predefinição. A definição está na rede, não no túnel nem no router.

O comando de inventário é só de leitura e responde a isso numa linha:

gcloud compute networks describe VPC_NAME --format='value(routingConfig.routingMode)'

Execute-o no projeto anfitrião quando a VPC é partilhada. A rede pertence a esse projeto, e uma função de visualizador no projeto de carga pode nem mostrar a configuração de roteamento. Uma resposta rápida do projeto errado é pior do que nenhuma resposta.

A mudança é um comando e uma direção

A troca é uma edição do plano de controlo para toda a VPC, não um desvio por VM: gcloud compute networks update VPC_NAME --routing-mode=GLOBAL. É também num só sentido, porque uma rede definida como global não pode voltar a regional. Verifique mais uma vez o nome do projeto e da rede antes de o executar, já que o comando não pede confirmação. A mudança merece uma nota de manutenção e a aprovação do proprietário da rede, não uma experiência rápida numa VPC partilhada.

Cada ligação Cloud Router, VPN e Interconnect nessa rede herda o novo âmbito de imediato. Isso inclui as ligações que ninguém mencionou no pedido de alteração. As regiões que nunca tinham tido a rota começam a recebê-la assim que a mudança entra em vigor, e é por isso que não há implementação faseada para esta troca.

Global é um âmbito, não uma garantia

A elegibilidade e a preferência são independentes do âmbito. Uma rota que entra em conflito com um prefixo mais específico, perde a seleção do melhor caminho ou é filtrada por política comporta-se exatamente como antes. O modo global alarga onde uma rota pode ser usada, mas não decide qual rota ganha. Uma rota aprendida pode estar dentro do âmbito e ainda assim perder para um caminho estático ou mais específico na mesma VPC.

Essa distinção importa porque a mudança de modo é fácil de culpar mais tarde. Se a sub-rede europeia continuar sem rota depois da troca, a pergunta é se a rota existe e é elegível, não se o âmbito entrou em vigor. Os conflitos de prefixos e a saúde do próximo salto são as duas coisas seguintes a ler.

O lado remoto também anuncia de forma diferente

O comportamento de anúncio segue a mesma definição. Com o comportamento predefinido, um router em modo regional anuncia as sub-redes da sua própria região, enquanto o modo global anuncia as sub-redes da VPC de forma mais ampla. Por isso mudar o modo altera não só o que as suas regiões podem usar, mas também o que o lado remoto instala.

Uma lista de anúncios personalizada não se expande quando o modo muda. Se o router local tiver uma lista de intervalos escrita à mão, o prefixo europeu continua ausente dela. O caminho de retorno continua quebrado nesse caso, embora a rota de saída já exista. Verifique o que o lado remoto instalou em vez do que exportou.

O que o modo nunca vai reparar

O roteamento global não concede acesso à internet pública, trânsito entre VPC não relacionadas nem rotas estáticas em falta. Não altera regras de firewall nem IAM, por isso uma ligação recusada por política continua recusada.

Essas falhas parecem iguais de dentro de uma carga de trabalho e não têm nada a ver com o âmbito das rotas.

Teste a partir da região remota para o serviço real e depois confirme que a resposta volta pelo túnel previsto. Registe o modo, a configuração de anúncios e o destino que testou. Se o teste continuar a falhar, compare a tabela BGP do router remoto com a lista de rotas da VPC antes de tocar novamente no modo. Assim o próximo relatório entre regiões começa com factos e não com uma mudança de modo.

Artigos relacionados