Configuring hybrid and multicloud connectivity

Choosing a connection type

Rules of thumb: Interconnect for sustained, predictable, high bandwidth; VPN for quick, low-cost or backup; Partner when you cannot reach a colocation facility; Cross-Cloud when the other end is a cloud. Interconnect traffic reaches only your VPC private addresses and Google APIs via private access; it does not give you internet egress for VMs.

Dedicated Interconnect

1. Order the connection in a colocation facility that is in a metro near your data centre (or use cross-connects from your facility). Google emails a Letter of Authorization and Connecting Facility Assignment (LOA-CFA); give it to the colocation provider so they connect your router to Google’s edge.
2. Google tests for light and LACP, and the connection goes active. Circuits are bundled with LACP. A connection of two or more links raises capacity and resiliency.
3. Create one or more VLAN attachments (also called interconnect attachments), each tied to a Cloud Router in a VPC and a region. The attachment capacity is 50 Mbps up to 50 Gbps. Each attachment forms a BGP session between your router and Cloud Router over an 802.1q VLAN.
4. Configure BGP on your router using the attachment’s link-local address pair and ASN.

Points tested: Dedicated needs a physical presence or cross-connect in a Google-supported colocation facility; each VLAN attachment belongs to one region (the region of its Cloud Router), but global dynamic routing lets one attachment serve the VPC’s other regions. Use a different edge availability domain for redundancy (two domains per metro, maintenance happens in one at a time).

Partner Interconnect

You buy a VLAN attachment from a service provider who already connects to Google.

• You create the attachment in Google Cloud and get a pairing key; you give it to the provider, who completes the connection and you activate it.
• Layer 2 partner: the provider only carries your VLAN. You run BGP directly with Cloud Router (Google ASN 16550 for the Partner Interconnect BGP session).
• Layer 3 partner: the provider runs BGP for you and your traffic is routed at their layer 3. Simpler, but you do not control the BGP session.
• Capacity per attachment 50 Mbps to 50 Gbps; choose layer 2 when you want your own routing control, and layer 3 when your provider offers managed routing.

Cross-Cloud Interconnect

Google provisions and maintains a dedicated connection between Google’s network and another cloud provider’s network. Capacity is 10 or 100 Gbps; you create VLAN attachments as for Dedicated Interconnect, with the remote cloud’s router in the other side. It supports MACsec where available. Use it for multicloud connectivity that avoids the public internet and the work of building a physical fabric. For lower bandwidth or no support, build HA VPN tunnels to the other cloud’s VPN gateway instead.

Availability topologies and SLAs

• A single Interconnect connection has no SLA; production-grade is two or four.
• For 99.99 Google also wants two Cloud Routers per region where applicable and equal capacity on both sides so a failure keeps the load (capacity planning: provision so that the loss of half the links does not exceed the remaining capacity).
• HA VPN reaches 99.99% when it has two tunnels on two interfaces (all interfaces used) and the peer side is redundant. A peer with one interface is only 99.9%.
• Classic VPN SLA is 99.9%.

HA VPN

• A regional resource with two external interfaces, each with its own public IP, IKEv2 only, with IPsec ESP. Requires a Cloud Router for dynamic routing (BGP). Static routing is possible but for 99.99% use BGP.
• Each tunnel supports up to about 3 Gbps; scale out with more tunnels and ECMP, and by using more tunnel pairs. Traffic is load-shared across tunnels with equal-cost multipath when the BGP priorities match.
• Create a peer VPN gateway resource describing the on-premises device with 1, 2 or 4 interfaces (SINGLE_IP_INTERNALLY_REDUNDANT, TWO_IPS_REDUNDANCY, FOUR_IPS_REDUNDANCY). Four tunnels (two to each of two peer interfaces) are used for the best redundancy.
• Toward on-premises: create gateway, peer gateway, tunnels with a shared secret, a Cloud Router, and BGP sessions per tunnel using link-local addresses from 169.254.0.0/16.
• Toward another VPC: create HA VPN gateways in both VPCs and connect them in pairs with the Cloud Routers. Useful for transitive routing between VPCs (peering cannot do this) and for connecting VPCs in different organizations. Each side needs its own HA VPN gateway, two tunnels and a Cloud Router.
• Supports IPv6 (dual-stack) traffic over tunnels.
• Throughput guidance: tunnel MTU and packet size affect rate; the Cloud VPN gateway MTU is 1460 bytes, so lower workload MTU or clamp TCP MSS.

