Google PCNE: Hybrid Connectivity, Cloud Router and BGP — Study Guide

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

Part of the Google Professional Cloud Network Engineer — Study Guide. Practice with verified answers in the Google exam hub, or take timed practice tests on ExamRoll.io.

Overview

Hybrid connectivity on Google Cloud enables private, controlled communication between VPC networks and external networks such as on-premises data centers or other clouds. Core building blocks are HA VPN and Cloud VPN gateways, Cloud Router with BGP for dynamic routing, and Interconnect with VLAN attachments. Designs must balance bandwidth, latency, reliability, operational complexity, and cost while following deterministic routing behavior and failure-domain isolation. This section covers design and operational reasoning, common failure modes, and systematic troubleshooting.

Hybrid Connectivity: HA VPN, Cloud Router, and Interconnect

HA VPN and Cloud VPN
- HA VPN is a regional, highly available IPsec VPN that supports IKEv2 and requires Cloud Router for dynamic routing (eBGP). An HA VPN gateway has two interfaces; for SLA and ECMP, build two tunnels per interface to distinct peer endpoints.
- Classic Cloud VPN supports IKEv1 or IKEv2 and static or route-based tunnels; it does not support the HA VPN SLA. Use it only when peers lack BGP or you must use policy-based selectors.
- Peer gateway is the remote VPN device/IP. For HA VPN, define a peer VPN gateway with one or more public IPs to model distinct interfaces or devices for redundancy.
- SLA design: To be eligible for the HA VPN 99.99% SLA, deploy redundant tunnels across independent on-premises devices or interfaces and use dynamic routing. Classic VPN is not SLA-backed.
- Throughput scaling: A single IPsec tunnel has finite throughput. Use ECMP across multiple tunnels to increase aggregate throughput. Achieve this by terminating additional tunnels on unique peer public IPs.
Cloud Router and BGP
- Cloud Router is a regional control-plane service that establishes BGP sessions with VPN tunnels or Interconnect VLAN attachments and exchanges routes dynamically.
- Dynamic routing mode (VPC-level) governs where learned dynamic routes are usable and which VPC subnet routes get advertised:
  - Regional: learn and use/import dynamic routes only in the same region.
  - Global: learn and use/import dynamic routes across all regions; advertise all VPC subnet routes (global) to peers.
Dedicated Interconnect and Partner Interconnect
- Dedicated Interconnect provides physical 10 Gbps or 100 Gbps circuits directly to Google in a colocation facility. You obtain a Letter of Authorization – Connecting Facility Assignment (LOA‑CFA) to enable cross‑connects. Create VLAN attachments (interconnect attachments) that map 802.1Q tags to regional L3 connectivity associated to a Cloud Router.
- Partner Interconnect provides logical connectivity via a service provider. You request VLAN attachments from the partner; bandwidth is delivered on the partner’s edge. Still associate attachments to Cloud Router for BGP.
- Redundancy and SLA: Use two attachments in the same region placed on distinct edge availability domains (and distinct physical interconnects, when applicable) to reach higher SLAs (e.g., 99.99%). A single attachment or link reduces SLA. For Partner Interconnect, overall SLA also depends on the partner.
Cross‑connects and VLAN attachments
- Cross‑connects are the physical fiber connections between your cage/equipment and Google’s cage at a meet‑me room. Present the LOA‑CFA to your provider to complete them.
- VLAN attachments are the logical L2 demarcation to a VPC region. Each attachment:
  - Associates to exactly one VPC and region via a Cloud Router.
  - Is configured in pairs for redundancy and ECMP.
  - Carries only L3 traffic; no L2 extension.

Short example:

Create Cloud Router and BGP for an attachment or HA VPN peer: 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

Routing and BGP Behavior

Dynamic versus static routing
- Dynamic routing with Cloud Router provides automatic route learning, convergence, and ECMP. It scales and reduces operational overhead as networks grow.
- Static routing is appropriate when peers lack BGP or for narrowly scoped, deterministic paths. In VPC, static routes have a numeric priority; lower values are preferred among static routes to the same prefix length.
- Route selection in a VPC:
  - Longest prefix match wins.
  - Subnet routes cannot be overridden by custom routes.
  - For equal prefix lengths, static routes are selected by lowest priority. Among dynamic routes, Cloud Router has already resolved best paths before installing them. The system default route is least preferred.
