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 dentro da 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: Instâncias e balanceadores de carga de rede de passagem interna Instâncias do próximo salto Próximos saltos do balanceador de carga de rede de passagem interna Próximos saltos do túnel da VPN clássica
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.	Uma opção para pular a avaliação de outras rotas com base em políticas Um balanceador de carga de rede de passagem interna	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

Uma rota padrão tem o destino mais amplo possível: 0.0.0.0/0 para IPv4 e ::/0 para IPv6. O Google Cloud usa apenas uma rota padrão para entregar uma pacote quando ele não corresponder a uma rota mais específica na seção de roteamento ordem.

A ausência de uma rota padrão não isola necessariamente sua rede da Internet porque os caminhos de roteamento especiais para balanceadores de carga de rede de passagem externa e encaminhamento de protocolo não dependem de uma rota padrão.

Quando você cria uma VPC rede, O Google Cloud adiciona um padrão IPv4 gerado pelo sistema trajeto para o rede VPC do produtor de serviços. A rota padrão IPv4 gerada pelo sistema é uma rota Rota estática que tem um destino 0.0.0.0/0 e um gateway de Internet padrão próximo salto. Uma rota estática local com o destino 0.0.0.0/0 e o padrão o próximo salto do gateway de Internet fornece um caminho para IPv4 externo endereços IP, incluindo endereços IPv4 na Internet. Os recursos de exemplo abaixo usam esse caminho:

• VMs com endereços IPv4 externos atribuídos às interfaces de rede, quando os pacotes que eles enviam têm origens que correspondem à instância principal endereço IPv4 interno.
• Um gateway Cloud NAT público configurados para fornecer serviços NAT a sub-redes usadas por interfaces de rede de VMs. Dependendo dos intervalos de endereços IPv4 da sub-rede, o gateway do Cloud NAT estiver configurado para ser exibido, as origens de pacotes poderão corresponder a um dos seguintes itens:
  • Um endereço IPv4 interno de um intervalo de endereços IP do alias da VM de rede (se a interface de rede tem ou não uma conexão externa endereço IPv4) ou
  • O endereço IPv4 interno principal da interface de rede da VM, se o interface de rede não tem um endereço IPv4 externo atribuído.

Quando você cria uma sub-rede que tem um intervalo de endereços IPv6 externo, O Google Cloud adiciona uma rota padrão IPv6 gerada pelo sistema à rede VPC, caso ainda não tenha uma. A rota padrão IPv6 gerada pelo sistema é uma rota Rota estática que tem um destino ::/0 e um gateway de Internet padrão próximo salto. Uma rota estática local com o destino ::/0 e o padrão o próximo salto do gateway de Internet fornece um caminho para IPv6 externo endereços IP, incluindo endereços IPv6 na Internet. Esse caminho pode ser usado por:

• VMs com /96 intervalos de endereços IPv6 externos atribuídos à rede interfaces, quando os pacotes que elas enviam têm origens nesse endereço /96 do intervalo.

O acesso às APIs globais do Google às vezes depende de um padrão local do IPv4 ou IPv6 rota com o próximo salto do gateway de Internet padrão:

• Se você acessar serviços e APIs globais do Google enviando pacotes para um Endpoint do Private Service Connect para serviços globais do Google APIs, sua rede VPC não exige uma rota padrão com padrão gateway da Internet no próximo salto. O Google Cloud adiciona uma caminho de roteamento especial para o endpoint.

• Se você acessar serviços e APIs globais do Google enviando pacotes para endereços IPv4 ou endereços IPv6 para os domínios padrão, os endereços IPv4 ou IPv6 para private.googleapis.com ou os endereços IPv4 ou IPv6 de restricted.googleapis.com, é possível usar rotas IPv4 e IPv6 padrão com os próximos saltos padrão do gateway de Internet ou criar e usar as rotas estáticas IPv6 que têm destinos mais específicos próximos saltos do gateway de Internet:

  • Se as VMs tiverem apenas endereços IP internos, consulte as opções de Roteamento para Acesso privado do Google.
  • Se as VMs tiverem endereços IP externos, consulte Roteamento .

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-redes, consulte Sub-redes.

