Visão geral do Cloud Router

O Cloud Router é um serviço do Google Cloud totalmente distribuído e gerenciado que programa rotas dinâmicas personalizadas e escalona com o tráfego de rede. O Cloud Router funciona com redes legadas e redes de nuvem privada local (VPC).

O Cloud Router não é uma opção de conectividade, mas um serviço que funciona em conexões do Cloud VPN ou do Cloud Interconnect para fornecer roteamento dinâmico usando o protocolo de gateway de borda (BGP) para suas redes VPC. O Cloud Router não é compatível com conexões de peering direto ou peering por operadora.

O Cloud Router não é um dispositivo físico que pode causar um gargalo e não pode ser usado sozinho. No entanto, ele é obrigatório ou recomendado nos seguintes casos:

  • Necessário para Cloud NAT
  • Necessário para Cloud Interconnect e VPN de alta disponibilidade
  • Uma opção de configuração recomendada para a VPN clássica

Ao estender sua rede local para o Google Cloud, use o Cloud Router para trocar rotas dinamicamente entre suas redes do Google Cloud e sua rede local. O Cloud Router faz o peering com o gateway da sua VPN local ou com seu roteador. Os roteadores trocam informações de topologia por meio do BGP.

As alterações de topologia são propagadas automaticamente entre sua rede VPC e sua rede local. Ao usar o Cloud Router, não é necessário configurar rotas estáticas.

Tarefas de software do Cloud Router

Os Cloud Routers são implementados por uma ou duas tarefas de software, dependendo dos pontos em que as interfaces se conectam:

  • Se um Cloud Router tiver pelo menos duas interfaces, cada uma conectada a um túnel do Cloud VPN no mesmo par de túneis VPN de alta disponibilidade (conectado ao mesmo gateway de VPN de alta disponibilidade), o Google Cloud usará duas tarefas de software para implementar o Cloud Router para fornecer redundância de software.
  • Em todas as outras situações, o Google Cloud implementa o Cloud Router usando uma única tarefa de software.

Roteamento estático versus dinâmico

Com rotas estáticas, você precisa criar ou manter uma tabela de roteamento. Uma alteração de topologia em qualquer uma das redes exige que você atualize rotas estáticas manualmente. Além disso, rotas estáticas não podem redirecionar o tráfego automaticamente caso ocorra uma falha de link.

O roteamento estático é adequado para redes pequenas com topologias estáveis. Com ele, você também tem um controle rigoroso sobre as tabelas de roteamento. Os roteadores não enviam divulgação entre redes.

Com o Cloud Router, você pode usar o BGP para trocar informações de roteamento entre as redes. Em vez de configurar manualmente rotas estáticas, as redes detectam alterações de topologia de forma automática e rápida por meio do BGP. As alterações são implementadas sem interromper o tráfego. Esse método de troca de rotas por meio do BGP é chamado de roteamento dinâmico.

O roteamento dinâmico é adequado para redes de qualquer tamanho. Ele não exige que você gerencie rotas estáticas. Além disso, se um link falhar, o roteamento dinâmico poderá redirecionar automaticamente o tráfego, se possível. Para ativar o roteamento dinâmico, crie um Cloud Router. Em seguida, configure uma sessão do BGP entre o Cloud Router e seu gateway ou roteador local.

Roteamento estático para túneis do Cloud VPN

Sem o Cloud Router, é possível configurar o Cloud VPN usando somente rotas estáticas. As desvantagens de usar rotas estáticas são as seguintes:

  • Uma alteração na configuração de rede em qualquer lado de um túnel do Cloud VPN exige a criação e exclusão manual das rotas estáticas correspondentes a essas alterações. Além disso, as alterações na rota estática têm convergência lenta.
  • Ao criar um túnel do Cloud VPN para funcionar com rotas estáticas, você precisa especificar a lista de prefixos IP em cada lado do túnel antes de criar o túnel. Isso significa que, sempre que as rotas precisarem ser alteradas, você precisará excluir e recriar o túnel do Cloud VPN e configurar novas rotas, o que interrompe o tráfego atual
  • Não há nenhum método padrão para configurar rotas estáticas. Os comandos usados variam de acordo com o fornecedor.

No exemplo a seguir, sua rede combinada consiste em sua rede do Google Cloud e 29 sub-redes (uma por rack) na rede local no outro lado do túnel do Cloud VPN. Para este exemplo, suponha que sua empresa esteja crescendo de forma que você precise adicionar uma nova sub-rede de máquinas toda semana. Nesta semana, você está adicionando a sub-rede 10.0.30.0/24, conforme mostrado no diagrama a seguir:

Cloud Router para Cloud VPNs com rede VPC (clique para ampliar)
Cloud VPN sem Cloud Router (clique para ampliar)

Nesse cenário, o Cloud VPN baseado em rota estática requer as seguintes alterações:

  1. É necessário adicionar rotas estáticas ao Google Cloud para alcançar a nova sub-rede local.
  2. Você precisa separar e recriar o túnel do Cloud VPN para incluir a nova sub-rede local.

