Informações gerais do Cloud Router

O Cloud Router é um serviço do Google Cloud totalmente distribuído e gerenciado que usa o Border Gateway Protocol (BGP) para divulgar prefixos de IP. Ele programa rotas dinâmicas com base nas divulgações do BGP recebidas de um par. Em vez de um dispositivo ou dispositivo físico, cada Cloud Router é composto de tarefas de software que atuam como alto-falantes e participantes do BGP. Um Cloud Router também serve como plano de controle para o Cloud NAT. O Cloud Router fornece serviços do BGP para os seguintes produtos do Google Cloud:

Cada Cloud Router funciona com pelo menos um dos produtos de conectividade de rede listados anteriormente.

Quando uma rede local ou multicloud é conectada ao Google Cloud, o Cloud Router usa o BGP para trocar rotas dinamicamente entre a rede VPC do Google Cloud e a rede remota. As alterações de prefixo e próximo salto se propagam automaticamente entre sua rede VPC e a outra, sem a necessidade de rotas estáticas.

Também é possível usar o Cloud Router para conectar duas redes VPC no Google Cloud. Nesse cenário, as redes VPC são conectadas usando duas VPNs de alta disponibilidade e dois Cloud Routers, uma VPN de alta disponibilidade e o Cloud Router associado em cada rede.

O peering direto e o peering por operadora não usam o Cloud Router.

Especificações

Um Cloud Router pode anunciar rotas de sub-rede da nuvem privada virtual (VPC) e prefixos personalizados nas sessões do protocolo de gateway de borda (BGP, na sigla em inglês). A menos que você configure o modo de divulgação personalizada, o Cloud Router só divulga rotas de sub-rede VPC. O modo de divulgação personalizado também permite configurar um Cloud Router para omitir rotas de sub-rede VPC de divulgação.

O modo de roteamento dinâmico de uma rede VPC (regional ou global) determina qual sub-rede VPC roteia os Cloud Routers nessa divulgação de rede. Para mais detalhes, consulte Modo de divulgação padrão.

O modo de roteamento dinâmico também controla como cada Cloud Router aplica os prefixos aprendidos como rotas dinâmicas em uma rede VPC. Para mais detalhes sobre esse comportamento, consulte Efeitos do modo de roteamento dinâmico.

Ao configurar o BGP para o Cloud Interconnect, a VPN de alta disponibilidade e o dispositivo roteador, é possível configurar as sessões de peering do roteador para usar a autenticação MD5.

Número de sistema autônomo (ASN)

Ao criar um Cloud Router, escolha o ASN do Google para todas as sessões do BGP usadas pelo Cloud Router. As instruções para cada produto de conectividade de rede listadas na seção Outros recursos fornecem detalhes sobre como cada produto usa o ASN.

Endereços de peering do BGP

As sessões do BGP para os seguintes produtos usam endereços link-local IPv4 no intervalo 169.254.0.0/16 como endereços de peering do BGP:

  • Na Interconexão dedicada, é possível especificar endereços IPv4 de link local candidatos para endereços de peering do BGP, ou o Google Cloud pode selecionar automaticamente endereços IPv4 de link local não usados.
  • Na Interconexão por parceiro, o Google Cloud seleciona automaticamente os endereços IPv4 de link local não usados.
  • Na VPN de alta disponibilidade e VPN clássica que usam roteamento dinâmico, é possível especificar os endereços de peering do BGP ao [criar a interface do BGP no Cloud Router](/network-connectivity/docs/router/how-to/configuring-bgp).

Os dispositivos do roteador usam endereços IPv4 internos das VMs do Google Cloud como endereços IP do BGP. Para detalhes, consulte Como criar instâncias do appliance de roteador.

O Cloud Router também aceita endereços IPv6 para o peering do BGP. Com a configuração de peerings IPv6 do BGP, é possível criar sessões IPv6 do BGP em túneis de VPN de alta disponibilidade e anexos da VLAN de Interconexão dedicada. A compatibilidade com sessões IPv6 do BGP está em Prévia.

Para túneis de VPN de alta disponibilidade, use endereços locais (ULA, na sigla em inglês) exclusivos de IPv6 no intervalo fdff:1::/64 como os endereços de peering do BGP. Os endereços de peering para sessões IPv6 do BGP precisam usar um comprimento de máscara de 126 ou um valor de contagem de bits menor, como /122. Ao configurar uma sessão IPv6 do BGP na VPN de alta disponibilidade, você pode configurar os endereços IPv6 de peering manualmente ou permitir que o Google Cloud os atribua automaticamente para você.

Na Interconexão dedicada, os endereços IPv6 de peering são atribuídos automaticamente a partir do intervalo 2600:2d00:0:1::/64 de endereços unicast globais (GUA, na sigla em inglês) de propriedade do Google. Não é possível especificar um intervalo candidato para esses endereços IPv6 de peering ou configurar esses endereços IPv6 de peering manualmente.

Acesso a balanceadores de carga internos

Para mais detalhes sobre como acessar balanceadores de carga internos de uma rede local conectada, consulte Balanceadores de carga internos e redes conectadas na documentação do Cloud Load Balancing.

Suporte ao IPv6

