Professional Cloud Network Engineer

Troubleshoot Dynamic Route Propagation and Route Conflicts

Dynamic Route Propagation and Dynamic Routing Modes

Dynamic route propagation in Network Connectivity Center (NCC) distributes learned dynamic routes and subnet prefixes across Virtual Private Cloud (VPC) spokes and hybrid spokes attached to a central hub. When hybrid spokes such as Cloud Interconnect VLAN attachments, Cloud VPN tunnels, or Router appliance instances share routes into a hub, the dynamic routing mode of each attached VPC network controls where those routes are placed:

• If the VPC dynamic routing mode is set to regional, dynamic routes learned from hybrid spokes are programmed only into the route tables of the specific region where the hybrid spoke terminates.
• If the VPC dynamic routing mode is set to global, dynamic routes learned from hybrid spokes are programmed across all regions within the VPC network.

Setting the dynamic routing mode to regional prevents Compute Engine virtual machine (VM) instances in other regions from discovering paths to on-premises networks. Changing the dynamic routing mode to global ensures reachability for workloads across all cloud regions attached to the hub.

Subnet Route Advertisement to Hybrid Spokes

Subnet route advertisement enables on-premises networks to receive reachability paths for workloads operating inside VPC spokes. Network administrators advertise VPC spoke subnet IP address ranges to hybrid spokes through specific configuration options:

• Setting the includeImportRanges field to ["ALL_IPV4_RANGES"] or applying the --include-import-ranges=[ALL_IPV4_RANGES] flag on Router appliance, VLAN attachment, or Cloud VPN spokes.
• Configuring Cloud Router custom route advertisements to announce specific IPv4 subnet ranges or aggregated CIDR blocks for all VPC spokes attached to the hub.

If subnet routes are omitted from both spoke import settings and Cloud Router custom advertisements, return traffic from on-premises networks cannot reach cloud workloads. Network administrators must also inspect dynamic route sharing and prefix limits to maintain steady route table convergence across the hub-and-spoke transit network.

Hub Route Table Operations and Route Overlap Mitigation

The Network Connectivity Center hub route table is a read-only, fully managed resource that aggregates dynamic routes from hybrid spokes and subnet ranges from attached VPC spokes. When two VPC spokes contain overlapping IPv4 address spaces, direct communication causes address collisions that prevent proper packet delivery. Administrators resolve IP address collisions between VPC spokes by deploying Cloud NAT configured as Private NAT through the following ordered process:

1. Create a dedicated subnet with its purpose configured as PRIVATE_NAT that does not overlap with any spoke subnets.
2. Deploy a Private NAT gateway in the source VPC network applied to the colliding subnet range.
3. Configure a NAT rule with a next-hop constraint where nexthop.hub matches the Network Connectivity Center hub resource URL.

Traffic originating from the source VM undergoes translation to an IP address from the Private NAT subnet before traversing the hub. This translation prevents IP collisions and allows traffic to route correctly to the destination VPC spoke.

BGP Configuration and Path Selection

Hybrid spokes exchange dynamic routing information with remote networks using Border Gateway Protocol (BGP) over Cloud VPN tunnels or Cloud Interconnect VLAN attachments. Cloud Router peers with remote Autonomous Systems using a configured autonomous system number (ASN), with optional MD5 authentication keys applied to secure peering sessions. Path selection and failover behavior depend on Multi-Exit Discriminator (MED) values and Cloud Router base priorities:

• An active-passive configuration assigns different MED values across connections, directing traffic to a primary path while holding a secondary path on standby to guarantee consistent capacity during failover.
• An active-active configuration shares identical route priorities across paths to aggregate bandwidth, though available capacity drops by half if an individual connection fails.

Configuring active-passive topologies across more than two tunnels on multiple HA VPN gateways can cause traffic loss because passive tunnels remain inactive until every active tunnel across all gateways fails. Furthermore, duplicate BGP route advertisements can trigger equal-cost multi-path (ECMP) routing across all available next hops, including links not designated for data transfer.

Diagnose Spoke Health and Operational States

Spoke Connectivity and Lifecycle Monitoring

Diagnosing spoke health in Network Connectivity Center involves evaluating the operational and administrative states of attached VPC and hybrid spokes using Cloud Monitoring metrics and Cloud Audit Logs. Spoke resources transition through specific lifecycle phases, moving from creation toward an ACTIVE state or entering a failed state when resource bindings are misconfigured. When updating an existing spoke, administrators must specify its location to ensure proper state transitions. Spoke creation failures displaying internal errors on Router appliance resources often point to incorrect IP address configurations. If persistent state errors or control plane discrepancies continue after configuration checks, administrators must contact Google Cloud Support to resolve underlying platform issues.

Router Appliance and Hybrid Spoke Health

Router Appliance and hybrid spoke health depends on correct BGP session establishment, export policies, and firewall configurations. BGP peering sessions between Cloud Router and a Router Appliance VM instance require specific network parameters:

• Peering addresses must use RFC 1918 internal IP addresses rather than link-local 169.254.x.x addresses.
• Firewall rules must allow inbound and outbound BGP traffic over TCP port 179.
• Cloud Router must establish two separate BGP sessions with the Router Appliance instance.

If configured hub subnets fail to appear in on-premises route tables, administrators must inspect the hub route table of the hybrid spoke's group. If the subnets appear in the hub route table, a BGP route policy may have dropped the advertisement; if they are missing from the table, administrators must check the include-export and exclude-export IP address ranges on the VPC spoke.

NCC Gateway Spoke Operations

NCC Gateway spokes require command-line verification to ensure routing entries propagate correctly between the hub route table and the VPC data plane. Administrators execute gcloud network-connectivity spokes describe to display the gateway's connected services and active routers. Running gcloud compute routes list confirms whether hub route table entries have successfully installed into the VPC routing table. If advertised gateway routes are missing from the data plane, deleting and recreating the advertised routes forces route reinstallation.

Validate Transit Reachability with Network Intelligence Center

Connectivity Tests for Network Connectivity Center

Connectivity Tests is a diagnostic tool within Network Intelligence Center that evaluates end-to-end reachability by simulating packet paths through network configurations and executing live data plane analysis. Connectivity Tests evaluates transit paths between non-Google Cloud networks and VPC networks across an NCC hub, between VM instances through a hub, between two on-premises networks, and between separate VPC spokes. Because Connectivity Tests cannot access on-premises router configurations, traffic from an on-premises network to Google Cloud is always treated as valid during configuration analysis. The configuration analysis checks source IP spoofing, egress firewall policies, VPC route tables, ingress firewall policies, and destination IP forwarding settings in order.

Configuration analysis produces one of four distinct operational states:

• Deliver confirms that the simulated packet reaches its destination successfully.
• Undetermined indicates that verification cannot complete due to missing permissions or unresolvable endpoints outside Google Cloud.
• Ambiguous highlights that multiple non-deterministic forwarding paths exist.
• Abort identifies that invalid arguments or deleted network resources halted the test.

For supported routes, Connectivity Tests performs live data plane analysis by sending TCP or UDP probe packets between VMs, Google Kubernetes Engine (GKE) control plane endpoints, or Google edge locations to measure latency and packet loss. Generating complete Connectivity Tests results takes between 30 seconds and 10 minutes depending on network complexity and resource count.

Network Topology and Flow Analysis

Network Topology and VPC Flow Logs provide visual metrics and packet-level telemetry to isolate throughput bottlenecks and traffic anomalies across spokes. Network Topology presents an infrastructure view that overlays real-time metrics on VPC networks, hybrid connections, and Network Connectivity Center hubs. This view helps administrators identify dropping traffic, latency spikes, and unexpected data paths across spokes.

Traffic flow investigation uses telemetry tools with specific collection and filtering behaviors:

• VPC Flow Logs samples network packets sent and received by VM instances, capturing all egress traffic regardless of deny rules while capturing ingress traffic only when permitted by an ingress allow firewall rule.
• Flow Analyzer uses Log Analytics and BigQuery to analyze VPC Flow Logs using 5-tuple criteria, which include source IP, destination IP, source port, destination port, and protocol.

Administrators can launch Connectivity Tests directly from Flow Analyzer to validate the live forwarding configuration of problematic traffic flows identified within log records.

Key Facts

• When a Virtual Private Cloud (VPC) network uses regional dynamic routing, Network Connectivity Center dynamic routes learned from hybrid spokes are programmed only into the route table of the region where the hybrid spoke terminates.
• IP address collisions between overlapping VPC spokes attached to the same hub are resolved using Cloud NAT configured as Private NAT with a next-hop constraint matching the hub resource URL.
• BGP peering for a Router appliance spoke requires internal RFC 1918 IP addresses, open firewall access on TCP port 179, and two separate BGP sessions established by Cloud Router.
• Connectivity Tests within Network Intelligence Center evaluates Google Cloud network configurations and produces one of four states: Deliver, Undetermined, Ambiguous, or Abort.

Frequently Asked Questions

How does the dynamic routing mode of a VPC network affect Network Connectivity Center route propagation?

A VPC network set to regional dynamic routing installs learned hybrid spoke dynamic routes only in the region where the hybrid connection terminates. A VPC network set to global dynamic routing installs those learned dynamic routes across all regions, enabling global workload reachability.

How are overlapping IP address spaces handled between VPC spokes connected to the same hub?

Overlapping IP address spaces are resolved by deploying Cloud NAT configured as Private NAT in the source VPC network. The Private NAT gateway uses a dedicated subnet with its purpose set to PRIVATE_NAT and applies a rule matching the hub resource URL to translate colliding source IP addresses before packets traverse the hub.

What are the main limitations when using Connectivity Tests to evaluate hybrid transit reachability?

Connectivity Tests cannot access or verify firewall rules and routing configurations residing on on-premises routers. As a result, configuration analysis assumes that any traffic originating from an on-premises network toward Google Cloud is valid, testing only the configurations and policies within Google Cloud itself.