É possível evitar alterações de configuração em túneis estáticos e de Cloud VPNs com a implementação de um Cloud Router. É feito peering do Cloud Router com seu gateway do Cloud VPN por meio do uso do BGP para trocar informações de topologia. Na verdade, ao usar o BGP, as alterações na topologia de rede na rede do Google Cloud são propagadas automaticamente para sua rede e vice-versa. Assim, você não precisa configurar rotas estáticas para os túneis do Cloud VPN.

Requisitos de roteamento dinâmico para o Cloud Interconnect e o Cloud VPN

É necessário ter um Cloud Router atual antes que seja possível fazer o seguinte:

Ao criar um Cloud Router, é possível escolher o ASN do lado do Google. Se um ASN não for especificado, o Google Cloud escolherá um para você. No entanto, você deve especificar manualmente o ASN do seu roteador local (de peering) nas configurações do Cloud Router.

É possível especificar endereços do BGP das seguintes maneiras:

  • Para Interconexão dedicada, é possível especificar intervalos de endereços ou deixar que o Google Cloud os selecione. Para mais informações, consulte Como criar Anexos da VLAN do Cloud Interconnect.
  • Para a Interconexão por parceiro, você nunca especifica o endereço do BGP.
  • Para VPN de alta disponibilidade e VPN clássica que usam o roteamento dinâmico, é possível especificar os endereços IP do BGP quando você cria a interface do BGP no Cloud Router.

Roteamento dinâmico para túneis do Cloud VPN em redes VPC

Use redes VPC para segmentar regionalmente o espaço de IP da rede em prefixos (sub-redes) e controlar a alocação do prefixo do endereço IP interno da instância de uma máquina virtual (VM). Para evitar o gerenciamento estático dessas sub-redes, incluindo a obrigação de adicionar e remover rotas estáticas relacionadas ao Cloud VPN, use o Cloud Router para ativar o roteamento dinâmico no seu túnel do Cloud VPN.

Um Cloud Router pertence a uma rede VPC e região específicas. O Cloud Router usa o BGP para divulgar as sub-redes na rede VPC para o gateway local. Ele divulga as sub-redes em sua região local ou todas as sub-redes na rede com base no modo de roteamento dinâmico da rede VPC. O Cloud Router também aprende as rotas locais por meio do BGP e permite que a infraestrutura de rede selecione a melhor rota para alcançar os prefixos associados.

O exemplo a seguir mostra o Cloud Router com redes VPC de modo personalizado. Se você usar redes VPC no modo automático, o Cloud Router divulgará automaticamente o prefixo/20 da região. Para mais informações sobre os modos automático e personalizado, consulte a visão geral da rede VPC.

O diagrama a seguir mostra duas sub-redes regionais diferentes em uma rede VPC e 30 sub-redes na rede local. As duas redes estão conectadas por meio de um túnel do Cloud VPN. Nesse cenário, novas sub-redes estão sendo adicionadas em ambas as redes:

  1. Uma nova 192.168.1.0/24sub-rede na regiãous-east1 da rede do Google Cloud.
  2. Uma nova sub-rede 10.0.30.0/24 no local para processar o tráfego crescente no seu data center.
Cloud Router para Cloud VPNs com rede VPC (clique para ampliar)
Cloud Router para Cloud VPNs com rede VPC (clique para ampliar)

Para propagar automaticamente alterações de configuração de rede, o túnel do Cloud VPN usa o Cloud Router a fim de estabelecer uma sessão BGP entre o gateway VPN local, que precisa ser compatível com o BGP. As novas sub-redes são divulgadas sem problemas entre as redes. As instâncias nas novas sub-redes estão aptas a enviar e receber tráfego imediatamente.

Para configurar o BGP, você precisa atribuir um novo endereço IP a cada extremidade do túnel do Cloud VPN. Esses dois endereços IP precisam ser de link local pertencentes ao intervalo de endereços IP 169.254.0.0/16. Esses endereços não fazem parte do espaço de endereço IP de nenhuma das redes. Eles são usados exclusivamente para estabelecer uma sessão do BGP. Além disso, esses endereços não são roteáveis e funcionam bem com ferramentas comuns de teste de rede. Por exemplo, o Traceroute não funciona, e um teste de ping só funciona se a solicitação vier do endereço local de link destinado ao endereço local de link de peering.

Roteamento dinâmico para túneis do Cloud VPN em redes legadas

Em redes legadas, as alterações de configuração de rede são propagadas automaticamente sem a necessidade de reconfigurar rotas estáticas e reiniciar o túnel do Cloud VPN. Esse processo é semelhante ao exemplo anterior.

A sessão do BGP informa cada roteador sobre as mudanças locais. Para configurar o BGP, é preciso atribuir um novo endereço IP a cada extremidade do túnel do Cloud VPN. Esses dois endereços IP precisam ser de link local pertencentes ao intervalo de endereços IP 169.254.0.0/16. Esses endereços não fazem parte do espaço de endereços IP de cada lado do túnel e são usados exclusivamente para configurar pares de BGP para estabelecer uma sessão do BGP.