O Cloud Router oferece suporte à troca de rotas IPv6 em sessões IPv4 do BGP usando o BGP de vários protocolos (MP-BGP). O Cloud Router também aceita a troca de rotas IPv6 usando o peering IPv6 do BGP. No entanto, o suporte à sessão IPv6 do BGP está em Prévia.

O Cloud Router anuncia prefixos IPv6 para redes VPC que incluem sub-redes de pilha dupla. Por padrão, os intervalos de sub-redes IPv6 internos são divulgados automaticamente. Os intervalos de sub-redes IPv6 externas não são anunciados automaticamente, mas é possível divulgá-los manualmente usando rotas divulgadas personalizadas.

É possível criar os seguintes tipos de sessões do BGP.

  • Sessões IPv4 do BGP que trocam apenas rotas IPv4
  • Sessões IPv6 do BGP que trocam apenas rotas IPv6 (Prévia)
  • Sessões IPv4 do BGP que trocam rotas IPv4, mas também rotas IPv6 usando MP-BGP
  • Sessões IPv6 do BGP que trocam rotas IPv6, mas também rotas IPv4 usando MP-BGP (prévia)
  • Sessões IPv4 do BGP e sessões IPv6 executadas em paralelo no mesmo túnel de VPN de alta disponibilidade ou anexo da VLAN de Interconexão dedicada. A sessão IPv4 do BGP troca apenas rotas IPv4, e a sessão IPv6 do BGP troca apenas rotas IPv6

Veja mais detalhes nos seguintes documentos:

Para detalhes sobre divulgações de rota IPv6, consulte Modos de divulgação de rota.

Limitações do IPv6

O peering do BGP IPv6 e a troca de rota IPv6 não são compatíveis com os seguintes recursos:

  • Anexos da VLAN do parceiro de interconexão
  • Túneis de VPN clássica
  • Dispositivo do roteador (parte do Network Connectivity Center)
  • Anexos da VLAN do Cross-Cloud Interconnect

Tarefas de software do Cloud Router

Os Cloud Routers são implementados por uma, duas ou, em casos raros, três tarefas de software.

A tabela a seguir fornece cenários de exemplo e o número de tarefas de software usados pelo Google Cloud para implementar o Cloud Router em cada cenário.

  • Para as configurações de alta disponibilidade listadas na tabela, duas tarefas de software são usadas para fornecer redundância de software.
  • No caso de anexos da VLAN, uma tarefa de software separada processa cada domínio de disponibilidade de borda com anexos.
Exemplo Número de tarefas de software usadas para implementar o Cloud Router
Uma ou mais interfaces, cada uma conectada a um túnel de VPN clássica Um
Uma ou mais interfaces, cada uma conectada a um anexo da VLAN, em que os anexos da VLAN estão no mesmo domínio de disponibilidade de borda. Um
Qualquer número de interfaces, cada uma conectada a um túnel de VPN de alta disponibilidade, em que todos os túneis estão conectados ao mesmo número de interface em um ou mais gateways de VPN de alta disponibilidade. Por exemplo, dois túneis, cada um conectado a interface 0 em gateways de VPN de alta disponibilidade diferentes. Um
Pelo menos duas interfaces, uma conectada a um anexo da VLAN em um único domínio de disponibilidade de borda, e outra conectada a um único túnel de VPN de alta disponibilidade, em que os domínios da disponibilidade de borda e os números da interface do gateway de VPN são iguais. Por exemplo, o primeiro domínio de disponibilidade de borda em um par de domínios de disponibilidade de borda e a primeira interface de gateway de VPN. Um
Pelo menos duas interfaces, cada uma conectada a uma instância de dispositivo de roteador, em que uma das interfaces é configurada como uma interface redundante. Para criar uma interface redundante, use a sinalização redundant-interface (Google Cloud CLI) ou o campo redundantInterface (API Compute Engine). O dispositivo do roteador faz parte do Network Connectivity Center. Dois
Pelo menos duas interfaces, cada uma conectada a um anexo da VLAN, em que os anexos da VLAN estão em domínios de disponibilidade de borda diferentes. Dois
Pelo menos duas interfaces, cada uma conectada a um túnel de VPN de alta disponibilidade, em que cada túnel está conectado a interface 0 diferentes números de interface do gateway da VPN de alta disponibilidade.. Gateway e outro túnel conectado a interface 1 do mesmo gateway ou de um gateway diferente. Dois
Um Cloud Router com pelo menos o seguinte:
  • Uma interface conectada a um anexo da VLAN em edge availability domain 0 e/ou uma interface conectada a um túnel de VPN de alta disponibilidade que está conectada a interface 0 de um gateway de VPN de alta disponibilidade.
  • Uma interface conectada a um anexo da VLAN em edge availability domain 1 e/ou uma interface conectada a um túnel de VPN de alta disponibilidade conectado a interface 1 de um gateway de VPN de alta disponibilidade.
  • Uma interface conectada a um túnel de VPN clássica.
 Três

Manutenção de software e reinicializações automáticas de tarefas

O Google Cloud realiza eventos de manutenção regulares para lançar novos recursos e melhorar a confiabilidade. Durante a manutenção, novas tarefas de software são provisionadas. Os registros do roteador local indicam que as sessões do BGP gerenciadas por essas tarefas de software caíram e voltaram a funcionar (uma falha do BGP).

