Google PCNE: Enrutamiento, Network Connectivity Center y segmentación — 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

Esta sección explica el enrutamiento, Network Connectivity Center (NCC) y los patrones de segmentación en Google Cloud. Se centra en cómo se crean y seleccionan las rutas, cómo interconectar VPC y organizaciones preservando el aislamiento, cómo construir diseños escalables de tránsito e inserción de servicios, y cómo validar y contener fallos.

Fundamentos y control del enrutamiento

• Tipos de rutas

  • Rutas de subred generadas por el sistema: una por cada rango de subred principal y secundario; siempre son las más preferidas por sus prefijos exactos.
  • Ruta predeterminada a la puerta de enlace de internet: se crea automáticamente en las VPC nuevas; se puede eliminar o anular.
  • Rutas estáticas: prefijos personalizados con saltos siguientes (next hops) como la puerta de enlace de internet predeterminada, una instancia específica, un balanceador de cargas TCP/UDP interno (ILB) como salto siguiente o un túnel de Cloud VPN. Las rutas basadas en políticas añaden condiciones de coincidencia (etiquetas, cuentas de servicio, protocolo/puerto) y dirigen el tráfico a una instancia o un ILB como salto siguiente para la inserción de servicios avanzada.
  • Rutas dinámicas: aprendidas a través de Cloud Router sobre BGP desde Cloud VPN o Cloud Interconnect. Su alcance está controlado por el modo de enrutamiento dinámico de la VPC (regional o global).

• Selección de ruta

  • Primero, la coincidencia de prefijo más largo.
  • Si varias rutas tienen la misma longitud de prefijo, gana la prioridad de ruta con el número más bajo (el valor predeterminado es 1000 para las rutas personalizadas). Evite las superposiciones de prefijos iguales entre rutas estáticas y dinámicas; diseñe para preferir una de forma inequívoca.
  • Los empates más allá de la prioridad se resuelven mediante mecanismos de desempate internos de la plataforma; no confíe en ellos.

• Opciones de salto siguiente e inserción de servicios

  • Para centralizar la salida (egress) o insertar servicios L3/L7, apunte una ruta estática 0.0.0.0/0 o rutas basadas en políticas a un ILB como salto siguiente (next hop) cuyos backends sean dispositivos virtuales de red (NVA).
  • Cuando las instancias sin IP externas deban omitir los dispositivos para acceder a las API de Google, habilite Private Google Access en las subredes y añada rutas estáticas personalizadas para los rangos VIP de las API de Google publicadas hacia la puerta de enlace de internet predeterminada. Esto preserva el acceso privado a los servicios de Google mientras que el resto del tráfico de salida sigue la ruta del NGFW.

• Modo de enrutamiento dinámico y comportamiento multirregional

  • Regional: las rutas aprendidas por un Cloud Router se instalan solo para las subredes de la misma región.
  • Global: las rutas aprendidas en cualquier lugar se instalan para todas las regiones de la VPC, lo que permite una conectividad multirregional sencilla y reduce la sobrecarga operativa para los diseños de tipo hub-and-spoke. Para los usuarios y las cargas de trabajo cerca de us-east1 y europe-west1, una única VPC con subredes regionales y enrutamiento dinámico global les permite comunicarse de forma privada sobre RFC1918 con una eficiencia óptima.

• Control del anuncio de rutas

  • Cloud Router puede anunciar todas las subredes o un conjunto personalizado de prefijos (incluida una ruta predeterminada) al entorno on-premises. Controle la selección de la ruta de entrada desde on-prem utilizando herramientas BGP estándar (MED, AS-path prepending, local preference en on-prem). Para una configuración activo/en espera (active/standby) hacia on-prem, establezca un MED más bajo en la ruta principal y un MED más alto en la de respaldo.
  • Evite anunciar el mismo prefijo desde diferentes peers on-prem con distintos ASN al mismo Cloud Router; para un ECMP de doble conexión (dual-homed) o una conmutación por error (failover) limpia, utilice el mismo ASN de peer en los routers on-prem redundantes.

Interconectividad y segmentación de VPC