É necessário configurar dois endereços IP de link local, ambos a partir da mesma sub-rede, e uma máscara de rede em ambas as extremidades do túnel. Depois de configurar essas alterações em ambas as extremidades do túnel, uma sessão do BGP é estabelecida.

Novamente, se uma rede tiver túneis do Cloud VPN em várias regiões, será preciso criar um Cloud Router em cada região em que você quer usar o roteamento dinâmico. É possível usar um único Cloud Router para vários gateways do Cloud VPN e vários túneis na região da rede que inclui o roteador.

Modo de roteamento dinâmico

O modo de roteamento dinâmico de uma rede VPC determina quais sub-redes são visíveis para os Cloud Routers. É possível configurar o modo de roteamento dinâmico como global ou regional:

  • Com o roteamento dinâmico global, um roteador do Cloud Router divulga todas as sub-redes na rede VPC para o roteador local. O Cloud Router propaga as rotas aprendidas do roteador local para todas as regiões.
  • Com o roteamento dinâmico regional, o Cloud Router divulga e propaga rotas na região local dele.

O modo de roteamento dinâmico é configurado na rede VPC. Ao criar ou editar uma rede VPC, é possível configurar o modo de roteamento dinâmico como global ou regional. Todas as instâncias do Cloud Router na rede VPC usam o modo de roteamento dinâmico da rede. Por padrão, o modo é regional.

Se você alterar o modo de roteamento dinâmico de uma rede VPC, considere as implicações, como a interrupção de conexões atuais ou a permissão de rotas não intencionais. Por exemplo, se você mudar para o roteamento dinâmico regional, as VMs disponíveis para conexão com túneis do Cloud VPN e conexões do Cloud Interconnect em outra região talvez percam a conexão. Se você alterar para o roteamento dinâmico global, o Cloud Router talvez divulgue VMs de regiões que você não pretendia. Para visualizar ou configurar o modo de roteamento dinâmico, consulte Como configurar o roteamento dinâmico regional ou global.

Modo de roteamento dinâmico e balanceadores de carga

Revise cuidadosamente o Balanceamento de carga interno TCP/UDP e as redes conectadas para entender como os balanceadores de carga internos TCP/UDP são acessíveis por meio de túneis do Cloud VPN e de anexos do Cloud Interconnect (VLANs, na sigla em inglês). Por exemplo, os balanceadores de carga internos TCP/UDP com acesso global desabilitado podem ser acessados apenas por VMs clientes, túneis do Cloud VPN e anexos do Cloud Interconnect (VLANs, na sigla em inglês) localizados na mesma região que o balanceador de carga.

Exemplo de roteamento dinâmico regional

Com o roteamento dinâmico regional, é possível ter um túnel e VMs do Cloud VPN em uma única região do Google Cloud. O túnel amplia sua rede local para uma rede VPC. As VMs em outras regiões talvez precisem se conectar à rede local, mas não são capazes de acessar o túnel. Uma alternativa para contornar essa restrição é criar rotas estáticas. No entanto, manter rotas estáticas deixa o processo propenso a erros e talvez interrompa o tráfego.

No exemplo a seguir, o Cloud Router tem visibilidade somente para recursos na região us-west1. VMs em outras regiões, como us-central1, não são capazes de alcançar o túnel do Cloud VPN.

Roteamento dinâmico regional do Cloud Router (clique para ampliar)
Roteamento dinâmico regional do Cloud Router (clique para ampliar)

Exemplos de roteamento dinâmico global

Com o roteamento dinâmico global, o Cloud Router tem visibilidade de recursos em todas as regiões. Por exemplo, se você tem VMs em uma região, elas conseguem alcançar um túnel do Cloud VPN em outra região automaticamente sem manter rotas estáticas.

O exemplo a seguir mostra uma rede VPC com roteamento dinâmico global. O Cloud Router em us-west1 divulga sub-redes em duas regiões diferentes: us-west1 e us-central1. As VMs em ambas as regiões aprendem dinamicamente sobre hosts locais.

Roteamento dinâmico global do Cloud Router (clique para ampliar)
Roteamento dinâmico global do Cloud Router (clique para ampliar)

Para topologias redundantes, o roteamento dinâmico (BGP) fornece informações suficientes para a VPC e as redes locais. Assim, quando um caminho falha, o tráfego é reencaminhado. Se uma conexão em uma região apresenta um problema, é possível fazer o failover do tráfego para outra região.

O exemplo a seguir mostra dois túneis do Cloud VPN em duas regiões diferentes. As VMs (10.128.0.0/20) usam o tunnel-us-west1 na região us-west1 para acessar as duas sub-redes na rede local. Da mesma forma, as VMs (10.138.0.0/20) em us-central1 usam tunnel-us-central1.

Roteamento dinâmico global do Cloud Router (clique para
    ampliar)
Roteamento dinâmico global do Cloud Router (clique para ampliar)

As rotas são configuradas para que as VMs prefiram os túneis locais, ou seja, os túneis na região delas. O Cloud Router define pesos diferentes para rotas locais e remotas com o mesmo destino. Se um túnel falhar, o Cloud Router poderá redirecionar o tráfego adequadamente.

