Google PCNE: Conectividade Híbrida, Cloud Router e BGP — Guia de estudos

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

Faz parte do Google Professional Cloud Network Engineer — Guia de estudos. Pratique com respostas verificadas no centro de exames da Google, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

A conectividade híbrida no Google Cloud permite a comunicação privada e controlada entre redes VPC e redes externas, como data centers on-premises ou outras nuvens. Os componentes essenciais são os gateways HA VPN e Cloud VPN, o Cloud Router com BGP para roteamento dinâmico e o Interconnect com anexos de VLAN. Os projetos devem equilibrar largura de banda, latência, confiabilidade, complexidade operacional e custo, ao mesmo tempo em que seguem um comportamento de roteamento determinístico e o isolamento de domínios de falha. Esta seção aborda o raciocínio por trás do projeto e da operação, os modos de falha comuns e a solução de problemas sistemática.

Conectividade Híbrida: HA VPN, Cloud Router e Interconnect

HA VPN e Cloud VPN
- O HA VPN é uma VPN IPsec regional de alta disponibilidade que suporta IKEv2 e requer o Cloud Router para roteamento dinâmico (eBGP). Um gateway de HA VPN tem duas interfaces; para SLA e ECMP, construa dois túneis por interface para endpoints de peer distintos.
- O Cloud VPN Clássico suporta IKEv1 ou IKEv2 e túneis estáticos ou baseados em rota; ele não suporta o SLA do HA VPN. Use-o apenas quando os peers não tiverem BGP ou quando você precisar usar seletores baseados em política.
- O gateway de peer é o dispositivo/IP de VPN remoto. Para o HA VPN, defina um gateway de VPN de peer com um ou mais IPs públicos para modelar interfaces ou dispositivos distintos para redundância.
- Projeto de SLA: Para ser elegível ao SLA de 99,99% do HA VPN, implante túneis redundantes em dispositivos ou interfaces on-premises independentes e use roteamento dinâmico. O VPN Clássico não tem garantia de SLA.
- Escalonamento de throughput: Um único túnel IPsec tem um throughput finito. Use ECMP em múltiplos túneis para aumentar o throughput agregado. Isso é alcançado terminando túneis adicionais em IPs públicos de peer exclusivos.
Cloud Router e BGP
- O Cloud Router é um serviço de plano de controle regional que estabelece sessões BGP com túneis de VPN ou anexos de VLAN do Interconnect e troca rotas dinamicamente.
- O modo de roteamento dinâmico (nível de VPC) governa onde as rotas dinâmicas aprendidas podem ser usadas e quais rotas de sub-rede da VPC são anunciadas:
  - Regional: aprende e usa/importa rotas dinâmicas apenas na mesma região.
  - Global: aprende e usa/importa rotas dinâmicas em todas as regiões; anuncia todas as rotas de sub-rede da VPC (globais) para os peers.
Dedicated Interconnect e Partner Interconnect
- O Dedicated Interconnect fornece circuitos físicos de 10 Gbps ou 100 Gbps diretamente para o Google em uma instalação de colocation. Você obtém uma Letter of Authorization – Connecting Facility Assignment (LOA‑CFA) para habilitar os cross-connects. Crie anexos de VLAN (anexos de interconexão) que mapeiam tags 802.1Q para conectividade L3 regional associada a um Cloud Router.
- O Partner Interconnect fornece conectividade lógica por meio de um provedor de serviços. Você solicita os anexos de VLAN ao parceiro; a largura de banda é entregue na borda do parceiro. Ainda assim, associe os anexos ao Cloud Router para BGP.
- Redundância e SLA: Use dois anexos na mesma região, localizados em domínios de disponibilidade de borda distintos (e interconexões físicas distintas, quando aplicável) para alcançar SLAs mais altos (por exemplo, 99,99%). Um único anexo ou link reduz o SLA. Para o Partner Interconnect, o SLA geral também depende do parceiro.
Cross-connects e anexos de VLAN
- Cross-connects são as conexões físicas de fibra entre seu cage/equipamento e o cage do Google em uma meet-me room. Apresente a LOA-CFA ao seu provedor para concluí-los.
- Anexos de VLAN são a demarcação lógica L2 para uma região da VPC. Cada anexo:
  - Associa-se a exatamente uma VPC e região por meio de um Cloud Router.
  - É configurado em pares para redundância e ECMP.
  - Transporta apenas tráfego L3; sem extensão L2.

Exemplo curto:

Crie um Cloud Router e BGP para um anexo ou peer de HA VPN: gcloud compute routers create cr-us-east1 –region=us-east1 –network=my-vpc –asn=65010 gcloud compute routers add-bgp-peer cr-us-east1 –region=us-east1 –peer-name=onprem-peer1 –peer-asn=65020 –interface=if-1 –peer-ip-address=169.254.0.2 –advertise-mode=DEFAULT –enable-bfd

