Visão geral do Cloud Router

O Cloud Router é um serviço de nuvem do Google totalmente distribuído e gerenciado. Por oferecer escalabilidade de acordo com seu tráfego de rede, ele não é um dispositivo físico que pode causar gargalos.

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 protocolo do gateway de borda (BGP, na sigla em inglês). As alterações de topologia se propagam automaticamente entre sua rede VPC e a rede local. Não é necessário configurar rotas estáticas.

O Cloud Router funciona com redes legadas e redes de nuvem privada local (VPC).

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 descobrem alterações de topologia de maneira rápida e automática por meio do BGP. As mudanças 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 VPN

Sem o Cloud Router, só é possível configurar a VPN com rotas estáticas. O uso de rotas estáticas apresenta as seguintes desvantagens:

  • Uma alteração na configuração de rede em qualquer lado de um túnel VPN exige a criação e exclusão manual das rotas estáticas correspondentes a essas alterações. Além disso, as alterações nas rotas estáticas têm convergência lenta.
  • Antes da criação do túnel VPN para uso de rotas estáticas, é necessário especificar a lista de prefixos de IP nos dois lados do túnel. Isso significa que, sempre que for necessário alterar as rotas, o túnel VPN precisará ser atualizado (excluído e recriado) com as novas rotas. Isso interrompe o tráfego existente.
  • 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 é composta pela sua rede do Google Cloud e 29 sub-redes (uma por rack) na rede local no outro lado do túnel VPN. Neste exemplo, imagine que sua empresa esteja crescendo de tal forma que você precise adicionar uma nova sub-rede de máquinas a cada semana. Nesta semana, você está adicionando a sub-rede 10.0.30.0/24, conforme mostrado no diagrama a seguir:

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

Nesse cenário, a VPN com base em rota estática exige as seguintes alterações:

  1. As rotas estáticas precisam ser adicionadas ao Google Cloud Platform para alcançar a nova sub-rede local.
  2. É preciso eliminar e recriar o túnel VPN para incluir a nova sub-rede local.

Para evitar as alterações nas configurações das rotas estáticas e dos túneis VPN, implante um roteador do Cloud Router. O Cloud Router faz o peering com o gateway da VPN usando o BGP para trocar informações de topologia. As mudanças de topologia de rede na sua rede do Google Cloud Platform se propagam automaticamente para sua própria rede e vice-versa via BGP. Assim, você não precisa configurar rotas estáticas para seus túneis VPN.

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

Use redes VPC para permitir a segmentação regional do espaço IP da rede em prefixos (sub-redes) e o controle dos prefixos aos quais um endereço IP interno da instância da VM é alocado. Para evitar o gerenciamento estático dessas sub-redes, incluindo a obrigação de adicionar e remover rotas estáticas relacionadas à VPN, use o Cloud Router para ativar o roteamento dinâmico no seu túnel VPN.

Um Cloud Router pertence a uma rede VPC e região específicas. O Cloud Router divulga sub-redes da rede VPC em que ele está localizado para o gateway local via BGP. Ele divulga as sub-redes na região local dele ou todas as sub-redes da 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.

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 Cloud VPN. Nesse cenário, novas sub-redes estão sendo adicionadas em ambas as redes:

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

Para propagar automaticamente as mudanças na configuração de rede, o túnel VPN usa o Cloud Router para estabelecer uma sessão do BGP entre os gateways de peering e da VPN local, que precisa ser compatível com o BGP. As novas sub-redes são anunciadas sem interrupções entre as redes. As instâncias nas novas sub-redes podem começar a enviar e receber tráfego imediatamente.

Para configurar o BGP, atribua um endereço IP adicional a cada extremidade do túnel 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 VPN em redes legadas

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

A sessão do BGP informa cada roteador sobre as mudanças locais. Para configurar o BGP, atribua um endereço IP adicional a cada extremidade do túnel 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 VPN em várias regiões, será preciso criar um Cloud Router em cada região que precisa de roteamento dinâmico. Um Cloud Router pode ser usado para vários gateways da VPN e vários túneis na região da rede em que ele está.

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, você pode 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 existentes ou a permissão de rotas não intencionais. Por exemplo, se você muda para o roteamento dinâmico regional, as instâncias de VM que podem se conectar a túneis VPN e interconexões de outra região podem perder a conexão. Se você muda para o roteamento dinâmico global, o Cloud Router pode divulgar instâncias de VM 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.

Exemplo de roteamento dinâmico regional