No exemplo a seguir, tunnel-us-west1 falha. O tráfego de e para as VMs (10.128.0.0/20) é redirecionado por meio de tunnel-us-central1 em vez de ser descartado.

Roteamento dinâmico global do Cloud Router (clique para ampliar)
Roteamento dinâmico global do Cloud Router (clique para ampliar)

Divulgações de rota

Por meio do BGP, o Cloud Router divulga os endereços IP que os clientes da sua rede local podem alcançar. Sua rede local envia pacotes para sua rede VPC que tem um endereço IP de destino correspondente a um intervalo de IP divulgado. Depois de chegar ao Google Cloud, as regras de firewall e as rotas da sua rede VPC determinam como o Google Cloud processa os pacotes.

Você pode usar as divulgações padrão do Cloud Router ou especificar explicitamente quais intervalos CIDR serão divulgados. Se você não especificar divulgações, o Cloud Router usará o padrão.

Padrão

Por padrão, o Cloud Router divulga sub-redes na região para roteamento dinâmico regional ou todas as sub-redes em uma rede VPC para roteamento dinâmico global. Novas sub-redes são divulgadas automaticamente pelo Cloud Router. Além disso, se uma sub-rede tiver um intervalo de IP secundário para a configuração de endereços IP de alias, o Cloud Router divulga os endereços IP primários e secundários.

Cada sessão do BGP em um roteador do Cloud também tem uma divulgação padrão. Por padrão, o Cloud Router propaga as próprias divulgações de rota para todas as suas sessões do BGP. Se você configurar divulgações de rota personalizadas em um roteador do Cloud, as sessões do BGP dela herdam essas divulgações personalizadas.

Você precisa especificar divulgações de rota personalizadas nos seguintes casos:

  • Para divulgar endereços IP fora do intervalo de IP principal de uma sub-rede ou um de seus intervalos de IP secundários. Por exemplo, publicidade de endereços IP externos.
  • Para divulgar rotas de uma rede VPC diferente conectada à sua rede VPC usando Peering de rede VPC. Nesse caso, as rotas de sub-rede e as rotas personalizadas importadas em uma rede de mesmo nível não são divulgados automaticamente por um roteador de nuvem na sua rede VPC. Para divulgá-las, é preciso criar anúncios de rota personalizados no Cloud Router em sua rede VPC e também garantir que as conexões de peering de redes VPC estejam configuradas para trocar as rotas personalizadas.

Ao usar anúncios personalizados, é possível divulgar seletivamente sub-redes ou partes de uma sub-rede. Dessa maneira, é possível impedir que determinadas sub-redes sejam divulgadas. Se você não precisa desses recursos, use as divulgações padrão.

Personalizadas

Ao configurar divulgações de rota personalizadas, você especifica explicitamente as rotas divulgadas pelo Cloud Router. Na maioria dos casos, divulgações personalizadas são úteis para complementar a divulgação de sub-redes padrão com endereços IP personalizados. Endereços IP personalizados são aqueles fora do intervalo de IP de uma sub-rede, como endereços IP externos reservados. Sem divulgações de rota personalizadas, você precisaria criar e manter rotas estáticas para endereços IP personalizados.

Ao configurar divulgações de rotas personalizadas, você pode optar por divulgar todas as sub-redes, o que emula o comportamento padrão. Você pode optar por não divulgar todas as sub-redes e, em vez disso, divulgar sub-redes específicas ou determinados blocos de CIDR dentro de uma sub-rede. Por exemplo, é recomendado evitar que o Cloud Router divulgue sub-redes particulares. Para isso, divulgue apenas aquelas que você quer expor. No entanto, quando você divulgar sub-redes seletivamente, será preciso adicionar novas sub-redes manualmente à divulgação de rota personalizada. O Cloud Router não divulgará novas sub-redes automaticamente.

Você pode especificar divulgações de rota personalizadas em um roteador do Cloud ou em uma sessão do BGP. As divulgações de rota personalizadas no Cloud Router são aplicáveis a todas as sessões do BGP. No entanto, se você especificar uma divulgação de rota personalizada em uma sessão do BGP, a divulgação de rota do Cloud Router será ignorada e substituída pela opção da sessão.

Para cada roteador do Cloud, você pode especificar um máximo de 200 intervalos CIDR. Além disso, cada sessão do BGP tem o mesmo limite de 200.

Exemplos

Os exemplos a seguir mostram o comportamento padrão do Cloud Router e os cenários em que divulgações de rota personalizadas podem ser úteis. Os exemplos pressupõem uma conexão existente entre a redes VPC e locais, como um túnel VPN IPsec ou interconexões dedicadas.

Divulgação de rota padrão

Para o roteamento dinâmico regional, o Cloud Router divulga as sub-redes na região. No exemplo a seguir, o Cloud Router divulga sub-redes na região us-central1. Ele também divulga o intervalo de IP secundário de alias-subnet. Se você criar novas sub-redes em us-central1, o Cloud Router as divulgará automaticamente. O Cloud Router não divulga endereços IP que não estão incluídos no intervalo de IP de uma sub-rede, como endereços IP externos.

