Trajetos

Google Cloud As rotas definem os caminhos que o tráfego de rede percorre a partir de uma instância de máquina virtual (VM) para outros destinos. Estes destinos podem estar dentro da sua Google Cloud rede da nuvem virtual privada (VPC) (por exemplo, noutra VM) ou fora dela.

Numa rede VPC, uma rota consiste num único prefixo de destino no formato CIDR e num único salto seguinte. Quando uma instância numa rede VPC envia um pacote, 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 vista geral de como funcionam os trajetos no Google Cloud.

Rotas em Google Cloud

Todas as redes VPC usam um mecanismo de encaminhamento virtual distribuído e escalável. Não existe nenhum dispositivo físico atribuído à rede. Algumas rotas podem ser aplicadas seletivamente, mas a tabela de encaminhamento para uma rede de VPC é definida ao nível da rede de VPC.

Cada instância de VM tem um controlador que é mantido informado de todas as rotas aplicáveis da tabela de encaminhamento da rede. Cada pacote que sai de uma VM é entregue ao próximo salto adequado de uma rota aplicável com base numa ordem de encaminhamento. Quando adiciona ou elimina uma rota, o conjunto de alterações é propagado aos controladores de VMs através de um design eventualmente consistente.

Tipos de trajetos

As tabelas seguintes resumem como o Google Cloud categoriza os trajetos nas redes VPC.

Tipo e destino Salto seguinte Notas
Rotas baseadas em políticas: as rotas baseadas em políticas são avaliadas antes de qualquer outro tipo de rota.
Rota baseada em políticas
As rotas baseadas em políticas podem aplicar-se a pacotes com base no endereço IP de origem, no endereço IP de destino, no protocolo ou numa combinação destes.

As rotas baseadas em políticas podem aplicar-se a todas as VMs na rede, a determinadas VMs selecionadas por etiqueta de rede ou ao tráfego que entra na rede VPC através de anexos de VLAN para o Cloud Interconnect (apenas numa região ou em todas as regiões).

As rotas baseadas em políticas nunca são trocadas através do intercâmbio das redes da VPC.
Encaminhamentos de sub-redes: todos os tipos de encaminhamentos de sub-redes são avaliados após os encaminhamentos baseados em políticas, mas antes dos encaminhamentos personalizados.
Encaminhamento de sub-rede local
Criado automaticamente para cada intervalo de endereços IP da sub-rede 		Rede da VPC

Criado, atualizado e removido automaticamente por Google Cloud durante eventos do ciclo de vida da sub-rede.

Os encaminhamentos de sub-rede local aplicam-se a toda a rede VPC.
Rota de sub-rede de intercâmbio
Representa um intervalo de endereços IP de sub-rede numa rede VPC diferente ligada através do intercâmbio da rede da VPC 		Salto seguinte na rede VPC de intercâmbio

O intercâmbio da rede da VPC oferece opções para trocar trajetos de sub-redes.

Criado, atualizado e removido automaticamente por Google Cloud durante eventos do ciclo de vida da sub-rede.

Os encaminhamentos de sub-rede de intercâmbio importados aplicam-se a toda a rede VPC.
Rota de sub-rede do Network Connectivity Center
Representa um intervalo de endereços IP de sub-rede num raio de VPC (uma rede VPC diferente ligada ao hub do Network Connectivity Center) 		Hub do Network Connectivity Center

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

Criado, atualizado e removido automaticamente por Google Cloud durante eventos do ciclo de vida da sub-rede.

Os encaminhamentos de sub-redes do Network Connectivity Center importados aplicam-se a toda a rede VPC.
Rotas personalizadas: as rotas personalizadas são avaliadas após as rotas baseadas em políticas e após as rotas de sub-rede.
Rota estática local
Suporta vários destinos 		Encaminha pacotes para um salto seguinte de rota estática Para ver detalhes sobre cada salto seguinte da rota estática, consulte as considerações para:
Trajeto dinâmico local
Destinos que não entram em conflito com trajetos de sub-rede ou trajetos estáticos		 Par de uma sessão de BGP num Cloud Router Os trajetos são adicionados e removidos automaticamente com base nos trajetos aprendidos dos Cloud Routers na sua rede VPC.

As rotas aplicam-se às VMs de acordo com o modo de encaminhamento dinâmico da rede VPC.
Rota estática de intercâmbio, rota dinâmica de intercâmbio
Rotas estáticas ou dinâmicas numa rede VPC diferente ligadas através do intercâmbio da rede da VPC 		Salto seguinte na rede VPC de intercâmbio

O intercâmbio da rede da VPC oferece opções para trocar rotas estáticas.

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

O intercâmbio da rede da VPC oferece opções para trocar rotas dinâmicas.