A manutenção do Cloud Router é um processo automático e foi projetada para que não interrompa o roteamento. Espera-se que os eventos de manutenção levem mais de 60 segundos. Antes da manutenção, o Cloud Router envia uma notificação de reinicialização normal (um pacote TCP FIN) para o roteador local.

Se o roteador local puder processar eventos de reinicialização normal, ele registrará um evento de reinicialização normal durante a manutenção do Cloud Router. Para roteadores locais que não são compatíveis com reinicialização normal, verifique se o temporizador de espera do roteador local está definido como 60 segundos. Para mais detalhes, consulte Gerenciar timers do BGP.

Os eventos de manutenção do Cloud Router não são anunciados com antecedência porque as rotas não são perdidas em roteadores locais configurados corretamente. Para ver detalhes sobre eventos de manutenção concluídos, consulte Como identificar eventos de manutenção do roteador.

Para saber mais sobre como a reinicialização normal funciona com a detecção de encaminhamento bidirecional (BFD, na sigla em inglês), consulte Reinicialização otimizada e BFD.

Modos de divulgação de rota

Ao usar o BGP e um produto listado na seção Recursos adicionais, um Cloud Router anuncia intervalos de endereços para sua rede local. Isso permite que os clientes na sua rede local enviem e recebam pacotes de recursos na rede VPC.

O Cloud Router oferece dois modos de divulgação de rota: o modo de divulgação padrão e o modo de divulgação personalizado.

Modo de publicidade padrão

O uso da divulgação de rota padrão configura uma sessão do Cloud Router ou do BGP para anunciar prefixos nos seguintes tipos de intervalos de endereços IP de sub-rede. O modo de roteamento dinâmico da rede VPC controla se os intervalos de endereços IP da sub-rede anunciada vêm apenas da mesma região do Cloud Router ou de todas as regiões:

Se você anunciar endereços IPv4 públicos de uso particular, os sistemas locais talvez não consigam acessar os recursos da Internet que usam esses endereços IPv4 públicos.

As divulgações de rota de sub-rede são atualizadas automaticamente, conforme descrito em Atualizações automáticas de divulgações de rota de sub-rede.

Modo de publicidade personalizada

O modo de divulgação personalizado oferece controle sobre os prefixos que um Cloud Router divulga. É possível especificar rotas anunciadas personalizadas (incluindo prefixos de rota padrão, 0.0.0.0/0 para rotas IPv4 ou ::/0 para rotas IPv6) para todas as sessões do BGP em um Cloud Router ou por sessão do BGP de dois minutos. Há duas categorias de rotas anunciadas personalizadas:

  • Só é possível anunciar prefixos IPv4 e IPv6 personalizados. Esse tipo de rota anunciada personalizada omite as rotas de sub-rede que seriam anunciadas usando o modo de divulgação padrão.

  • É possível anunciar prefixos IPv4 e IPv6 personalizados, além de rotas de sub-rede. Esse tipo de rota divulgada personalizada inclui as mesmas rotas de sub-rede anunciadas usando o modo de divulgação padrão.

Se você optar por anunciar rotas de sub-rede, as divulgações serão atualizadas automaticamente, conforme descrito em Atualizações automáticas para divulgações de rota de sub-rede.

Se as condições de divulgação do IPv6 forem atendidas, o Cloud Router divulgará os intervalos de sub-rede IPv6 internos sempre que você optar por promover rotas de sub-rede. É necessário adicionar qualquer intervalo de sub-rede IPv6 externo à sua lista de prefixos personalizados para anunciá-los.

Para saber o número máximo de rotas anunciadas personalizadas que podem ser anunciadas em cada sessão do BGP, consulte o número máximo de rotas anunciadas personalizadas por sessão do BGP na página de limites do Cloud Router. Esse limite se aplica a rotas divulgadas personalizadas para todo o Cloud Router e individualmente por sessão do BGP.

Para mais informações, consulte estes documentos:

Prefixos anunciados eficazes

O modo de divulgação de rota é configurável em todo o Cloud Router e em sessões individuais do BGP do Cloud Router. A tabela a seguir descreve quais prefixos são anunciados na sessão do BGP com base no modo de divulgação selecionado do Cloud Router e na sessão do BGP.

Modo do Cloud Router Modo da sessão do BGP Prefixos anunciados eficazes na sessão do BGP
padrão padrão A sessão do BGP herda a configuração do Cloud Router. As rotas de sub-rede são divulgadas conforme descrito em Modo de divulgação padrão.
Personalizada padrão A sessão do BGP herda a configuração do Cloud Router. As rotas personalizadas configuradas em todo o Cloud Router são anunciadas conforme descrito em Modo de divulgação personalizada. Rotas personalizadas podem conter algumas ou todas as rotas de sub-rede.
padrão ou personalizado Personalizada A sessão do BGP não herda a configuração do Cloud Router. As rotas anunciadas personalizadas configuradas na própria sessão do BGP são anunciadas conforme descrito em Modo de divulgação personalizada. Rotas personalizadas podem conter algumas ou todas as rotas de sub-rede.

Atualizações automáticas para divulgações de rota de sub-rede

O Cloud Router atualiza automaticamente as divulgações de rota de sub-rede nas seguintes situações:

Condições para divulgação de rota IPv6