Divulgação de rota padrão do Cloud Router (clique para ampliar)
Divulgação de rota padrão do Cloud Router (clique para ampliar)

É possível usar um endereço IP estático externo para um aplicativo do Google Cloud que atende clientes em sua rede local. Ao realizar a manutenção no aplicativo, é possível remapear o endereço IP estático para outra VM a fim de minimizar o tempo de inatividade. Com as divulgações padrão do Cloud Router, é necessário configurar e manter uma rota estática. Em vez disso, você pode usar divulgações personalizadas para divulgar o endereço IP externo por meio do BGP.

No exemplo a seguir, o Cloud Router divulga o endereço IP externo 1.2.3.4do servidor proxy. O endereço IP externo é mapeado para o endereço IP interno do servidor 10.20.0.2. O Cloud Router não divulga o endereço IP interno do servidor proxy nem as VMs na sub-rede my-subnet. Os clientes locais só estão cientes do endereço IP externo do servidor proxy.

Divulgação de endereço IP externo (clique para ampliar)
Divulgação de endereço IP externo (clique para ampliar)

Para mais informações, consulte Como divulgar intervalos de IP personalizados.

Divulgação de sub-rede restrita

Você pode evitar que instâncias sejam divulgadas para que elas fiquem ocultas. No exemplo a seguir, o Cloud Router divulga subnet-1 e subnet-2. Os clientes na rede local acessam as VMs nessas sub-redes, mas não VMs na sub-rede unadvertised-subnet.

Divulgar sub-redes específicas no Cloud Router (clique para ampliar)
Divulgar sub-redes específicas no Cloud Router (clique para ampliar)

Para mais informações, consulte Como divulgar sub-redes VPC específicas.

Divulgação de rota por sessão do BGP

Suponha que você tem recursos de produção e de teste nas suas redes VPC e local e que organizou esses recursos em diferentes sub-redes. Assim, você configura duas sessões do BGP que divulgam diferentes intervalos de endereços IP. Ao usar duas sessões do BGP diferentes, o tráfego vinculado a uma sub-rede não simplesmente vai para a outra. O exemplo a seguir mostra duas sessões do BGP: prod-bgp, que divulga apenas prod-subnet, e test- bgp, que divulga somente test-subnet.

Divulgar sub-redes específicas em uma sessão do BGP (clique para ampliar)
Divulgar sub-redes específicas em uma sessão do BGP (clique para ampliar)

Para mais informações, consulte Como divulgar intervalos de IP personalizados ou Como divulgar sub-redes VPC específicas.

Rotas dinâmicas personalizadas aprendidas

Quando um Cloud Router recebe vários "próximos saltos" para o mesmo prefixo de destino, o Google Cloud usa métricas de rota e, em alguns casos, o tamanho do caminho AS para criar rotas dinâmicas personalizadas na rede VPC. Esta seção descreve esse processo.

Efeitos do modo de roteamento dinâmico

O modo de roteamento dinâmico de uma rede VPC determina como as rotas dinâmicas personalizadas aprendidas com os Cloud Routers são aplicadas.

  • No modo de roteamento dinâmico regional, o Cloud Router cria uma rota dinâmica personalizada 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 personalizada como prioridade básica, que o Cloud Router obtém do MED divulgado pelo roteador local.

  • No modo de roteamento dinâmico global, o Cloud Router cria uma rota dinâmica personalizada 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 personalizada como prioridade básica. Em todas as outras regiões, o Cloud Router define a prioridade como prioridade básica mais um custo regional apropriado.

É possível definir a prioridade da rota como "rotas para o Google Cloud" exportadas para o roteador local. No entanto, essa prioridade de rota pode ser modificada pelo roteador local, dependendo da configuração. Por exemplo, se o roteador local modificar a prioridade da rota.

Para rotas no 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 (prefixo), com um tamanho do caminho AS mais curto. A MED só é considerada 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 só é considerado no âmbito de cada tarefa de software do Cloud Router nos seguintes cenários.

Se uma única tarefa de software do Cloud Router aprender o mesmo destino a partir de 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 rota candidata é definida como MED recebida.

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

  • Cada tarefa de software escolhe uma sessão do BGP do 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 duas ou mais rotas candidatas. A prioridade básica de cada rota candidata é definida como MED recebida.

Em seguida, o plano de controle do Cloud Router instala uma ou mais rotas dinâmicas personalizadas 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 personalizada regional é ajustada em regiões diferentes da região do Cloud Router. Consulte Ordem de roteamento para mais informações sobre como o Google Cloud seleciona uma rota.

Prioridade básica e MED

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.

O valor final da prioridade que o Cloud Router define ao criar rotas dinâmicas personalizadas 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

Consulte a seção Ordem de roteamento na documentação de roteamento da VPC.

Como sobrepor intervalos de IP entre uma sub-rede VPC e uma divulgação de rota local

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.