Roteamento e Comportamento do BGP

Roteamento dinâmico versus estático
- O roteamento dinâmico com o Cloud Router oferece aprendizado automático de rotas, convergência e ECMP. Ele escala e reduz a sobrecarga operacional à medida que as redes crescem.
- O roteamento estático é apropriado quando os peers não têm BGP ou para caminhos determinísticos e de escopo restrito. Na VPC, as rotas estáticas têm uma prioridade numérica; valores mais baixos são preferidos entre rotas estáticas para o mesmo comprimento de prefixo.
- Seleção de rota em uma VPC:
  - A correspondência de prefixo mais longo vence.
  - Rotas de sub-rede não podem ser sobrepostas por rotas personalizadas.
  - Para comprimentos de prefixo iguais, as rotas estáticas são selecionadas pela menor prioridade. Entre as rotas dinâmicas, o Cloud Router já resolveu os melhores caminhos antes de instalá-los. A rota padrão do sistema é a menos preferida.
Sessões BGP, anúncio (advertisement) e importação/exportação
- O Cloud Router exporta as sub-redes da VPC por padrão ou um conjunto personalizado de prefixos. Você pode anunciar 0.0.0.0/0 ou agregar prefixos quando necessário, mas fazer isso atrai o tráfego on-premise para a nuvem se as políticas permitirem; projete deliberadamente.
- O Cloud Router importa quaisquer prefixos on-premises permitidos e os instala como rotas dinâmicas de acordo com o modo de roteamento dinâmico da VPC.
- A prioridade de rota anunciada por peer permite que você influencie como os roteadores on-premise preferem um caminho do Google em detrimento de outro; um valor de prioridade mais baixo se traduz em um MED mais preferencial em direção ao peer.
ASNs, MED e ativo-standby
- Use um ASN privado exclusivo por domínio administrativo, a menos que ASNs públicos sejam justificados. Para múltiplos roteadores on-premise fazendo peering com a mesma VPC para os mesmos prefixos:
  - Para habilitar ECMP ou um melhor caminho consistente, use o mesmo ASN remoto on-premise em todos os roteadores que anunciam os mesmos prefixos. ASNs remotos diferentes podem impedir a instalação de custo igual no Cloud Router.
  - Para ativo/standby, manipule o MED (menor é mais preferido) do lado on-premise ou ajuste a prioridade de rota anunciada por peer do Cloud Router para que o on-premise prefira o primário. O AS-path prepending é uma alternativa, mas uma ferramenta mais grosseira.
Projeto de múltiplos caminhos (Multipath)
- O Cloud Router suporta ECMP em múltiplos caminhos BGP iguais tanto para anexos de HA VPN quanto de Interconnect. Garanta atributos iguais (comprimento do AS-path, MED, local-pref) e next hops distintos. Para HA VPN, termine os túneis em IPs de peer distintos. Para o Interconnect, use anexos redundantes.

Resiliência, Detecção e Serviços de Saída (Egress)

BFD e detecção de falhas
- O BFD acelera a detecção de falhas para sessões BGP em HA VPN e Interconnect. Habilite o BFD em ambos os lados com intervalos compatíveis para alcançar detecção em sub-segundos ou poucos segundos, conforme apropriado para suas necessidades de estabilidade. Combine com IKE DPD em túneis IPsec. Garanta que seus dispositivos peer possam processar o tráfego de controle mais frequente.
- Cuidado com a detecção assimétrica: BFD agressivo somado a links congestionados pode causar instabilidade nas sessões (flapping); comece com temporizadores conservadores e monitore.
Padrões de topologia redundante
- HA VPN: Use um gateway de HA VPN por região e termine os túneis em dois dispositivos ou interfaces on-premise distintos. Crie pelo menos quatro túneis (dois por interface) e um Cloud Router por região. Mantenha os ASNs remotos consistentes ao oferecer ECMP.
- Interconnect: Use pelo menos dois anexos (attachments) em cada região, em domínios de disponibilidade de borda (edge availability domains) distintos. Para o Dedicated Interconnect, implante os links em diferentes dispositivos e instalações de borda, quando possível.
Cloud NAT, endereços externos e saída de workloads privadas
- O Cloud NAT é um serviço de saída (egress) gerenciado e regional para recursos sem IPs externos. Ele não faz SNAT em instâncias que têm IPs externos; essas saem diretamente. Selecione sub-redes ou todas as sub-redes em uma região para cobrir as workloads privadas.
- Dimensione os pools de IPs do NAT para conexões simultâneas e portas efêmeras; escolha alocação de IP manual ou automática. Habilite o registro de logs (logging) para diagnóstico.
- Para acessar as APIs do Google de forma privada:
  - Na VPC: habilite o Private Google Access nas sub-redes para que VMs sem IPs externos possam acessar as APIs do Google por meio dos IPs virtuais do Google.
  - Do on-premise: use endpoints do Private Service Connect para as APIs do Google e DNS híbrido para que os clientes on-premise resolvam e acessem as APIs por links híbridos privados, evitando a internet.
