Rotas

As rotas do Google Cloud definem os caminhos percorridos pelo tráfego de rede de uma instância de máquina virtual (VM) para outros destinos. Esses destinos podem estar na sua rede de nuvem privada virtual (VPC) do Google Cloud (por exemplo, em outra VM) ou fora dela.

Em uma rede VPC, uma rota consiste em um prefixo de destino no formato CIDR e um próximo salto. Quando uma instância em uma rede VPC envia um pacote, o Google Cloud entrega o pacote ao próximo salto da rota se o endereço de destino do pacote estiver dentro do intervalo de destino da rota.

Esta página fornece uma visão geral de como as rotas funcionam no Google Cloud.

Roteamento no Google Cloud

Toda rede VPC usa um mecanismo de roteamento virtual distribuído e escalonável. Não há nenhum dispositivo físico atribuído à rede. Algumas rotas podem ser aplicadas seletivamente, mas a tabela de roteamento de uma rede VPC é definida no nível da rede VPC.

Cada instância de VM tem um controlador que conhece todas as rotas aplicáveis da tabela de roteamento da rede. Cada pacote que deixa uma VM é entregue no próximo salto apropriado de uma rota aplicável com base em uma ordem de roteamento. Quando você adiciona ou exclui uma rota, o conjunto de alterações é propagado para os controladores de VM usando um design de consistência posterior.

Tipos de rota

As tabelas a seguir resumem como o Google Cloud categoriza rotas em redes VPC.

Tipo e destino Próximo salto Observações
Rotas geradas pelo sistema
Rotas padrão geradas pelo sistema
0.0.0.0/0 para IPv4
::/0 para IPv6
default-internet-gateway Aplica-se a toda a rede VPC

Pode ser removida ou substituída
Rota de sub-rede
Criada automaticamente para cada intervalo do endereço IP da sub-rede
Rede VPC
Encaminha pacotes a VMs e balanceadores de carga internos

Criados, atualizados e removidos automaticamente pelo Google Cloud durante eventos de ciclo de vida da sub-rede.

As rotas de sub-rede local se aplicam a toda a rede VPC.

Rotas personalizadas
Rota estática
Compatível com vários destinos
Encaminha pacotes a um próximo salto de rota estática Para ver detalhes sobre cada próxima rota de salto estático, consulte as considerações para:
Rota dinâmica
Destinos que não entram em conflito com rotas de sub-rede ou rotas estáticas
Par de uma sessão do BGP em um Cloud Router As rotas são adicionadas e removidas automaticamente com base nas rotas aprendidas dos Cloud Routers na sua rede VPC.

As rotas se aplicam às VMs de acordo com o modo de roteamento dinâmico da rede VPC.
Rotas de peering de rede VPC
Rota de sub-rede com peering
Representa um intervalo de endereços IP de sub-rede em uma rede VPC diferente conectada usando peering de rede VPC
Próximo salto na rede VPC com peering

O peering de rede VPC oferece opções para trocar rotas de sub-rede.

Criados, atualizados e removidos automaticamente pelo Google Cloud durante eventos de ciclo de vida da sub-rede.

As rotas de sub-rede de peering importadas se aplicam a toda a rede VPC.

Peering de rotas estáticas e dinâmicas
Rotas estáticas ou dinâmicas em uma rede VPC diferente conectada usando peering de rede VPC
Próximo salto na rede VPC com peering

O peering de rede VPC oferece opções para trocar rotas estáticas.

As rotas estáticas de peering importadas aplicam-se a toda a rede VPC.

O peering de rede VPC oferece opções para trocar rotas dinâmicas.

As rotas dinâmicas de peering importadas aplicam-se a uma ou a todas as regiões da rede VPC de acordo com o modo de roteamento dinâmico da rede VPC que exporta as rotas.

Rotas do Network Connectivity Center
Rota de sub-rede do Network Connectivity Center
Representa um intervalo de endereços IP de sub-rede em um spoke VPC (uma rede VPC diferente conectada ao hub do Network Connectivity Center).
Hub do Network Connectivity Center

Os administradores spoke do Network Connectivity Center podem excluir a exportação de rotas de sub-rede.

Criados, atualizados e removidos automaticamente pelo Google Cloud durante eventos de ciclo de vida da sub-rede.

As rotas de sub-rede importadas do Network Connectivity Center se aplicam a toda a rede VPC.

Rotas com base em políticas
Rota com base em políticas
Rotas com base em políticas podem ser aplicadas a pacotes com base no endereço IP de origem, no endereço IP de destino, no protocolo ou em uma combinação deles.

As rotas com base na política são avaliadas antes de outras rotas. Rotas com base na política podem ser aplicadas a todas as VMs na rede, a determinadas VMs selecionadas por tag de rede ou ao tráfego que entra na rede VPC por meio de anexos da VLAN do Cloud Interconnect que você especifica.

Rotas com base na política não são trocadas por peering de rede VPC.

Rotas padrão geradas pelo sistema

Ao criar uma rede VPC, ela inclui uma rota padrão de IPv4 gerada pelo sistema (0.0.0.0/0). Ao criar uma sub-rede de pilha dupla com um intervalo de endereços IPv6 externo em uma rede VPC, uma rota padrão IPv6 gerada pelo sistema (::/0) é adicionada a essa rede, se a rota ainda não existir. As rotas padrão têm as seguintes finalidades:

O Google Cloud usa uma rota padrão se uma rota com um destino mais específico não se aplicar a um pacote. Para ver informações sobre como a especificidade do destino e a prioridade da rota são usadas para selecionar uma rota, consulte Ordem de rotas.

Se você quiser isolar completamente sua rede da Internet ou se precisar substituir a rota padrão por uma personalizada, você pode excluir a rota padrão:

  • Somente IPv4: se você quiser rotear o tráfego da Internet para um próximo salto diferente, substitua a rota padrão por uma dinâmica ou estática personalizada. Por exemplo, é possível substituí-la por uma rota estática personalizada que tenha como próximo salto uma VM do proxy.

  • IPv4 e IPv6: se você excluir a rota padrão e não a substituir, os pacotes destinados a intervalos IP que não forem cobertos por outras rotas serão descartados.

Rotas de sub-rede

As rotas de sub-rede definem os caminhos para recursos como VMs e balanceadores de carga internos em uma rede VPC.

Cada sub-rede tem pelo menos uma rota de sub-rede com um destino que corresponde ao intervalo de IPv4 primário da sub-rede. Se a sub-rede tiver intervalos de IP secundários, há uma rota de sub-rede correspondente para cada um dos intervalos de endereços IP secundários. Se a sub-rede tiver um intervalo IPv6, há uma rota de sub-rede correspondente ao intervalo de endereços IPv6. Para mais informações sobre intervalos de IP de sub-rede, consulte Sub-redes.