O Cloud Router pode anunciar rotas IPv6 quando todas as condições a seguir forem atendidas:

  • O produto de conectividade de rede usado com o Cloud Router, como o gateway de VPN de alta disponibilidade, está configurado para usar o tipo de pilha dupla IPv4 e IPv6.

  • A sessão IPv4 do BGP é configurada especificamente para ativar a troca de rotas IPv6 ou a sessão IPv6 do BGP (prévia) está configurada e ativada.

    Para mais informações sobre como configurar sessões do BGP, consulte Estabelecer sessões do BGP.

Para anunciar intervalos de sub-rede IPv6 internos, a rede VPC precisa ter um intervalo IPv6 interno atribuído (ULA) e ter criado pelo menos uma instância de sub-rede de pilha dupla com um intervalo de sub-rede de IPv6 interno.

Prefixos e prioridades anunciados

Quando um Cloud Router divulga prefixos para um par do BGP, ele inclui uma prioridade para cada prefixo no anúncio (mensagem do BGP). A prioridade anunciada é implementada como um MED.

É possível controlar quais prefixos o Cloud Router divulga para todas ou algumas das sessões do BGP. Para controlar a prioridade anunciada (MED), defina uma prioridade básica para os prefixos.

  • Se sua rede VPC usar o modo de roteamento dinâmico regional, a menos que você divulgue intervalos personalizados, cada Cloud Router divulgará apenas os intervalos de sub-rede na mesma região do Cloud Router. Cada intervalo é anunciado como um prefixo e o MED é a prioridade básica.

  • Caso sua rede VPC use o modo de roteamento dinâmico global, a menos que você divulgue intervalos personalizados, cada Cloud Router divulgará os intervalos de sub-rede da região local como prefixos cujo MED corresponde à prioridade básica. Além disso, os Cloud Routers divulgam intervalos de sub-rede de regiões diferentes como prefixos cujos MEDs têm a mesma prioridade básica mais o custo regional. O Google Cloud calcula automaticamente um custo regional com base em fatores como desempenho da rede, distância e largura de banda disponível entre as regiões. Cada custo regional tem um valor específico para um par de regiões: a região da sub-rede e a região do Cloud Router anunciado.

Quando os roteadores locais recebem os prefixos anunciados e as prioridades deles, eles criam rotas usadas para enviar pacotes para a rede VPC.

Orientação para prioridades básicas

Ao configurar uma sessão do protocolo de gateway de borda (BGP) em um Cloud Router, é possível especificar uma prioridade de base anunciada para a sessão do BGP. A prioridade anunciada básica se aplica a todos os prefixos (destinos) anunciados por essa sessão do BGP.

As prioridades básicas são números inteiros de 0 a 65535. A maior prioridade básica possível é 0. A prioridade básica padrão é 100. Se você não especificar uma prioridade básica, será usada a prioridade padrão.

As prioridades básicas permitem que você especifique quais túneis do Cloud VPN ou anexos da VLAN são usados para enviar pacotes para sua rede VPC. É possível criar ativo/ativo, ativo/passivo ou uma combinação personalizada dessas topologias usando a prioridade básica. Para um exemplo sobre o uso dos túneis de VPN de alta disponibilidade, consulte Opções de roteamento ativo/ativo e ativo/passivo para VPN de alta disponibilidade na documentação do Cloud VPN.

Ao escolher prioridades básicas, lembre-se do seguinte:

  • Os custos regionais ficam entre 201 e 9999, inclusive. O valor depende da distância, da latência e de outros fatores entre duas regiões. O Google gera os valores de custo regionais, que não podem ser modificados.

  • Recomendamos que as prioridades básicas dos Cloud Routers em uma região estejam entre 0 e 200, inclusive. Como os custos regionais são pelo menos 201, se você usar prioridades básicas de 201 ou mais, poderá atribuir acidentalmente uma prioridade mais baixa do que pretende a um túnel do Cloud VPN ou a um anexo da VLAN. Outra sessão do BGP em uma região diferente pode anunciar o mesmo prefixo com uma prioridade geral mais alta (MED, que equivale à prioridade básica mais o custo regional). Sem configurar cuidadosamente as prioridades básicas em outras regiões, é possível que o tráfego local seja entregue à sua rede VPC por um túnel inesperado do Cloud VPN ou por um anexo da VLAN.

  • Prioridades básicas de 10200 ou mais garantem que a prioridade geral anunciada (MED, prioridade básica mais o custo regional) do prefixo seja sempre menor do que qualquer outro prefixo anunciado com prioridade básica de 200 ou menos.

Para mais informações sobre como definir uma prioridade básica, consulte Como atualizar a prioridade de rota anunciada básica.

Exemplos

Nesta seção, você verá exemplos que mostram como os custos regionais influenciam os MEDs anunciados quando você usa o roteamento dinâmico global.

VPNs de alta disponibilidade com túneis ativos/ativos

Neste exemplo, você tem uma rede VPC com o seguinte:

  • Uma sub-rede em cada uma das seguintes regiões: us-central1, europe-west1 e us-west-1
  • Um Cloud Router que gerencia duas sessões do BGP para dois túneis de VPN de alta disponibilidade em us-central1
  • Um Cloud Router que gerencia duas sessões do BGP para dois túneis de VPN de alta disponibilidade em us-west1

Para ver uma ilustração deste exemplo, consulte o diagrama a seguir, que inclui valores de exemplo para o custo de região para região.

VPNs de alta disponibilidade com túneis ativos/ativos
VPNs de alta disponibilidade com túneis ativos/ativos (clique para ampliar)