- Se uma rota padrão aponta para um firewall de terceiros, mas você quer que as workloads privadas o contornem (bypass) para acessar as APIs do Google, use o Private Service Connect ou instale rotas estáticas de maior prioridade para os intervalos de IP publicados das APIs do Google em direção ao gateway de internet padrão, combinado com o Private Google Access nas sub-redes.
Integração de DNS híbrido
- Use zonas privadas do Cloud DNS para resolução de nomes dentro da VPC. Estenda para o on-premise com:
  - Encaminhamento de entrada (inbound): resolvedores on-premise encaminham para o Cloud DNS para zonas privadas hospedadas na VPC.
  - Encaminhamento de saída (outbound): resolvedores da VPC encaminham domínios selecionados para o DNS on-premise.
  - Zonas de peering para resolução entre VPCs em ambientes de VPC compartilhada (Shared VPC) ou de múltiplos projetos.
- Para acessibilidade privada de APIs, crie uma zona privada mapeando os hostnames das APIs para endpoints do Private Service Connect ou para os VIPs privados apropriados do Google ao usar o Private Google Access, e garanta que esses nomes sejam resolvíveis do on-premise por meio do encaminhamento de DNS.

Planejamento e Solução de Problemas

Trade-offs de largura de banda, latência e custo
- VPN: mais rápido de implantar, menor custo fixo, throughput por túnel limitado, maior overhead de CPU/criptografia por bit e latência tipicamente maior em comparação com links privados.
- Dedicated Interconnect: maior throughput e menor custo por bit com latência previsível; custos fixos e tempo de espera (cross-connects, colocation) mais altos.
- Partner Interconnect: um meio-termo; aproveita a presença do provedor; o SLA e a latência dependem do caminho do parceiro.
- Posicione os attachments e gateways regionalmente próximos das cargas de trabalho para minimizar a latência. Use o Shared VPC para centralizar a conectividade em um projeto host enquanto atende a vários projetos de serviço.
- Considere a simetria do tráfego, os requisitos de inspeção e os domínios de falha. Evite pontos únicos de falha no last-mile on-premise e nos caminhos do provedor.
Diagnóstico sistemático de problemas de túnel, BGP e roteamento
1. Estabelecimento do túnel
  - Verifique a compatibilidade da versão do IKE: o HA VPN requer IKEv2; se o peer suportar apenas IKEv1 ou VPN baseada em política (policy-based), use o Classic VPN.
  - Verifique os segredos compartilhados (shared secrets), as propostas (criptografia, grupos DH), o NAT-T e a alcançabilidade das portas UDP 500/4500.
  - Confirme os IPs do peer e que cada túnel aponta para uma interface de peer distinta para redundância.
2. Saúde da sessão BGP
  - Confirme os estados do BGP em ambas as pontas; examine o status do Cloud Router. Se o BFD estiver habilitado, mas as sessões oscilam (flap), relaxe os timers.
  - Valide a configuração do ASN; expectativas incompatíveis podem impedir o ECMP ou causar surpresas na escolha do melhor caminho (best-path).
  - Garanta que o endereçamento IP para as sessões BGP use os endereços link-local ou RFC1918 corretos configurados na interface do túnel ou do attachment.
3. Troca e propagação de rotas
  - Verifique o modo de anúncio (advertisement mode) do Cloud Router (DEFAULT vs CUSTOM). Certifique-se de que as sub-redes ou agregados esperados sejam exportados.
  - Inspecione as rotas recebidas no Cloud Router; avalie o AS-path e o MED. Se a intenção for um modo ativo/standby, garanta que o MED ou a prioridade da rota anunciada reflitam essa intenção.
  - Verifique o modo de roteamento dinâmico da VPC (REGIONAL vs GLOBAL) para que as rotas aprendidas apareçam onde for necessário. Lembre-se de que as rotas de sub-rede não podem ser sobrescritas.
  - Para conflitos, se uma rota estática e uma rota dinâmica corresponderem ao mesmo comprimento de prefixo, a rota estática com a menor prioridade prevalece. Ajuste ou remova rotas estáticas sobrepostas quando não for intencional.