Com o roteamento dinâmico regional, você pode ter um túnel Cloud VPN e instâncias de VM em uma única região do GCP. O túnel amplia sua rede local para uma rede VPC. As instâncias de VM de outras regiões podem precisar se conectar à rede local, mas não podem alcançar o túnel. Para contornar essa restrição, você poderia criar rotas estáticas. No entanto, manter rotas estáticas deixa o processo propenso a erros e pode interromper o tráfego.

No exemplo a seguir, o Cloud Router tem visibilidade apenas dos recursos na região us-west1. As instâncias de VM de outras regiões, como us-central1, não podem alcançar o túnel 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ê tiver instâncias de VM em uma região, elas podem alcançar um túnel 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 instâncias de 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 Cloud VPN em duas regiões diferentes. As instâncias de VM (10.128.0.0/20) usam o tunnel-us-west1 na região us-west1 para alcançar ambas as sub-redes na rede local. Da mesma maneira, as instâncias de VM (10.138.0.0/20) em us-central1 usam o túnel 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 de modo que as instâncias de VM prefiram os túneis locais (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, o tunnel-us-west1 falha. Em vez de ser descartado, o tráfego com origem e destino nas instâncias de VM (10.128.0.0/20) é redirecionado pelo tunnel-us-central1.

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 alcançar o GCP, as regras e as rotas de firewall da rede VPC determinam como o GCP manipula 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.

Divulgaçã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 personalizados em um roteador do Cloud, as sessões do BGP dele herdam essas divulgações personalizadas.

Para divulgar endereços IP fora do alcance de uma sub-rede, como endereços IP externos reservados, é preciso especificar divulgações personalizadas. Além disso, quando você usa divulgações personalizadas, pode 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 precisar desses recursos, use as divulgações padrão.

Divulgação personalizada

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. Os endereços IP personalizados são endereços 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. Divulgações de rota personalizadas no Cloud Router se aplicam 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 as sub-redes na região us-central1 e também o intervalo de IP secundário de alias-subnet. Se você criar novas sub-redes em us-central1, elas serão divulgadas 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)

Você pode usar um endereço IP estático externo para um aplicativo do GCP que atende aos clientes na sua rede local. Quando você executar a manutenção no aplicativo, será possível remapear o endereço IP estático para outra instância da VM para 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.4 do servidor proxy. O endereço IP externo mapeia o endereço IP interno 10.20.0.2 do servidor. O Cloud Router não divulga o endereço IP interno do servidor proxy ou qualquer instância de VM 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 podem alcançar instâncias da VM nessas sub-redes, mas não instâncias 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 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 vai inadvertidamente para a outra. O exemplo a seguir mostra duas sessões do BGP: prod-bgp que divulga somente 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.

Melhor caminho para o tráfego de saída do GCP para sua rede local

Se o Cloud Router receber várias rotas para o mesmo destino, o GCP usará as métricas de rota e, em alguns casos, o tamanho do caminho AS para determinar o melhor caminho. A lista a seguir descreve o algoritmo usado para o tráfego de saída com um ou mais roteadores do Cloud Router gerenciando rotas dinâmicas para uma rede VPC.

  1. Se você tiver várias sessões do BGP em um único roteador do Cloud Router, a saída será determinada pela primeira condição atendida:
    1. Todo o tráfego de saída é enviado para a rota com a extensão de caminho AS mais curta.
    2. Se as rotas tiverem a mesma extensão de caminho AS, todo o tráfego de saída será enviado para aquele com o menor valor de Discriminador de várias saídas (MED, na sigla em inglês), ou seja, com a métrica de rota mais baixa.
    3. Se as rotas tiverem a mesma extensão de caminho AS e valor de MED (as mesmas métricas de rota), o tráfego de saída será equilibrado em todas as rotas com o roteamento de vários caminhos de custo igual (ECMP, na sigla em inglês).
  2. Se você usar vários roteadores do Cloud Router na mesma região, o GCP usará apenas as métricas de rota para determinar o melhor caminho. A extensão do caminho AS não será usada. A saída será determinada pela primeira condição atendida:
    1. Todo o tráfego de saída é enviado para a rota com o menor valor de MED (a métrica de rota mais baixa).
    2. Se as rotas tiverem o mesmo valor de MED (as mesmas métricas de rota), o tráfego de saída será equilibrado em todas as rotas com o ECMP.
  3. As rotas estáticas têm prioridade sobre as rotas dinâmicas do Cloud Router em caso de conflito. Uma rota estática com o mesmo prefixo e métrica de uma rota dinâmica sempre tem prioridade. Portanto, qualquer rota dinâmica conflitante é ignorada.

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 GCP encaminha o tráfego de saída de acordo com os intervalos de IP.