Suponha que cada sessão do BGP tenha a prioridade básica padrão de 100.

As tabelas a seguir mostram como a prioridade básica e o custo regional são usados para calcular os valores do MED anunciados para o tráfego da rede local para cada sub-rede.

10.0.1.0/24 (us-central1)

Esta tabela mostra as sessões do BGP que anunciam o intervalo de endereços IP da sub-rede 10.0.1.0/24, localizado em us-central1.

O tráfego da sua rede local usa um tunel da VPN de alta disponibilidade em us-central1 porque as sessões do BGP têm o MED anunciado mais baixo.

Túnel VPN Prioridade básica Custo regional MED anunciado Classificação do caminho
central-tunnel-0,
central-tunnel-1		 100 0 100 1ª opção
west-tunnel-0,
west-tunnel-1		 100 250 350 2ª opção

10.0.2.0/24 (europe-west1)

Esta tabela mostra as sessões do BGP que anunciam o intervalo de endereços IP da sub-rede 10.0.2.0/24, localizado em europe-west1.

O tráfego da sua rede local usa um tunel da VPN de alta disponibilidade em us-central1 porque as sessões do BGP têm o MED anunciado mais baixo.

Túnel VPN Prioridade básica Custo regional MED anunciado Classificação do caminho
central-tunnel-0,
central-tunnel-1		 100 300 400 1ª opção
west-tunnel-0,
west-tunnel-1		 100 350 450 2ª opção

10.0.3.0/24 (us-west1)

Esta tabela mostra as sessões do BGP que anunciam o intervalo de endereços IP da sub-rede 10.0.3.0/24, localizado em us-west1.

O tráfego da sua rede local usa um tunel da VPN de alta disponibilidade em us-west1 porque as sessões do BGP têm o MED anunciado mais baixo.

Túnel VPN Prioridade básica Custo regional MED anunciado Classificação do caminho
central-tunnel-0,
central-tunnel-1		 100 250 350 2ª opção
west-tunnel-0,
west-tunnel-1		 100 0 100 1ª opção

VPNs de alta disponibilidade com túneis ativos/passivos

Este exemplo usa a mesma topologia do exemplo anterior, mas com prioridades básicas modificadas para atingir um par de túnel de VPN de alta disponibilidade ativo/passivo em cada região:

  • Um túnel principal cuja sessão do BGP tem a prioridade básica padrão de 100
  • Um túnel secundário cuja sessão do BGP tem uma prioridade mais baixa de 351

As tabelas a seguir mostram como a prioridade básica e o custo regional são usados para calcular os valores do MED anunciados para o tráfego da rede local para cada sub-rede.

10.0.1.0/24 (us-central1)

Esta tabela mostra as sessões do BGP que anunciam o intervalo de endereços IP da sub-rede 10.0.1.0/24, localizado em us-central1.

O tráfego da sua rede local usa o túnel de VPN principal em us-central1 porque a sessão do BGP tem o MED anunciado mais baixo. Se esse túnel não estiver disponível, o tráfego usará o túnel principal em us-west1.

Túnel VPN Prioridade básica Custo regional MED anunciado Classificação do caminho
central-tunnel-0 100 0 100 1ª opção
central-tunnel-1 351 0 351 3ª opção
west-tunnel-0 100 250 350 2ª opção
west-tunnel-1 351 250 601 4ª opção

10.0.2.0/24 (europe-west1)

Esta tabela mostra as sessões do BGP que anunciam o intervalo de endereços IP da sub-rede 10.0.2.0/24, localizado em europe-west1.

O tráfego da sua rede local usa o túnel de VPN principal em us-central1 porque a sessão do BGP tem o MED anunciado mais baixo. Se esse túnel não estiver disponível, o tráfego usará o túnel principal em us-west1.

Túnel VPN Prioridade básica Custo regional MED anunciado Classificação do caminho
central-tunnel-0 100 300 400 1ª opção
central-tunnel-1 351 300 651 3ª opção
west-tunnel-0 100 350 450 2ª opção
west-tunnel-1 351 350 701 4ª opção

10.0.3.0/24 (us-west1)

Esta tabela mostra as sessões do BGP que anunciam o intervalo de endereços IP da sub-rede 10.0.3.0/24, localizado em us-west1.

O tráfego da sua rede local usa o túnel de VPN principal em us-west1 porque a sessão do BGP tem o MED anunciado mais baixo. Se esse túnel não estiver disponível, o tráfego usará o túnel principal em us-central1.

Túnel VPN Prioridade básica Custo regional MED anunciado Classificação do caminho
central-tunnel-0 100 250 350 2ª opção
central-tunnel-1 351 250 601 4ª opção
west-tunnel-0 100 0 100 1ª opção
west-tunnel-1 351 0 351 3ª opção

Interconexão dedicada globalmente preferencial

Este exemplo é semelhante aos exemplos anteriores, mas você substituiu os dois túneis do Cloud VPN na região us-west1 por dois anexos da VLAN.

Para uma ilustração deste exemplo, consulte o diagrama a seguir.

Interconexão dedicada globalmente preferencial.
Interconexão dedicada globalmente preferencial (clique para ampliar)

Você quer priorizar os anexos da VLAN. Você especifica prioridades de base maiores para os túneis de VPN de alta disponibilidade na região us-central1 para diminuir a prioridade.