BGP sessions, advertisement, and import/export
- Cloud Router exports VPC subnets by default or a custom set of prefixes. You can advertise 0.0.0.0/0 or aggregate prefixes when needed, but doing so pulls on-prem traffic toward Cloud if policies allow; design deliberately.
- Cloud Router imports any allowed on-premises prefixes and installs them as dynamic routes according to the VPC dynamic routing mode.
- Per‑peer advertised route priority lets you bias how on‑prem routers prefer one Google path over another; lower priority value translates to more preferred MED toward the peer.
ASNs, MED, and active‑standby
- Use a unique private ASN per administrative domain unless public ASNs are warranted. For multiple on‑prem routers peering to the same VPC for the same prefixes:
  - To enable ECMP or consistent best‑path, use the same on‑prem remote ASN on all routers advertising the same prefixes. Different remote ASNs can prevent equal‑cost installation on Cloud Router.
  - For active/standby, manipulate MED (lower is more preferred) from the on‑prem side, or adjust Cloud Router’s per‑peer advertised route priority so on‑prem prefers the primary. AS‑path prepending is an alternative but coarser tool.
Multipath design
- Cloud Router supports ECMP across multiple equal BGP paths for both HA VPN and Interconnect attachments. Ensure equal attributes (AS‑path length, MED, local‑pref) and distinct next hops. For HA VPN, terminate tunnels on distinct peer IPs. For Interconnect, use redundant attachments.

Resilience, Detection, and Egress Services

BFD and failure detection
- BFD accelerates failure detection for BGP sessions on HA VPN and Interconnect. Enable BFD on both sides with compatible intervals to achieve sub‑second or low‑second detection, as appropriate for your stability needs. Combine with IKE DPD on IPsec tunnels. Ensure your peer devices can process more frequent control traffic.
- Beware of asymmetric detection: aggressive BFD plus congested links can flap sessions; start with conservative timers and monitor.
Redundant topology patterns
- HA VPN: Use one HA VPN gateway per region and terminate tunnels to two distinct on‑prem devices or interfaces. Build at least four tunnels (two per interface) and a Cloud Router per region. Keep remote ASNs consistent when offering ECMP.
- Interconnect: Use at least two attachments in each region across distinct edge availability domains. For Dedicated Interconnect, deploy links in different edge devices and facilities where possible.
Cloud NAT, external addresses, and private‑workload egress
- Cloud NAT is regional, managed egress for resources without external IPs. It does not SNAT instances that have external IPs; those egress directly. Select subnets or all subnets in a region to cover private workloads.
- Size NAT IP pools for concurrent connections and ephemeral ports; choose manual or automatic IP allocation. Enable logging for diagnosis.
- To reach Google APIs privately:
  - In‑VPC: enable Private Google Access on subnets so VMs without external IPs can reach Google APIs via Google’s virtual IPs.
  - From on‑prem: use Private Service Connect endpoints for Google APIs and hybrid DNS so on‑prem clients resolve and reach APIs over private hybrid links, avoiding internet.
- If a default route points to a third‑party firewall but you want private workloads to bypass it for Google APIs, either use Private Service Connect or install higher‑priority static routes for published Google API IP ranges to the default internet gateway, combined with Private Google Access on the subnets.
Hybrid DNS integration
- Use Cloud DNS private zones for in‑VPC name resolution. Extend to on‑prem with:
  - Inbound forwarding: on‑prem resolvers forward to Cloud DNS for VPC‑hosted private zones.
  - Outbound forwarding: VPC resolvers forward selected domains to on‑prem DNS.
  - Peering zones for cross‑VPC resolution in Shared VPC or multi‑project environments.
- For private API reachability, create a private zone mapping API hostnames to Private Service Connect endpoints or to the appropriate Google private VIPs when using Private Google Access, and ensure those names are resolvable from on‑prem via DNS forwarding.

Planning and Troubleshooting

Bandwidth, latency, and cost trade‑offs
- VPN: fastest to deploy, lowest fixed cost, limited per‑tunnel throughput, higher per‑bit CPU/crypto overhead and typically higher latency vs. private links.
- Dedicated Interconnect: highest throughput and lowest per‑bit cost with predictable latency; higher fixed costs and lead time (cross‑connects, colocation).
- Partner Interconnect: middle ground; leverages provider footprint; SLA and latency depend on the partner’s path.
- Place attachments and gateways regionally close to workloads to minimize latency. Use Shared VPC to centralize connectivity in a host project while serving multiple service projects.
- Consider traffic symmetry, inspection requirements, and failure domains. Avoid single points of failure in on‑prem last‑mile and provider paths.
Systematic diagnosis of tunnel, BGP, and routing issues
1. Tunnel establishment
  - Verify IKE version compatibility: HA VPN requires IKEv2; if the peer only supports IKEv1 or policy‑based VPN, use Classic VPN.
  - Check shared secrets, proposals (encryption, DH groups), NAT‑T, and UDP ports 500/4500 reachability.
  - Confirm peer IPs and that each tunnel points to a distinct peer interface for redundancy.
