Google Cloud uses a multi-stage routing order to decide which route wins when multiple routes exist for the same destination. The evaluation begins with policy-based routes, which are checked by priority with the highest priority (lowest numeric value) evaluated first. If no policy-based route matches, the system moves to subnet routes, which include local subnet routes, peering subnet routes imported from VPC Network Peering, and Network Connectivity Center subnet routes imported from VPC spokes. Only after subnet routes are evaluated does Google Cloud look at static and dynamic routes, selecting the most specific destination (the longest subnet mask) that contains the packet's destination IP address.
When custom routes compete at the same specificity level, Google Cloud applies a strict preference hierarchy: local custom routes (routes created in the local VPC) are preferred over Network Connectivity Center dynamic routes, and Network Connectivity Center dynamic routes are preferred over peering custom routes imported from VPC Network Peering. This means a local static route always beats a peering dynamic route for the same destination, regardless of priority settings. If multiple networks advertise the same route, an internal algorithm selects a single next hop from one of those networks before considering priority.
When VPC networks connect through both VPC Network Peering and Network Connectivity Center, route conflicts can occur because both mechanisms may provide routes to the same destination. The key principle is that Network Connectivity Center dynamic routes take precedence over peering custom routes when no local custom routes exist for the destination. Network Connectivity Center provides a centralized hub-and-spoke model where the hub route table aggregates routes from all spokes, and these routes are programmed into each VPC spoke's route table.
To resolve conflicts, administrators can adjust route priorities so the intended route has a higher priority (lower numeric value). For Network Connectivity Center dynamic routes from hybrid spokes in different routing VPC networks, ensuring unique priorities in each hybrid spoke prevents ambiguity in next hop selection. When using static routes with next hop internal passthrough Network Load Balancer across VPC spokes, the subnet range used by the load balancer must be accessible in the VPC spoke where the static route is defined, and both the hub topology configuration and export filters must allow this accessibility.
Google Cloud enforces strict rules to prevent overlapping IPv4 subnet routes in VPC Network Peering. Peering prohibits identical IPv4 subnet routes—for example, two peered VPC networks cannot both have a subnet route whose destination is 100.64.0.0/10. Peering also prohibits a subnet route from being contained within a peering subnet route; if the local VPC network has a subnet route whose destination is 100.64.0.0/24, none of the peered VPC networks can have a subnet route whose destination is 100.64.0.0/10. These conditions are enforced when networks are first connected, while they remain peered, and when peering configuration changes such as enabling import of subnet IPv4 routes with privately used public IP addresses.
The interaction between subnet routes and static routes also requires careful attention. A local static route cannot have a destination that exactly matches or fits within a local subnet route. Similarly, a local static route cannot have a destination that exactly matches or fits within a peering subnet route, and a peering static route cannot have a destination that exactly matches or fits within a local subnet route. Google Cloud enforces these rules by blocking the creation of new peering connections that would result in conflicting routes, blocking updates to existing peering connections that would import conflicting routes, and blocking the creation of new static routes that would conflict with imported peering subnet routes.
Custom route import and export policies control which routes are exchanged between VPC networks connected via VPC Network Peering. Each peered VPC can independently choose to import routes from, or export its own routes to, the peer network. These policies allow you to manage network reachability and path selection across your hybrid environment. A VPC network can import routes from a peered network, but Google Cloud may ignore an imported route if a local route with an identical or more specific destination already exists.
If multiple peered VPC networks advertise the same most-specific route for a packet's destination, Google Cloud uses an internal algorithm to select a next hop from just one of those peered networks before considering route priority. This selection is not configurable, so to avoid unintended routing changes, you should avoid configurations where multiple peers advertise overlapping routes. IPv6 subnet routes are globally unique within Google Cloud by definition, so overlap is inherently prevented.
Network Connectivity Center serves as a centralized hub-and-spoke control plane in Google Cloud that automates the distribution of network routes across VPC networks and hybrid infrastructure. The NCC hub manages a global routing engine that dynamically collects subnet and dynamic routes from attached spokes and programs the underlying data plane for any-to-any or star topology reachability. By connecting workload VPCs, transit VPCs, and hybrid connections such as Cloud Interconnect VLAN attachments and Cloud VPN tunnels, NCC allows organizations to build scalable cross-cloud and inter-VPC networks without the scaling limitations of full-mesh peerings.
The Network Connectivity Center hub maintains centralized route tables that receive and propagate network reachability information across attached VPC spokes and hybrid spokes. VPC spokes export their local subnet IP address ranges to the hub route table, while hybrid spokes inject dynamic BGP routes learned from Cloud Routers. In a default mesh topology, the hub places all spokes into a single group and propagates learned routes to every connected spoke. In a star topology, spokes belong to either an edge or center group, which generates two distinct hub route tables so that edge spokes propagate routes only to the center group, while center spokes propagate routes to both groups.
Spoke export filters allow administrators to define precise boundaries for IPv4 and IPv6 address ranges that a VPC spoke shares with the NCC hub. By default, a VPC spoke exports all private IPv4 subnet ranges to the hub upon attachment. Administrators can modify this behavior using the --include-export-ranges flag to specify exact subnets or the --exclude-export-ranges flag to omit specific IP address ranges from propagation. IPv6 route propagation is explicitly toggled by enabling the export of all internal and external IPv6 subnet ranges.
Spoke management and policy enforcement depend on administrative authorization workflows between project owners and the central hub. When a spoke is proposed from another project, its lifecycle state remains inactive until a hub administrator approves the attachment. Hub administrators can streamline multi-project deployments by configuring auto-accept projects, which automatically approves spoke creation or filter modifications from authorized project IDs without manual intervention. Adjusting export filters dynamically recalculates the hub route table, immediately updating routing paths or revoking reachability for excluded prefixes across all connected spokes.
Custom static routes in NCC VPC spokes can forward traffic directly to an internal passthrough Network Load Balancer located in a separate VPC spoke. Unlike dynamic and subnet routes, static routes themselves are not exchanged directly across the NCC hub; instead, the hub provides reachability to the next-hop ILB IP address. For this configuration to work, the static route must use an IPv4 destination range, must not contain network tags, and must reference the next hop using the ILB's IPv4 forwarding rule IP address.
Establishing cross-spoke static routing requires specific reachability criteria within the NCC hub topology. The subnet containing the ILB forwarding rule must be exported to the hub and not blocked by spoke export filters. In a star topology, an edge VPC spoke can only target an ILB located within its own network or within a center VPC spoke. Center VPC spokes can target ILBs located in either edge or center VPC spokes. The target ILB must have global access enabled if client workloads or gateways reside in a Google Cloud region different from the load balancer. If the target ILB is deleted, Google Cloud automatically activates a replacement ILB deployed with the same IP address without requiring administrative changes to the existing static route.
Choosing between VPC Network Peering and Network Connectivity Center depends on transitivity requirements, scale limits, and appliance architectures. VPC Network Peering is non-transitive and prevents spoke-to-spoke communication through an intermediary network, requiring direct peerings between every VPC pair. Network Connectivity Center introduces transit routing across multiple VPCs and hybrid connections using a single control plane, avoiding peering connection quotas.
Organizations migrating from an existing VPC Network Peering mesh to NCC star or mesh topologies must plan for route conflict avoidance. Because NCC prohibits attaching two VPCs as spokes if an active VPC peering exists between them, direct migrations require scheduling a maintenance window to delete peering connections before creating VPC spokes. For zero-downtime migrations, administrators can establish temporary HA VPN tunnels between the peered VPCs, delete the VPC Network Peering connections, and subsequently attach the VPCs to the NCC hub. Once NCC establishes the data path, adjusting BGP MED values allows traffic to shift predictably onto the new fabric before decommissioning legacy VPN tunnels.
When both mechanisms provide routes to the same destination, Network Connectivity Center dynamic routes take precedence over peering custom routes, but local custom routes always win over both. If multiple peers advertise the same route, Google Cloud uses an internal algorithm to select one next hop before considering priority.
No. Google Cloud blocks the creation of new static routes that would conflict with imported peering subnet routes, and it also blocks peering connections that would import subnet routes conflicting with existing local static routes. This enforcement happens during peering creation, while networks remain peered, and during any configuration changes.
The internal passthrough Network Load Balancer must be reachable from the VPC spoke where the static route is defined. This requires the ILB's subnet to be exported to the NCC hub and not blocked by spoke export filters. If the ILB and client workloads are in different regions, the ILB must have global access enabled.
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills
StudyCerts
StudyCerts