Como divulgar uma rota aprendida de uma sessão do BGP para outra sessão do BGP

No momento, o Cloud Router não oferece suporte à divulgação, por meio de divulgações de rota estática, de uma rota local aprendida de uma sessão do BGP para outra sessão do BGP. Tentar fazer isso pode resultar na queda da rota.

Para mais informações sobre como trocar corretamente rotas dinâmicas com várias redes VPC, consulte Prefixos IP não propagáveis ou indisponíveis na página Solução de problemas do Cloud Router.

Métricas de rota

Quando o Cloud Router divulga ou propaga rotas, ele usa métricas de rota para especificar as prioridades da rota. Quando você tem vários caminhos entre sua rede VPC e a rede local, as métricas de rota determinam um caminho prioritário. Esse valor é equivalente ao valor da MED. Uma métrica de rota (MED, na sigla em inglês) menor indica maior prioridade.

Uma métrica de rota é composta por uma prioridade de rota divulgada básica e um custo regional. A prioridade básica é um valor especificado pelo usuário, enquanto o custo regional é um valor gerado pelo Google que não pode ser modificado. O custo regional representa o custo de comunicação entre duas regiões em uma rede VPC. O Cloud Router adiciona esses dois valores para gerar uma métrica de rota.

Para roteamento dinâmico regional, como o Cloud Router lida somente com rotas na região dele, não há custo regional adicional para métricas de rota. O Cloud Router usa apenas a prioridade da rota divulgada básica.

Para o roteamento dinâmico global, todos os Cloud Routers divulgam e propagam as mesmas rotas. No entanto, cada Cloud Router pode usar diferentes métricas de rota devido a custos regionais.

Prioridade de rota divulgada básica

Ao calcular métricas da rota, o Cloud Router começa com o valor da prioridade de rota divulgada básica e, em seguida, adiciona os custos regionais. Esse valor de base é a métrica de rota mínima para rotas divulgadas. Ao configurar uma sessão do BGP em um Cloud Router, você pode especificar uma prioridade de rota anunciada básica que se aplica a todas as rotas dessa sessão. Por padrão, o valor de prioridade básica divulgado é 100 e tem um número inteiro positivo como valor. O Cloud Router considera uma prioridade básica divulgada com o valor numérico de 1 como a rota de maior prioridade. Este valor tem precedência sobre prioridades mais baixas que têm um valor de 2 ou mais.

A prioridade de rota divulgada básica permite que você estabeleça prioridades para rotas. Por exemplo, é possível ter um túnel do Cloud VPN e uma conexão da Interconexão dedicada conectando sua VPC e as redes locais. Também é possível definir a prioridade de rota divulgada básica para que o tráfego prefira a Interconexão dedicada. Se a conexão da Interconexão dedicada estiver indisponível, o tráfego atravessará o túnel. Para mais informações, consulte as topologias de exemplo.

Custo regional

Quando um Cloud Router divulga rotas de outras regiões além da sua região (rotas de regiões remotas do Google Cloud) ou propaga rotas para regiões remotas, ele adiciona um custo regional.

O custo regional pode variar entre 201 e 9999, incluindo esses números. O valor depende da distância, da latência e de outros fatores entre duas regiões. O Google gera o valor de custo regional, e não é possível modificá-lo. Para mais informações sobre custos regionais, consulte as topologias de exemplo.

Os custos regionais ajudam a priorizar caminhos com base na proximidade da região. Por exemplo, imagine que você tem duas conexões entre sua VPC e a rede local, como dois túneis do Cloud VPN com seus próprios Cloud Routers. Uma conexão está em us-central1 e a outra em europe-west1. Ao adicionar um custo regional às métricas da rota, o tráfego entre as redes em us-central1 prioriza o túnel us-central1. Da mesma forma, o tráfego entre as redes em europe-west1 prioriza o túnel europe-west1. Sem os custos regionais, o tráfego é direcionado igualmente por ambas as conexões, o que gera um desempenho de rede inconsistente.

Para rotas aprendidas, o Cloud Router adiciona custos regionais quando propaga as rotas aprendidas para regiões remotas do Google Cloud. Isso ajuda a manter a simetria entre o tráfego de entrada e de saída entre a VPC e as redes locais. O Cloud Router adiciona custos regionais ao valor de MED que é divulgado pelo seu roteador local.

Valores de prioridade básica sugeridos

Para ajustar as prioridades entre rotas de uma única região, use valores inferiores a 201. Isso garante que os custos regionais não afetarão as prioridades de rota globais. Uma rota de outra região (uma região remota) não pode ter prioridade menor que 201. Se você usar valores mais altos, os custos regionais poderão afetar suas prioridades de rota. Por exemplo, imagine que você tenha uma conexão principal e uma de backup. Se você definir a prioridade básica da conexão de backup com um valor muito alto, poderá acidentalmente dar preferência a rotas de outras regiões em vez da conexão de backup.

Para remover globalmente a preferência de uma rota em uma rede VPC, use valores maiores que 10,200. Isso garante que todas as outras rotas menores que 201 tenham prioridade, independentemente dos custos regionais.