2. BGP session health
  - Confirm BGP states on both ends; examine Cloud Router status. If BFD is enabled but sessions flap, relax timers.
  - Validate ASN configuration; mismatched expectations can prevent ECMP or cause best‑path surprises.
  - Ensure IP addressing for BGP sessions uses the correct link‑local or RFC1918 addresses configured on the tunnel or attachment interface.
3. Route exchange and propagation
  - Check Cloud Router advertisement mode (DEFAULT vs CUSTOM). Make sure expected subnets or aggregates are exported.
  - Inspect received routes on Cloud Router; evaluate AS‑path, MED. If active/standby is intended, ensure MED or advertised route priority reflect that intent.
  - Verify VPC dynamic routing mode (REGIONAL vs GLOBAL) so learned routes appear where needed. Remember subnet routes cannot be overridden.
  - For conflicts, if a static route and a dynamic route match the same prefix length, the static route with lowest priority wins. Adjust or remove overlapping statics when unintended.
4. Data‑plane validation
  - Use VPC Flow Logs and Cloud NAT logs to confirm egress path and address translation. If a VM still egresses with its external IP, remove that external IP to force NAT.
  - For Interconnect, verify attachment operational state and that both attachments are admin‑enabled and associated to the correct Cloud Router.
  - Confirm firewall rules permit BGP and application traffic; remember Google health check source ranges must be allowed to reach load balancer backends.
5. Interconnect turn‑up specifics
  - Obtain LOA‑CFA from the console or NOC contact email. Confirm cross‑connect light levels and VLAN tagging with the provider before BGP turn‑up.

Practical Problem Scenario

Contoso Manufacturing is migrating ERP workloads to Google Cloud while keeping on‑prem factories online. Requirements: 20 Gbps private connectivity with sub‑second failover, centralized routing control, active/standby on‑prem egress to Cloud, private access to Google APIs without public internet, and minimal operational overhead.

Approach:

Deploy two Dedicated Interconnect links in the same metro across distinct edge availability domains and facilities; create two VLAN attachments per region (primary and secondary) and associate them to a regional Cloud Router.
- Rationale: Dedicated Interconnect delivers the required aggregate throughput and predictable latency. Redundant links and attachments isolate failures and qualify for higher SLA. Multiple attachments enable ECMP and maintenance without traffic loss.
Configure a single Cloud Router per region with two BGP peers—one per attachment—and enable BFD.
- Rationale: A single router simplifies control‑plane management while still supporting ECMP over multiple next hops. BFD reduces failure detection to low seconds, improving convergence RTO for the ERP application.
Standardize on the same on‑prem remote ASN on both factory edge routers that peer to Google, and advertise identical prefixes from each.
- Rationale: Matching remote ASNs allows Cloud Router to install equal‑cost paths and load‑balance when desired. If different ASNs were used, only one set of routes might be installed, defeating multipath.
Implement active/standby preference from on‑prem to Google using MED, and from Google to on‑prem using Cloud Router’s advertised route priority; set lower values on the primary paths.
- Rationale: Dual‑sided policy ensures deterministic directionality: factories prefer the primary metro to reach Cloud, and Contoso’s VPC prefers the primary factory DC for return traffic. This avoids unintended asymmetry.
Enable Private Service Connect for Google APIs in the shared VPC and create a private DNS zone mapping API hostnames to the PSC endpoint; configure Cloud DNS inbound forwarding so on‑prem resolvers can resolve these names privately.
- Rationale: PSC provides private, in‑VPC access to Google APIs. Hybrid DNS makes these endpoints reachable from factories over Interconnect, eliminating internet exposure and firewall dependencies for ERP’s supporting services.
For VPN backup, add an HA VPN gateway in each region with two tunnels to distinct on‑prem devices; enable BFD on BGP sessions and allow ECMP.
- Rationale: If Interconnect is impaired, HA VPN maintains private reachability. Dual tunnels per device maintain SLA and throughput continuity, and BFD speeds failover.
For private workload egress to the internet and non‑Google destinations, configure regional Cloud NAT on ERP subnets; do not assign external IPs to the VMs.
- Rationale: Cloud NAT scales translation without VM management overhead and preserves private addressing. Removing external IPs guarantees that NAT is used and simplifies egress controls.
Validate routing and failover with staged tests: pull one attachment, then one on‑prem router, then simulate link degradation; monitor BGP, BFD, and application SLOs. Tune BFD timers if flaps occur.
- Rationale: Controlled fault injection verifies that the design meets recovery objectives and prevents surprises in production. Adjusting timers balances stability and responsiveness.