Se o intervalo de IP da sub-rede for maior ou o mesmo que a divulgação de rota local, o GCP ignora a divulgação local. Todo o tráfego de saída do GCP destinado ao intervalo de IP da sub-rede é direcionado para a sub-rede VPC. Por exemplo, se você tem uma sub-rede com um intervalo de IP 10.2.0.0/16 e um roteador local que divulga 10.2.1.0/24, o GCP ignora a divulgação local e direciona o tráfego de 10.2.0.0/16 para a sub-rede VPC.

Se o intervalo de IP da sub-rede for menor que a divulgação de rota local, o tráfego de saída do GCP é direcionado para a sub-rede VPC se o IP de destino estiver dentro do intervalo de IP da sub-rede. Todo o tráfego de saída restante que corresponde à divulgação local é direcionado para a rede local. Por exemplo, se você tem uma sub-rede com um intervalo de IP 10.2.0.0/16 e um roteador local que divulga 10.0.0.0/8, o GCP direciona o tráfego destinado a 10.0.0.0/8 para a rede local, a menos que o destino corresponda a 10.2.0.0/16, que o GCP encaminha para a sub-rede.

Métricas de rota

Quando o Cloud Router anuncia 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 de MED. Uma métrica de rota (MED) menor indica maior prioridade.

Uma métrica de rota é composta por uma prioridade de rota anunciada 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 anunciada básica.

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

Prioridade de rota anunciada básica

Ao calcular métricas da rota, o Cloud Router começa com o valor da prioridade de rota anunciada básica e, em seguida, adiciona os custos regionais. Esse valor de base é a métrica de rota mínima para rotas anunciadas. 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 anunciado é 100.

A prioridade de rota anunciada básica permite que você estabeleça prioridades para rotas. Por exemplo, você pode ter um túnel VPN e uma interconexão dedicada para conectar suas redes VPC e locais. Você pode definir a prioridade de rota anunciada básica para que o tráfego prefira a interconexão dedicada. Se a interconexão não estiver disponível, o tráfego passará pelo túnel. Para mais informações, consulte as topologias de exemplo.

Custo regional

Quando um Cloud Router anuncia rotas de regiões diferentes da dele (rotas de regiões do GCP remotas) ou propaga rotas para regiões remotas, ela 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ê tenha duas conexões entre sua rede VPC e sua rede local, como dois túneis VPN com Cloud Routers próprios. Uma conexão está em us-central1 e a outra está em europe-west1. Ao adicionar um custo regional às métricas de rota, o tráfego entre redes na região us-central1 prioriza o túnel us-central1. Da mesma maneira, o tráfego entre redes na região europe-west1 prioriza o túnel europe-west1. Sem custos regionais, o tráfego será direcionado igualmente por meio das duas conexões, o que leva a um desempenho inconsistente da rede.

Para rotas aprendidas, o Cloud Router adiciona custos regionais quando as propaga para regiões do GCP remotas. Isso ajuda a manter a simetria entre os tráfegos de entrada e de saída entre as redes VPC e locais. O Cloud Router adiciona custos regionais ao valor de MED que é anunciado 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 primária 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, você pode usar 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.

Imagine que você tenha uma rede VPC com dois túneis VPN que têm Cloud Routers próprios. Um túnel está em us-central1 e o outro 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 acontecerá se você quiser alcançar instâncias de VM que não estão nessas regiões, como instâncias 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 anunciadas (clique para ampliar)
Métricas de rota do Cloud Router para rotas anunciadas (clique para ampliar)

Ambos os Cloud Routers anunciam rotas em europe-west1, mas com métricas de rota diferentes. O Cloud Router em us-central1 anuncia rotas para europe-west1 com uma métrica de rota menor que o de us-west1 devido a fatores como distância, latência e outros. Para o exemplo, vamos supor que o custo regional para europe-west1 seja de 300 via us-central1 e 350 via us-west1. O tráfego de entrada usa o túnel us-central1, que tem uma métrica de rota menor. Ele tem uma métrica de rota de 350, contra 400 do 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 ele tem uma métrica de rota menor. 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 a redundância em us-west1, suponha que você crie um túnel de backup. Você especifica uma prioridade básica mais alta ao túnel de backup para que o tráfego de entrada para us-west1 prefira o túnel primário, como 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 primário falhar, o tráfego de entrada para us-west1 dará preferência para o túnel de backup com uma métrica de rota de 51 em comparação com o 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 dentro de uma região (clique para ampliar)