Rotas de sub-rede sempre têm os destinos mais específicos. Elas não podem ser substituídas por outras rotas, mesmo que outra tenha uma prioridade mais alta. Isso ocorre porque o Google Cloud considera a especificidade do destino antes da prioridade ao selecionar uma rota. O Google Cloud usa 0 como prioridade para todas as rotas de sub-redes.

Interações com rotas estáticas

As rotas de sub-rede local e as rotas de sub-rede de peering importadas interagem com rotas estáticas personalizadas das seguintes maneiras:

  • O Google Cloud não permite que você crie uma rota estática personalizada que tenha um destino igual ou mais restrito do que qualquer rota de sub-rede ou rota de sub-rede de peering. Exemplo:

    • Se uma rota de sub-rede local ou uma rota de sub-rede de peering existir para o destino 10.70.1.0/24, não será possível criar uma nova rota estática personalizada para 10.70.1.0/24, 10.70.1.0/25, 10.70.1.128/25 ou outros destinos que se encaixam em 10.70.1.0/24.

    • Se uma rota de sub-rede local ou uma rota de sub-rede de peering existir para o 2001:0db8:0a0b:0c0d::/64 destino, não será possível criar uma nova rota estática personalizada para2001:0db8:0a0b:0c0d::/64 ou qualquer destino que se encaixe2001:0db8:0a0b:0c0d::/64, como2001:0db8:0a0b:0c0d::/96 do Google Analytics.

  • Por outro lado, o Google Cloud não permite que você crie uma nova rota de sub-rede ou uma rota de sub-rede de peering cujo destino corresponda exatamente ou seja mais amplo que (contém) uma rota estática personalizada existente. Exemplo:

    • Se sua rede VPC tiver uma rota estática personalizada para o destino 10.70.1.128/25, o Google Cloud proibirá a criação de qualquer rota de sub-rede ou rota de sub-rede de peering que tenha um intervalo de endereços IPv4 primário ou secundário de 10.70.1.128/25, 10.70.1.0/24 ou qualquer outro intervalo que contenha todos os endereços IPv4 em 10.70.1.128/25.

    • Se sua rede VPC tiver uma rota estática personalizada para o destino 2001:0db8:0a0b:0c0d::/96, o Google Cloud proibirá a criação de qualquer rota de sub-rede de pilha dupla ou rota de sub-rede de peering que tenha um intervalo de endereços IPv6 de 2001:0db8:0a0b:0c0d::/64 ou qualquer outro intervalo que contenha todos os endereços IPv6 em 2001:0db8:0a0b:0c0d::/96.

Interações com rotas dinâmicas

As rotas de sub-rede local e as rotas de sub-rede de peering importadas interagem com Cloud Routers das seguintes maneiras:

  • Quando os Cloud Routers aprendem um prefixo que corresponde exatamente ao destino de uma sub-rede ou rota de sub-rede de peering atual, o Google Cloud não cria nenhuma rota dinâmica personalizada para o prefixo conflitante. Por exemplo, quando existe uma sub-rede ou rota de sub-rede de peering com destino 10.70.1.0/24, se os Cloud Routers na rede VPC receberem o prefixo 10.70.1.0/24 pelo BGP, o Google Cloud usará a sub-rede ou peering de sub-rede e não cria nenhuma rota dinâmica personalizada para 10.70.1.0/24.

    • Quando uma sub-rede ou rota de sub-rede de peering com destino correspondente exatamente a um prefixo aprendido pelos Cloud Routers na rede VPC é criada, o Google Cloud remove a rota dinâmica personalizada para o conflito. para criar espaço para a sub-rede ou a rota de sub-rede de peering.
  • Quando os Cloud Routers aprendem prefixos que se encaixam no destino de uma sub-rede ou rota de sub-rede de peering atual, o Google Cloud não cria nenhuma rota dinâmica personalizada para os prefixos conflitantes. Por exemplo, quando uma sub-rede ou rota de sub-rede de peering com destino 10.70.1.0/24 existe, se os Cloud Routers na rede VPC receberem os prefixos 10.70.1.0/25 e 10.70.1.128/25 pelo BGP, o Google O Cloud usa a sub-rede ou a rota de sub-rede de peering e não cria nenhuma rota dinâmica personalizada para 10.70.1.0/25 e 10.70.1.128/25.

    • Quando uma sub-rede ou rota de sub-rede de peering com destinos contém prefixos aprendizados pelos Cloud Routers na rede VPC é criada, o Google Cloud remove as rotas dinâmicas personalizadas dos prefixos conflitantes em para liberar espaço para a sub-rede ou a rota de sub-rede de peering.

Ciclo de vida das rotas de sub-rede

Rotas de sub-rede são criadas, atualizadas e excluídas quando você cria, modifica ou exclui sub-redes ou os intervalos de endereços IP delas:

  • Quando você adiciona uma sub-rede, o Google Cloud cria uma rota de sub-rede correspondente ao intervalo de endereços IP primário da sub-rede.

  • As redes VPC de modo automático criam uma rota de sub-rede para os intervalos de IP principais de cada uma das sub-redes criadas automaticamente. Só é possível excluir essas sub-redes se você converter a rede VPC do modo automático para o modo personalizado.

  • Não é possível excluir uma rota de sub-rede a menos que você modifique ou exclua a sub-rede:

    • Quando você remove um intervalo secundário de uma sub-rede, a rota de sub-rede desse intervalo secundário é excluída automaticamente.

    • Quando você exclui uma sub-rede, todas as rotas de sub-rede para os intervalos principais e secundários são excluídas automaticamente. Não é possível excluir a rota de sub-rede para o intervalo principal da sub-rede de nenhuma outra maneira.

O número de rotas de sub-rede em uma rede VPC é limitado pelo número máximo de intervalos de IP de sub-redes (primários e secundários).

Rotas dinâmicas

O Cloud Routers instrui a rede VPC a criar, atualizar e remover rotas dinâmicas com base nas mensagens recebidas pelo protocolo de gateway de borda (BGP, na sigla em inglês) e no Cloud Router personalizado. routes que você configura. O plano de controle do Cloud Router instala rotas dinâmicas regionalmente com base no modo de roteamento dinâmico da rede VPC:

  • Se uma rede VPC usar o modo de roteamento dinâmico regional, os Cloud Routers em cada região criarão rotas dinâmicas somente na mesma região do Cloud Router.

  • Se uma rede VPC usa o modo de roteamento dinâmico global, os Cloud Routers em cada região criam rotas dinâmicas em todas as regiões da rede VPC.