Uma rede VPC pode incluir os seguintes tipos de rotas de sub-rede:

• As rotas de sub-redes para sub-redes na mesma rede VPC, chamadas como rotas de sub-rede locais.
• Rotas de sub-rede de peering que são importadas de redes conectadas usando Peering de rede VPC.
• Rotas de sub-rede do Network Connectivity Center importadas da VPC de um hub do Network Connectivity Center.

Interações com rotas estáticas

O Google Cloud aplica as regras a seguir para rotas de sub-rede local, peering de rotas de sub-rede e rotas de sub-rede do Network Connectivity Center, menos a que foi configurada como uma sub-rede híbrida.

• O Google Cloud não permite que você crie uma nova rota estática se a nova rota estática corresponde ou se encaixa exatamente no destino de uma sub-rede local, de peering ou do trajeto no Network Connectivity Center. Por exemplo:

  • Se existir uma rota de sub-rede local, de peering ou do Network Connectivity Center com a 10.70.1.0/24, não é possível criar uma nova rota estática para 10.70.1.0/24, 10.70.1.0/25, 10.70.1.128/25 ou qualquer outro destino que caiba em 10.70.1.0/24.

  • Se existir uma rota de sub-rede local ou de peering com o 2001:0db8:0a0b:0c0d::/64, não é possível criar um novo destino estático trajeto para 2001:0db8:0a0b:0c0d::/64, 2001:0db8:0a0b:0c0d::/96 ou qualquer outro destino que se encaixe em 2001:0db8:0a0b:0c0d::/64.

• O Google Cloud não permite que você faça alterações nas sub-redes que resultam em um intervalo de endereços IP de sub-rede que corresponde exatamente ou contém o destino de uma rota estática local ou de peering existente. Por exemplo:

  • Se a rede VPC tiver uma rota estática com o 10.70.1.128/25, não será possível criar uma nova sub-rede que tenha um intervalo de endereços IPv4 principal ou secundário de 10.70.1.128/25, 10.70.1.0/24 ou qualquer outro intervalo de endereços IP que contenha todas os endereços em 10.70.1.128/25.

  • Se a rede VPC tiver uma rota estática com o 2001:db8:a0b:c0d:e0f:f0e::/96, o Google Cloud proíbe a criação de uma nova rota de sub-rede local ou de peering com um endereço IP intervalo de endereços de 2001:db8:a0b:c0d::/64 ou qualquer outro intervalo que contenha todos os endereços IPv6 em 2001:db8:a0b:c0d:e0f:f0e::/96.

Interações com rotas dinâmicas

O Google Cloud aplica as regras a seguir a menos que uma sub-rede tenha sido configuradas como sub-redes híbridas.

• O Google Cloud não cria uma rota dinâmica para um prefixo aprendido por uma Sessão do BGP de um Cloud Router se o prefixo corresponder exatamente ou se encaixa no destino de um servidor local, de peering ou Rota de sub-rede do Network Connectivity Center. Por exemplo:

  • Se existir uma rota de sub-rede local, de peering ou do Network Connectivity Center com a destino 10.70.1.0/24, e se um Cloud Router na ou uma rede VPC com peering recebe 10.70.1.128/25, 10.70.1.0/24 ou qualquer outro prefixo que se encaixe 10.70.1.0/24, o Google Cloud não cria dinâmica local ou de peering rotas para os prefixos conflitantes recebidos.

  • Se existir uma rota de sub-rede local, de peering ou do Network Connectivity Center com a 2001:0db8:0a0b:0c0d::/64, e se um Cloud Router em a rede VPC ou uma rede VPC com peering receber 2001:0db8:0a0b:0c0d::/96, 2001:0db8:0a0b:0c0d::/64 ou qualquer outro prefixo que caiba em 2001:0db8:0a0b:0c0d::/64, O Google Cloud não cria rotas dinâmicas locais ou de peering para a receberam prefixos conflitantes.