As tabelas a seguir mostram como a prioridade básica e o custo regional são usados para calcular os valores do MED anunciados para o tráfego da rede local para cada sub-rede.

10.0.1.0/24 (us-central1)

Esta tabela mostra as sessões do BGP que anunciam o intervalo de endereços IP da sub-rede 10.0.1.0/24, localizado em us-central1.

O tráfego da sua rede local usa o anexo da VPN em us-west1 porque as sessões do BGP têm o MED anunciado mais baixo.

Túnel de VPN ou anexo da VLAN Prioridade básica Custo regional MED anunciado Classificação do caminho
central-tunnel-0,
central-tunnel-1		 351 0 351 2ª opção
west-attachment-0,
west-attachment-1		 100 250 350 1ª opção

10.0.2.0/24 (europe-west1)

Esta tabela mostra as sessões do BGP que anunciam o intervalo de endereços IP da sub-rede 10.0.2.0/24, localizado em europe-west1.

O tráfego da sua rede local usa o anexo da VPN em us-west1 porque as sessões do BGP têm o MED anunciado mais baixo.

Túnel de VPN ou anexo da VLAN Prioridade básica Custo regional MED anunciado Classificação do caminho
central-tunnel-0,
central-tunnel-1		 351 300 651 2ª opção
west-attachment-0,
west-attachment-1		 100 350 450 1ª opção

10.0.3.0/24 (us-west1)

Esta tabela mostra as sessões do BGP que anunciam o intervalo de endereços IP da sub-rede 10.0.3.0/24, localizado em us-west1.

O tráfego da sua rede local usa o anexo da VPN em us-west1 porque as sessões do BGP têm o MED anunciado mais baixo.

Túnel de VPN ou anexo da VLAN Prioridade básica Custo regional MED anunciado Classificação do caminho
central-tunnel-0,
central-tunnel-1		 351 250 601 2ª opção
west-attachment-0,
west-attachment-1		 100 0 100 1ª opção

Rotas aprendidas

Rotas aprendidas são rotas que o Cloud Router usa para alcançar outra rede. A outra rede pode ser sua rede local, uma rede em outro provedor de serviços em nuvem ou outra rede VPC. As rotas aprendidas são chamadas de rotas recebidas.

No Google Cloud, há dois tipos de rotas aprendidas:

  • Rotas aprendidas de roteadores externos pelo BGP

  • Rotas configuradas manualmente para uma sessão individual do BGP (rotas aprendidas personalizadas)

Usando os dois tipos de rotas aprendidas, o Cloud Router cria rotas dinâmicas na sua rede VPC. Cada rota dinâmica criada pelo Cloud Router é derivada de uma ou mais dessas rotas aprendidas.

Se o Cloud Router tiver várias rotas aprendidas para o mesmo prefixo de destino, ele usará métricas de rota e, em alguns casos, o tamanho do caminho AS para criar rotas dinâmicas. As seções a seguir descrevem mais informações sobre esse processo e sobre as rotas aprendidas em geral.

Rotas aprendidas personalizadas

Conforme descrito na seção anterior, é possível configurar uma sessão do BGP para ter rotas aprendidas personalizadas. Quando você configura rotas aprendidas personalizadas, o Cloud Router se comporta como se tivesse aprendido essas rotas com um par do BGP.

Rotas aprendidas personalizadas podem ser úteis se você quiser evitar as limitações das rotas estáticas. Por exemplo, rotas estáticas não podem detectar uma perda de acessibilidade no próximo salto de uma rota. Por outro lado, rotas aprendidas personalizadas podem detectar uma perda de acessibilidade e reagem de acordo com elas para evitar a queda do tráfego sem notificação.

Para mais informações, consulte Rotas aprendidas personalizadas.

Efeitos do modo de roteamento dinâmico

O modo de roteamento dinâmico de uma rede VPC determina como as rotas aprendidas são aplicadas:

  • No modo de roteamento dinâmico regional, o Cloud Router cria uma rota dinâmica para o destino e para o próximo salto na mesma região que o Cloud Router. O Cloud Router define a prioridade para essa rota dinâmica como prioridade básica, que o Cloud Router recebe do MED divulgado pelo roteador local.

  • No modo de roteamento dinâmico global, o Cloud Router cria uma rota dinâmica para o destino e para o próximo salto em cada região do Google Cloud. Na região que contém o Cloud Router que aprendeu essa rota, o Cloud Router define a prioridade da rota dinâmica como prioridade básica. Em todas as outras regiões, o Cloud Router define a prioridade como básica mais um custo regional apropriado.

É possível definir a prioridade das rotas para o Google Cloud exportadas para o roteador local. No entanto, seu roteador local pode substituir essa prioridade de rota, dependendo da configuração.

Em rotas até o local aprendidas pelo Cloud Router, ele calcula uma prioridade básica a partir do tamanho do caminho AS e dos valores MED, conforme descrito nas próximas duas seções.

Prefixo de caminho AS e tamanho do caminho AS

O prefixo de caminho AS é um meio pelo qual se retira a prioridade do próximo salto para um destino (prefixo) intencionalmente. Assim, será selecionado um próximo salto diferente para o mesmo destino, com um tamanho do caminho AS mais curto. A MED é considerada apenas quando os tamanhos do caminho AS dos próximos saltos são iguais.