O próximo salto de uma rota dinâmica pode ser um dos seguintes:

Se um próximo salto de uma rota dinâmica ficar inacessível, o Cloud Router que gerencia a sessão do BGP instruirá a rede VPC a remover a rota dinâmica depois que uma das seguintes condições for atendida:

O Google Cloud resolve conflitos entre rotas dinâmicas e rotas de sub-rede locais e de peering, conforme descrito em Interações com rotas dinâmicas.

Rotas de sub-redes de peering

As rotas de sub-rede de peering definem caminhos para recursos em sub-redes em outra rede VPC que estão conectadas por meio de peering de rede VPC. Para mais informações, consulte Opções para trocar rotas de sub-rede.

As rotas de sub-rede local e de peering não podem se sobrepor. Para mais informações, consulte Interações de rotas de sub-rede e peering de sub-rede.

O número de rotas de sub-rede por grupo de peering é controlado pelos intervalos de sub-rede por rede por cota do grupo de peering.

Como fazer peering de rotas estáticas e dinâmicas

Ao usar o peering de rede VPC para conectar duas redes VPC, é possível exportar rotas estáticas e dinâmicas de uma rede e importá-las para a outra. Veja mais informações em:

O número de rotas estáticas por grupo de peering e rotas dinâmicas por região por grupo de peering é limitado por cotas de rota estática e dinâmica por rede.

Aplicabilidade e ordem

Rotas aplicáveis

Cada instância tem um conjunto de rotas aplicáveis, que são um subconjunto de todas as rotas na rede VPC. As rotas aplicáveis são os caminhos de saída possíveis que um pacote pode seguir quando enviado da instância.

  • Os caminhos de retorno especiais se aplicam ao retornar para balanceadores de carga de proxy, sistemas de verificação de integridade e outros serviços do Google. Para mais informações, consulte Caminhos de retorno do balanceador de carga. Essas rotas não são exibidas em nenhuma tabela de rotas.

  • Rotas com base em políticas podem ser aplicadas a pacotes enviados de instâncias de VM do Compute Engine ou aos pacotes recebidos por anexos da VLAN do Cloud Interconnect. Rotas com base na política só se aplicam se um pacote corresponder aos critérios da rota com base na política.

  • As rotas de sub-rede e de peering de peering se aplicam a todas as instâncias. Exceto para rotas baseadas em políticas, nenhum outro tipo de rota pode ter um destino que corresponda ou caiba no destino de uma rota de sub-rede local ou de peering. Para mais detalhes sobre resolução de conflitos entre sub-redes, rotas estáticas e dinâmicas, consulte Interações de rotas estáticas e de sub-redes e Interações de rotas dinâmicas e de sub-rede. do Google Analytics.

  • Rotas estáticas personalizadas podem ser aplicadas a todas as instâncias ou instâncias específicas. Rotas estáticas com um atributo de tag aplicam-se a instâncias que têm a mesma tag de rede. Se a rota não tiver uma tag de rede, a rota será aplicada a todas as instâncias na rede.

  • Rotas dinâmicas se aplicam a instâncias baseadas no modo de roteamento dinâmico da rede VPC.

Caminhos de retorno especiais

As redes VPC têm rotas especiais para determinados serviços. Essas rotas são definidas fora da sua rede VPC, na rede de produção do Google. Elas não aparecem na sua tabela de rota de rede VPC. Não é possível removê-las ou substituí-las, mesmo se você excluir ou substituir uma rota padrão na sua rede VPC. No entanto, é possível permitir ou negar pacotes usando regras de firewall VPC, políticas de firewall de rede ou políticas hierárquicas de firewall.

Caminhos de retorno do balanceador de carga

O Google Cloud usa rotas especiais fora da rede VPC para entregar pacotes entre:

  • Sistemas cliente e back-ends de balanceador de carga (para balanceadores de carga de rede de passagem externa)
  • Sistemas proxy e back-ends de balanceador de carga (para balanceadores de carga de proxy externos)
  • Sondagens de verificação de integridade e back-ends de balanceador de carga
Caminhos entre proxies e back-ends do Google Front End (GFE)

Balanceadores de carga de aplicativo externos globais, Balanceadores de carga de aplicativo clássicos, Balanceadores de carga de rede de proxy clássico e Balanceadores de carga de rede de proxy externos globais usam sistemas Google Front End (GFE) como proxies.

Quando um cliente envia uma solicitação ao balanceador de carga, os GFEs encerram essa primeira conexão TCP. Os GFEs abrem uma segunda conexão TCP com as VMs de back-end. O Google Cloud usa rotas definidas fora da rede VPC para rotear pacotes entre os proxies GFE e as VMs de back-end.

Caminhos para back-ends de balanceador de carga de rede de passagem externa

Para balanceadores de carga de rede de passagem externa, o Google Cloud usa rotas definidas fora da sua rede VPC para rotear pacotes entre clientes e VMs de back-end.

Verificações de integridade para todos os tipos de balanceador de carga

Os pacotes enviados dos sistemas de sondagem de verificação de integridade do Google Cloud usam origens de pacote documentadas em intervalos de IP de sondagem e regras de firewall.

IAP

O Google Cloud inclui rotas de e para 35.235.240.0/20 em cada rede VPC compatível com o encaminhamento de TCP usando o IAP. A rede de produção do Google usa 35.235.240.0/20 como um intervalo somente interno. Os próximos saltos para 35.235.240.0/20 estão totalmente dentro da rede de produção do Google.

Cloud DNS e diretório de serviços

O Google Cloud inclui rotas de e para 35.199.192.0/19 em cada rede VPC para aceitar destinos de encaminhamento que usam roteamento particular, servidores de nomes alternativos do Cloud DNS que usam roteamento particular e acesso de rede privada ao Diretório de serviços. A rede de produção do Google usa 35.199.192.0/19 como um intervalo somente interno. Os próximos saltos para 35.199.192.0/19 estão totalmente dentro da rede de produção do Google.

Acesso VPC sem servidor

O Google Cloud inclui rotas de e para 35.199.224.0/19 em cada rede VPC compatível com o acesso VPC sem servidor. A rede de produção do Google usa 35.199.224.0/19 como um intervalo somente interno. Os próximos saltos para 35.199.224.0/19 estão totalmente dentro da rede de produção do Google.

Ordem de roteamento

