Google PCNE: Conectividad híbrida, Cloud Router y BGP — Guía de estudio

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

Forma parte de la Google Professional Cloud Network Engineer — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Google, o realiza tests cronometrados en ExamRoll.io.

Descripción general

La conectividad híbrida en Google Cloud permite una comunicación privada y controlada entre redes VPC y redes externas, como centros de datos locales (on-premises) u otras nubes. Los componentes fundamentales son HA VPN y las puertas de enlace de Cloud VPN, Cloud Router con BGP para el enrutamiento dinámico, e Interconnect con adjuntos de VLAN. Los diseños deben equilibrar el ancho de banda, la latencia, la fiabilidad, la complejidad operativa y el coste, al tiempo que siguen un comportamiento de enrutamiento determinista y el aislamiento de dominios de error. Esta sección cubre el razonamiento de diseño y operativo, los modos de fallo comunes y la resolución sistemática de problemas.

Conectividad híbrida: HA VPN, Cloud Router e Interconnect

HA VPN y Cloud VPN
- HA VPN es una VPN IPsec regional de alta disponibilidad que admite IKEv2 y requiere Cloud Router para el enrutamiento dinámico (eBGP). Una puerta de enlace de HA VPN tiene dos interfaces; para el SLA y ECMP, construya dos túneles por interfaz hacia puntos finales de par distintos.
- Classic Cloud VPN admite IKEv1 o IKEv2 y túneles estáticos o basados en rutas; no es compatible con el SLA de HA VPN. Úselo solo cuando los pares no dispongan de BGP o deba usar selectores basados en políticas.
- La puerta de enlace de par (peer gateway) es el dispositivo/IP VPN remoto. Para HA VPN, defina una puerta de enlace de VPN de par con una o más IP públicas para modelar interfaces o dispositivos distintos para la redundancia.
- Diseño para el SLA: Para ser elegible para el SLA del 99,99 % de HA VPN, despliegue túneles redundantes a través de dispositivos o interfaces locales (on-premises) independientes y utilice enrutamiento dinámico. Classic VPN no está respaldado por un SLA.
- Escalado del rendimiento: Un único túnel IPsec tiene un rendimiento finito. Use ECMP a través de múltiples túneles para aumentar el rendimiento agregado. Consiga esto terminando túneles adicionales en IP públicas de par únicas.
Cloud Router y BGP
- Cloud Router es un servicio regional de plano de control que establece sesiones BGP con túneles VPN o adjuntos de VLAN de Interconnect e intercambia rutas dinámicamente.
- El modo de enrutamiento dinámico (a nivel de VPC) rige dónde se pueden usar las rutas dinámicas aprendidas y qué rutas de subred de la VPC se anuncian:
  - Regional: aprende y usa/importa rutas dinámicas solo en la misma región.
  - Global: aprende y usa/importa rutas dinámicas en todas las regiones; anuncia todas las rutas de subred de la VPC (globales) a los pares.
Dedicated Interconnect y Partner Interconnect
- Dedicated Interconnect proporciona circuitos físicos de 10 Gbps o 100 Gbps directamente a Google en una instalación de colocación (colocation). Usted obtiene una Carta de Autorización – Asignación de Instalación de Conexión (LOA‑CFA) para habilitar las interconexiones (cross-connects). Cree adjuntos de VLAN (interconnect attachments) que mapean etiquetas 802.1Q a una conectividad L3 regional asociada a un Cloud Router.
- Partner Interconnect proporciona conectividad lógica a través de un proveedor de servicios. Usted solicita los adjuntos de VLAN al socio; el ancho de banda se entrega en el borde (edge) del socio. Asocie igualmente los adjuntos a Cloud Router para BGP.
- Redundancia y SLA: Use dos adjuntos en la misma región ubicados en dominios de disponibilidad de borde (edge availability domains) distintos (y en interconexiones físicas distintas, cuando corresponda) para alcanzar SLAs más altos (p. ej., 99,99 %). Un solo adjunto o enlace reduce el SLA. Para Partner Interconnect, el SLA general también depende del socio.
Interconexiones (Cross‑connects) y adjuntos de VLAN
- Las interconexiones (cross-connects) son las conexiones físicas de fibra entre su jaula/equipo y la jaula de Google en una sala de interconexión (meet-me room). Presente la LOA‑CFA a su proveedor para completarlas.
- Los adjuntos de VLAN son la demarcación lógica L2 a una región de la VPC. Cada adjunto:
  - Se asocia exactamente a una VPC y una región a través de un Cloud Router.
  - Se configura en pares para redundancia y ECMP.
  - Transporta solo tráfico L3; sin extensión L2.

Ejemplo corto:

Crear un Cloud Router y BGP para un adjunto o un par 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

