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 com conexões do Cloud VPN ou do Interconnect para fornecer roteamento dinâmico usando o Border Gateway Protocol (BGP, na sigla em inglês) 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, duas ou, em casos raros, três tarefas de software.

Veja na tabela a seguir cenários de exemplos e o número de tarefas de software usadas 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.
  • Para anexos da VLAN, cada domínio de disponibilidade de borda com anexos é processado por uma tarefa de software separada.
Exemplo Número de tarefas de software usadas pelo Google Cloud 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 à interface zero 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 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 diferentes números de interface do gateway da VPN de alta disponibilidade. Por exemplo, um túnel conectado à interface zero de um gateway de VPN de alta disponibilidade e outro túnel conectado à interface 1 do mesmo gateway ou a um gateway diferente. Dois
Um Cloud Router com pelo menos o seguinte:
  • Uma interface conectada a um anexo da VLAN no domínio de disponibilidade de borda zero e/ou uma interface conectada a um túnel de VPN de alta disponibilidade conectado à interface zero de um gateway de VPN de alta disponibilidade
  • Uma interface conectada a um anexo da VLAN no domínio de disponibilidade de borda 1 e/ou uma interface conectada a um túnel de VPN de alta disponibilidade conectada à interface 1 de um gateway de VPN de alta disponibilidade
  • Uma interface conectada a um túnel de VPN clássica
Três

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.

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

Modo de roteamento dinâmico

Nesta seção, descrevemos exemplos de roteamento dinâmico regional e roteamento dinâmico global. Saiba mais sobre os modos de roteamento dinâmico de redes VPC na visão geral da rede VPC.

Saiba mais sobre o modo de roteamento dinâmico e os balanceadores de carga em Balanceamento de carga TCP/UDP interno e redes conectadas.

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)

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

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-bgpque 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 recebe 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 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, 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 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.

Limites das rotas aprendidas

Há dois limites para as rotas aprendidas. Esses limites não definem diretamente um número máximo de rotas aprendidas. Em vez disso, eles definem o número máximo de prefixos de destino exclusivos. Para mais informações sobre esses limites, consulte esta página.

Para monitorar o uso em relação a esses 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 solução de problemas, consulte Verificar cotas e limites em Solução de problemas.

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 prefixos anunciados e suas prioridades são recebidos pelos roteadores locais, os roteadores locais criam rotas usadas para enviar pacotes para a rede VPC.

Orientação para prioridades básicas

Ao configurar uma sessão do BGP em um Cloud Router, é possível especificar uma prioridade anunciada básica 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, a prioridade padrão será usada.

As prioridades básicas permitem que você controle quais túneis do Cloud VPN ou anexos do Cloud Interconnect (VLANs) são usados pelos sistemas locais 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.

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 e não é possível modificá-los.

  • As prioridades básicas para sessões do BGP entre os Cloud Routers em uma região precisam estar 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 do Cloud Interconnect. 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 do Cloud Interconnect.

  • Prioridades básicas de 10,200 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

Veja o diagrama a seguir para uma ilustração deste exemplo. O diagrama inclui valores de exemplo para o custo regional.

VPNs de alta disponibilidade com túneis ativos/ativos (clique para ampliar)
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 a 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 a 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 a 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 do Cloud Interconnect.

Veja o diagrama a seguir para uma ilustração deste exemplo.

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

É necessário priorizar os anexos da VLAN da Interconexão dedicada. 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 a Interconexão dedicada 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 a Interconexão dedicada 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 a Interconexão dedicada 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

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.

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.

O Cloud Router define esse valor como 1 segundo. Para seu roteador local, defina o timer de reinicialização normal como um valor apropriado para suas necessidades. Cada roteador comunica o valor do timer de reinicialização normal ao peer por meio da mensagem OPEN ao estabelecer uma sessão do BGP.

O Cloud Router retira as rotas dinâmicas personalizadas que 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.

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.

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