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 com base na política: são avaliadas antes de qualquer outro tipo de rota.
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 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 (em apenas uma região ou em todas).

As rotas com base na política nunca são trocadas por peering de rede VPC.
Rotas de sub-rede: todos os tipos de rota de sub-rede são avaliados após as rotas com base na política, mas antes das rotas personalizadas.
Rota de sub-rede local
Criada automaticamente para cada intervalo do endereço IP da sub-rede 		Rede VPC

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.
Rota de sub-rede de 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.
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 personalizadas: são avaliadas após as rotas com base na política e as rotas de sub-rede.
Rota estática local
Suporta vários destinos 		Encaminha pacotes para um próximo salto de rota estática Para saber detalhes sobre cada próxima rota de salto estático, consulte as considerações para:
Rota dinâmica local
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.
Rota estática de peering, rota dinâmica de peering
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 se aplicam 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.
Rota dinâmica do Network Connectivity Center
Rotas dinâmicas importadas de spokes híbridos do Network Connectivity Center localizados em diferentes redes VPC 		Hub do Network Connectivity Center

Um hub do Network Connectivity Center pode ter spokes VPC e híbridos.

As rotas dinâmicas do Network Connectivity Center se aplicam a uma ou a todas as regiões da rede VPC de acordo com o modo de roteamento dinâmico da rede VPC que contém o spoke híbrido.
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

Rotas de sub-rede

Cada sub-rede tem pelo menos uma rota de sub-rede para cada intervalo de endereços IP associado a ela. Para mais informações sobre intervalos de IP de sub-redes, consulte Sub-redes.

Tipos de rotas de sub-rede

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 do Network Connectivity Center importadas de spokes VPC de um hub do Network Connectivity Center.
  • Rotas de sub-rede de peering que são importadas de redes conectadas usando Peering de rede VPC.

Os intervalos de destino de todos os tipos de rotas de sub-rede precisam ser exclusivos. Para mais informações, veja:

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

Os Cloud Routers 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, nas políticas de rota do BGP aplicáveis (Prévia) e nas Rotas aprendidas personalizadas do Cloud Router.

As rotas dinâmicas são criadas em uma ou em todas as regiões com base no modo de roteamento dinâmico e no modo de seleção do melhor caminho da rede VPC que contém o Cloud Router. Para saber mais, consulte:

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. Para mais informações, consulte Alterações de estado do BGP.

Tipos de rotas dinâmicas

Uma rede VPC pode incluir os seguintes tipos de rotas dinâmicas:

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

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 .

Interações de rota

As seções a seguir descrevem as interações entre rotas de sub-rede e outros tipos de rotas.

Interações entre rotas de sub-rede e 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 entre rotas de sub-rede e 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 se um Cloud Router enviar um prefixo que corresponde exatamente ou se encaixa no destino de uma rota de sub-rede local, de peering ou do Network Connectivity Center. Exemplo:

    • Se uma rota de sub-rede local, de peering ou do Network Connectivity Center existir com o destino 10.70.1.0/24 e se um Cloud Router na rede VPC, uma rede VPC pareada ou uma rede que contém um elo de conexão híbrido do Network Connectivity Center receber 10.70.1.128/25, 10.70.1.0/24 ou qualquer outro prefixo que se encaixe em 10.70.1.0/24, o Google Cloud não cria rotas dinâmicas locais, de peering ou do Network Connectivity Center para os prefixos conflitantes recebidos.

    • Se uma rota de sub-rede local, de peering ou do Network Connectivity Center existir com o destino 2001:0db8:0a0b:0c0d::/64 e um Cloud Router na rede VPC, uma rede VPC com peering ou uma rede que contém um elo de conexão híbrido do Network Connectivity Center receber 2001:0db8:0a0b:0c0d::/96, 2001:0db8:0a0b:0c0d::/64 ou qualquer outro prefixo que se encaixe em 2001:0db8:0a0b:0c0d::/64, o Google Cloud não cria rotas dinâmicas locais, de peering ou do Network Connectivity Center para os prefixos conflitantes recebidos.

  • O Google Cloud remove qualquer rota dinâmica existente se uma mudança nas sub-redes resultar na criação de uma nova rota de sub-rede local, de peering ou do Network Connectivity Center com destino que corresponda exatamente a ou contenha o destino da rota dinâmica local, de peering ou do Network Connectivity Center. Exemplo:

    • Se a rede VPC tiver uma rota dinâmica local, de peering ou do Network Connectivity Center com o destino 10.70.1.128/25, o Google Cloud remove a 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 que contenha todos os endereços IPv4 em 10.70.1.128/25 é criada.

    • Se a rede VPC tiver uma rota dinâmica local, de peering ou do Network Connectivity Center 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 do Network Connectivity Center para 2001:db8:a0b:c0d::/64 é criada.

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 e túneis do Cloud VPN:

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

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