As rotas dinâmicas de intercâmbio aplicam-se a uma região ou a todas as regiões da rede VPC de acordo com o modo de encaminhamento dinâmico da rede VPC que exporta as rotas.
Rota dinâmica do Network Connectivity Center
Rotas dinâmicas importadas de raios híbridos do Network Connectivity Center localizados em diferentes redes VPC 		Hub do Network Connectivity Center

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

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

Encaminhamentos de sub-redes

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

Tipos de encaminhamentos de sub-redes

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

  • Encaminhamentos de sub-rede para sub-redes na mesma rede VPC, referidos como encaminhamentos de sub-rede locais.
  • Encaminhamentos de sub-redes do Network Connectivity Center importados de raios da VPC de um hub do Network Connectivity Center.
  • Encaminhamentos de sub-rede de peering importados de redes ligadas através do peering de redes VPC.

Os intervalos de destino para todos os tipos de rotas de sub-rede têm de ser únicos. Para mais informações, consulte:

Encaminhamentos de sub-redes híbridas

Os encaminhamentos de sub-rede local e os encaminhamentos de sub-rede de peering podem ser encaminhamentos de sub-rede híbrida se a sub-rede correspondente estiver configurada como uma sub-rede híbrida.

Ciclo de vida dos encaminhamentos de sub-rede

Todos os intervalos de endereços IP que fazem parte de uma sub-rede (intervalos de endereços IPv4 principais, intervalos de endereços IPv4 secundários e intervalos de endereços IPv6) têm uma rota de sub-rede correspondente. Google Cloud cria e elimina rotas de sub-rede nestes cenários:

  • Faz uma alteração à configuração da sub-rede, por exemplo:

    • Adicione ou elimine uma sub-rede.
    • Expanda um intervalo IPv4 principal.
    • Adicione ou elimine um intervalo IPv4 secundário.
    • Adicione ou elimine um intervalo IPv6.

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

Rotas dinâmicas

Os Cloud Routers indicam à rede VPC que crie, atualize e remova rotas dinâmicas com base nas mensagens do Border Gateway Protocol (BGP) recebidas, nas políticas de rotas BGP aplicáveis (pré-visualização) e nas rotas aprendidas personalizadas do Cloud Router.

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

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

Se um próximo salto de uma rota dinâmica se tornar inacessível, o Cloud Router que gere a respetiva sessão BGP indica à rede VPC para remover a rota dinâmica. Para mais informações, consulte o artigo Alterações ao estado do BGP.

Tipos de rotas dinâmicas

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

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

Rotas predefinidas geradas pelo sistema

Uma rota predefinida tem o destino mais amplo possível: 0.0.0.0/0 para IPv4 e ::/0 para IPv6.O Google Cloud Google Fiber usa uma rota predefinida para entregar um pacote quando o pacote não corresponde a uma rota mais específica na ordem de encaminhamento.

A ausência de um trajeto predefinido não isola necessariamente a sua rede da Internet, porque os caminhos de encaminhamento especiais para equilibradores de carga de rede de passagem externa e encaminhamento de protocolos externos não dependem de um trajeto predefinido.

Quando cria uma rede VPC, Google Cloud adiciona um encaminhamento predefinido IPv4 gerado pelo sistema à rede VPC. O encaminhamento predefinido IPv4 gerado pelo sistema é um encaminhamento estático local que tem um destino 0.0.0.0/0 e um próximo salto do gateway de Internet predefinido. Uma rota estática local com o destino 0.0.0.0/0 e o próximo salto do gateway de Internet predefinido fornece um caminho para endereços IPv4 externos, incluindo endereços IPv4 na Internet. Os seguintes recursos de exemplo usam este caminho:

  • VMs com endereços IPv4 externos atribuídos às respetivas interfaces de rede, quando os pacotes que enviam têm origens que correspondem ao endereço IPv4 interno principal da interface de rede.
  • Um gateway NAT do Google Cloud público configurado para fornecer serviços NAT a sub-redes usadas por interfaces de rede de VMs. Tanto para NAT44 como para NAT64, os gateways Cloud NAT públicos dependem sempre de uma rota estática IPv4 local que usa o próximo salto do gateway de Internet predefinido. Para mais informações sobre o tráfego que pode ser traduzido por gateways NAT da Cloud pública, consulte as especificações gerais.

Quando cria uma sub-rede com um intervalo de endereços IPv6 externos, o Google CloudGoogle Cloud adiciona uma rota predefinida IPv6 gerada pelo sistema à rede VPC se ainda não tiver uma. A rota predefinida IPv6 gerada pelo sistema é uma rota estática local que tem um destino ::/0 e um salto seguinte do gateway de Internet predefinido. Uma rota estática local com o ::/0 destino e o próximo salto do gateway de Internet predefinido fornece um caminho para endereços IPv6 externos, incluindo endereços IPv6 na Internet. Este caminho pode ser usado pelos seguintes elementos:

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