O processo a seguir modela o comportamento de seleção de rotas da rede VPC, começando com o conjunto de rotas aplicáveis descrito na seção anterior.

  1. Caminhos de retorno especiais: não são exibidos na tabela de rotas da sua rede VPC. As rotas configuradas em uma rede VPC não se aplicam a pacotes de resposta para determinados balanceadores de carga do Google Cloud, sistemas de verificação de integridade, Identity-Aware Proxy (IAP) e proxies do Cloud DNS. Para mais detalhes, consulte Caminhos de retorno especiais.

    Se um caminho de retorno especial for aplicável, seu modelo de seleção de rota conterá apenas o caminho de retorno especial. Todas as outras rotas são desconsideradas, e a avaliação é interrompida nesta etapa.

  2. Rotas com base em políticas: as rotas com base em políticas são avaliadas após caminhos de retorno especiais, mas antes de outros tipos de rotas. Se não houver rotas com base em políticas na rede VPC, o Google Cloud vai pular esta etapa e seguir para a etapa do destino mais específico.

    • O Google Cloud só avalia rotas com base em políticas de acordo com a prioridade delas. O Google Cloud avalia a origem e o destino de um pacote para cada rota com base em políticas, começando pela rota ou rotas de acordo com a política de prioridade mais alta. Se as características de um pacote não corresponderem a uma rota com base em políticas, o Google Cloud vai ignorar essa rota e continuar avaliando a próxima rota com base em políticas na lista classificada. A próxima rota com base em políticas a ser avaliada pode ter a mesma prioridade que a rota com base em políticas desconsiderada ou ter uma prioridade mais baixa.

    • Se as características de um pacote não corresponderem a qualquer rota com base em políticas depois de avaliar todas as rotas com base em políticas no seu modelo de seleção de rotas, o Google Cloud vai ignorar todas as rotas com base em políticas e seguir para a etapa de destino mais específico.

    • Se as características de um pacote corresponderem a uma rota com base na política de prioridade mais alta, o Google Cloud primeiro vai ignorar todas as rotas com base em políticas de menor prioridade. Se duas ou mais rotas com base em políticas forem deixadas na lista, o Google Cloud avaliará cada uma das rotas com base em políticas restantes que tiverem prioridades idênticas. O Google Cloud vai ignorar as rotas com base em políticas restantes se as características de um pacote não corresponderem. Após esta etapa, seu modelo de seleção de rota poderá conter uma ou mais rotas com base em políticas.

      • Se o modelo de seleção de rota incluir duas ou mais rotas com base em política de maior prioridade correspondentes, o Google Cloud selecionará uma única rota com base em política usando um algoritmo interno. A rota com base em política selecionada pode não ser a correspondência mais específica para a origem ou o destino do pacote. Para evitar essa ambiguidade, recomendamos que você crie rotas com base em políticas que tenham prioridades exclusivas.

      • Se o modelo de seleção de rotas incluir apenas uma rota com base em política de prioridade mais alta configurada para ignorar outras rotas com base em políticas, o Google Cloud avaliará rotas não baseadas em política na etapa de destino mais específico e desconsiderará todas as rotas com base em políticas.

      • Se o modelo de seleção de rota incluir apenas uma rota com base em política de prioridade mais alta que não esteja configurada para ignorar outras rotas com base em políticas, o Google Cloud entregará o pacote para o balanceador de carga de rede de passagem interna do próximo salto e desconsiderará todas as rotas não baseadas em políticas.

  3. Destino mais específico: o Google Cloud determina qual das rotas aplicáveis tem o destino mais específico que contém o endereço IP de destino do pacote. O Google Cloud desconsidera todas as outras rotas com destinos menos específicos. Por exemplo, 10.240.1.0/24 é um destino mais específico que 10.240.0.0/16. O destino mais específico pode ser qualquer tipo de trajeto. No entanto, as rotas de sub-rede, as rotas de sub-rede com peering e os caminhos de retorno especiais são as mais específicas por definição.

    Após essa etapa, seu modelo de seleção de rota não conterá caminhos de retorno especiais ou rotas com base na política. Incluirá apenas as rotas com os destinos mais específicos.

  4. Próximos saltos em uma única rede VPC: esta etapa só é aplicável se a rede VPC que tem o comportamento de rota sendo modelado estiver conectada a uma ou mais redes VPC usando o peering de rede VPC. Com o peering de rede VPC, é possível que haja rotas personalizadas com destinos idênticos em mais de uma das redes no grupo de peering. O requisito modelado nesta etapa é que o Google Cloud selecione os próximos saltos que estiverem todos em uma única rede VPC.

    • Se uma ou mais das rotas em seu modelo de rota tiverem próximos saltos dentro da rede VPC que você está modelando, desconsidere todas as rotas que têm próximos saltos em redes de peering. Nessa situação, o Google Cloud só usa os próximos saltos na rede VPC local, mesmo que os próximos saltos para o mesmo destino existam em uma ou mais redes VPC com peering.

    • Se nenhuma das rotas no seu modelo de rota tiver próximos saltos dentro da rede VPC que você está modelando e todos os próximos saltos existirem em várias redes de peering, o Google Cloud usa um algoritmo interno para selecionar uma única rede com os próximos saltos para os destinos mais específicos. A prioridade da rota não é considerada neste momento. Além disso, se a rede VPC fizer peering com uma nova rede VPC ou se ela se desconectar de uma rede VPC existente, a rede VPC selecionada para os próximos saltos pode mudar.

    Após esta etapa, o modelo de seleção de rota contém apenas as rotas com os destinos mais específicos, e os próximos saltos para essas rotas estão todos em uma única rede VPC.

  5. Ignorar rotas estáticas personalizadas que tenham próximos saltos que não estejam em execução: esta etapa modela duas situações em que o Google Cloud desconsidera próximos saltos que considera não em execução. Esta etapa se aplica somente a rotas estáticas personalizadas. Em vez disso, as rotas dinâmicas personalizadas são adicionadas e removidas automaticamente usando anúncios do BGP.

    • O Google Cloud ignorará todas as instâncias de VM do próximo salto (next-hop-instance ou next-hop-address) se a VM do próximo salto tiver sido interrompida ou excluída. Para mais detalhes, consulte Comportamento quando as instâncias forem interrompidas ou excluídas na seção Considerações sobre instâncias do próximo salto. Se o modelo de rota contiver rotas estáticas com VMs de próximo salto que sejam interrompidas ou excluídas, remova essas rotas do modelo.

    • O Google Cloud ignorará todas as rotas estáticas personalizadas que usam um túnel de VPN clássica do próximo salto se o túnel não tiver uma associação de segurança (SA, na sigla em inglês) da Fase 1 (IKE). Para mais detalhes, consulte Ordem das rotas na documentação da VPN clássica. Se o modelo de rota tiver rotas estáticas com próximos saltos que são túneis de VPN clássica sem SAs do IKE estabelecidas, remova-as do modelo.

  6. Desconsidere rotas de baixa prioridade: esta etapa modela como o Google Cloud descarta todas as rotas, exceto aquelas com a prioridade mais alta.

    Após essa etapa, o modelo de seleção de rota pode estar vazio ou conter uma ou mais rotas. Se o modelo contém rotas, todas as rotas têm todas estas características:

    • Destinos idênticos e mais específicos
    • Todos os próximos saltos em uma rede VPC: a rede VPC local ou uma rede VPC com peering único
    • Próximos saltos que não são conhecidos por estarem inativos
    • Prioridades idênticas e mais altas
  7. Selecione apenas a categoria de preferência mais favorável: o Google Cloud evita o roteamento de ECMP entre diferentes tipos de próximos saltos. Você pode modelar esse comportamento considerando o sistema de categorias de preferência descrito na tabela a seguir. Esta etapa refina seu modelo de rota para que ele contenha somente rotas que sejam do mesmo tipo de rota ou combinação de tipo de rota e do próximo salto.

    Categoria de preferência Combinação de categoria e próximo salto
    Primeira opção (maior preferência) Rotas estáticas personalizadas com uma instância do próximo salto em execução (next-hop-instance ou next-hop-address) ou túnel estabelecido de VPN clássica do próximo salto
    Segunda escolha Rotas dinâmicas personalizadas aprendidas de qualquer sessão do BGP de qualquer Cloud Router
    Terceira escolha Uma única rota estática personalizada com um próximo salto do balanceador de carga de rede de passagem interno
    O Google Cloud usa um algoritmo interno para selecionar um único balanceador de carga de rede de passagem interno do próximo salto ignorando os próximos saltos do balanceador de carga de rede de passagem interno com a mesma prioridade. Para mais detalhes, consulte "Mesmos balanceadores de carga de rede de passagem de mesmo destino e de vários próximos saltos" na seção Considerações para os próximos saltos do balanceador de carga de rede de passagem interna.
    Quarta opção Uma rota estática personalizada usando o próximo salto default-internet-gateway

    No final desta etapa, pode não haver rotas, uma ou duas ou mais rotas no modelo.

  8. Enviar ou soltar o pacote: o que acontece depende do número de rotas que permanecem no modelo de rota:

    • Se o modelo de rota estiver vazio, o pacote será descartado com um erro de destino do ICMP ou de rede inacessível. O Google Cloud nunca usa uma rota menos específica, que pode ter um próximo salto funcional.

    • Se o modelo de rota contiver uma única rota, o Google Cloud enviará o pacote para o próximo salto. Para os próximos saltos da VM, o Google Cloud não valida que o próximo salto da VM pode processar pacotes. Para mais detalhes, consulte Considerações comuns sobre os próximos saltos para do balanceador de carga de rede de passagem interna e da instância. Se a única rota for de sub-rede ou de peering e não houver recurso do Google Cloud no endereço IP de destino do pacote, o pacote será descartado.

    • Se o modelo de rota tiver duas ou mais rotas, elas compartilham o mesmo destino mais específico, estão localizadas em uma única rede VPC, têm os próximos saltos que não são conhecidos por estarem inativos, têm a mesmo prioridade mais alta e pertencem a um tipo de rota e a uma combinação de próximo salto (categoria de preferência). O Google Cloud distribui pacotes entre os próximos saltos que implementam vários caminhos de custo igual (ECMP, na sigla em inglês) usando um algoritmo de hash. Os cálculos de hash são feitos para cada pacote no momento em que ele é enviado, com base no número atual de próximos saltos. O Google Cloud usará um hash de cinco tuplas se o pacote contiver informações de porta. Caso contrário, ele usa um hash de três tuplas. Se o modelo de rota mudar conforme os pacotes subsequentes são enviados, o Google Cloud pode direcionar esses pacotes para um próximo salto diferente, mesmo que o hash seja o mesmo.