• O Google Cloud remove qualquer rota dinâmica local ou de peering, se houver alteração para sub-redes resulta na criação de uma nova rota de sub-rede local, de peering ou do Network Connectivity Center com corresponde exatamente a ou contém o destino da rota dinâmica local ou de peering existente. Por exemplo:

  • Se a rede VPC tiver uma rota dinâmica local ou de peering com o destino 10.70.1.128/25, o Google Cloud remove rota dinâmica quando uma nova rota de sub-rede local, de peering ou do Network Connectivity Center para 10.70.1.128/25, 10.70.1.0/24 ou qualquer outro intervalo de endereços IP contiver todos os endereços IPv4 em 10.70.1.128/25 for criado.

  • Se a rede VPC tiver uma rota dinâmica local ou de peering com o destino 2001:db8:a0b:c0d::/96, o Google Cloud remove a rota dinâmica quando uma nova sub-rede local, de peering ou a rota do Network Connectivity Center para 2001:db8:a0b:c0d::/64 é criada.

Ciclo de vida das rotas de sub-rede

Todos os intervalos de endereços IP que fazem parte de uma sub-rede: endereço IPv4 primário de rede, intervalos de endereços IPv4 secundários e intervalos de endereços IPv6 têm uma rota de sub-rede correspondente. O Google Cloud cria e exclui rotas de sub-rede nestas situações:

• Você faz uma configuração de sub-rede mudança, por exemplo:

  • adicionar ou excluir uma sub-rede.
  • Expandir um intervalo de IPv4 principal.
  • Adicione ou exclua um intervalo IPv4 secundário.
  • Adicione ou exclua um intervalo IPv6.

• O Google Cloud adiciona uma nova região, que adiciona automaticamente uma nova sub-rede VPC às redes de modo automático. Para informações sobre o endereço IPv4 para cada sub-rede por região, consulte intervalos IPv4 de modo automático.

Rotas dinâmicas

Roteadores de nuvem instruem a rede VPC a criar, atualizar e remover rotas dinâmicas com base nas mensagens do protocolo de gateway de borda (BGP, na sigla em inglês) recebidas, políticas de rota do BGP aplicáveis (Prévia) e Rotas aprendidas personalizadas do Cloud Router que você configurar. 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:

• Um anexo da VLAN apoiado por uma conexão de Interconexão dedicada ou Interconexão por parceiro

• Um túnel do Cloud VPN, um túnel VPN de alta disponibilidade ou uma VPN clássica configurada para usar o roteamento dinâmico

• Uma instância de VM do dispositivo roteador no Network Connectivity Center

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 timer de Graceful Restart do roteador de peer expirou (se o peer BGP for compatível com o Graceful Restart).

• O timer de espera do Cloud Router expirou. O timer de espera do Cloud Router é proporcional ao timer de sinal de atividade configurável do Cloud Router.

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. Confira mais informações:

• Opções para troca de rotas estáticas personalizadas

• Opções para trocar rotas dinâmicas personalizadas

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, túnel do Cloud VPN e anexo da VLAN tem um conjunto de rotas aplicáveis, que são as rotas aplicáveis a esse recurso específico. As rotas aplicáveis são um subconjunto de todas as rotas na rede VPC.

Os tipos de rota a seguir sempre se aplicam a todas as instâncias de VM, anexos da VLAN do Cloud Interconnect e túneis do Cloud VPN:

• Caminhos de roteamento especiais
• Rotas de sub-rede

Os tipos de rota a seguir podem ser configurados para serem aplicados apenas a determinadas instâncias de VM, anexos de VLAN ou túneis do Cloud VPN:

• As Rotas com base na política podem ser aplicadas a:

  • todas as instâncias de VM, anexos da VLAN e túneis de VPN;
  • somente instâncias de VM identificadas por tag de rede;
  • somente anexos da VLAN em uma região específica.

• As rotas estáticas podem ser aplicadas a:

  • todas as instâncias de VM, anexos da VLAN e túneis do Cloud VPN;
  • somente instâncias de VM identificadas por tag de rede.

• As rotas dinâmicas podem ser aplicadas a instâncias de VM, anexos da VLAN e túneis do Cloud VPN na região que contém o próximo salto da rota dinâmica ou em todas as regiões, com base no modo de roteamento dinâmico da rede VPC.

Caminhos de roteamento especiais