Nos casos em que todas as rotas em uma região têm a mesma preferência, use o valor padrão 100.

Topologias de exemplo

Os exemplos a seguir explicam como os custos regionais influenciam as métricas da rota quando você usa o roteamento dinâmico global.

Suponha que você tenha uma rede VPC com dois túneis do Cloud VPN com seus próprios Cloud Routers. Um túnel está em us-central1 e o outro está em us-west1. Por padrão, o tráfego de entrada para essas regiões usa os túneis correspondentes das respectivas regiões. No entanto, o que acontece se você quiser alcançar VMs que não estão nessas regiões, como VMs em europe-west1? O diagrama a seguir mostra como os custos regionais afetam as métricas de rota.

Métricas de rota do Cloud Router para rotas divulgadas (clique para ampliar)
Métricas de rota do Cloud Router para rotas divulgadas (clique para ampliar)

Os dois roteadores do Cloud divulgam rotas para europe-west1, mas com diferentes métricas de rota. O Cloud Router em us-central1 divulga rotas para europe-west1 com uma métrica de rota inferior a us-west1 devido à distância, latência e outros fatores. O exemplo considera que o custo regional para europe-west1 é 300 até us-central1 e 350 até us-west1. O tráfego de entrada usa o túnel us-central1, que tem uma métrica de rota mais baixa. Ele tem uma métrica de rota de 350 vs 400 para o túnel us-west1.

Da mesma maneira, o Cloud Router adiciona um custo regional ao valor de MED das rotas aprendidas (especificado pelo roteador local). Por padrão, o tráfego de saída da região europe-west1 também usa o túnel us-central1 porque tem uma métrica de rota mais baixa. Dessa maneira, os tráfegos de entrada e saída mantêm uma simetria.

Métricas de rota do Cloud Router para rotas aprendidas (clique para ampliar)
Métricas de rota do Cloud Router para rotas aprendidas (clique para ampliar)

Prioridades de encaminhamento dentro de uma região

Para redundância em us-west1, suponha que você crie um túnel de backup. Você especifica uma prioridade básica mais alta para o túnel de backup, de modo que o tráfego de entrada para us-west1 prefira o túnel principal, conforme mostrado no exemplo a seguir.

Prioridades básicas para rotas dentro de uma região (clique para ampliar)
Prioridades básicas para rotas dentro de uma região (clique para ampliar)

Se o túnel principal falhar, o tráfego de entrada para us-west1 prefere o túnel de backup com uma métrica de rota de 51 no lugar do túnel us-central1, que tem uma métrica de rota de 400.

Prioridades básicas para rotas dentro de uma região (clique para ampliar)
Prioridades básicas para rotas em uma região (clique para ampliar)

Da mesma maneira, para o tráfego de saída da rede VPC para sua rede local, use valores de MED menores que 201 se quiser priorizar um caminho em relação a outro. Caso contrário, o tráfego de saída da rede VPC para sua rede local não será simétrico ao tráfego de entrada.

Nos casos em que todos os túneis ou conexões do Cloud Interconnect em uma região são igualmente preferidos, é possível usar a prioridade de roteamento base padrão de 100.

Rota preferencial global

Suponha que você tenha uma Interconexão dedicada e um túnel do Cloud VPN em diferentes regiões. Você quer priorizar a Interconexão dedicada porque ela é mais econômica para suas cargas de trabalho do que o túnel do Cloud VPN. Especifique uma prioridade básica de 10,051 para que as rotas do túnel do Cloud VPN não sejam priorizadas. Como resultado, todo o tráfego de entrada usa a Interconexão dedicada, independentemente dos custos regionais. As métricas de rota para a Interconexão dedicada não excederão 10,051. O tráfego usa o túnel do Cloud VPN somente se a conexão falhar.

Prioridades básicas para rotas globais (clique para ampliar)
Prioridades básicas para rotas globais (clique para ampliar)

Você também precisará fazer os mesmos ajustes em seu roteador local para que o tráfego de saída da rede VPC para a rede local sempre prefira usar a Interconexão dedicada.

Para mais informações sobre como definir uma prioridade básica, consulte Como criar sessões do BGP ou Como atualizar a prioridade básica de rota divulgada.

Rota padrão

Quando nenhuma rota é especificada para um destino de IP específico, o tráfego é enviado por uma rota padrão, que atua como último recurso quando não existem outras opções. Por exemplo, as redes do Google Cloud VPC incluem automaticamente uma rota padrão (0.0.0.0/0) que envia tráfego para o gateway da Internet.

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ê for divulgar 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.

Graceful Restart

O Cloud Router aceita mensagens de reinicialização normal enviadas pelo seu roteador no local. Se você configurou seu roteador local com inicialização normal, ele enviará uma notificação ao Cloud Router sempre que seu roteador precisar instalar atualizações de software ou executar manutenção periódica. O Cloud Router retém as rotas dinâmicas personalizadas aprendidas do roteador local durante período definido pela configuração do timers de reinicialização normal no seu roteador local.