Rotas estáticas

É possível criar rotas estáticas de duas maneiras:

É possível trocar rotas estáticas com uma rede VPC com peering, conforme descrito em Opções para trocar rotas estáticas personalizadas na documentação do Peering de redes VPC.

Parâmetros de rota

As rotas estáticas são compatíveis com os seguintes atributos:

  • Nome e descrição. Esses campos identificam a rota. O nome é obrigatório, mas a descrição é opcional. Cada rota no seu projeto precisa ter um nome exclusivo.

  • Rede: Cada rota precisa estar associada a exatamente uma rede VPC.

  • Próximo salto. O próximo salto identifica o recurso de rede a que os pacotes são enviados. Todos os tipos de próximo salto oferecem suporte a destinos IPv4, e alguns tipos de próximo salto oferecem suporte a destinos IPv6. Para mais informações, consulte Próximos saltos e recursos.

  • Intervalo de destino. O intervalo de destino é uma única notação CIDR IPv4 ou IPv6. Os destinos de rotas estáticas precisam seguir as regras descritas em Interações com rotas estáticas personalizadas e Interações de sub-rede e rota estática. O destino mais amplo possível para uma rota estática IPv4 é 0.0.0.0/0. O destino mais amplo possível para uma rota estática IPv6 é ::/0.

  • Prioridade. Números menores indicam prioridades mais altas. A prioridade mais alta possível é 0, e a prioridade mais baixa é 65,535.

  • Tags de rede. É possível fazer com que uma rota estática seja aplicada apenas a instâncias de VM selecionadas na rede VPC, identificadas por uma tag de rede. Se você não especificar uma tag de rede, o Google Cloud aplicará a rota estática a todas as instâncias da rede. Rotas estáticas com tags nunca são trocadas ao usar o peering de rede VPC.

Próximos saltos e recursos

A tabela a seguir resume o suporte ao recurso de rota estática por tipo de próximo salto:

Próximo tipo de salto IPv4 IPv6 ECMP1
Gateway do próximo salto (next-hop-gateway)
Especifique um gateway de Internet padrão para definir um caminho para endereços IP externos.
Instância do próximo salto por nome e zona (next-hop-instance)
Enviar pacotes para uma VM do próximo salto que seja identificada por nome e zona e que esteja no mesmo projeto como a rota. Para mais informações, consulte Considerações para instâncias do próximo salto.
Instância do próximo salto por endereço (next-hop-address)
Envie pacotes para uma VM do próximo salto identificada pelo endereço IPv4 principal da interface de rede. Para mais informações, consulte Considerações para instâncias do próximo salto.
Balanceador de carga de rede de passagem interna do próximo salto por nome e região da regra de encaminhamento (next-hop-ilb)
Envie pacotes para back-ends de um balanceador de carga de rede de passagem interna identificado pelo nome e região da regra de encaminhamento. Para mais informações, consulte Considerações para os próximos saltos do balanceador de carga de rede interno.
Balanceador de carga de rede de passagem interna do próximo salto por endereço (next-hop-ilb).
Envie pacotes para back-ends de um balanceador de carga de rede de passagem interna, que é identificado pelo endereço IP da regra de encaminhamento do balanceador de carga. Para mais informações, consulte Considerações para os próximos saltos do balanceador de carga de rede interno.
Túnel da VPN clássica do próximo salto (next-hop-vpn-tunnel)
Enviar pacotes para um túnel da VPN clássica do próximo salto usando um roteamento com base em política ou uma VPN baseada em rota. Para mais informações, consulte Considerações para próximos saltos de túnel de VPN clássica.
1Multicaminho de custo igual (ECMP, na sigla em inglês) significa que duas ou mais rotas estáticas podem compartilhar o mesmo intervalo de destino e prioridade. Embora seja possível criar duas ou mais rotas estáticas em uma rede VPC com o mesmo destino, prioridade e próximo salto do gateway de Internet padrão, o efeito é o mesmo de uma única rota estática que usa o próximo salto de gateway de Internet padrão para esse destino e prioridade.

Projeto e rede do próximo salto

Uma rota estática do próximo salto está associada a uma rede VPC e a um projeto:

  • Rede: exceto conforme indicado na tabela abaixo, a rede VPC do próximo salto precisa corresponder à rede VPC da rota.

  • Projeto: exceto conforme indicado na tabela abaixo, o próximo salto precisa estar localizado no projeto que contém a rede VPC dele (um projeto independente ou um projeto host de VPC compartilhada). Alguns próximos saltos podem estar localizados em projetos de serviço de VPC compartilhada.

Próximo tipo de salto Podem estar em uma rede VPC com peering Pode estar em um projeto de serviço de VPC compartilhada
Gateway do próximo salto (next-hop-gateway)
Instância do próximo salto por nome (next-hop-instance)
Instância do próximo salto por endereço (next-hop-address)
Balanceador de carga de rede de passagem interna do próximo salto por nome e região da regra de encaminhamento (next-hop-ilb)
Balanceador de carga de rede de passagem interna do próximo salto por endereço (next-hop-ilb)
Túnel da VPN clássica do próximo salto (next-hop-vpn-tunnel)

Considerações comuns para os próximos saltos do balanceador de carga de rede da instância e da passagem interna

O roteamento baseado em instância refere-se a uma rota estática com um próximo salto que é uma instância de VM (next-hop-instance ou next-hop-address).

Balanceador de carga de rede de passagem interna como um próximo salto refere-se a uma rota estática com um próximo salto que é um balanceador de carga de rede de passagem interna (next-hop-ilb).

Ao configurar o roteamento com base em instância ou um balanceador de carga de rede de passagem interno como um próximo salto, considere as seguintes diretrizes:

  • É preciso configurar as VMs de back-end ou a instância de próximo salto para encaminhar pacotes de qualquer endereço IP de origem. Para configurar o encaminhamento, ative o encaminhamento de IP (can-ip-forward) por VM quando criar a VM. Para VMs criadas automaticamente como parte de um grupo gerenciado de instâncias, ative o encaminhamento de IP no modelo de instância usado pelo grupo de instâncias. Você deve fazer esta alteração de configuração além de qualquer configuração de sistema operacional necessária para rotear pacotes.

  • O software em execução na VM de back-end ou na instância de próximo salto deve ser configurado adequadamente. Por exemplo, VMs de dispositivos de terceiros que agem como roteadores ou firewalls devem ser configuradas de acordo com as instruções do fabricante.

  • As VMs de back-end ou a instância de próximo salto devem ter regras de firewall apropriadas. Você deve configurar regras de firewall que se aplicam aos pacotes que estão sendo roteados. Lembre-se:

    • As regras de entrada do firewall aplicáveis a instâncias que executam funções de roteamento devem incluir os endereços IP de origens de pacotes roteados. A regra de entrada de negação implícita bloqueia todos os pacotes de entrada. Portanto, você deve ao menos criar regras personalizadas de firewall com permissão de entrada.
    • As regras de saída do firewall aplicáveis a instâncias que executam funções de roteamento devem incluir os endereços IP de destinos de pacotes roteados. A regra de saída de permissão implícita permite isso, a menos que você tenha criado uma regra de proibição de saída específica para substituí-la.
    • Leve em consideração se a VM de back-end ou a Próxima instância de salto está realizando a Conversão de endereços de rede (NAT) ao criar suas regras de firewall.

    Para mais informações, consulte Regras de firewall implícitas.

  • A região de origem de um pacote enviado por uma VM de back-end ou uma instância do próximo salto é onde a VM de back-end ou a instância do próximo salto está localizada. Por exemplo, os pacotes processados por VMs de back-end ou instâncias do próximo salto em us-west1 podem ser enviados para destinos acessíveis apenas em us-west1, mesmo que a VM de back-end ou a instância do próximo salto originalmente receberam o pacote de um recurso em uma região diferente de us-west1. Veja a seguir alguns exemplos de recursos que podem ser acessados apenas na mesma região de uma VM que envia um pacote:

    • Balanceadores de carga de rede de passagem interna, balanceadores de carga de aplicativo internos e balanceadores de carga de rede de proxy interno regional com acesso global desativado
    • Túneis do Cloud VPN, anexos da VLAN do Cloud Interconnect e VMs do dispositivo Network Connectivity Router se a rede VPC usar roteamento dinâmico regional