As redes VPC têm rotas especiais para determinados serviços. Esses caminhos de roteamento especiais não aparecem na sua tabela de rotas da rede VPC. Não é possível remover caminhos de roteamento especiais. No entanto, é possível permitir ou negar pacotes usando regras de firewall de VPC ou políticas de firewall.

Caminhos para balanceadores de carga de rede de passagem externa e encaminhamento de protocolo externo

Balanceadores de carga de rede de passagem externa e encaminhamento de protocolo externo usam os sistemas Maglev para rotear pacotes de clientes na Internet para VMs de back-end e instâncias de destino na sua rede VPC. Esses sistemas Maglev encaminham pacotes com destinos que correspondem ao destino da regra de encaminhamento da página.

Cada regra de encaminhamento para um balanceador de carga de rede de passagem externa ou para um encaminhamento de protocolo externo também fornece um caminho de roteamento para as VMs de back-end ou a instância de destino para enviar pacotes para destinos fora da rede VPC:

• Os pacotes enviados por VMs de back-end ou instâncias de destino podem enviar pacotes de resposta (enviados de volta ao cliente) ou podem ser pacotes de saída que iniciam uma nova conexão.
• As origens dos pacotes precisam corresponder ao endereço IP da regra de encaminhamento. Protocolo de pacote e a porta de origem não precisam corresponder ao protocolo e à porta da regra de encaminhamento especificação.
• Os caminhos de roteamento das regras de encaminhamento não dependem de uma rota padrão ou do uso de o próximo salto do gateway de Internet padrão.
• As VMs de back-end e as instâncias de destino não precisam ter o encaminhamento de IP ativado.

Caminhos entre o Google Front Ends e os back-ends

Balanceadores de carga de aplicativo externos e balanceadores de carga de rede de proxy externos usam o Google Front Ends (GFEs). Os GFEs de segunda camada abrem conexões TCP com as VMs de back-end e enviam pacotes das seguintes fontes:

• 35.191.0.0/16
• 130.211.0.0/22

O Google Cloud usa rotas na rede do Google para entregar pacotes desses intervalos de origem para VMs de back-end na rede VPC. Cada rede VPC tem caminhos de roteamento que permitem às VMs enviar pacotes de resposta a 35.191.0.0/16 e 130.211.0.0/22.

Caminhos para verificações de integridade

Verificações de integridade para todos os balanceadores de carga e para o grupo gerenciado de instâncias de recuperação automática enviar pacotes para as VMs de back-end de intervalos de endereços IP de sondagem de verificação de integridade.

O Google Cloud usa rotas na rede do Google para entregar pacotes de sistemas de sondagem de verificação de integridade para VMs na rede VPC. Cada rede VPC tem caminhos de roteamento que permitem às VMs enviar pacotes de resposta aos sistemas de sondagem de verificação de integridade.

Caminhos para o Identity-Aware Proxy (IAP)

O encaminhamento de TCP com IAP usa 35.235.240.0/20 como um intervalo somente interno com os próximos saltos totalmente na rede do Google. O Google não publica rotas para 35.235.240.0/20 na Internet.

As rotas na rede do Google entregam pacotes de 35.235.240.0/20 para VMs na rede VPC ao usar o encaminhamento de TCP do IAP. Cada rede VPC inclui caminhos de roteamento que permitem que as VMs enviem pacotes de resposta para 35.235.240.0/20.

Caminhos para o Cloud DNS e o Diretório de serviços

Os seguintes recursos do Cloud DNS e do Diretório de serviços usam 35.199.192.0/19 como um intervalo somente interno com os próximos saltos totalmente na rede do Google. O Google não publica rotas para 35.199.192.0/19 na Internet.

• Destinos de encaminhamento que usam roteamento particular do Cloud DNS
• Servidores de nomes alternativos que usam roteamento particular do Cloud DNS
• Acesso à rede privada para o Diretório de serviços

As rotas na rede do Google entregam pacotes de 35.199.192.0/19 para VMs na rede VPC quando você usa essas instâncias do Cloud DNS e recursos do Diretório de serviços. Cada rede VPC inclui caminhos de roteamento que permitem que as VMs enviem pacotes de resposta para 35.199.192.0/19.