Da mesma maneira, para o tráfego de saída da rede VPC à sua rede local, use valores de MED abaixo de 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 pode não ser simétrico ao tráfego de entrada.

Nos casos em que todos os túneis ou interconexões em uma região têm a mesma preferência, você pode usar a prioridade de rota básica padrão de 100.

Rota preferencial global

Imagine que você tem uma interconexão dedicada e um túnel 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 VPN. Especifique uma prioridade básica de 10.051 para as rotas do túnel VPN para remover a prioridade delas. Como resultado, todo o tráfego de entrada usará 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 usará o túnel VPN somente se a interconexã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 no seu roteador local para que o tráfego de saída da rede VPC à rede local sempre dê preferência para 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 VPC do GCP 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, você pode anunciar 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 e veja a Prioridade para rotas com 0.0.0.0/0 no Intervalo do IP de destino e Default internet gateway no Próximo salto (hop).

Graceful Restart

O Cloud Router tem o mecanismo Graceful Restart ativo. O Graceful Restart permite que o dispositivo do BGP local fique off-line e se recupere dentro do período definido sem interromper o fluxo de tráfego. Esse recurso protege contra interrupções em caso de falhas temporárias ou quando os agentes do BGP precisam de atualizações de software e outros tipos de manutenção.

Ative o Graceful Restart no dispositivo do BGP se ele for compatível com esse recurso.

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.

Graceful Restart e Cloud Router (clique para ampliar)
Graceful Restart e Cloud Router (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 do temporizador:

Temporizador de sinal de atividade: é o intervalo entre os sinais de funcionamento periódicos do BGP trocados entre um roteador do 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. O Google recomenda configurar o temporizador de sinal de atividade para 20 segundos no seu roteador local.

Temporizador de espera: registra a quantidade mínima de tempo desde que o último sinal de funcionamento bem-sucedido foi detectado. Indica quanto tempo o Cloud Router ou o roteador local precisa aguardar antes de remover as rotas descobertas do outro roteador. O Google recomenda configurar o temporizador de espera para 60 segundos no seu roteador local.

Temporizador do Graceful Restart: é a quantidade de tempo que seu roteador local aguardará em inatividade, sem receber sinais de atividade periódicos, depois de receber uma mensagem de notificação do Graceful Restart do Cloud Router correspondente. Se novos sinais de atividade não forem recebidos dentro desse período, o roteador local removerá as rotas descobertas no Cloud Router. O Google recomenda que este temporizador seja definido para 60 segundos.

Temporizador stalepath: configuração que determina quanto tempo um roteador aguardará para excluir as rotas descobertas 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. O Google recomenda configurar esse temporizador para 300 segundos, para corresponder à configuração do Cloud Router.

Túneis redundantes do Google VPN

Se o gateway local não for compatível com o Graceful Restart, uma falha em qualquer lado da sessão do BGP fará com que a sessão falhe e o tráfego seja 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 da VPN roteado dinamicamente não passará mais pelo túnel. As rotas estáticas para o túnel continuarão a ser atendidas.

Sem a compatibilidade com Graceful Restart, 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 VPN são criados para produzir redundância, as duas sessões do BGP trocam exatamente o mesmo conjunto de prefixos de rota, mas com próximos saltos (hops) diferentes que apontam para túneis VPN distintos.

Redundância sem Graceful Restart (clique para ampliar)
Redundância sem Graceful Restart (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. As rotas serão preservadas pelos roteadores durante as atualizações, e o tráfego continuará a fluir.

Durante os ciclos de manutenção com apenas um gateway da VPN, o uso do Cloud Router adiciona cerca de 20 segundos ao tempo de recuperação do túnel. Isso ocorre porque a sessão do BGP é redefinida e as rotas precisam ser coletadas novamente. Normalmente, o tempo de recuperação do gateway da VPN é de cerca de um minuto. Quando há gateways da VPN redundantes, o tráfego não é afetado, porque apenas um gateway da VPN é desativado por vez.

Próximas etapas

Para ver mais informações sobre como usar o roteamento estático e dinâmico com um serviço compatível, consulte a seguinte documentação:

Produto Roteamento Documentação
Dedicated Interconnect Estático Incompatível
Dedicated Interconnect Dinâmico Como criar anexos da VLAN
Cloud VPN Com base em políticas Como criar um túnel VPN com rotas baseadas em políticas
Cloud VPN Estático Como criar um túnel VPN com rotas estáticas
Cloud VPN Dinâmico Como criar um túnel VPN com rotas dinâmicas
Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…