4. Validação do plano de dados (data-plane)
  - Use os VPC Flow Logs e os logs do Cloud NAT para confirmar o caminho de saída (egress) e a tradução de endereços. Se uma VM ainda sair com seu IP externo, remova esse IP externo para forçar o uso do NAT.
  - Para o Interconnect, verifique o estado operacional do attachment e se ambos os attachments estão habilitados administrativamente (admin-enabled) e associados ao Cloud Router correto.
  - Confirme se as regras de firewall permitem o tráfego BGP e da aplicação; lembre-se de que os intervalos de origem das verificações de saúde (health check) do Google devem ter permissão para alcançar os backends do load balancer.
5. Especificidades da ativação do Interconnect
  - Obtenha a LOA-CFA no console ou pelo e-mail de contato do NOC. Confirme os níveis de luz do cross-connect e o tagueamento de VLAN com o provedor antes da ativação do BGP.

Cenário de Problema Prático

A Contoso Manufacturing está migrando cargas de trabalho de ERP para o Google Cloud, mantendo as fábricas on-premise online. Requisitos: conectividade privada de 20 Gbps com failover abaixo de um segundo, controle de roteamento centralizado, saída (egress) on-premise para a nuvem em modo ativo/standby, acesso privado às APIs do Google sem usar a internet pública e sobrecarga operacional (overhead) mínima.

Abordagem:

Implantar dois links de Dedicated Interconnect na mesma região metropolitana, em domínios de disponibilidade de borda (edge availability domains) e instalações distintas; criar dois VLAN attachments por região (primário e secundário) e associá-los a um Cloud Router regional.
- Justificativa: O Dedicated Interconnect entrega o throughput agregado necessário e a latência previsível. Links e attachments redundantes isolam falhas e se qualificam para um SLA mais alto. Múltiplos attachments permitem ECMP e manutenção sem perda de tráfego.
Configurar um único Cloud Router por região com dois peers BGP — um por attachment — e habilitar o BFD.
- Justificativa: Um único roteador simplifica o gerenciamento do plano de controle (control-plane), ao mesmo tempo que suporta ECMP sobre múltiplos next hops. O BFD reduz a detecção de falhas para poucos segundos, melhorando o RTO de convergência para a aplicação de ERP.
Padronizar o mesmo ASN remoto on-premise em ambos os roteadores de borda da fábrica que fazem peering com o Google e anunciar prefixos idênticos de cada um.
- Justificativa: ASNs remotos correspondentes permitem que o Cloud Router instale caminhos de custo igual (equal-cost paths) e faça o balanceamento de carga quando desejado. Se ASNs diferentes fossem usados, apenas um conjunto de rotas poderia ser instalado, inviabilizando o multipath.
Implementar a preferência ativo/standby do ambiente on-premise para o Google usando MED, e do Google para o on-premise usando a prioridade de rota anunciada do Cloud Router; definir valores mais baixos nos caminhos primários.
- Justificativa: A política de lado duplo (dual-sided) garante direcionalidade determinística: as fábricas preferem a região metropolitana primária para alcançar a nuvem, e a VPC da Contoso prefere o DC primário da fábrica para o tráfego de retorno. Isso evita assimetria não intencional.
Habilitar o Private Service Connect para as APIs do Google na VPC compartilhada (Shared VPC) e criar uma zona de DNS privado mapeando os hostnames das APIs para o endpoint do PSC; configurar o encaminhamento de entrada (inbound forwarding) do Cloud DNS para que os resolvers on-premise possam resolver esses nomes de forma privada.
- Justificativa: O PSC fornece acesso privado, dentro da VPC, às APIs do Google. O DNS híbrido torna esses endpoints alcançáveis a partir das fábricas através do Interconnect, eliminando a exposição à internet e as dependências de firewall para os serviços de suporte do ERP.
Para o backup com VPN, adicionar um gateway de HA VPN em cada região com dois túneis para dispositivos on-premise distintos; habilitar o BFD nas sessões BGP e permitir o ECMP.
- Justificativa: Se o Interconnect for prejudicado, o HA VPN mantém a alcançabilidade privada. Túneis duplos por dispositivo mantêm a continuidade do SLA e do throughput, e o BFD acelera o failover.
Para a saída (egress) de cargas de trabalho privadas para a internet e destinos que não são do Google, configure o Cloud NAT regional nas sub-redes do ERP; não atribua IPs externos às VMs.
- Justificativa: O Cloud NAT escala a tradução sem a sobrecarga de gerenciamento de VMs e preserva o endereçamento privado. A remoção de IPs externos garante que o NAT seja usado e simplifica os controles de saída (egress).
Validar o roteamento e o failover com testes em etapas: desconecte um attachment, depois um roteador on-premise e, em seguida, simule a degradação do link; monitore o BGP, o BFD e os SLOs da aplicação. Ajuste os timers do BFD se ocorrerem oscilações (flaps).
- Justificativa: A injeção de falhas controlada verifica se o design atende aos objetivos de recuperação e evita surpresas em produção. O ajuste dos timers equilibra estabilidade e capacidade de resposta.