O acesso às APIs Google globais depende por vezes de uma rota IPv4 ou IPv6 predefinida local com o próximo salto do gateway de Internet predefinido:

  • Se aceder a APIs e serviços Google globais enviando pacotes para um ponto final do Private Service Connect para APIs Google globais, a sua rede VPC não requer uma rota predefinida com o próximo salto do gateway de Internet predefinido.O Google Cloud adiciona um caminho de encaminhamento especial ao ponto final.

  • Se aceder às APIs e aos serviços Google globais enviando pacotes para endereços IPv4 ou IPv6 para os domínios predefinidos, os endereços IPv4 ou IPv6 para private.googleapis.com, ou os endereços IPv4 ou IPv6 para restricted.googleapis.com, pode usar rotas IPv4 e IPv6 predefinidas que tenham saltos seguintes do gateway de Internet predefinido, ou pode criar e usar rotas estáticas IPv4 e IPv6 que tenham destinos mais específicos e saltos seguintes do gateway de Internet predefinido:

Interações com trajetos

As secções seguintes descrevem as interações entre as rotas de sub-rede e outros tipos de rotas.

Interações entre encaminhamentos de sub-redes e encaminhamentos estáticos

Google Cloud Aplica as seguintes regras para rotas de sub-rede locais, rotas de sub-rede de peering e rotas de sub-rede do Network Connectivity Center a menos que a sub-rede correspondente tenha sido configurada como uma sub-rede híbrida.

  • Google Cloud não permite criar uma nova rota estática se o destino da nova rota estática corresponder exatamente ou se enquadrar no destino de uma rota de sub-rede local, de peering ou do Network Connectivity Center existente. Por exemplo:

    • Se existir uma rota de sub-rede local, de peering ou do Network Connectivity Center com o destino 10.70.1.0/24, não pode 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 se enquadre em 10.70.1.0/24.

    • Se existir um caminho de sub-rede local ou de peering com o destino 2001:0db8:0a0b:0c0d::/64, não pode criar um novo caminho estático para 2001:0db8:0a0b:0c0d::/64, 2001:0db8:0a0b:0c0d::/96 ou qualquer outro destino que se enquadre em 2001:0db8:0a0b:0c0d::/64.

  • Google Cloud Não lhe permite fazer alterações às sub-redes que resultem num intervalo de endereços IP de sub-rede que corresponda exatamente ou contenha o destino de uma rota estática local ou de peering existente. Por exemplo:

    • Se a sua rede VPC tiver uma rota estática com o destino 10.70.1.128/25, não pode criar uma nova sub-rede 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 de endereços IP que contenha todos os endereços IPv4 em 10.70.1.128/25.

    • Se a sua rede VPC tiver um encaminhamento estático com o destino 2001:db8:a0b:c0d:e0f:f0e::/96,impede a criação de um novo encaminhamento de sub-rede local ou de peering que tenha um intervalo de endereços IPv6 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. Google Cloud

Interações entre encaminhamentos de sub-redes e encaminhamentos dinâmicos

Google Cloud Aplica as seguintes regras exceto se uma sub-rede tiver sido configurada como uma sub-rede híbrida.

  • Google Cloud não cria uma rota dinâmica se um Cloud Router enviar um prefixo que corresponda exatamente ou se enquadre no destino de uma rota de sub-rede local, de peering ou do Network Connectivity Center existente. Por exemplo:

    • Se existir uma rota de sub-rede local, de intercâmbio ou do Network Connectivity Center com o destino 10.70.1.0/24 e se um Cloud Router na rede VPC, numa rede VPC de intercâmbio ou numa rede que contenha um ponto de acesso híbrido do Network Connectivity Center receber 10.70.1.128/25, 10.70.1.0/24 ou qualquer outro prefixo que se enquadre em 10.70.1.0/24, Google Cloud não criar rotas dinâmicas locais, de intercâmbio ou do Network Connectivity Center para os prefixos recebidos em conflito.

    • Se existir uma rota de sub-rede local, de intercâmbio ou do Network Connectivity Center com o destino 2001:0db8:0a0b:0c0d::/64 e se um Cloud Router na rede VPC, numa rede VPC de intercâmbio ou numa rede que contenha um ponto de acesso híbrido do Network Connectivity Center receber 2001:0db8:0a0b:0c0d::/96, 2001:0db8:0a0b:0c0d::/64 ou qualquer outro prefixo que se enquadre em 2001:0db8:0a0b:0c0d::/64, Google Cloud não cria rotas dinâmicas locais, de intercâmbio ou do Network Connectivity Center para os prefixos em conflito recebidos.

  • Google Cloud remove qualquer rota dinâmica existente, se alguma alteração aos sub-redes resultar na criação de uma nova rota de sub-rede local, de peering ou do Network Connectivity Center cujo destino corresponda exatamente ou contenha o destino da rota dinâmica local, de peering ou do Network Connectivity Center existente. Por exemplo:

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

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