Caminhos para acesso VPC sem servidor

Usos de acesso VPC sem servidor 35.199.224.0/19 como um intervalo somente interno com os próximos saltos totalmente na rede do Google. O Google não publica rotas para 35.199.224.0/19 na Internet.

As rotas na rede do Google entregam pacotes de 35.199.224.0/19 para Instâncias do conector de acesso VPC sem servidor. Cada rede VPC inclui caminhos de roteamento que permitem que as instâncias do conector enviem pacotes de respostas para 35.199.224.0/19.

Caminhos para endpoints do Private Service Connect para APIs globais do Google

Quando você cria um endpoint do Private Service Connect para as APIs do Google, o Google Cloud adiciona uma rota para o endpoint da sua rede VPC. O destino da rota é o endereço IP interno global do endpoint.

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 roteamento especiais: alguns caminhos de roteamento especiais do Google Cloud não são mostrados na tabela de rotas da rede VPC. Para mais detalhes, consulte Caminhos de roteamento especiais:

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

2. Rotas com base na política: são avaliadas após caminhos de retorno especiais, mas antes de outros tipos de rotas. Se a rede VPC não tiver rotas com base na política, o Google Cloud pulará esta etapa e seguirá para a etapa de rotas de sub-rede.

   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 na política depois de avaliar todas essas rotas no seu modelo de seleção de rotas, o Google Cloud ignorará todas as rotas com base na política e seguirá para a etapa de rotas de sub-rede.

   • 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, o 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 na política de prioridade mais alta configurada para ignorar outras rotas com base na política, o Google Cloud ignorará todas essas rotas e seguirá para a etapa de rotas de sub-rede.

   • 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. Rotas de sub-rede: o Google Cloud determina se o destino do pacote se encaixa no intervalo de destino de uma rota de sub-rede local, de peering ou do Network Connectivity Center na rede VPC.

   • Se o destino de um pacote não corresponder ao intervalo de destino de qualquer rota de sub-rede local, de peering ou do Network Connectivity Center, o Google Cloud ignorará todas as rotas de sub-rede e seguirá para a etapa de destino mais específico.

   • Se o destino de um pacote corresponder ao intervalo de destino de uma rota de sub-rede local, de peering ou do Network Connectivity Center na rede VPC, o comportamento será diferente caso a sub-rede esteja configurada como uma sub-rede híbrida:

     • Para a maioria das sub-redes, o Google Cloud usa exclusivamente a rota de sub-rede, tentando enviar o pacote para um recurso na sub-rede, como uma interface de rede de VM ou uma regra de encaminhamento interno. Todas as outras rotas são desconsideradas, e a avaliação é interrompida nesta etapa. Se nenhum recurso estiver presente usando o destino do pacote ou se o recurso for uma instância de VM interrompida, o pacote será descartado.

     • No entanto, se a rota de sub-rede correspondente vier de uma sub-rede híbrida, o Google Cloud tentará localizar um recurso de destino correspondente na sub-rede, como uma interface de rede de VM ou uma regra de encaminhamento interna:

       • Se houver um recurso na sub-rede, o Google Cloud usará exclusivamente a rota de sub-rede, tentando enviar o pacote ao recurso. Todas as outras rotas são desconsideradas, e a avaliação é interrompida nesta etapa. Se não houver recurso no destino do pacote, ele será descartado. Se o recurso for uma VM que não está em execução, o pacote também será descartado.

       • Se um recurso não existir na sub-rede, o Google Cloud ignorará todas as rotas de sub-rede, incluindo a rota de sub-rede correspondente, e seguirá para a etapa de destino mais específico.

4. Destino mais específico: no início desta etapa, o modelo de seleção de rotas não tem caminhos de roteamento especiais, rotas com base na política, rotas locais, de peering ou de sub-rede do Network Connectivity Center.

   O Google Cloud determina qual das rotas aplicáveis restantes 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.

   Ao final desta etapa, o modelo de seleção de rotas conterá apenas as rotas personalizadas mais específicas.