• VPC Network Peering

  • Permite la conectividad privada RFC1918 entre VPC con baja latencia y sin dispositivos en el plano de datos. Intercambia rutas de subred por defecto y, opcionalmente, puede importar/exportar rutas personalizadas (estáticas y dinámicas) para extender la alcanzabilidad a recursos detrás de Cloud VPN/Interconnect. No hay enrutamiento transitivo: las rutas aprendidas de un peer no se reexportan a otro peer.
  • Modos de fallo y límites: no se permiten CIDR superpuestos; las reglas de firewall permanecen independientes por cada VPC; el ancho de banda es alto pero no sustituye a los balanceadores de cargas; no se admite el enrutamiento asimétrico a través de un peering en malla. Para conectar tres VPC en un triángulo, configure una malla completa de pares de peering; Ventas↔Finanzas y Marketing↔Finanzas no habilitan la conexión Ventas↔Marketing a menos que ese par también esté conectado por peering.
  • Planificación de direcciones: al hacer peering con una VPC en modo automático (que reserva 10.128.0.0/9), cree el peer en modo personalizado con un CIDR que no se superponga, como 10.0.0.0/9.

• Shared VPC y conectividad multiproyecto

  • Un proyecto host es el propietario de la VPC; los proyectos de servicio se adjuntan a subredes seleccionadas. Esto centraliza las redes y la conectividad híbrida (Cloud Routers, Cloud NAT, Interconnect) a la vez que permite la propiedad delegada de las aplicaciones por proyecto. Ubique las VLAN attachments y los Cloud Routers para Dedicated Interconnect en el proyecto host para proporcionar una conectividad on-prem centralizada y rentable a todos los proyectos de servicio.
  • Mínimo privilegio: los administradores de red (Network Admins) gestionan el enrutamiento y las subredes; los administradores de seguridad (Security Admins) gestionan las reglas y políticas de firewall. Si no puede actualizar los firewalls con el rol de Network Admin, solicite el rol de Security Admin en el ámbito de la Shared VPC.
  • Segmentación: comparta solo las subredes específicas que requiere un proyecto de servicio. Esto se alinea con las mejores prácticas de Google para controlar estrictamente la exposición de rutas entre Producción y Staging.

• Controles de aislamiento de red

  • Límites de la VPC: no hay enrutamiento entre VPC sin un peering explícito, VPN o Private Service Connect. Utilice VPC separadas para departamentos o inquilinos (tenants) que deban estar completamente aislados; haga peering solo con aquellos que necesiten conectividad para minimizar la sobrecarga operativa.
  • Políticas de firewall: utilice políticas de firewall jerárquicas a nivel de organización/carpeta para tener barreras de protección (guardrails) consistentes y reglas por VPC para excepciones locales. La configuración predeterminada de denegación de entrada (ingress) y permiso de salida (egress) se puede hacer más estricta.
  • Perímetros: utilice VPC Service Controls para restringir el acceso a las API de Google y mitigar los riesgos de exfiltración de datos entre proyectos y redes.
  • Exposición de IPv6: para el acceso público a IPv6, asigne IPv6 a un balanceador de cargas HTTP(S) externo y global que actúe como frontend de su servicio. Los backends permanecen privados.

Network Connectivity Center y arquitecturas de tránsito

• Hub-and-spoke con NCC

  • El hub proporciona un plano de control para el enrutamiento entre los spokes. Los spokes incluyen adjuntos de VLAN (Interconnect), túneles de HA VPN, spokes de dispositivo de router y spokes de VPC compatibles para la transferencia de datos de sitio a sitio. Las tablas de rutas de NCC controlan qué prefijos se importan/exportan y qué spokes los reciben, permitiendo una segmentación precisa.
  • La transferencia de datos de sitio a sitio permite que los sitios on-prem se comuniquen entre sí a través de la red troncal de Google usando el hub como tránsito, lo que reduce la necesidad de tránsito de terceros y simplifica las operaciones.