Pode haver mais de uma rota aplicável para um determinado pacote. As etapas a seguir modelam o processo usado para selecionar uma rota.

  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 rota vai conter apenas rotas personalizadas com destinos idênticos.

  5. Selecione apenas o tipo de rota personalizada mais favorável: nesta etapa, o Google Cloud remove todas as rotas personalizadas, exceto o tipo mais favorável. As rotas personalizadas locais são preferidas em relação às rotas dinâmicas do Network Connectivity Center, e as rotas dinâmicas do Network Connectivity Center são preferidas em relação às rotas personalizadas de peering.

    A tabela a seguir resume a lógica usada pelo Google Cloud nesta etapa.

    Categoria de rota personalizada O que acontece
    Rotas estáticas e dinâmicas locais

    Se o modelo de rota contiver pelo menos uma rota estática ou dinâmica local para o destino, o Google Cloud removerá os seguintes tipos de rota personalizada, se estiverem presentes no modelo de rota:

    • Rotas dinâmicas do Network Connectivity Center de spokes híbridos, em diferentes redes VPC
    • Rotas dinâmicas de peering (importadas de outras redes VPC conectadas usando o peering de rede VPC)
    Rotas dinâmicas do Network Connectivity Center Se todas as condições a seguir forem atendidas, o Google Cloud vai remover todas as rotas estáticas e dinâmicas de peering do modelo de rota:
    • Seu modelo de rota não contém rotas personalizadas locais para o destino
    • O modo de rota contém pelo menos uma rota dinâmica do Network Connectivity Center para o destino
    • A rota dinâmica do Network Connectivity Center vem de um spoke híbrido em uma rede VPC diferente
    Rotas estáticas e dinâmicas de peering O tipo de rota personalizada menos favorável contém rotas personalizadas de peering. As rotas personalizadas de peering para o destino são usadas apenas quando o modelo de rota não contém rotas personalizadas locais ou dinâmicas do Network Connectivity Center para o destino.

  6. Selecionar próximos saltos para rotas personalizadas de peering de uma única rede VPC: os próximos saltos para o mesmo destino precisam estar localizados na mesma rede VPC. Esta etapa só se aplica se o modelo de rota contiver rotas estáticas ou dinâmicas de peering importadas de duas ou mais redes VPC diferentes conectadas usando o peering de rede VPC.

    O Google Cloud usa um algoritmo interno para importar rotas personalizadas de peering de uma única rede VPC. A rede peer que o Google Cloud seleciona pode mudar se a rede VPC fizer peering com uma nova rede VPC ou se ela se desconectar de uma rede VPC de app semelhante.

  7. Desconsiderar rotas estáticas e dinâmicas 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: o next-hop-address de uma rota estática precisa corresponder a um endereço IP atribuído a uma VM na rede VPC da rota. O endereço IP precisa ser atribuído à interface de rede da VM como uma das seguintes opções:

      • Um endereço IPv4 interno principal
      • Um endereço IPv6 interno
      • Um endereço IPv6 externo

      Se o endereço IP especificado por next-hop-address corresponder a um tipo diferente de recurso (como um intervalo de IP de alias) ou não corresponder a nenhum recurso, o Google Cloud vai desconsiderar a rota.

    • VM do próximo salto interrompida ou excluída: o Google Cloud ignora cada rota estática em que a instância da VM do próximo salto foi interrompida ou excluída. Esse comportamento se aplica a rotas com próximos saltos especificados usando next-hop-instance ou next-hop-address. Para mais informações, consulte Comportamento quando as instâncias são interrompidas ou excluídas.

    • Especificação de endereço IP do balanceador de carga do próximo salto inválida: para rotas estáticas com um balanceador de carga do próximo salto especificado por endereço IP, o endereço IP precisa corresponder a uma regra de encaminhamento de um balanceador de carga de rede de passagem interna localizado na rede VPC da rota ou em uma rede VPC com peering. Se o endereço IP do próximo salto corresponder à regra de encaminhamento de um tipo diferente de balanceador de carga ou não corresponder a nenhuma regra de encaminhamento, o Google Cloud desconsiderará a rota.

    • Túnel da VPN clássica do próximo salto não estabelecido: o Google Cloud desconsidera todas as rotas estáticas com um túnel da VPN clássica do próximo salto que não tenha uma associação de segurança (SA, na sigla em inglês) da Fase 1 ativa. 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 ser desativada, o Google Cloud desconsidera uma rota dinâmica se o próximo salto do túnel do Cloud VPN, o anexo da VLAN ou a VM do dispositivo roteador não estiverem funcionando. Essa situação geralmente só existe por alguns segundos antes que a rota dinâmica seja removida quando a sessão do BGP do Cloud Router fica inativa.

    O Google Cloud não valida se o SO convidado de uma VM de próximo salto ou uma VM de back-end para um balanceador de carga de próximo salto está processando pacotes. Para mais informações, consulte Considerações comuns sobre os próximos saltos do balanceador de carga de rede de passagem interna e da instância.

  8. Desconsiderar rotas de baixa prioridade: esta etapa modela como o Google Cloud descarta todas as rotas, exceto aquelas com a maior prioridade.

    Após essa etapa, o modelo de rota pode estar vazio ou conter uma ou mais rotas. Se o modelo não estiver vazio, todas as rotas nele terão as seguintes características:

    • Prioridades idênticas
    • Próximos saltos que não foram desconsiderados
    • Destinos idênticos
    • Tipos de rotas que não são com base em políticas ou de sub-rede

  9. Selecionar os próximos saltos para rotas dinâmicas do Network Connectivity Center em uma única rede VPC: os próximos saltos para o mesmo destino precisam estar localizados na mesma rede VPC. Esta etapa só se aplica se o modelo de rota contiver rotas dinâmicas do Network Connectivity Center importadas de dois ou mais raios híbridos localizados em redes VPC diferentes.

    O Google Cloud usa um algoritmo interno para importar rotas dinâmicas do Network Connectivity Center de aros híbridos localizados em uma única rede VPC. Os spokes híbridos selecionados podem mudar se você adicionar ou remover spokes híbridos do hub do Network Connectivity Center. Para evitar essa ambiguidade, verifique se as rotas dinâmicas do Network Connectivity Center têm prioridades exclusivos quando o seguinte se aplica:

    • As rotas têm destinos idênticos.
    • As rotas são importadas de dois ou mais spokes híbridos em diferentes redes VPC.

  10. Selecione apenas a categoria de preferência mais favorável: o Google Cloud não executa multipath de custo igual (ECMP, na sigla em inglês) entre rotas que pertencem a diferentes categorias de preferência, conforme definido nesta etapa.

    Categoria de preferência Tipo de rota e tipo de próximo salto
    Primeira preferência (mais preferida) Uma ou mais rotas estáticas com instâncias do próximo salto (next-hop-instance ou next-hop-address) ou túneis do próximo salto da VPN clássica.
    Segunda preferência Uma ou mais rotas dinâmicas de um único tipo.
    Terceira escolha Uma única rota estática com balanceador de carga de rede de passagem interna do próximo salto.
    Quarta preferência (menos preferida) Uma ou mais rotas estáticas com próximo salto default-internet-gateway:

    Nesta etapa, quando duas ou mais rotas estáticas com o balanceador de carga do próximo salto existem, o Google Cloud seleciona uma única rota estática usando um algoritmo interno. O Google Cloud não executa ECMP entre vários balanceadores de carga. Para mais informações, consulte Considerações sobre os próximos saltos do balanceador de carga de rede de passagem interna.

    Após essa etapa, o modelo de rota pode estar vazio ou conter uma ou mais rotas. Se o modelo não estiver vazio, todas as rotas nele terão estas características:

    • Categoria de preferência idêntica
    • Prioridades idênticas
    • Próximos saltos que não foram desconsiderados
    • Próximos saltos em uma rede VPC
    • Destinos idênticos
    • Tipos de rotas que não são com base em políticas ou de sub-rede

  11. Enviar ou soltar o pacote: dependendo do número de rotas restantes no modelo de rota, o Google Cloud envia ou solta o pacote:

    • Se o modelo de rota contiver uma única rota, o Google Cloud enviará o pacote para o próximo salto, com a seguinte exceção:

      Os balanceadores de carga de rede de passagem interna do próximo salto que não têm o acesso global ativado não podem ser acessados de regiões fora da região do balanceador de carga. Consequentemente, se um balanceador de carga de próximo salto não tiver o acesso global ativado, o Google Cloud vai descartar todos os pacotes enviados de instâncias de VM, anexos de VLAN e túneis do Cloud VPN em regiões diferentes da região do balanceador de carga. Para mudar esse comportamento, ative o acesso global.

    • Se o modelo de rota tiver duas ou mais rotas, o Google Cloud vai executar a ECMP, distribuindo pacotes entre os próximos saltos. A seleção do próximo salto depende de um cálculo de hash e do número 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.

    • Se o modelo de rota estiver vazio, o Google Cloud vai descartar o pacote com uma mensagem ICMP do tipo 3, código 0 (rede inacessível).

A seguir