Considerações sobre instâncias do próximo salto

  • Próximo salto por nome e zona da instância (next-hop-instance): quando você cria uma rota estática que tem uma instância do próximo salto especificada por nome e zona, o Google Cloud exige que uma instância com esse nome exista na zona especificada e atenda ao seguinte:

    • A instância está localizada no mesmo projeto da rota.
    • A instância tem uma interface de rede (NIC) na rede VPC da rota, e não uma rede VPC com peering.

    Enquanto houver uma rota estática em que o próximo salto for especificado pelo nome da instância e pela zona, o seguinte será aplicável:

    • O Google Cloud atualiza automaticamente a programação para o próximo salto em um dos seguintes casos:

      • O endereço IPv4 interno principal da próxima instância de salto for alterado ou
      • Você substitui a instância do próximo salto, e ela tem o mesmo nome, está na mesma zona e projeto e tem uma interface de rede na rede VPC da rota.
    • O Google Cloud não atualiza a programação do próximo salto nos seguintes casos:

      • Quando a instância é excluída
      • O intervalo de endereços IPv6 atribuído às mudanças de placa de rede (NIC) da instância
      • Quando o endereço IPv4 ou IPv6 da instância não estiver atribuído
  • Endereço IP interno da instância do próximo salto (next-hop-address): quando você cria uma rota estática que tem uma instância do próximo salto especificada por um endereço IPv4 interno, o Google Cloud verifica se o endereço IPv4 da VM do próximo salto se encaixa em um intervalo IPv4 de sub-rede de uma sub-rede na rede VPC da rota. No entanto, o Google Cloud só programa a rota se o endereço do próximo salto for um endereço IPv4 interno principal atribuído a uma placa de rede (NIC, na sigla em inglês) da VM na rede VPC da rota, e não uma rede VPC com peering.

    O Google Cloud atualiza automaticamente a programação do próximo salto quando o endereço IPv4 do próximo salto é movido para uma VM diferente, desde que a VM substituta atenda aos mesmos requisitos.

  • Instâncias do próximo salto em projetos de serviço de VPC compartilhada: quando você especifica uma VM de próximo salto por endereço IP, a VM pode estar localizada em um mesmo projeto como a rota (um projeto independente ou um projeto host de VPC compartilhada) ou a VM pode estar localizada em um projeto de serviço de VPC compartilhada. Quando você especifica uma VM de próximo salto por nome e zona da instância, ela precisa estar localizada no mesmo projeto que a rota e a rede VPC (um projeto autônomo ou um projeto host de VPC compartilhada).

  • Custos e latência entre regiões: quando você usa uma VM como próximo salto, o próximo salto está localizado em uma zona de uma região. A rota que usa o próximo salto está disponível para todas as instâncias na mesma rede VPC ou para selecionar instâncias com uma tag de rede correspondente. O Google Cloud não considera a distância regional para rotas que usam uma instância como próximo salto. Portanto, é possível criar uma rota que envia tráfego para uma VM de próximo salto em uma região diferente. O envio de pacotes de uma região para outra aumenta os custos da transferência de dados de saída e gera latência de rede.

  • Sem verificação de integridade, sem validação de configuração: o Google Cloud nunca verifica se uma próxima instância de próximo salto atende a todos os requisitos descritos na seção Considerações comuns sobre os próximos saltos do balanceador de carga de rede de passagem interno e da instância. Desativar a interface de rede da VM configurando o sistema operacional convidado da instância não faz com que o Google Cloud desconsidere a instância do próximo salto.

  • Sem hash simétrico ao conectar duas redes VPC: o Google Cloud não oferece hash simétrico ao usar duas ou mais VMs de próximo salto com várias interfaces de rede em uma configuração que atenda todos os seguintes critérios:

    • As VMs têm uma interface de rede em uma rede VPC e outra interface em uma segunda rede VPC.
    • Em cada rede VPC, existe um conjunto de pelo menos duas rotas estáticas personalizadas para o mesmo destino, usando a mesma prioridade, em que cada rota no conjunto faz referência a uma VM de próximo salto única.

    Se você usar duas ou mais VMs com várias interfaces para conectar redes VPC e precisar que a mesma VM processe pacotes para uma determinada conexão em ambas as direções, precisará de hash simétrico, que é compatível apenas com pelos balanceadores de carga de rede de passagem interna do próximo salto. Para detalhes sobre hash simétrico, consulte Hash simétrico na autenticação de balanceadores de carga de rede de passagem interna como próximos saltos.

  • Comportamento quando as instâncias são interrompidas ou excluídas: o Google Cloud não impede que você pare ou exclua uma VM do próximo salto de rota estática (especificada por um nome e zona ou endereço interno). Quando uma VM de próximo salto não está em execução, o roteamento para o destino depende da existência de outras rotas para o mesmo destino e se elas têm próximos saltos em execução. Para ilustrar esse comportamento, considere os exemplos a seguir:

    • Os pacotes com destinos que se encaixam em 192.168.168.0/24 são enviados para o próximo salto de route-vm-b na seguinte situação, em que o próximo salto para a rota de maior prioridade não está em execução. Esse roteamento acontece porque o Google Cloud desconsidera os próximos saltos que não estão em execução antes de considerar a etapa Ignorar rotas de baixa prioridade da ordem de roteamento:

      • route-vm-a, destino 192.168.168.0/24, prioridade 10, a VM do próximo salto está interrompida
      • route-vm-b, destino 192.168.168.0/24, prioridade 20, a VM do próximo salto está em execução.
      • route-vm-c, destino 192.168.168.0/24, prioridade 30, a VM do próximo salto está em execução.
    • Os pacotes com destinos que se encaixam em 192.168.168.0/24 são descartados neste próximo exemplo, em que todas as VMs do próximo salto para as rotas 192.168.168.0/24 não estão em execução, mesmo que uma rota para a 192.168.0.0/16 mais ampla tenha uma VM do próximo salto que esteja em execução. Os pacotes são descartados porque o Google Cloud desconsidera rotas com intervalos de destino mais amplos (menores comprimento de máscara de sub-rede) no destino mais específico que acontece antes da etapa desconsiderar rotas estáticas personalizadas cujos próximos saltos não estejam em execução daordem de roteamento:

      • route-vm-x, destino 192.168.168.0/24, prioridade 10, a VM do próximo salto está interrompida
      • route-vm-y, destino 192.168.168.0/24, prioridade 20, a VM do próximo salto está interrompida
      • route-vm-z, destino 192.168.0.0/16, prioridade 0, a VM do próximo salto está em execução.

