Professional Cloud Network Engineer

Configure Network Connectivity Center Hubs and Hybrid Spokes

Network Connectivity Center Hub Architecture

A Network Connectivity Center (NCC) hub is a centralized, global Google Cloud resource that manages network connectivity across hybrid and multicloud environments. The hub acts as a single management plane to connect external networks together through the Google Cloud global backbone. When creating a hub, administrators choose a fixed topology, such as a mesh or star topology, which cannot be altered after creation. Hubs also support Private Service Connect (PSC) connection propagation, which allows private endpoints to be published across regions and attached spokes automatically.

Hybrid Spoke Types and Capabilities

A hybrid spoke is an NCC resource attachment that links external, non-Google networks directly to a hub. Google Cloud supports three distinct backing resource types for hybrid spokes:

• Cloud Interconnect VLAN attachments for dedicated or partner physical cross-connects.
• High Availability VPN (HA VPN) tunnels for encrypted IPsec transit over the public internet.
• Router Appliance virtual machine (VM) instances for hosting third-party virtual routing appliances inside a Virtual Private Cloud (VPC) network.

Hybrid spokes enable two functional connectivity models: site-to-cloud connectivity, which links external networks to Google Cloud VPC workloads, and site-to-site data transfer, which links remote external networks to each other through the Google backbone.

Requirements for Site-to-Site Data Transfer

Site-to-site data transfer is an NCC capability that routes transit data between external sites through a common Google Cloud network. To enable this feature, network operators must explicitly activate site-to-site data transfer on each attached hybrid spoke. A strict architectural rule requires all hybrid spokes participating in site-to-site transfer to belong to the same VPC network. Furthermore, the underlying VPC network must have its dynamic routing mode set to global, allowing Cloud Router instances in different regions to share dynamic routes between remote locations.

High Availability Deployment Standards

High availability configurations are mandatory for hybrid spokes to maintain continuous site-to-site data transfer during link failures. Cloud Interconnect spokes require redundant VLAN attachments placed in separate metropolitan edge availability domains to prevent single points of failure. HA VPN spokes must deploy dual tunnels across separate gateway interfaces to provide a 99.99% service level objective (SLO). Router Appliance deployments require multiple VM instances configured with equal-cost multipath (ECMP) routing or placement into distinct spokes, and all instances within a single spoke must remain within the same Google Cloud region.

Manage Dynamic BGP Routing and Path Selection Across Spokes

Cloud Router and BGP Peering

Cloud Router provides fully managed Border Gateway Protocol (BGP) routing to exchange dynamic reachability information between Google Cloud and connected hybrid spokes. Each Cloud Router advertises internal routes and receives remote branch prefixes using assigned Autonomous System Numbers (ASNs). To deliver high availability, each Cloud Router establishes redundant BGP sessions across two separate interfaces connected to external peer routers. Traffic flows directly between external endpoints and Google Cloud through these established peering sessions.

Global Dynamic Routing and Route Exchange

Global dynamic routing controls how Cloud Router propagates learned routes across regional boundaries within a VPC network. When a VPC network uses global dynamic routing, a Cloud Router in one region shares routes learned from its local spoke with Cloud Routers in all other regions. The NCC hub installs these routes into a centralized routing table and advertises them out to all other participating hybrid spokes. If the VPC dynamic routing mode is set to regional, Cloud Routers only advertise local subnet routes, which blocks cross-region site-to-site communication.

Path Selection and Traffic Engineering with MED

Path selection across redundant spokes depends on route priority metrics defined by the BGP Multi-Exit Discriminator (MED) attribute. Lower MED values take precedence over higher values, making routes with lower metrics the primary path for ingress and egress traffic. When Cloud Router receives identical network prefixes with identical MED values across multiple active links, it balances traffic evenly using ECMP routing. To configure an active/standby failover design, administrators assign a lower MED value (such as 100) to the primary hybrid link and a higher MED value (such as 200) to the backup link.

Custom Route Advertisements and Route Policies

Custom route advertisements allow Cloud Router to announce specific aggregated address blocks rather than default subnet ranges to external peers. Advertising aggregated prefixes reduces the total number of route table entries on remote hardware and prevents router memory exhaustion. Route policies allow administrators to apply custom include-export and exclude-export filters to control which prefixes leave the VPC network. These policies prevent sensitive internal subnets from being advertised and stop routing loops across hybrid connections.

Router Appliance BGP Session Requirements

Router Appliance instances use internal RFC 1918 IP addresses assigned from their local VPC subnet to establish BGP peering with Cloud Router. Unlike Cloud Interconnect and Cloud VPN, which rely on link-local 169.254.x.x addresses, Router Appliance interfaces must never use link-local IP addresses. VPC firewall rules must explicitly allow ingress Transmission Control Protocol (TCP) traffic on port 179 so Router Appliance instances can negotiate BGP sessions with Cloud Router. Each Router Appliance VM must establish dual BGP sessions to redundant Cloud Router interfaces and advertise matching routes to avoid asymmetric routing issues.