Comportamiento del enrutamiento y de BGP

Enrutamiento dinámico frente a estático
- El enrutamiento dinámico con Cloud Router proporciona aprendizaje automático de rutas, convergencia y ECMP. Escala y reduce la sobrecarga operativa a medida que crecen las redes.
- El enrutamiento estático es apropiado cuando los pares carecen de BGP o para rutas deterministas de alcance limitado. En una VPC, las rutas estáticas tienen una prioridad numérica; se prefieren los valores más bajos entre las rutas estáticas con la misma longitud de prefijo.
- Selección de rutas en una VPC:
  - Gana la coincidencia de prefijo más largo.
  - Las rutas de subred no pueden ser invalidadas por rutas personalizadas.
  - Para longitudes de prefijo iguales, las rutas estáticas se seleccionan por la prioridad más baja. Entre las rutas dinámicas, Cloud Router ya ha resuelto las mejores rutas antes de instalarlas. La ruta por defecto del sistema es la menos preferida.
Sesiones BGP, anuncio e importación/exportación
- Cloud Router exporta las subredes de la VPC por defecto o un conjunto personalizado de prefijos. Puede anunciar 0.0.0.0/0 o agregar prefijos cuando sea necesario, pero hacerlo atrae el tráfico local (on-prem) hacia la nube si las políticas lo permiten; diseñe de forma deliberada.
- Cloud Router importa cualquier prefijo local permitido y lo instala como ruta dinámica según el modo de enrutamiento dinámico de la VPC.
- La prioridad de ruta anunciada por par le permite influir en cómo los routers locales prefieren una ruta de Google sobre otra; un valor de prioridad más bajo se traduce en un MED más preferido hacia el par.
ASN, MED y configuración activo-en espera
- Use un ASN privado único por cada dominio administrativo, a menos que se justifique el uso de ASN públicos. Para múltiples routers locales que se conectan a la misma VPC para los mismos prefijos:
  - Para habilitar ECMP o una mejor ruta consistente, use el mismo ASN remoto local en todos los routers que anuncian los mismos prefijos. Diferentes ASN remotos pueden impedir la instalación de rutas de igual costo en Cloud Router.
  - Para una configuración activo/en espera, manipule el MED (el más bajo es más preferido) desde el lado local, o ajuste la prioridad de ruta anunciada por par de Cloud Router para que el entorno local prefiera la ruta principal. El AS-path prepending es una alternativa, pero una herramienta menos precisa.
Diseño de múltiples rutas (multipath)
- Cloud Router soporta ECMP a través de múltiples rutas BGP iguales tanto para HA VPN como para adjuntos de Interconnect. Asegúrese de que los atributos sean iguales (longitud de AS-path, MED, local-pref) y que los siguientes saltos sean distintos. Para HA VPN, termine los túneles en IP de pares distintas. Para Interconnect, use adjuntos redundantes.

Resiliencia, detección y servicios de egreso

BFD y detección de fallos
- BFD acelera la detección de fallos para las sesiones BGP en HA VPN e Interconnect. Habilite BFD en ambos lados con intervalos compatibles para lograr una detección por debajo del segundo o de pocos segundos, según sus necesidades de estabilidad. Combínelo con IKE DPD en túneles IPsec. Asegúrese de que sus dispositivos pares puedan procesar un tráfico de control más frecuente.
- Tenga cuidado con la detección asimétrica: un BFD agresivo junto con enlaces congestionados puede provocar intermitencias en las sesiones; comience con temporizadores conservadores y monitorice.
Patrones de topología redundante
- HA VPN: Use un gateway de HA VPN por región y termine los túneles en dos dispositivos o interfaces locales distintos. Construya al menos cuatro túneles (dos por interfaz) y un Cloud Router por región. Mantenga los ASN remotos consistentes cuando ofrezca ECMP.
- Interconnect: Use al menos dos adjuntos en cada región a través de distintos dominios de disponibilidad perimetral. Para Dedicated Interconnect, despliegue los enlaces en diferentes dispositivos e instalaciones perimetrales siempre que sea posible.
Cloud NAT, direcciones externas y egreso de cargas de trabajo privadas
- Cloud NAT es un servicio de egreso regional y gestionado para recursos sin IP externas. No aplica SNAT a las instancias que tienen IP externas; estas salen directamente. Seleccione subredes o todas las subredes de una región para cubrir las cargas de trabajo privadas.
- Dimensione las reservas de IP de NAT para las conexiones concurrentes y los puertos efímeros; elija la asignación de IP manual o automática. Habilite el registro para el diagnóstico.
- Para alcanzar las API de Google de forma privada:
  - Dentro de la VPC: habilite Private Google Access en las subredes para que las VM sin IP externas puedan alcanzar las API de Google a través de las IP virtuales de Google.
  - Desde el entorno local (on-prem): use Private Service Connect endpoints para las API de Google y DNS híbrido para que los clientes locales resuelvan y alcancen las API a través de enlaces híbridos privados, evitando internet.