O Google Cloud pode usar o caminho AS para selecionar um próximo salto entre as sessões do BGP implementadas pela mesma tarefa de software do Cloud Router.

Como o Google Cloud usa o caminho AS

O prefixo de caminho AS é irrelevante para o plano de controle e a rede VPC. O tamanho do caminho AS é considerado apenas em cada tarefa de software do Cloud Router, conforme descrito nos cenários a seguir.

Se uma única tarefa do software do Cloud Router aprender o mesmo destino em duas ou mais sessões do BGP:

  • A tarefa de software escolhe uma sessão do BGP do próximo salto com o tamanho do caminho AS mais curto.
  • A tarefa de software envia informações de destino, próximo salto e MED para o plano de controle do Cloud Router.
  • O plano de controle usa as informações para criar uma ou mais rotas candidatas. A prioridade básica de cada candidato é definida como MED recebida.

Se duas ou mais tarefas de software do Cloud Router aprenderem o mesmo destino em duas ou mais sessões do BGP:

  • cada tarefa de software escolhe uma sessão do BGP de próximo salto com o tamanho do caminho AS mais curto;
  • cada tarefa de software envia informações de destino, próximo salto e MED para o plano de controle do Cloud Router;
  • o plano de controle usa as informações para criar dois ou mais trajetos possíveis. A prioridade básica de cada candidato é definida como MED recebida.

Em seguida, o plano de controle do Cloud Router instala uma ou mais rotas dinâmicas na rede VPC, de acordo com o modo de roteamento dinâmico da rede VPC. No modo de roteamento dinâmico global, a prioridade de cada rota dinâmica regional é ajustada em regiões diferentes da região do Cloud Router. Para detalhes sobre como o Google Cloud seleciona uma rota, consulte Ordem de roteamento na documentação da VPC.

Prioridade básica, MED e origem

O Cloud Router usa o valor MED divulgado pelo roteador de peering para calcular uma prioridade básica:

  • Se o valor MED de um prefixo de destino estiver entre 0 e 231 -1 (inclusive), o Cloud Router definirá a prioridade básica para o valor MED.
  • Se o valor MED de um prefixo de destino estiver entre 231 e 232 -1 (inclusive), o Cloud Router definirá a prioridade básica como 231 -1.

Para que o MED entre em vigor durante a melhor seleção de caminho entre várias rotas aprendidas para o mesmo destino, o valor do atributo de origem do BGP para as rotas recebidas precisa ser o mesmo. Caso contrário, a seleção acontecerá com base no valor do atributo de origem, que precede a etapa de comparação do MED no processo de seleção de melhor caminho (RFC 4271).

O Cloud Router divulga rotas do BGP para seus pares com o valor do atributo de origem definido como Incomplete. Esse valor é o tipo de origem menos preferido na seleção de rota.

O valor final da prioridade que o Cloud Router define ao criar rotas dinâmicas em uma rede VPC depende do modo de roteamento dinâmico da rede. Para mais informações, consulte Efeitos do modo de roteamento dinâmico.

Rotas estáticas

Quando uma instância envia um pacote, o Google Cloud tenta selecionar uma rota do conjunto de rotas aplicáveis de acordo com a ordem de roteamento. Para detalhes, consulte a seção Ordem de roteamento na documentação da VPC.

Intervalos de endereços IPv4 ou IPv6 sobrepostos

Nos casos em que você tem uma sub-rede VPC e uma divulgação de rota local com intervalos de IP sobrepostos, o Google Cloud direciona o tráfego de saída dependendo de seus intervalos de IP.

Para mais informações, consulte Rotas aplicáveis na documentação da VPC.

Transferência de dados site a site

Se você precisar transferir dados entre dois sites externos ao Google Cloud, use o Network Connectivity Center. O Network Connectivity Center funciona com o Cloud Router para permitir que você divulgue rotas de forma dinâmica entre sessões do BGP.

O Cloud Router por si só não oferece suporte a essa funcionalidade (de forma dinâmica ou ao configurar divulgações de rotas personalizadas que correspondem aos prefixos aprendidos). Se você adicionar uma rota anunciada personalizada a uma sessão do BGP e ela se sobrepor a uma rota aprendida de outra sessão do BGP, a rota aprendida poderá ser descartada.

Limites das rotas aprendidas

Há vários limites que afetam as rotas aprendidas. Para mais informações, consulte Limites.

As rotas IPv4 e IPv6 são contabilizadas no mesmo limite máximo e não têm limites separados.

Para monitorar o uso em relação aos limites, use as seguintes métricas:

  • router.googleapis.com/dynamic_routes/learned_routes/used_unique_destinations
  • router.googleapis.com/dynamic_routes/learned_routes/unique_destinations_limit
  • router.googleapis.com/dynamic_routes/learned_routes/any_dropped_unique_destinations

Para informações sobre mensagens de registro relacionadas a esses limites, as métricas que podem ser usadas para monitorá-las e resolver problemas, consulte Verificar cotas e limites na página "Solução de problemas".

Rota padrão

Quando nenhuma rota é especificada para um destino IPv4 ou IPv6 específico, o tráfego é enviado para uma rota padrão, que é o último recurso quando não há outras opções. Por exemplo, as redes do Google Cloud VPC incluem automaticamente uma rota padrão que envia tráfego para o gateway da Internet. A rota padrão para IPv4 é 0.0.0.0/0 e para IPv6 é ::/0.