Avoiding Routing Loops and Address Conflicts

Routing integrity requires strict address planning and distinct ASN assignments across all connected hybrid endpoints. If the same IP address range exists in both a local VPC subnet and an external spoke, Google Cloud always prioritizes the local subnet route, causing dropped packets or blackholed traffic for the remote site. Additionally, advertising matching prefixes across both data-transfer-enabled spokes and non-data-transfer spokes can cause ECMP to misroute transit packets. Network operators must establish non-overlapping IP address ranges and uniform BGP filtering rules across all hybrid spokes.

Diagnose, Monitor, and Optimize Site-to-Site Connectivity

Transit Route Evaluation Hierarchy

Google Cloud resolves traffic forwarding decisions by evaluating routing tables in a strict, deterministic sequence:

1. Policy-based routes are evaluated first to override standard routing behavior for matching traffic filters.
2. Subnet routes are evaluated second to direct traffic to local VPC subnets and peered networks.
3. Custom routes are evaluated third, where local dynamic and static routes take priority over NCC dynamic routes, which take priority over imported VPC peering routes.

Understanding this sequence is essential when troubleshooting missing paths or unexpected route selection across hybrid spokes.

Traffic Steering for Unsupported Locations

Site-to-site data transfer is restricted to specific supported Google Cloud regions, requiring external traffic steering when unsupported regions are involved. If an organization maintains hybrid links in an unsupported region, Cloud Router will not readvertise those prefixes to other NCC hybrid spokes. To resolve this, network administrators configure the on-premises router to advertise lower MED values to supported regions and higher MED values to unsupported regions. This metric difference forces external routers to send transit traffic exclusively through supported NCC spoke paths while reserving unsupported regional paths strictly for local site-to-cloud traffic.

Monitoring and Diagnostic Tools

Google Cloud offers several native tools to verify spoke health, trace data paths, and isolate connectivity failures:

• Network Topology provides a visual map of hybrid spoke connections, operational link states, and effective transit routes across regions.
• Cloud Monitoring collects real-time performance metrics, packet loss statistics, and throughput data across BGP sessions and interconnect attachments.
• Connectivity Tests runs hop-by-hop configuration analyses from source to destination to detect blocking firewall rules, missing dynamic routes, or incorrect VPC route priorities.

Maintaining Traffic Symmetry and Resiliency

High availability architectures require dual-region redundancy to ensure uninterrupted site-to-site transit during regional outages. A 99.99% availability profile requires two pairs of Dedicated Interconnect connections deployed across two separate metro locations, with each connection carrying its own VLAN attachment. Network engineers must also balance routing policies between domains to prevent asymmetric traffic flows that disrupt stateful firewalls. Pairing cold-potato routing (holding traffic on the internal backbone as long as possible) in one network domain with hot-potato routing (handing traffic off at the earliest exit point) in the peer domain ensures return packets follow the original ingress path.

Key Facts

• Network Connectivity Center site-to-site data transfer requires all participating hybrid spokes to reside in the same Virtual Private Cloud (VPC) network configured with global dynamic routing.
• Router Appliance instances must peer with Cloud Router using internal RFC 1918 IP addresses in the same VPC subnet, rather than link-local 169.254.x.x addresses, and require firewall rules allowing ingress TCP port 179.
• Google Cloud evaluates routing priority by checking policy-based routes first, subnet routes second, and custom routes third, where local dynamic routes take precedence over Network Connectivity Center dynamic routes.
• Lower BGP Multi-Exit Discriminator (MED) values indicate higher route priority, allowing network operators to steer site-to-site transit traffic toward supported Network Connectivity Center spokes and away from unsupported transit regions.

Frequently Asked Questions

Why must a Virtual Private Cloud network use global dynamic routing for Network Connectivity Center site-to-site data transfer?

Network Connectivity Center relies on global dynamic routing so that Cloud Routers in different regions can share dynamically learned BGP prefixes with one another. If dynamic routing is set to regional, Cloud Routers only advertise routes located within their local region, preventing external sites connected in different regions from exchanging traffic across the Google backbone.

How do Router Appliance BGP peering configurations differ from Cloud Interconnect and Cloud VPN configurations?

Router Appliance instances peer with Cloud Router using internal RFC 1918 IP addresses belonging to their local VPC subnet, whereas Cloud Interconnect and Cloud VPN typically configure link-local 169.254.x.x addresses for BGP sessions. Additionally, Router Appliance deployments require explicit VPC firewall rules allowing ingress TCP port 179 traffic to establish peering.

How do network operators steer traffic when connecting through both supported and unsupported Network Connectivity Center regions?

Operators configure external routers to advertise lower BGP MED values to Cloud Routers in supported Network Connectivity Center regions and higher MED values to unsupported regions. This forces transit traffic to enter Google Cloud through supported hybrid spokes, allowing the Network Connectivity Center hub to readvertise the prefixes to other remote sites.