Aplicabilidade e ordem

Trajetos aplicáveis

Cada instância, túnel da Cloud VPN e anexo de VLAN tem um conjunto de rotas aplicáveis, ou seja, rotas que se aplicam a esse recurso específico. As rotas aplicáveis são um subconjunto de todas as rotas na rede VPC.

Os seguintes tipos de percursos aplicam-se sempre a todas as instâncias de VMs, anexos de VLAN e túneis de VPN do Google Cloud:

Os seguintes tipos de percursos podem ser configurados para aplicação apenas a determinadas instâncias de VMs, anexos de VLANs ou túneis de Cloud VPN:

  • Os trajetos baseados em políticas podem aplicar-se a:

    • Todas as instâncias de VM, associações VLAN e túneis do Cloud VPN
    • Apenas instâncias de VM identificadas por etiquetas de rede
    • Apenas associações VLAN numa região específica

  • As rotas estáticas podem aplicar-se a:

    • Todas as instâncias de VM, associações VLAN e túneis do Cloud VPN
    • Apenas instâncias de VM identificadas por etiquetas de rede

  • Os trajetos dinâmicos podem aplicar-se a instâncias de VMs, anexos de VLAN e túneis da Cloud VPN na região que contém o próximo salto do trajeto dinâmico ou em todas as regiões, com base no modo de encaminhamento dinâmico da rede VPC.

Caminhos de planeamento de trajetos especiais

As redes VPC têm rotas especiais para determinados serviços. Estes caminhos de encaminhamento especiais não aparecem na tabela de rotas da rede VPC. Não pode remover caminhos de planeamento de trajetos especiais. No entanto, pode permitir ou negar pacotes através de regras de firewall da VPC ou políticas de firewall.

Caminhos para balanceadores de carga de rede de encaminhamento externo e encaminhamento de protocolos externos

Os balanceadores de carga de rede de encaminhamento externo e o encaminhamento de protocolo externo usam sistemas Maglev para encaminhar pacotes de clientes na Internet para VMs de back-end e instâncias de destino na sua rede da VPC. Estes sistemas Maglev encaminham pacotes que têm destinos que correspondem ao destino da regra de encaminhamento externo.

Cada regra de encaminhamento para um balanceador de carga de rede de passagem externo ou para encaminhamento de protocolos externos também fornece um caminho de encaminhamento para as respetivas VMs de back-end ou 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 ser pacotes de resposta de saída (enviados de volta para o cliente) ou podem ser pacotes de saída que iniciam uma nova ligação.
  • As origens dos pacotes têm de corresponder ao endereço IP da regra de encaminhamento. O protocolo de pacotes e a porta de origem não têm de corresponder à especificação de protocolo e porta da regra de encaminhamento.
  • Os caminhos de encaminhamento das regras de encaminhamento não dependem de um caminho predefinido nem da utilização do próximo salto do gateway de Internet predefinido.
  • As VMs de back-end e as instâncias de destino não precisam de ter o encaminhamento de IP ativado.

Caminhos entre as interfaces da Google e os backends

Os balanceadores de carga de aplicações externos e os balanceadores de carga de rede de proxy externos usam front-ends da Google (GFEs). As GFEs de segunda camada abrem ligações TCP às suas VMs de back-end e enviam pacotes das seguintes origens:

  • 35.191.0.0/16 e 130.211.0.0/22 para IPv4
  • 2600:2d00:1:1::/64 para IPv6

Google Cloud usa rotas na rede da Google para entregar pacotes desses intervalos de origem a VMs de back-end na sua rede VPC. Cada rede da VPC inclui caminhos de encaminhamento que permitem que as VMs enviem pacotes de resposta para os intervalos.

Caminhos para verificações de funcionamento

As verificações de funcionamento para todos os balanceadores de carga e para a autorreparação do grupo de instâncias geridas enviam pacotes para as suas VMs de back-end a partir de intervalos de endereços IP de sondagem de verificação de funcionamento.

Google Cloud usa rotas na rede da Google para entregar pacotes de sistemas de sondagem de verificação de estado a VMs na sua rede VPC. Cada rede VPC inclui caminhos de encaminhamento que permitem que as VMs enviem pacotes de resposta aos sistemas de sondagem de verificação de funcionamento.

Caminhos para o Identity-Aware Proxy (IAP)

O encaminhamento TCP com o IAP usa 35.235.240.0/20 para IPv4 e 2600:2d00:1:7::/64 para IPv6 como intervalos apenas internos com saltos seguintes que estão totalmente dentro da rede da Google. A Google não publica rotas para estes intervalos na Internet.