HA VPN over Cloud Interconnect (encryption)

To encrypt traffic over Interconnect, create IPsec-encrypting VLAN attachments (attachment with an encryption type of IPSEC and reserved internal IP ranges), then an HA VPN gateway whose interfaces use those internal IPs, and tunnels running over the attachments. The result is an IPsec tunnel over a private link; capacity is limited by the VPN tunnels (about 3 Gbps each), so you need several tunnels or multiple attachments. Works for Dedicated, Partner and Cross-Cloud.

MACsec for Cloud Interconnect

MACsec encrypts at layer 2 between your router and Google’s edge router and is configured on the Dedicated (and Cross-Cloud) connection, requiring MACsec-capable 10 or 100 Gbps ports and compatible customer equipment. Compare: MACsec protects the single hop of the physical link (and keeps line rate), while HA VPN over Interconnect gives end-to-end IPsec between your gateway and Google, at lower throughput. If a question says “line-rate encryption on a Dedicated connection” pick MACsec; “encrypt Partner Interconnect traffic” picks HA VPN over Interconnect.

Classic VPN

Classic VPN has a single interface and a single external IP, with a 99.9% SLA. It supports route-based (static routes with a Cloud Router for BGP in older configurations) and policy-based (local and remote traffic selectors, static routes). It supports IKEv1 and IKEv2. Classic VPN is being phased out: new dynamic routing setups are not allowed and it is deprecated in favor of HA VPN. Choose it only if the peer cannot support IKEv2 or the question explicitly refers to it. Policy-based VPN matters when the on-premises device only supports traffic selectors (no route-based interface); HA VPN is route-based but supports narrower traffic selectors for compatibility.

Cloud Router and BGP

Cloud Router is the managed BGP speaker. It is not in the data path; it exchanges routes and programs them into the VPC. It is regional, and it serves HA VPN, VLAN attachments, router appliances and Cloud NAT (as a control-plane associate).

Dynamic routing mode

• Regional: Cloud Router only advertises subnets of its own region and learned routes are applied only in that region.
• Global: Cloud Router advertises all subnets of the VPC (all regions), and learned routes are available in all regions. When a route is learned in a different region than the destination VM, Google adds an inter-regional cost (a MED penalty) so local routes win ties.

Set the routing mode on the VPC network. For multi-region DR with Interconnect in two regions, use global mode.

Best path selection mode (legacy vs standard)

The VPC has a BGP best path selection mode: legacy (default for existing) and standard. In legacy mode, Cloud Router regions apply MED and a region preference in Google’s own order (local region first, with cost added for cross-region). In standard mode Cloud Router uses the usual BGP decision process (AS path length, origin, MED, and so on) with options to always compare MED and to add the inter-region cost (or not). Choose standard when you want to steer traffic with AS-path prepending or to coordinate with on-premises routing in a conventional way. You change the mode through the VPC network settings; changes can shift traffic paths, so plan a maintenance window.

Custom advertisements and custom learned routes

• By default (default advertisement) Cloud Router announces the subnets of the VPC (all in global mode, local region in regional mode).
• Custom advertisement: pick groups (all subnets, all VPC subnets, all peered VPC subnets) and add custom IP ranges, for example a Private Service Connect for Google APIs range, restricted.googleapis.com, a PSA allocated range, or a peered VPC’s range. Custom advertisement is required to reach peered VPCs and PSA services from on-premises.
• Custom learned routes: filter or override what is imported (for example to add routes with a chosen priority, or to restrict to specific prefixes), useful for overlapping or unwanted prefixes and for traffic steering.
• Prefix limits exist per Cloud Router session; check them when advertising many ranges. A session may drop if the peer exceeds the maximum learned prefixes.

Peering with Google at the edge

Both give lower cost and latency for public Google services. If a question asks for private RFC 1918 connectivity to a VPC, peering is the wrong answer and Interconnect or VPN is correct.

Network Connectivity Center for hybrid

NCC uses a hub and spokes. For hybrid you add hybrid spokes:

• VLAN attachment spokes and HA VPN tunnel spokes attach on-premises sites to the hub.
• Site-to-site data transfer lets two on-premises sites exchange traffic over Google’s network using their hybrid spokes (for example two branches both connected by Interconnect or VPN), with Google as the WAN backbone. It is turned on per spoke.
• Router appliance (RA) spokes attach VMs running third-party routing or SD-WAN software; the appliance peers with a Cloud Router over BGP, advertising on-premises or branch routes into the VPC and onward.
• Transitivity: VPC peering is non-transitive and a VPN into VPC A does not give routes to peered VPC B. With NCC, spokes can exchange routes via the hub, so on-premises reaches multiple VPCs (and other sites) without a full mesh of VPNs. Where routes still do not propagate, check spoke groups, include/exclude filters, the route table, and that the Cloud Router has custom advertisements for the right ranges.
• More about NCC topologies and filters is in the dns-routing notes.

Hybrid designs the exam likes

• Access multiple VPCs from on-premises: Shared VPC (one VPC, many projects) is simplest; otherwise HA VPN or Interconnect to a hub VPC and peering with custom routes exported from the hub (one hop only), or NCC with VPC spokes plus a hybrid spoke, or an HA VPN to each VPC.
• Private access to Google APIs from on-premises (including the Gemini Enterprise Agent Platform, formerly Vertex AI): resolve *.googleapis.com to restricted.googleapis.com or private.googleapis.com VIPs, or use a PSC endpoint for Google APIs and advertise its range with Cloud Router. For Vertex-style private endpoints, use PSC or private services access depending on the product.
• Hybrid DNS (forwarding, inbound policies, peering) is in the dns-routing notes.
• Overlapping IPs with on-premises: Private NAT, or PSC to publish only the service that needs to be reached.
• Bandwidth over 10 Gbps but no colocation: multiple Partner Interconnect attachments (up to 50 Gbps each) or a 100 Gbps Dedicated via a provider cross-connect.
• Mixed: Interconnect as primary, HA VPN as backup with a higher advertised priority value (lower preference) so VPN is used only on failure. Keep matching prefixes on both so failover works.
• Single-region failure: global routing, a second Cloud Router in another region, and Interconnect in two metros.

Troubleshooting hybrid links

VPN

• Check the tunnel status (gcloud compute vpn-tunnels describe) and Cloud VPN logs in Cloud Logging. Common causes: IKE version mismatch, pre-shared key mismatch, mismatched cipher or phase 1/2 proposals, incorrect peer IP, firewall or NAT on the peer blocking UDP 500 and 4500 and ESP, and wrong traffic selectors (policy-based).
• Tunnel up but no traffic: missing routes (static route not defined, BGP not established), the on-premises firewall, or Google firewall rules blocking ingress from on-premises ranges.
• Tunnel flapping: dead peer detection timeouts, unstable internet path, or BGP timer mismatch.
• HA VPN to a peer with one interface or only one tunnel means no 99.99% SLA; the tunnel status page shows missing redundancy.

Interconnect

• Look at circuit status: light levels (optical power), LACP state, operational status and any Google maintenance notifications. A down circuit with no light is a physical or cross-connect problem.
• VLAN attachment states: PENDING_PARTNER, PENDING_CUSTOMER (waiting for you to activate), ACTIVE, UNPROVISIONED. A Partner attachment stuck pending needs the provider or activation.
• BGP up but no traffic: check the advertised and learned routes, VPC firewall rules and the peer-side filters.
• Monitor with Cloud Monitoring metrics for VLAN attachment capacity use, bytes, packet drops, interconnect link status and optical power.

Cloud Router BGP

• States to know: Idle, Connect, Active, OpenSent, OpenConfirm, Established. A session stuck in Active or Connect usually means a link-local IP, ASN or reachability error. MD5 mismatches also keep it down.
• Check: ASNs, peer IP in the same link-local /30, MD5 setting, BFD mismatch, the max-prefix limit, and the advertised routes (default vs custom) to see what Google is sending.
• Use gcloud compute routers get-status to see learned and advertised routes, and Connectivity Tests and Network Topology from Network Intelligence Center for end-to-end checks.
• Logs: Cloud Router logs record BGP state changes and route events; enable them in Cloud Logging.