5. 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 app semelhantes. 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 app semelhante.

   • 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 de app semelhante com os próximos saltos para os destinos mais específicos. A prioridade da rota não é considerada agora. Além disso, se a rede VPC fizer peering com uma nova rede VPC ou se ela se desconectar de uma rede VPC de app semelhante 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.

6. Desconsiderar elementos estáticos e dinâmicos rotas com próximos saltos inutilizáveis: esta etapa modela situações em que o Google Cloud desconsidera os próximos saltos que estão inativos ou são inválidos.

   • Especificação de endereço IP da VM do próximo salto inválido: endereços IP especificados usando next-hop-address precisam ser resolvidos para um dos seguintes na mesma rede VPC que a rota:

     • Um endereço IPv4 interno principal da interface de rede de uma VM
     • Um endereço IPv6 interno ou externo da interface de rede de uma VM

   • A VM do próximo salto não está em execução: o Google Cloud ignora cada rota estática de peering em que a instância da VM do próximo salto foi interrompida ou excluída. Esse comportamento se aplica a rotas configuradas com next-hop-instance ou next-hop-address. 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.

   • Especificação de endereço IP do balanceador de carga de rede do balanceador de carga de rede de passagem interna do próximo salto inválido: se um endereço IP da rota estática de peering tem um balanceador de carga do próximo salto por endereço IP, o endereço IP de salto deve ser resolvido para uma regra de encaminhamento para um balanceador de carga de rede de passagem interna, na rede VPC da rota ou em uma rede VPC com peering. Se o endereço IP do próximo salto for resolvido para uma regra de encaminhamento para outro tipo de balanceador de carga ou não resolve uma regra de encaminhamento, o Google Cloud desconsidera a rota.

   • Balanceador de carga de rede de passagem interna do próximo salto inacessível: se uma instância estática ou de peering tem um balanceador de carga do próximo salto e, se o recurso do Google Cloud que o envio do pacote esteja localizado em uma região diferente do balanceador de carga, o Google Cloud desconsidera a rota se regra de encaminhamento não tem o acesso global ativado. A rota foi descartada se o próximo salto é especificado por nome ou endereço IP.

   • Túnel da VPN clássica do próximo salto não estabelecido: O Google Cloud desconsidera todas as rotas estáticas locais ou de peering, o túnel da VPN clássica do próximo salto não tem uma Fase 1 ativa (IKE) do Google Cloud. Para mais detalhes, consulte Ordem das rotas na documentação da VPN clássica.

   • Rota dinâmica com próximo salto não funcional: mesmo antes da sessão do BGP responsável pela programação de uma rota dinâmica local ou de peering é desativada, o Google Cloud desconsidera um túnel do Cloud VPN de próximo salto, Anexo da VLAN do Cloud Interconnect ou VM do dispositivo roteador, se o próximo salto não estiver funcionando. Essa situação geralmente só existe para um alguns segundos antes que a rota dinâmica seja removida quando a sessão do BGP do Cloud Router fica inativa.

7. 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

8. 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 o 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 locais ou de peering com instâncias do próximo salto (next-hop-instance ou next-hop-address) ou próxima do túnel do Cloud VPN clássico.
   Segunda escolha	Rotas dinâmicas locais ou de peering
   Terceira escolha	Rotas estáticas locais ou de peering com balanceador de carga de rede de passagem interna do próximo salto (independentemente de como o próximo salto é especificado). O Google Cloud não faz o balanceamento de carga entre vários rotas estáticas com diferentes próximos saltos do balanceador de carga de rede de passagem interna. Para mais informações, consulte Considerações sobre próximos saltos do balanceador de carga de rede de passagem interna.
   Quarta opção	Rotas estáticas locais com próximo salto default-internet-gateway:

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

9. 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.

   • 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 informações, consulte Considerações comuns sobre próximos saltos do balanceador de carga de rede de passagem interna e da instância.

   • 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.

A seguir

• Para criar e gerenciar rotas, consulte Usar rotas.
• Para saber mais sobre as rotas estáticas, consulte Rotas estáticas.
• Para uma visão geral das redes VPC do Google Cloud, consulte Redes VPC.
• Para criar, modificar ou excluir redes VPC, consulte Criar e gerenciar redes VPC.