- Si una ruta por defecto apunta a un firewall de terceros pero desea que las cargas de trabajo privadas lo omitan para acceder a las API de Google, use Private Service Connect o instale rutas estáticas de mayor prioridad para los rangos de IP publicados de las API de Google hacia el gateway de internet por defecto, combinado con Private Google Access en las subredes.
Integración de DNS híbrido
- Use zonas privadas de Cloud DNS para la resolución de nombres dentro de la VPC. Extiéndalo al entorno local con:
  - Reenvío de entrada: los resolutores locales reenvían a Cloud DNS para las zonas privadas alojadas en la VPC.
  - Reenvío de salida: los resolutores de la VPC reenvían dominios seleccionados al DNS local.
  - Zonas de peering para la resolución entre VPC en entornos de VPC compartida o multiproyecto.
- Para la accesibilidad privada a las API, cree una zona privada que asigne los nombres de host de las API a los endpoints de Private Service Connect o a las VIP privadas de Google apropiadas cuando use Private Google Access, y asegúrese de que esos nombres se puedan resolver desde el entorno local mediante el reenvío de DNS.

Planificación y resolución de problemas

Compensaciones entre ancho de banda, latencia y costo
- VPN: la más rápida de implementar, el costo fijo más bajo, rendimiento limitado por túnel, mayor sobrecarga de CPU/criptografía por bit y latencia típicamente más alta en comparación con los enlaces privados.
- Dedicated Interconnect: el mayor rendimiento y el menor costo por bit con latencia predecible; costos fijos más altos y mayor tiempo de entrega (cross-connects, colocación).
- Partner Interconnect: un punto intermedio; aprovecha la presencia del proveedor; el SLA y la latencia dependen de la ruta del socio.
- Ubique los adjuntos y las puertas de enlace regionalmente cerca de las cargas de trabajo para minimizar la latencia. Use Shared VPC para centralizar la conectividad en un proyecto anfitrión mientras atiende a múltiples proyectos de servicio.
- Considere la simetría del tráfico, los requisitos de inspección y los dominios de falla. Evite los puntos únicos de falla en la última milla local (on-prem) y en las rutas del proveedor.
Diagnóstico sistemático de problemas de túnel, BGP y enrutamiento
1. Establecimiento del túnel
  - Verifique la compatibilidad de la versión de IKE: HA VPN requiere IKEv2; si el par solo admite IKEv1 o VPN basada en políticas, use Classic VPN.
  - Revise los secretos compartidos, las propuestas (cifrado, grupos DH), NAT-T y la alcanzabilidad de los puertos UDP 500/4500.
  - Confirme las IP de los pares y que cada túnel apunte a una interfaz de par distinta para la redundancia.
2. Salud de la sesión BGP
  - Confirme los estados de BGP en ambos extremos; examine el estado de Cloud Router. Si BFD está habilitado pero las sesiones son intermitentes (flap), relaje los temporizadores.
  - Valide la configuración de ASN; expectativas no coincidentes pueden impedir ECMP o causar sorpresas en la selección de la mejor ruta.
  - Asegúrese de que el direccionamiento IP para las sesiones BGP utilice las direcciones link-local o RFC1918 correctas configuradas en la interfaz del túnel o del adjunto.
3. Intercambio y propagación de rutas
  - Revise el modo de anuncio de Cloud Router (DEFAULT vs. CUSTOM). Asegúrese de que se exporten las subredes o los agregados esperados.
  - Inspeccione las rutas recibidas en Cloud Router; evalúe el AS-path y el MED. Si se pretende una configuración activo/en espera (active/standby), asegúrese de que el MED o la prioridad de la ruta anunciada reflejen esa intención.
  - Verifique el modo de enrutamiento dinámico de la VPC (REGIONAL vs. GLOBAL) para que las rutas aprendidas aparezcan donde se necesiten. Recuerde que las rutas de subred no se pueden anular.
  - En caso de conflictos, si una ruta estática y una ruta dinámica coinciden en la misma longitud de prefijo, la ruta estática con la prioridad más baja gana. Ajuste o elimine las rutas estáticas superpuestas cuando no sea intencionado.
4. Validación del plano de datos
  - Use VPC Flow Logs y los registros de Cloud NAT para confirmar la ruta de egreso y la traducción de direcciones. Si una VM todavía sale con su IP externa, elimine esa IP externa para forzar el uso de NAT.
  - Para Interconnect, verifique el estado operativo del adjunto y que ambos adjuntos estén habilitados administrativamente y asociados al Cloud Router correcto.
  - Confirme que las reglas de firewall permitan el tráfico de BGP y de la aplicación; recuerde que se debe permitir que los rangos de origen de las verificaciones de estado de Google lleguen a los backends del balanceador de carga.