Em alguns casos, você pode querer que o tráfego seja direcionado para sua rede local por padrão. Para isso, é possível divulgar uma rota padrão do seu roteador local para o Cloud Router. Com o Cloud Router, não é preciso criar e gerenciar rotas estáticas. Se você anunciar uma rota padrão da sua rede local, verifique se ela tem prioridade sobre outras rotas padrão criadas automaticamente (ou seja, se ela tem um valor de MED mais baixo). Acesse a página Rotas. Em seguida, veja a Prioridade para rotas com 0.0.0.0/0 no Intervalo de IP de destino e veja Default internet gateway em Próximo salto.

Túneis Cloud VPN redundantes

Se o gateway local não for compatível com reinicialização normal, uma falha em ambos os lados da sessão do BGP causará falha na sessão e o tráfego será interrompido. As rotas são removidas dos dois lados quando o tempo limite do BGP é excedido. No caso do Cloud Router, esse limite é de 60 segundos.

Sem a compatibilidade com reinicialização normal, a implantação de dois gateways locais, com um túnel cada, criará redundância e failover. Essa configuração permite desconectar um túnel e os dispositivos ligados a ele para realizar atualizações ou manutenção de software sem interromper o tráfego. Além disso, se um túnel falhar, o outro túnel poderá manter as rotas ativas e o fluxo de tráfego.

Eventos de manutenção

O Cloud Router é submetido a manutenção periódica, que leva menos de 60 segundos. O Cloud Router fica indisponível durante eventos de manutenção. O temporizador de espera do BGP determina o tempo durante o qual as rotas coletadas são preservadas quando o roteador BGP de mesmo nível não está disponível. Esse temporizador assume o menor valor nos dois lados. O Cloud Router usa um valor de 60 segundos (por padrão) para o temporizador de espera do BGP. Recomendamos que você defina o temporizador de espera do BGP no roteador local (par) como 60 segundos ou mais. Como resultado, ambos os roteadores preservam as rotas durante esses upgrades, e o tráfego continua fluindo.

Durante os ciclos de manutenção de gateway do Cloud VPN com um único gateway do Cloud VPN, o uso do Cloud Router aumenta em cerca de 20 segundos, porque a sessão do BGP é redefinida e as rotas precisam ser reaprendidas. Os tempos de recuperação do gateway do Cloud VPN geralmente duram cerca de um minuto. Se houver gateways redundantes do Cloud VPN, o tráfego não será afetado, porque apenas um gateway do Cloud VPN será removido de cada vez.

Identificador do BGP (ID do roteador)

Cada Cloud Router tem um identificador do BGP, também conhecido como ID do roteador. O identificador do BGP é exclusivo para cada Cloud Router na sua nuvem privada virtual, conforme exigido pela RFC 6286.

Geralmente, o identificador do BGP é atribuído automaticamente, mas é possível configurar seu Cloud Router com um intervalo de identificador do BGP explícito. Caso você escolha atribuir seu próprio intervalo de identificadores do BGP, o Cloud Router receberá um identificador do BGP estável dentro do intervalo selecionado. Um Cloud Router que não estiver configurado com um intervalo de identificadores do BGP recebe um identificador do BGP com base no endereço de interface IPv4 mais alto.

O suporte para sessões IPv6 do BGP e intervalos de identificadores do BGP está em Prévia.

Quando você adiciona a primeira interface IPv6 a um Cloud Router que não está configurado com um intervalo de identificadores do BGP, um intervalo de identificador do BGP é atribuído automaticamente.

Para mais informações, consulte Configurar o intervalo do identificador do BGP para um Cloud Router.

Reinicializações de sessão do BGP

O identificador do BGP de um Cloud Router ativo pode mudar devido a qualquer um dos seguintes motivos:

  • Você atualiza ou remove manualmente o intervalo do identificador do BGP configurado.
  • Você remove uma interface IPv4 do Cloud Router e ele não tem um intervalo de identificador do BGP atribuído.

Quando um identificador do BGP do Cloud Router ativo é alterado, cada sessão do BGP no Cloud Router é reiniciada.

O intervalo do identificador de um Cloud Router também pode mudar quando o roteador é reiniciado para manutenção periódica e não tem um intervalo de identificador do BGP atribuído.

Outros recursos

Para mais informações sobre o uso de roteamento dinâmico e estático com um serviço compatível, consulte a documentação a seguir.

Produto Roteamento Documentação
Interconexão dedicada Requer roteamento dinâmico com o Cloud Router Como criar anexos da VLAN
Interconexão por parceiro Requer roteamento dinâmico com o Cloud Router Como criar anexos da VLAN
Dispositivos de roteador Requer roteamento dinâmico com o Cloud Router Como criar instâncias do tipo de roteador
VPN de alta disponibilidade Requer roteamento dinâmico com o Cloud Router Como criar um gateway de VPN de alta disponibilidade para um gateway de VPN de mesmo nível
Como criar uma VPN de alta disponibilidade entre redes do Google Cloud
VPN clássica O roteamento dinâmico usando o Cloud Router é opcional Como criar uma VPN clássica usando o roteamento dinâmico
Como criar uma VPN clássica usando o roteamento estático

A seguir