As rotas na rede da Google entregam pacotes de 35.235.240.0/20 ou 2600:2d00:1:7::/64 a VMs na sua rede VPC quando usa o encaminhamento TCP do IAP. Cada rede VPC inclui caminhos de encaminhamento que permitem que as VMs enviem pacotes de resposta para estes intervalos.

Caminhos para o Cloud DNS e o Service Directory

As seguintes funcionalidades do Cloud DNS e do Service Directory usam 35.199.192.0/19 como um intervalo apenas interno com saltos seguintes que estão totalmente na rede da Google. A Google não publica rotas para 35.199.192.0/19 na Internet.

As rotas na rede da Google enviam pacotes de 35.199.192.0/19 para VMs na sua rede VPC quando usa estas funcionalidades do Cloud DNS e do Service Directory. Cada rede da VPC inclui caminhos de encaminhamento que permitem que as VMs enviem pacotes de resposta para 35.199.192.0/19.

Caminhos para o Acesso a VPC sem servidor

O acesso a VPC sem servidor usa 35.199.224.0/19 como um intervalo apenas interno com saltos seguintes que estão totalmente na rede da Google. A Google não publica rotas para 35.199.224.0/19 na Internet.

As rotas na rede da Google enviam pacotes de 35.199.224.0/19 para instâncias do conetor de acesso a VPC sem servidor. Cada rede VPC inclui caminhos de encaminhamento que permitem que as instâncias do conector enviem pacotes de resposta para 35.199.224.0/19.

Caminhos para pontos finais do Private Service Connect para APIs Google globais

Quando cria um ponto final do Private Service Connect para APIs Google globais, Google Cloud adiciona uma rota para o ponto final à sua rede VPC. O destino da rota é o endereço IP interno global do ponto final.

Ordem de encaminhamento