5. Detalles específicos de la puesta en marcha de Interconnect
  - Obtenga la LOA-CFA desde la consola o el correo electrónico de contacto del NOC. Confirme los niveles de luz del cross-connect y el etiquetado de VLAN con el proveedor antes de la puesta en marcha de BGP.

Escenario de problema práctico

Contoso Manufacturing está migrando cargas de trabajo de ERP a Google Cloud mientras mantiene en línea las fábricas locales (on-prem). Requisitos: 20 Gbps de conectividad privada con conmutación por error en menos de un segundo, control de enrutamiento centralizado, egreso activo/en espera (active/standby) desde el entorno local a la nube, acceso privado a las API de Google sin internet público y una sobrecarga operativa mínima.

Enfoque:

Desplegar dos enlaces de Dedicated Interconnect en la misma área metropolitana a través de distintos dominios de disponibilidad de borde e instalaciones; crear dos adjuntos de VLAN por región (primario y secundario) y asociarlos a un Cloud Router regional.
- Justificación: Dedicated Interconnect proporciona el rendimiento agregado requerido y una latencia predecible. Los enlaces y adjuntos redundantes aíslan las fallas y califican para un SLA más alto. Múltiples adjuntos permiten ECMP y mantenimiento sin pérdida de tráfico.
Configurar un único Cloud Router por región con dos pares BGP —uno por adjunto— y habilitar BFD.
- Justificación: Un único router simplifica la gestión del plano de control mientras sigue soportando ECMP sobre múltiples saltos siguientes. BFD reduce la detección de fallas a pocos segundos, mejorando el RTO de convergencia para la aplicación ERP.
Estandarizar el mismo ASN remoto local (on-prem) en ambos routers de borde de la fábrica que se conectan con Google, y anunciar prefijos idénticos desde cada uno.
- Justificación: Hacer coincidir los ASN remotos permite a Cloud Router instalar rutas de igual costo y balancear la carga cuando se desee. Si se usaran ASN diferentes, solo se podría instalar un conjunto de rutas, lo que anularía el uso de múltiples rutas (multipath).
Implementar la preferencia activo/en espera desde el entorno local a Google usando MED, y desde Google al entorno local usando la prioridad de ruta anunciada de Cloud Router; establecer valores más bajos en las rutas primarias.
- Justificación: Una política de doble lado asegura una direccionalidad determinista: las fábricas prefieren el área metropolitana primaria para llegar a la nube, y la VPC de Contoso prefiere el centro de datos primario de la fábrica para el tráfico de retorno. Esto evita una asimetría no deseada.
Habilitar Private Service Connect para las API de Google en la VPC compartida y crear una zona de DNS privada que mapee los nombres de host de las API al punto de conexión de PSC; configurar el reenvío de entrada de Cloud DNS para que los resolutores locales (on-prem) puedan resolver estos nombres de forma privada.
- Justificación: PSC proporciona acceso privado dentro de la VPC a las API de Google. El DNS híbrido hace que estos puntos de conexión sean alcanzables desde las fábricas a través de Interconnect, eliminando la exposición a internet y las dependencias de firewall para los servicios de soporte del ERP.
Para el respaldo con VPN, agregar una puerta de enlace HA VPN en cada región con dos túneles a dispositivos locales (on-prem) distintos; habilitar BFD en las sesiones BGP y permitir ECMP.
- Justificación: Si Interconnect se ve afectado, HA VPN mantiene la alcanzabilidad privada. Los túneles dobles por dispositivo mantienen la continuidad del SLA y del rendimiento, y BFD acelera la conmutación por error.
Para el egreso de cargas de trabajo privadas a internet y a destinos que no son de Google, configurar Cloud NAT regional en las subredes del ERP; no asignar IP externas a las VM.
- Justificación: Cloud NAT escala la traducción sin la sobrecarga de gestión de VM y preserva el direccionamiento privado. Eliminar las IP externas garantiza que se utilice NAT y simplifica los controles de egreso.
Validar el enrutamiento y la conmutación por error con pruebas por etapas: desconectar un adjunto, luego un router local (on-prem), y después simular la degradación del enlace; monitorear BGP, BFD y los SLO de la aplicación. Ajustar los temporizadores de BFD si ocurren intermitencias (flaps).
- Justificación: La inyección controlada de fallas verifica que el diseño cumple con los objetivos de recuperación y previene sorpresas en producción. Ajustar los temporizadores equilibra la estabilidad y la capacidad de respuesta.