• Spokes de dispositivo de router y NVA de terceros

  • Los spokes de dispositivo de router incorporan routers/firewalls virtuales alojados en Compute Engine como servicios de tránsito o en línea. Usa ILB como siguiente salto para lograr escalabilidad y conmutación por error con comprobación de estado entre múltiples dispositivos.
  • Diseño de alta disponibilidad (HA): Despliega al menos dos dispositivos en zonas diferentes; colócalos detrás de un ILB con un MIG cuando sea posible; habilita el reenvío de IP en las instancias; usa direccionamiento simétrico con ILB como siguiente salto; distribuye la carga usando rutas basadas en políticas según etiquetas o cuentas de servicio.
  • Compensaciones de rendimiento y fallos: Los NVA están limitados por el tipo de instancia y el ancho de banda de la NIC; planifica para una escalabilidad horizontal. Un fallo del dispositivo o de la comprobación de estado desencadena la eliminación del ILB y una conmutación por error rápida, pero asegúrate de que los temporizadores de convergencia de rutas y los umbrales de estado estén ajustados para evitar inestabilidad (flaps).

• Compensaciones de topologías de tránsito

  • Hub-and-spoke con NCC: Política centralizada, alta escalabilidad, control claro del radio de impacto; requiere diseño de tablas de rutas e intención de importación/exportación.
  • Peering de malla completa: Simple para un número reducido de VPC, sin tránsito central, pero escala mal y no puede proporcionar transitividad ni inserción de servicios.
  • Salida centralizada: Aplicación de seguridad simple a través de un NGFW o NAT único; puede añadir latencia y convertirse en un cuello de botella; mitígalo con puntos de salida regionales y autoescalado.
  • VPN en malla con Cloud Routers: Flexible y rápido de desplegar; la sobrecarga operativa aumenta con el número de peers; considera usar NCC para consolidar.

• Consideraciones sobre Cloud VPN

  • Si el dispositivo on-prem no tiene BGP, usa Cloud VPN basada en políticas con rutas estáticas y selectores de tráfico cuidadosamente definidos; planifica una migración eventual a HA VPN con BGP para minimizar la sobrecarga a largo plazo.
  • Para túneles activo/en espera hacia el entorno on-prem, manipula el MED o el AS-path en el lado on-prem.
  • Para routers on-prem duales que se conectan a un único Cloud Router, prefiere ASNs de peer idénticos para permitir la instalación de ambas rutas y ECMP; usar ASNs de peer diferentes comúnmente resulta en que solo se seleccione una ruta.

Operaciones: validación, análisis y contención de interrupciones

• Validación de conectividad y análisis de rutas

  • Usa Connectivity Tests de Network Intelligence Center para trazar la ruta de datos a través de VMs, balanceadores de carga, VPC peering, Cloud VPN e Interconnect, validando reglas de firewall y rutas.
  • Analiza las rutas efectivas por VM/subred para confirmar los siguientes saltos y prefijos dinámicos; verifica que el alcance del modo de enrutamiento dinámico se alinee con la intención.
  • Para problemas de rendimiento o de experiencia de usuario, prefiere el balanceo de carga global HTTP(S) para reducir la latencia para usuarios de todo el mundo a través de ingreso anycast y terminación en el borde; los balanceadores de carga de red son regionales y no mejoran la latencia global.

• Contención de interrupciones y reducción del radio de impacto

  • Segmenta por VPCs, tablas de rutas de NCC y subredes de Shared VPC por proyecto para prevenir la propagación no intencionada de fallos o configuraciones erróneas.
  • Evita las dependencias transitivas a través de peering; donde se requiera tránsito, usa NCC y una importación/exportación controlada para restringir la alcanzabilidad.
  • Usa políticas de firewall centralizadas a nivel de organización para denegaciones/permisos base y políticas locales para excepciones de aplicaciones; prueba los cambios con Connectivity Tests.
  • Donde se requiera seguridad en línea, despliega un ILB de siguiente salto con health checks y enrutamiento basado en políticas para una conmutación por error controlada (graceful failover). Asegúrate de que las APIs críticas de Google sean alcanzables a través de Private Google Access o Cloud NAT sin depender de IPs externas.
  • Monitorea las sesiones BGP y los cambios de ruta; estandariza las métricas (MED, local preference) y los planes de direccionamiento para evitar la oscilación de rutas y los flujos asimétricos.

• Ejemplos cortos de configuración

  • Crear una ruta estática para dirigir el tráfico a través de un ILB en línea:
    • gcloud compute routes create egress-via-ngfw –network my-vpc –destination-range 0.0.0.0/0 –next-hop-ilb ngfw-ilb –priority 900
  • Preferir una de dos rutas BGP de entrada hacia on-prem usando MED (en el router on-prem):
    • route-map FROM_GCP permit 10
    • set metric 20
    • router bgp 65000
    • neighbor 169.254.x.y route-map FROM_GCP in