Pode haver mais do que um trajeto aplicável para um determinado pacote. Os passos seguintes modelam o processo que o Google Cloud usa para selecionar um trajeto.

  1. Caminhos de encaminhamento especiais: alguns Google Cloud caminhos de encaminhamento especiais não apresentados nas tabelas de rotas da rede VPC. Para obter detalhes, consulte Caminhos de encaminhamento especiais.

    Se for aplicável um caminho de encaminhamento especial, o seu modelo de seleção de trajetos contém apenas o caminho especial. Todos os outros trajetos são ignorados e a avaliação para neste passo.

  2. Rotas baseadas em políticas: as rotas baseadas em políticas são avaliadas após os caminhos de planeamento de rotas especiais, mas antes de outros tipos de rotas. Se não existirem rotas baseadas em políticas na rede VPC, Google Cloud este passo é ignorado e o processo continua para o passo rotas de sub-rede.

    Google Cloud avalia as rotas baseadas em políticas apenas pela respetiva prioridade. Google Cloud avalia a origem e o destino de um pacote para cada rota baseada em políticas, começando pela rota ou pelas rotas baseadas em políticas de prioridade mais elevada. Se as caraterísticas de um pacote não corresponderem a uma rota baseada em políticas, Google Cloud ignora essa rota baseada em políticas e continua a avaliar a rota baseada em políticas seguinte na lista ordenada. A rota baseada em políticas seguinte a avaliar pode partilhar a mesma prioridade que a rota baseada em políticas ignorada ou ter uma prioridade inferior.

    • Se as caraterísticas de um pacote não corresponderem a nenhuma rota baseada em políticas depois de avaliar todas as rotas baseadas em políticas no seu modelo de seleção de rotas, Google Cloud ignora todas as rotas baseadas em políticas e continua para o passo das rotas de sub-rede.

    • Se as caraterísticas de um pacote corresponderem a uma rota baseada em políticas de prioridade mais elevada, Google Cloud ignora primeiro todas as rotas baseadas em políticas de prioridade mais baixa. Se ficarem duas ou mais rotas baseadas em políticas na lista,o Google Cloud avalia cada uma das rotas baseadas em políticas restantes que tenham prioridades idênticas.O Google Cloud ignora todas as rotas baseadas em políticas restantes se as caraterísticas de um pacote não corresponderem às mesmas. Após este passo, o modelo de seleção de trajetos pode conter um ou mais trajetos baseados em políticas.

    • Se o seu modelo de seleção de rotas incluir duas ou mais rotas baseadas em políticas de prioridade mais elevada, Google Cloud seleciona uma única rota baseada em políticas através de um algoritmo interno. A rota baseada em políticas selecionada pode não ser a correspondência mais específica para a origem ou o destino do pacote. Para evitar esta ambiguidade, recomendamos que crie rotas baseadas em políticas com prioridades únicas.

    • Se o seu modelo de seleção de trajetos incluir apenas um único trajeto baseado em políticas de prioridade mais elevada que esteja configurado para ignorar outros trajetos baseados em políticas, Google Cloud ignora todos os trajetos baseados em políticas e continua para o passo de trajetos de sub-rede.

    • Se o seu modelo de seleção de rotas incluir apenas uma rota baseada em políticas de prioridade mais alta que não esteja configurada para ignorar outras rotas baseadas em políticas, Google Cloud envia o pacote para o próximo encaminhamento interno do equilibrador de carga de rede e ignora todas as rotas não baseadas em políticas.

  3. Encaminhamentos de sub-rede: Google Cloud determina se o destino do pacote se enquadra no intervalo de destino de um encaminhamento de sub-rede local, de intercâmbio ou do Network Connectivity Center na rede VPC.

    • Nenhum caminho de sub-rede correspondente: se o destino de um pacote não corresponder ao intervalo de destino de nenhum caminho de sub-rede, Google Cloud ignora todos os caminhos de sub-rede. Remova todos os trajetos de sub-rede do seu modelo de seleção de trajetos e continue para o passo Destino mais específico para avaliar os trajetos estáticos e dinâmicos.

    • Correspondência com o trajeto de sub-rede normal: para a maioria das sub-redes, se o destino de um pacote corresponder ao intervalo de destino de um trajeto de sub-rede normal, oGoogle Cloud usa exclusivamente o trajeto de sub-rede Google Cloud, ignora todos os outros trajetos e a avaliação é interrompida neste passo. Se o destino do pacote não estiver associado a um recurso ou pertencer a uma instância de VM parada, o pacote é eliminado.

    • Rota de sub-rede híbrida correspondente: se o destino de um pacote corresponder ao intervalo de destino de uma rota de sub-rede híbrida e o destino corresponder a um endereço IP associado a uma instância de VM em execução ou a uma regra de encaminhamento interno, Google Cloudo pacote é encaminhado através da rota de sub-rede híbrida. Google CloudTodas as outras rotas são ignoradas e a avaliação é interrompida neste passo.

      Se o destino não corresponder a uma VM em execução ou a uma regra de encaminhamento interno, consulte o artigo Recursos não correspondentes em sub-redes híbridas.

  4. Destino mais específico: no início deste passo, o Google Cloud ignorou todos os caminhos de encaminhamento especiais, rotas baseadas em políticas e rotas de sub-rede.

    Google Cloud determina que rotas estáticas ou dinâmicas aplicáveis têm o destino mais específico que contém o endereço IP de destino do pacote. Google Cloud ignora todas as rotas, exceto as que têm o destino mais específico. Por exemplo, 10.240.1.0/24 é um destino mais específico do que 10.240.0.0/16.

    No final deste passo, o modelo de seleção de trajetos só contém trajetos estáticos ou dinâmicos com destinos idênticos.

  5. Selecione apenas o tipo de trajeto personalizado mais favorável: neste passo, Google Cloud remove todos os trajetos personalizados, exceto o tipo de trajeto personalizado mais favorável. As rotas personalizadas locais são preferíveis às rotas dinâmicas do Network Connectivity Center e as rotas dinâmicas do Network Connectivity Center são preferíveis às rotas personalizadas de peering.

    A tabela seguinte resume a lógica que o sistema Google Cloud usa neste passo.

    Categoria de trajeto personalizado O que acontece
    Rotas dinâmicas locais e rotas estáticas locais

    Se o seu modelo de trajeto contiver, pelo menos, um trajeto dinâmico local ou um trajeto estático local para o destino, Google Cloud remove os seguintes tipos de trajetos personalizados, se estiverem presentes no modelo de trajeto:

    • Rotas dinâmicas do Network Connectivity Center a partir de raios híbridos em diferentes redes VPC
    • Rotas dinâmicas de intercâmbio (importadas de outras redes VPC ligadas através do intercâmbio das redes da VPC)
    Rotas dinâmicas do Network Connectivity Center Se todas as seguintes condições forem cumpridas, Google Cloud remove todas as rotas dinâmicas e estáticas de peering do modelo de rota:
    • O seu modelo de trajeto não contém trajetos personalizados locais para o destino
    • O modo de trajeto contém, pelo menos, um trajeto dinâmico do Network Connectivity Center para o destino
    • A rota dinâmica do Network Connectivity Center é proveniente de um spoke híbrido numa rede VPC diferente
    Rotas dinâmicas de peering e rotas estáticas 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 rotas dinâmicas do Network Connectivity Center para o destino.

  6. Selecione os saltos seguintes para as rotas personalizadas de peering de uma única rede VPC: Os saltos seguintes para o mesmo destino têm de estar localizados na mesma rede VPC. Este passo só se aplica se o seu modelo de trajeto contiver trajetos dinâmicos de intercâmbio ou trajetos estáticos de intercâmbio que são importados de duas ou mais redes VPC diferentes ligadas através do intercâmbio da rede da VPC.

    Google Cloud usa um algoritmo interno para importar rotas personalizadas de peering de uma rede VPC única. A rede de pares que seleciona pode mudar se a sua rede de VPC estabelecer ligação com uma nova rede de VPC ou se desligar de uma rede de VPC de pares existente.Google Cloud

  7. Ignorar rotas estáticas e dinâmicas com saltos seguintes inutilizáveis: este passo modela situações em que o sistema Google Cloud ignora saltos seguintes inativos ou inválidos.

    • Especificação do endereço IP da VM do próximo salto inválida: o next-hop-address de uma rota estática tem de corresponder a um endereço IP atribuído a uma VM na rede VPC da rota. O endereço IP tem de ser atribuído à interface de rede da VM como um dos seguintes:

      • 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 IPs de alias) ou não corresponder a nenhum recurso,Google Cloud ignora a rota.

    • VM de salto seguinte parada ou eliminada: Google Cloud ignora cada rota estática cuja instância de VM de salto seguinte tenha sido parada ou eliminada. Este comportamento aplica-se a rotas cujos próximos trajetos são especificados através de next-hop-instance ou next-hop-address. Para mais informações, consulte o artigo Comportamento quando as instâncias são paradas ou eliminadas.

    • Especificação do endereço IP do balanceador de carga do próximo salto inválida: para rotas estáticas que tenham um balanceador de carga do próximo salto especificado por endereço IP, o endereço IP tem de corresponder a uma regra de encaminhamento de um Network Load Balancer de passagem interno localizado na rede VPC da rota ou numa 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, Google Cloud ignora a rota.

    • Túnel de VPN clássica de próximo salto não estabelecido: Google Cloud ignora cada rota estática com um túnel de VPN clássica de próximo salto que não tenha uma associação de segurança (SA) da Fase 1 (IKE) ativa. Para mais detalhes, consulte a Ordem das rotas na documentação da VPN clássica.

    • Rota dinâmica com salto seguinte não funcional: mesmo antes de a sessão BGP responsável pela programação de uma rota dinâmica ficar inativa, Google Cloudignora uma rota dinâmica se o respetivo túnel de VPN na nuvem, anexo de VLAN ou VM do dispositivo de router de salto seguinte não estiver a funcionar. Esta situação geralmente só existe durante alguns segundos antes de a rota dinâmica ser removida quando a sessão BGP do Cloud Router correspondente fica inativa.

    Google Cloud não valida se o SO convidado de uma VM de salto seguinte ou uma VM de back-end para um equilibrador de carga de salto seguinte está a processar pacotes. Para mais informações, consulte as Considerações comuns aos saltos seguintes do balanceador de carga de rede de encaminhamento interno e de instâncias.

  8. Ignorar trajetos de baixa prioridade: este passo modela a forma como Google Cloud descarta todos os trajetos, exceto os que têm a prioridade mais elevada.

    Após este passo, o modelo de trajeto pode estar vazio ou conter um ou mais trajetos. Se o seu modelo não estiver vazio, todos os trajetos no modelo têm as seguintes características:

    • Prioridades idênticas
    • Saltos seguintes que não foram ignorados
    • Destinos idênticos
    • Tipos de encaminhamento que não são baseados em políticas nem em encaminhamentos de sub-redes

  9. Selecione os saltos seguintes para as rotas dinâmicas do Network Connectivity Center a partir de uma única rede de VPC: os saltos seguintes para o mesmo destino têm de estar localizados na mesma rede de VPC. Este passo aplica-se apenas se o seu modelo de trajeto contiver trajetos dinâmicos do Centro de conetividade de rede importados de dois ou mais raios híbridos localizados em redes VPC diferentes.

    Google Cloud usa um algoritmo interno para importar rotas dinâmicas do Network Connectivity Center de raios híbridos localizados numa única rede VPC. Os raios híbridos selecionados podem mudar se adicionar ou remover raios híbridos do hub do Network Connectivity Center. Para evitar esta ambiguidade, certifique-se de que as rotas dinâmicas do Network Connectivity Center têm prioridades únicas quando se aplica o seguinte:

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

  10. Selecione apenas a categoria de preferência mais favorável: Google Cloud não executa o caminho múltiplo de custo igual (ECMP) entre rotas que pertencem a diferentes categorias de preferências, conforme definido neste passo.

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

    Neste passo, quando existem duas ou mais rotas estáticas com um equilibrador de carga de próximo salto,o Google Cloud seleciona uma única rota estática através de um algoritmo interno.Google Cloud não executa ECMP entre vários equilibradores de carga. Para mais informações, consulte o artigo Considerações para os próximos saltos do balanceador de carga de rede de encaminhamento interno.

    Após este passo, o modelo de trajeto pode estar vazio ou conter um ou mais trajetos. Se o seu modelo não estiver vazio, todos os trajetos no modelo têm as seguintes características:

    • Categoria de preferências idêntica
    • Prioridades idênticas
    • Saltos seguintes que não foram ignorados
    • Saltos seguintes numa rede VPC
    • Destinos idênticos
    • Tipos de encaminhamento que não são baseados em políticas nem em encaminhamentos de sub-redes

  11. Enviar ou rejeitar pacote: consoante o número de trajetos restantes no modelo de trajeto, Google Cloud envia ou rejeita o pacote:

    • Se o modelo de trajeto contiver um único trajeto, Google Cloud envia o pacote para o próximo salto, com a seguinte exceção:

      Os balanceadores de carga de rede de encaminhamento interno do próximo salto que não tenham o acesso global ativado não são acessíveis a partir de regiões fora da região do balanceador de carga. Consequentemente, se um balanceador de carga do próximo salto não tiver o acesso global ativado, Google Cloud descarta todos os pacotes enviados de instâncias de VM, anexos de VLAN e túneis de VPN na nuvem em regiões diferentes da região do balanceador de carga. Para alterar este comportamento, ative o acesso global.

    • Se o seu modelo de trajeto contiver dois ou mais trajetos, Google Cloud executa o ECMP, distribuindo pacotes entre os próximos saltos. A seleção do salto seguinte depende de um cálculo de hash e do número de saltos seguintes. OGoogle Cloud usa um hash de 5 tuplos se o pacote contiver informações de porta; caso contrário, usa um hash de 3 tuplos. A seleção do próximo salto consistente para um determinado hash não é garantida. OGoogle Cloudpode direcionar pacotes para um próximo salto diferente, mesmo que o hash seja o mesmo e o modelo de rota não seja alterado.

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