Considerações sobre os próximos saltos do balanceador de carga de rede de passagem interno

  • Regras de encaminhamento compatíveis. O Google Cloud é compatível apenas com regras de encaminhamento do balanceador de carga de rede de passagem interna de próximo salto. O Google Cloud não é compatível com regras de encaminhamento de próximo salto usadas por outros balanceadores de carga, encaminhamento de protocolo ou como endpoints do Private Service Connect.

  • Métodos de especificação e rede e projeto de regras de encaminhamento. É possível especificar uma regra de encaminhamento de próximo salto usando um dos três métodos a seguir. O método de especificação usado determina se a rede da regra de encaminhamento precisa corresponder à rede da rota e em qual projeto a regra de encaminhamento pode estar localizada:

    • Por nome (--next-hop-ilb) e região (--next-hop-ilb-region) da regra de encaminhamento: ao especificar uma regra de encaminhamento de próximo salto por nome e região, a rede da regra de encaminhamento precisa corresponder à rede VPC da rota. A regra de encaminhamento precisa estar localizada no mesmo projeto que contém a rede dela (um projeto independente ou um projeto host de VPC compartilhada).

    • Por link de recurso da regra de encaminhamento: um link de recurso da regra de encaminhamento usa o formato /projects/PROJECT_ID/regions/REGION/forwardingRules/FORWARDING_RULE_NAME, em que PROJECT_ID é o ID do projeto que contém a regra de encaminhamento, REGION é a região da regra de encaminhamento e FORWARDING_RULE_NAME é o nome da regra de encaminhamento. Ao especificar uma regra de encaminhamento do próximo salto pelo link do recurso, a rede da regra de encaminhamento precisa corresponder à rede VPC da rota. A regra de encaminhamento pode estar localizada em um destes projetos: no projeto que contém a rede dela (um projeto independente ou um projeto host de VPC compartilhada) ou em um projeto de serviço de VPC compartilhada.

    • Por endereço IPv4 da regra de encaminhamento: ao especificar uma regra de encaminhamento de próximo salto pelo respectivo endereço IPv4, a rede dela pode ser uma destas: a rede VPC da rota ou uma rede VPC com peering. A regra de encaminhamento pode estar localizada em um destes projetos: no projeto que contém a rede dela (um projeto independente ou um projeto host de VPC compartilhada) ou em um projeto de serviço de VPC compartilhada.

  • Efeito do acesso global. As rotas estáticas personalizadas que usam os próximos saltos do balanceador de carga de rede interno são programadas em todas as regiões. O uso do próximo salto depende da configuração de acesso global do balanceador de carga. Com o acesso global ativado, o próximo salto do balanceador de carga pode ser acessado em todas as regiões da rede VPC. Com o acesso global desativado, o próximo salto do balanceador de carga só poderá ser acessado na mesma região que o balanceador de carga. Com o acesso global desativado, os pacotes enviados de outra região para uma rota usando um próximo salto do balanceador de carga de rede de passagem interno são descartados.

  • Quando nenhum back-end é íntegro. Quando todos os back-ends de um balanceador de carga de rede de passagem interno falharem nas verificações de integridade, as rotas que usam esse próximo salto ainda estarão em vigor. Os pacotes processados pela rota são enviados para um dos back-ends do balanceador de carga do próximo salto, de acordo com a distribuição de tráfego.

  • Não é possível usar regras de encaminhamento que usam um endereço IP interno comum (--purpose=SHARED_LOADBALANCER_VIP). Os balanceadores de carga internos de passagem de salto e as regras de encaminhamento do balanceador de carga de rede de passagem interno com um endereço IP comum são recursos mutuamente exclusivos. Um balanceador de carga de rede de passagem interna do próximo salto precisa usar um endereço IP exclusivo para a regra de encaminhamento do balanceador de carga para que apenas um serviço de back-end (um balanceador de carga) seja referenciado sem ambiguidade. É possível que as regras de encaminhamento que usam um endereço IP interno comum se refiram a diferentes serviços de back-end (diferentes balanceadores de carga de rede de passagem internos).

  • Mesmo balanceador de carga de rede de passagem dupla do mesmo destino e do próximo salto. Se você criar duas ou mais rotas estáticas personalizadas com o mesmo destino usando os próximos saltos do balanceador de carga de rede de passagem interno, o Google Cloud nunca distribuirá o tráfego entre os próximos saltos do balanceador de carga usando ECMP. Se as rotas tiverem prioridades exclusivas, o Google Cloud usará o balanceador de carga de rede de passagem interno de próximo salto na rota com a prioridade mais alta. Se as rotas tiverem prioridades iguais, o Google Cloud ainda selecionará apenas um balanceador de carga de rede de passagem interna do próximo salto. Nesse caso, conforme ilustrado no diagrama abaixo, o Google Cloud usa um algoritmo interno determinístico para selecionar uma única regra de encaminhamento de próximo salto (forwarding-rule-a), ignorando outras rotas com a mesma prioridade.

    O Google Cloud seleciona um único próximo salto quando rotas estáticas com diferentes saltos internos do balanceador de carga de rede de passagem interna têm a mesma prioridade e destino.
  • Vários destinos e o mesmo balanceador de carga de rede de passagem interna do próximo salto.

    Com tags de instância:

    Se você usa tags de instância (também chamadas de tags de rede), pode usar o mesmo balanceador de carga de rede de passagem interno do próximo salto para várias rotas estáticas personalizadas com o mesmo destino e prioridade.

    Sem tags: sem tags de rede, não é possível criar várias rotas estáticas personalizadas com a mesma combinação de destino, prioridade e próximo salto do balanceador de carga de rede de passagem interno. Por exemplo, route-x, route-y e route-z podem ser criados, mas route-x-copy não pode ser criado.

    Rotas estáticas que não têm tags de instância não podem ser criadas com o mesmo destino, prioridade e próximo salto do balanceador de carga de rede de passagem interno.
  • Tags da instância.

    É possível especificar tags de instância (também chamadas de tags de rede) para que a rota de próximo salto se aplique apenas a instâncias de cliente que foram configuradas com a tag. Isso permite selecionar quais instâncias de clientes serão preenchidas com qual rota de próximo salto com tag e a qual conjunto de dispositivos rotear o seu tráfego.

    Você não precisa separar as diferentes instâncias de cliente em redes VPC separadas, cada uma apontando para o balanceador de carga de rede de passagem interno preferido de front-end de um conjunto de dispositivos.

    .
  • Várias rotas para o mesmo prefixo de destino. As tags permitem especificar várias rotas para o mesmo destino com diferentes balanceadores de carga internos como próximos saltos. É possível usar tags ou prioridades diferentes para essas mesmas rotas de destino.

Considerações sobre os próximos saltos do túnel da VPN clássica

  • Custos e latência de região para região: o Google Cloud não considera a distância regional para rotas que usam um túnel de VPN clássica do próximo salto. O envio de tráfego para um túnel de VPN clássica de próximo salto em outra região adiciona custos de transferência de dados de saída e introduz latência de rede. Como prática recomendada, use um túnel de VPN de alta disponibilidade com roteamento dinâmico porque essa configuração considera a distância regional.

  • Comportamento quando túneis de VPN clássica não estão em execução: rotas estáticas personalizadas com próximos saltos que são túneis de VPN clássica não são removidas automaticamente quando esses túneis não estão em execução. Para detalhes sobre o que acontece quando os túneis não estão em execução, consulte Quando os túneis estão desativados na documentação da VPN clássica.

A seguir