Para mais informações sobre timers de reinicialização normal, consulte Configurações de temporizador do BGP.

Túnel Cloud VPN com Graceful Restart

No exemplo a seguir, se o Cloud Router precisar de uma atualização de manutenção, ele poderá ser atualizado sem causar nenhuma interrupção no tráfego, desde que ele fique on-line novamente dentro do período do Graceful Restart.

Reinicialização otimizada e conectividade de rede (clique para ampliar)
Reinicialização otimizada e conectividade de rede (clique para ampliar)

Configurações do temporizador do BGP

O Cloud Router e seu roteador local mantêm a comunicação usando o seguinte conjunto de configurações de timer.

Timer de sinal de atividade
É o intervalo entre os sinais de funcionamento periódicos do BGP trocados entre um Cloud Router e o roteador de peering local correspondente. Junto com o temporizador de espera, o temporizador de sinal de atividade indica a disponibilidade de cada roteador ao outro. Defina o timer de sinal de atividade para 20 segundos no roteador local.
Timer de espera
Registra o tempo mínimo desde o último sinal de atividade bem-sucedido detectado. Indica quanto tempo o Cloud Router ou o roteador local precisa aguardar antes de remover as rotas descobertas do outro roteador. Defina o timer de espera para 60 segundos no roteador local.
Temporizador de reinicialização normal

É o tempo que seu roteador local espera, sem sinais de atividade semanais, depois de receber uma mensagem de notificação de reinicialização normal do Cloud Router correspondente antes de esperar novos sinais de atividade. Se os novos sinais de atividade não forem recebidos, seu roteador local removerá as rotas que aprendeu com o Cloud Router.

Se você quiser que o roteador se comporte da mesma forma que o Cloud Router, recomendamos definir o timer de reinicialização normal para 1 segundo em seu roteador local.

O Cloud Router retira as rotas dinâmicas personalizadas que ele aprende com dispositivos locais quando determina que um túnel do Cloud VPN de próximo salto está inativo ou que uma conexão do Cloud Interconnect está inativa. Se você definir o tempo de reinicialização normal do roteador local como um valor maior que um segundo, o roteador local enviará o tráfego de retorno para um próximo salto que não está mais ativo, em vez de alternar para um próximo salto secundário ativo.

Timer de stalepath

Esta configuração determina quanto tempo um roteador aguarda antes de excluir rotas aprendidas após receber uma mensagem de fim de registro (EOR, na sigla em inglÊs) do outro roteador. Esse temporizador é acionado quando a sessão do BGP é reinicializada após um Graceful Restart, sem o prefixo em questão ter sido abordado por uma mensagem UPDATE. Recomendamos definir o timer do stalepath para 300 segundos no roteador local para que corresponda à configuração do Cloud Router.

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. O tráfego do Cloud VPN roteado dinamicamente não entra mais no túnel. Rotas estáticas para o túnel continuam a ser disponibilizadas.

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.

No exemplo a seguir, a caixa representa o Cloud Router com dois endereços IP. Esses dois endereços são interfaces de Ethernet separadas dentro da mesma tarefa do Cloud Router. Cada interface é usada para uma sessão individual do BGP com um gateway local separado. Neste caso de uso específico, como esses túneis do Cloud VPN são criados para fins de redundância, as duas sessões do BGP trocam exatamente o mesmo conjunto de prefixos de rota, mas com próximos saltos que apontam para túneis diferentes do Cloud VPN.

Redundância sem inicialização normal (clique para ampliar)
Redundância sem reinicialização normal (clique para ampliar)

Ciclos de atualização

O Cloud Router é atualizado periodicamente, o que leva menos de 60 segundos. O Cloud Router fica indisponível durante a atualização. O temporizador de espera do BGP determina por quanto tempo 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 para o temporizador de espera do BGP. Recomendamos que você defina o temporizador de espera do BGP para 60 segundos ou mais. O valor padrão é de três minutos. 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.

A sessão e o ID do roteador do BGP são reiniciados

O Cloud Router seleciona o endereço IP com a interface mais ampla para o ID do roteador do BGP, e mantém esse ID enquanto o endereço estiver disponível. Se você excluir a interface do Cloud Router que está sendo usada para o ID do roteador do BGP, o Cloud Router precisará selecionar um novo ID do roteador. Essa seleção faz com que todas as sessões do BGP sejam reiniciadas. O ID do roteador também pode ser alterado se o Cloud Router for reiniciado devido às manutenções periódicas.

A seguir

Para resolver problemas comuns do Cloud Router, consulte a documentação de solução de problemas.

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
Dedicated Interconnect Estático Incompatível
Dedicated Interconnect Dinâmica Como criar anexos da VLAN
VPN clássica Estático, baseado em políticas Como criar uma VPN clássica usando o roteamento estático
VPN clássica ou VPN de alta disponibilidade Dinâmica Como criar uma VPN clássica usando o roteamento dinâmico
Como criar um gateway de VPN de alta disponibilidade para um gateway de VPN de peering
Como criar gateways de VPN de alta disponibilidade do Google Cloud para o Google Cloud