Recursos não correspondentes em sub-redes híbridas

Se o seu modelo de trajeto contiver um trajeto de sub-rede> híbrido e o destino do pacote corresponder a um endereço IP associado a uma VM parada ou não estiver associado a nenhum recurso na sub-rede híbrida, o Google CloudGoogle Cloud usa um processo diferente para encaminhar o pacote. Os passos seguintes modelam o processo que o Google Cloud usa para encaminhar estes pacotes:

  1. Identifique a rede VPC que contém a sub-rede híbrida:

    • A sub-rede híbrida e o recurso que envia pacotes para a sub-rede híbrida podem usar a mesma rede de VPC. Neste caso, a sub-rede híbrida cria uma rota de sub-rede local correspondente nessa rede VPC.

    • A sub-rede híbrida e o recurso que envia pacotes para a sub-rede híbrida podem estar em redes VPC diferentes ligadas através do intercâmbio das redes da VPC. Neste caso, a sub-rede híbrida cria uma rota de sub-rede de peering correspondente na rede VPC usada pelo recurso que envia pacotes.

  2. Comece com todas as rotas da rede VPC que contém a sub-rede híbrida e, em seguida, remova as seguintes rotas:

    • Todos os trajetos baseados em políticas
    • Todos os encaminhamentos de sub-rede
    • Todas as rotas estáticas que têm etiquetas de rede
    • Todos os trajetos cujos destinos sejam mais amplos do que o trajeto da sub-rede híbrida que foi correspondido no primeiro modelo de trajeto e o contenham

  3. Realizar o destino mais específico através dos passos de selecionar apenas a categoria de preferências mais favorável na ordem de planeamento de trajeto.

  4. Use as seguintes regras para determinar se Google Cloud envia ou rejeita o pacote:

    • Se o modelo de trajeto contiver um único trajeto e o próximo salto do trajeto estiver na mesma região que a sub-rede híbrida, Google Cloud envia o pacote para o próximo salto.

    • Se o modelo de trajeto contiver dois ou mais trajetos, Google Cloud executa o ECMP entre esses trajetos. Quando um próximo salto está na mesma região que a sub-rede híbrida, Google Cloud envia o pacote para o próximo salto.

    • Google Cloud Elimina o pacote com uma mensagem ICMP do tipo 3, código 0 (rede inacessível) se o modelo de rota estiver vazio ou se um próximo salto estiver numa região diferente da região da sub-rede híbrida.

    As seguintes rotas têm saltos seguintes em regiões diferentes da região da sub-rede híbrida, pelo que resultam sempre em perdas de pacotes:

    • Rotas dinâmicas aprendidas por routers na nuvem em regiões diferentes da região da sub-rede híbrida, mesmo que o modo de encaminhamento dinâmico da rede VPC que contém os routers na nuvem seja global
    • Rotas estáticas com saltos seguintes em regiões diferentes da região da sub-rede híbrida, incluindo todos os equilibradores de carga de rede de passagem internos em regiões diferentes, mesmo que tenham o acesso global ativado

O que se segue?