Escenario de Problema Práctico

Acme Retail opera en una organización de Google Cloud multiproyecto con dos poblaciones de usuarios cerca de us-east1 y europe-west1. Necesitan comunicación privada y de bajo costo entre cargas de trabajo a través de regiones, conectividad on-prem centralizada y filtrado de URL en línea para el egreso a internet, manteniendo a la vez al departamento de Finanzas aislado del de Ingeniería.

1. Construir una única Shared VPC en un proyecto host con subredes regionales en us-east1 y europe-west1, y establecer el modo de enrutamiento dinámico en global.

• Justificación: Una sola VPC permite la comunicación directa RFC1918 entre regiones sin la sobrecarga del peering. El enrutamiento dinámico global instala las rutas híbridas aprendidas en todas las regiones, simplificando las operaciones y asegurando flujos eficientes dentro de la VPC.

2. Compartir solo las subredes requeridas con cada proyecto de servicio; ubicar Finanzas e Ingeniería en proyectos de servicio separados.

• Justificación: Compartir a nivel de subred proporciona segmentación organizacional y minimiza la exposición no intencionada de rutas. Finanzas permanece aislado simplemente al no compartir las subredes de Ingeniería y mediante alcances de políticas de firewall separados.

3. Terminar Dedicated Interconnect en el proyecto host y adjuntar Cloud Routers; anunciar solo los prefijos necesarios usando anuncios personalizados (custom advertisements).

• Justificación: La conectividad híbrida centralizada reduce el costo y la complejidad, manteniendo el control sobre lo que llega a on-prem. Los anuncios personalizados previenen la sobreexposición y contienen el radio de impacto.

4. Insertar un appliance de filtrado de URL L7 en línea detrás de un balanceador de carga interno TCP/UDP regional; dirigir el egreso con una ruta estática 0.0.0.0/0 hacia el ILB como siguiente salto en cada región.

• Justificación: El siguiente salto a un ILB junto con health checks proporciona inserción de servicios de alta disponibilidad (HA) con flujos simétricos a través de los appliances. Las rutas estáticas con mayor prioridad que la predeterminada aseguran que todo el egreso sea filtrado.

5. Asegurar que las instancias sin IP externas puedan alcanzar las APIs de Google directamente: habilitar Private Google Access en todas las subredes y agregar rutas estáticas para los rangos VIP de las APIs de Google hacia el default internet gateway para omitir el appliance.

• Justificación: Private Google Access preserva el acceso privado a BigQuery y Pub/Sub; las rutas personalizadas evitan el hairpinning innecesario a través del filtro, reduciendo costos y latencia.

6. Mantener a Finanzas aislado: denegar el tráfico entre proyectos en las políticas de firewall jerárquicas y no configurar peering entre Finanzas e Ingeniería. Donde se necesite colaboración entre Ingeniería y Analítica, crear un par de VPCs dedicadas con peering y CIDRs que no se superpongan.

• Justificación: Los límites de la VPC, la ausencia de peering y las políticas de firewall a nivel de organización imponen el aislamiento. El peering específico ofrece una baja sobrecarga operativa para la conectividad departamental específica sin transitividad.

7. Validar y monitorear: usar Connectivity Tests para verificar la alcanzabilidad entre regiones y la inserción del appliance; monitorear la salud de BGP de Cloud Router y las tablas de rutas; implementar MED en los routers on-prem para una conmutación por error activo/pasivo (active/standby) si existen múltiples túneles.

• Justificación: La validación proactiva detecta configuraciones erróneas de forma temprana. Los controles de BGP mantienen las rutas on-prem determinísticas durante mantenimientos o fallos, mientras que la telemetría de NCC/Cloud Router acelera la resolución de problemas.

Este diseño cumple con los requisitos de Acme Retail con un costo mínimo y alta eficiencia: enrutamiento privado multirregional en una sola VPC, conectividad híbrida centralizada, inserción de servicios controlada y una fuerte segmentación organizacional.

← Conectividad privada a Google y servicios administrados · Todos los dominios · GKE →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →

Explorar Google →