Routes

Google Cloud routes define the paths that network traffic takes from a virtual machine (VM) instance to other destinations. These destinations can be inside your Google Cloud Virtual Private Cloud (VPC) network (for example, in another VM) or outside it.

In a VPC network, a route consists of a single destination prefix in CIDR format and a single next hop. When an instance in a VPC network sends a packet, Google Cloud delivers the packet to the route's next hop if the packet's destination address is within the route's destination range.

This page provides an overview of how routes work in Google Cloud.

Routing in Google Cloud

Every VPC network uses a scalable, distributed virtual routing mechanism. There is no physical device that's assigned to the network. Some routes can be applied selectively, but the routing table for a VPC network is defined at the VPC network level.

Each VM instance has a controller that is kept informed of all applicable routes from the network's routing table. Each packet leaving a VM is delivered to the appropriate next hop of an applicable route based on a routing order. When you add or delete a route, the set of changes is propagated to the VM controllers by using an eventually consistent design.

Route types

The following tables summarize how Google Cloud categorizes routes in VPC networks.

Type and destination	Next hop	Notes
Policy-based routes: Policy-based routes are evaluated before any other type of route.
Policy-based route Policy-based routes can apply to packets based on source IP address, destination IP address, protocol, or a combination thereof.	An option to skip evaluating other policy-based routes An internal passthrough Network Load Balancer	Policy-based routes can apply to all VMs in the network, to certain VMs selected by network tag, or to traffic entering the VPC network through VLAN attachments for Cloud Interconnect (in only one region, or in all regions). Policy-based routes are never exchanged through VPC Network Peering.
Subnet routes: All subnet route types are evaluated after policy based routes but before custom routes.
Local subnet route Created automatically for each subnet IP address range	VPC network	Created, updated, and removed automatically by Google Cloud during subnet lifecycle events. Local subnet routes apply to the whole VPC network.
Peering subnet route Represents a subnet IP address range in a different VPC network connected using VPC Network Peering	Next hop in the peer VPC network	VPC Network Peering provides options for exchanging subnet routes. Created, updated, and removed automatically by Google Cloud during subnet lifecycle events. Imported peering subnet routes apply to the whole VPC network.
Network Connectivity Center subnet route Represents a subnet IP address range in a VPC spoke (a different VPC network connected to the Network Connectivity Center hub)	Network Connectivity Center hub	Network Connectivity Center spoke administrators can exclude the export of subnet routes. Created, updated, and removed automatically by Google Cloud during subnet lifecycle events. Imported Network Connectivity Center subnet routes apply to the whole VPC network.
Custom routes: Custom routes are evaluated after policy based routes and after subnet routes.
Local static route Supports various destinations	Forwards packets to a static route next hop	For details about each static route next hop, see considerations for: Instances and internal passthrough Network Load Balancers Next hop instances Internal passthrough Network Load Balancer next hops Classic VPN tunnel next hops
Local dynamic route Destinations that don't conflict with subnet routes or static routes	Peer of a BGP session on a Cloud Router	Routes are added and removed automatically based on learned routes from Cloud Routers in your VPC network. Routes apply to VMs according to the VPC network's dynamic routing mode.
Peering static route, peering dynamic route Static or dynamic routes in a different VPC network connected using VPC Network Peering	Next hop in the peer VPC network	VPC Network Peering provides options for exchanging static routes. Imported peering static routes apply to the whole VPC network. VPC Network Peering provides options for exchanging dynamic routes. Peering dynamic routes apply to one region or all regions of the VPC network according to the dynamic routing mode of the VPC network that exports the routes.
Network Connectivity Center dynamic route Dynamic routes imported from Network Connectivity Center hybrid spokes located in different VPC networks	Network Connectivity Center hub	A Network Connectivity Center hub can have both VPC spokes and hybrid spokes. Network Connectivity Center dynamic routes apply to one region or all regions of the VPC network according to the dynamic routing mode of the VPC network that contains the hybrid spoke.
System-generated routes
System-generated default routes 0.0.0.0/0 for IPv4 ::/0 for IPv6	default-internet-gateway	Applies to the whole VPC network Can be removed or replaced

Subnet routes

Each subnet has at least one subnet route for each IP address range that is associated with the subnet. For more information about subnet IP ranges, see Subnets.

Types of subnet routes

A VPC network can include the following types of subnet routes:

• Subnet routes for subnets in the same VPC network, referred to as local subnet routes.
• Network Connectivity Center subnet routes that are imported from VPC spokes of a Network Connectivity Center hub.
• Peering subnet routes that are imported from networks connected using VPC Network Peering.

Destination ranges for all types of subnet routes must be unique. For more information, see:

• Options for exchanging subnet routes and Subnet and peering subnet route interactions in the VPC Network Peering documentation

• Subnet route uniqueness and VPC spokes overview in the Network Connectivity Center documentation

Lifecycle of subnet routes

All IP address ranges that are part of a subnet—primary IPv4 address ranges, secondary IPv4 address ranges, and IPv6 address ranges—have a corresponding subnet route. Google Cloud creates and deletes subnet routes in these scenarios:

• You make a subnet configuration change, for example:

  • Add or delete a subnet.
  • Expand a primary IPv4 range.
  • Add or delete a secondary IPv4 range.
  • Add or delete an IPv6 range.

• Google Cloud adds a new region, which automatically adds a new subnet to auto VPC mode networks. For information about the IPv4 address ranges for each subnet by its region, see auto mode IPv4 ranges.

Dynamic routes

Cloud Routers instruct the VPC network to create, update, and remove dynamic routes based on received Border Gateway Protocol (BGP) messages, applicable BGP route policies (Preview), and Cloud Router custom learned routes.

Dynamic routes are created in one region or in all regions based on the dynamic routing mode and best path selection mode of the VPC network that contains the Cloud Router. For more information, see the following:

• How Cloud Router works
• Learned routes

The next hop of a dynamic route can be one of the following:

• A VLAN attachment backed by either a Dedicated Interconnect connection or a Partner Interconnect connection

• A Cloud VPN tunnel, either a HA VPN tunnel or a Classic VPN configured to use dynamic routing

• A Router appliance VM instance

If a next hop for a dynamic route becomes inaccessible, the Cloud Router that manages its BGP session instructs the VPC network to remove the dynamic route. For more information, see BGP state changes.

Types of dynamic routes

A VPC network can include the following types of dynamic routes:

• Dynamic routes learned by Cloud Routers in the same VPC network are referred to as local dynamic routes.
• Peering dynamic routes that are imported with custom route exchange from networks connected using VPC Network Peering .
• Network Connectivity Center dynamic routes that are imported from hybrid spokes located in different VPC networks of a Network Connectivity Center hub.

Google Cloud resolves conflicts between dynamic routes and subnet routes as described in Interactions with dynamic routes.

System-generated default routes

A default route has the broadest possible destination: 0.0.0.0/0 for IPv4 and ::/0 for IPv6. Google Cloud only uses a default route to deliver a packet when the packet doesn't match a more specific route in the routing order.

The absence of a default route doesn't necessarily isolate your network from the internet because special routing paths for external passthrough Network Load Balancers and external protocol forwarding don't depend on a default route.

When you create a VPC network, Google Cloud adds a system-generated IPv4 default route to the VPC network. The system-generated IPv4 default route is a local static route that has a 0.0.0.0/0 destination and default internet gateway next hop. A local static route with the 0.0.0.0/0 destination and default internet gateway next hop provides a path to external IPv4 addresses, including IPv4 addresses on the internet. The following example resources use this path:

• VMs with external IPv4 addresses assigned to their network interfaces, when the packets they send have sources matching the network interface primary internal IPv4 address.
• A public Cloud NAT gateway configured to provide NAT services to subnets used by VM network interfaces. Depending on which subnet IPv4 address ranges the Cloud NAT gateway is configured to serve, packet sources can match either of the following:
  • An internal IPv4 address from an alias IP address range of the VM's network interface (whether or not the network interface has an external IPv4 address), or
  • The primary internal IPv4 address of the VM's network interface if the network interface doesn't have an external IPv4 address assigned.

When you create a subnet that has an external IPv6 address range, Google Cloud adds a system-generated IPv6 default route to the VPC network if it doesn't already have one. The system-generated IPv6 default route is a local static route that has a ::/0 destination and default internet gateway next hop. A local static route with the ::/0 destination and default internet gateway next hop provides a path to external IPv6 addresses, including IPv6 addresses on the internet. This path can be used by the following:

• VMs with /96 external IPv6 address ranges assigned to their network interfaces, when the packets they send have sources in that /96 address range.

Accessing global Google APIs sometimes depends on a local IPv4 or IPv6 default route with default internet gateway next hop:

• If you access global Google APIs and services by sending packets to a Private Service Connect endpoint for global Google APIs, your VPC network doesn't require a default route with default internet gateway next hop. Google Cloud adds a special routing path to the endpoint.

• If you access global Google APIs and services by sending packets to IPv4 or IPv6 addresses for the default domains, the IPv4 or IPv6 addresses for private.googleapis.com, or the IPv4 or IPv6 addresses for restricted.googleapis.com, you can either use default IPv4 and IPv6 routes that have default internet gateway next hops, or you can create and use IPv4 and IPv6 static routes that have more specific destinations and default internet gateway next hops:

  • If your VMs have only internal IP addresses, see Routing options for Private Google Access.
  • If your VMs have external IP addresses, see Routing options.

Route interactions

The following sections describe the interactions between subnet routes and other route types.

Interactions between subnet routes and static routes

Google Cloud enforces the following rules for local subnet routes, peering subnet routes, and Network Connectivity Center subnet routes unless the corresponding subnet has been configured as a hybrid subnet.

• Google Cloud doesn't let you create a new static route if the destination of the new static route exactly matches or fits within the destination of an existing local, peering, or Network Connectivity Center subnet route. For example:

  • If a local, peering, or Network Connectivity Center subnet route exists with the 10.70.1.0/24 destination, you cannot create a new static route for 10.70.1.0/24, 10.70.1.0/25, 10.70.1.128/25, or any other destination that fits within 10.70.1.0/24.

  • If a local or peering subnet route exists with the 2001:0db8:0a0b:0c0d::/64 destination, you can't create a new static route for 2001:0db8:0a0b:0c0d::/64, 2001:0db8:0a0b:0c0d::/96, or any other destination that fits within 2001:0db8:0a0b:0c0d::/64.

• Google Cloud doesn't let you make any changes to subnets that result in a subnet IP address range that exactly matches or contains the destination of an existing local or peering static route. For example:

  • If your VPC network has a static route with the 10.70.1.128/25 destination, you can't create a new subnet that has a primary or secondary IPv4 address range of 10.70.1.128/25, 10.70.1.0/24, or any other IP address range that contains all the IPv4 addresses in 10.70.1.128/25.

  • If your VPC network has a static route with the 2001:db8:a0b:c0d:e0f:f0e::/96 destination, Google Cloud prohibits the creation of a new local or peering subnet route that has an IPv6 address range of 2001:db8:a0b:c0d::/64 or any other range that contains all the IPv6 addresses in 2001:db8:a0b:c0d:e0f:f0e::/96.

Interactions between subnet routes and dynamic routes

Google Cloud enforces the following rules unless a subnet has been configured as a hybrid subnet.

• Google Cloud doesn't create a dynamic route if a Cloud Router sends a prefix that either exactly matches or fits within the destination of an existing local, peering, or Network Connectivity Center subnet route. For example:

  • If a local, peering, or Network Connectivity Center subnet route exists with the 10.70.1.0/24 destination, and if a Cloud Router in the VPC network, a peered VPC network, or a network containing a Network Connectivity Center hybrid spoke receives 10.70.1.128/25, 10.70.1.0/24, or any other prefix that fits within 10.70.1.0/24, Google Cloud doesn't create any local, peering, or Network Connectivity Center dynamic routes for the received conflicting prefixes.

  • If a local, peering, or Network Connectivity Center subnet route exists with the 2001:0db8:0a0b:0c0d::/64 destination, and if a Cloud Router in the VPC network, a peered VPC network, or a network containing a Network Connectivity Center hybrid spoke receives 2001:0db8:0a0b:0c0d::/96, 2001:0db8:0a0b:0c0d::/64, or any other prefix that fits within 2001:0db8:0a0b:0c0d::/64, Google Cloud doesn't create any local, peering, or Network Connectivity Center dynamic routes for the received conflicting prefixes.

• Google Cloud removes any existing dynamic route if any change to subnets results in the creation of a new local, peering, or Network Connectivity Center subnet route whose destination exactly matches or contains the destination of the existing local, peering, or Network Connectivity Center dynamic route. For example:

  • If your VPC network has a local, peering, or Network Connectivity Center dynamic route with the 10.70.1.128/25 destination, Google Cloud removes the dynamic route when a new local, peering, or Network Connectivity Center subnet route for 10.70.1.128/25, 10.70.1.0/24, or any other IP address range that contains all the IPv4 addresses in 10.70.1.128/25 is created.

  • If your VPC network has a local, peering, or Network Connectivity Center dynamic route with the 2001:db8:a0b:c0d::/96 destination, Google Cloud removes the dynamic route when a new local, peering, or Network Connectivity Center subnet route for 2001:db8:a0b:c0d::/64 is created.

Applicability and order

Applicable routes

Each instance, Cloud VPN tunnel, and VLAN attachment has a set of applicable routes—routes that apply to that specific resource. Applicable routes are a subset of all routes in the VPC network.

The following route types always apply to all VM instances, VLAN attachments, and Cloud VPN tunnels:

• Special routing paths
• Subnet routes

The following route types can be configured to apply only to certain VM instances, VLAN attachments, or Cloud VPN tunnels:

• Policy-based routes can apply to:

  • All VM instances, VLAN attachments, and Cloud VPN tunnels
  • Only VM instances identified by network tag
  • Only VLAN attachments in a particular region

• Static routes can apply to:

  • All VM instances, VLAN attachments, and Cloud VPN tunnels
  • Only VM instances identified by network tag

• Dynamic routes can apply to VM instances, VLAN attachments, and Cloud VPN tunnels in either the region containing the dynamic route's next hop or all regions, based on the dynamic routing mode of the VPC network.

Special routing paths

VPC networks have special routes for certain services. These special routing paths don't appear in your VPC network route table. You can't remove any special routing paths. However, you can allow or deny packets by using VPC firewall rules or firewall policies.

Paths for external passthrough Network Load Balancers and external protocol forwarding

External passthrough Network Load Balancers and external protocol forwarding use Maglev systems to route packets from clients on the internet to backend VMs and target instances in your VPC network. These Maglev systems route packets that have destinations that match the destination of the external forwarding rule.

Each forwarding rule for an external passthrough Network Load Balancer or for external protocol forwarding also provides a routing path for its backend VMs or target instance to send packets to destinations outside of the VPC network:

• Packets sent by backend VMs or target instances can be either outbound response packets (sent back to the client) or they can be outbound packets that initiate a new connection.
• Packet sources must match the forwarding rule's IP address. Packet protocol and source port don't have to match the forwarding rule's protocol and port specification.
• Forwarding rule routing paths don't depend on a default route or the use of the default internet gateway next hop.
• Backend VMs and target instances don't need to have IP forwarding enabled.

Paths between Google Front Ends and backends

External Application Load Balancers and external proxy Network Load Balancers use Google Front Ends (GFEs). Second layer GFEs open TCP connections to your backend VMs and send packets from the following sources:

• 35.191.0.0/16
• 130.211.0.0/22

Google Cloud uses routes in Google's network to deliver packets from those source ranges to backend VMs in your VPC network. Each VPC network includes routing paths that allow VMs to send response packets to 35.191.0.0/16 and 130.211.0.0/22.

Paths for health checks

Health checks for all load balancers and for managed instance group autohealing send packets to your backend VMs from health check probe IP address ranges.

Google Cloud uses routes in Google's network to deliver packets from health check probe systems to VMs in your VPC network. Each VPC network includes routing paths that allow VMs to send response packets to the health check probe systems.

Paths for Identity-Aware Proxy (IAP)

TCP forwarding using IAP uses 35.235.240.0/20 as an internal-only range with next hops that are entirely within Google's network. Google doesn't publish routes to 35.235.240.0/20 on the internet.

Routes in Google's network deliver packets from 35.235.240.0/20 to VMs in your VPC network when you use IAP TCP forwarding. Each VPC network includes routing paths that allow VMs to send response packets to 35.235.240.0/20.

Paths for Cloud DNS and Service Directory

The following Cloud DNS and Service Directory features use 35.199.192.0/19 as an internal-only range with next hops that are entirely within Google's network. Google doesn't publish routes to 35.199.192.0/19 on the internet.

• Cloud DNS forwarding targets that use private routing
• Cloud DNS alternative name servers that use private routing
• Private network access for Service Directory

Routes in Google's network deliver packets from 35.199.192.0/19 to VMs in your VPC network when you use these Cloud DNS and Service Directory features. Each VPC network includes routing paths that allow VMs to send response packets to 35.199.192.0/19.

Paths for Serverless VPC Access

Serverless VPC Access uses 35.199.224.0/19 as an internal-only range with next hops that are entirely within Google's network. Google doesn't publish routes to 35.199.224.0/19 on the internet.

Routes in Google's network deliver packets from 35.199.224.0/19 to Serverless VPC Access connector instances. Each VPC network includes routing paths that allow connector instances to send response packets to 35.199.224.0/19.

Paths for Private Service Connect endpoints for global Google APIs

When you create a Private Service Connect endpoint for global Google APIs, Google Cloud adds a route for the endpoint to your VPC network. The route's destination is the global internal IP address of the endpoint.

Routing order

There might be more than one applicable route for a given packet. The following steps model the process that is used to select a route.

1. Special routing paths: Some Google Cloud special routing paths not shown in your VPC network route table. For details, see Special routing paths.

   If a special routing path is applicable, your route selection model contains only the special path. All other routes are disregarded, and evaluation stops at this step.

2. Policy-based routes: Policy-based routes are evaluated after special routing paths but before other types of routes. If no policy-based routes exist in the VPC network, Google Cloud skips this step and continues to the subnet routes step.

   Google Cloud evaluates policy-based routes solely by their priority. Google Cloud evaluates a packet's source and destination for each policy-based route, starting with the highest priority policy-based route or routes. If a packet's characteristics don't match a policy-based route, Google Cloud disregards that policy-based route and continues to evaluate the next policy-based route in the sorted list. The next policy-based route to evaluate might share the same priority as the disregarded policy-based route, or it might have a lower priority.

   • If a packet's characteristics don't match any policy-based route after evaluating all policy-based routes in your route selection model, Google Cloud disregards all policy-based routes and continues to the subnet routes step.

   • If a packet's characteristics match a highest-priority policy-based route, Google Cloud first disregards all lower-priority policy-based routes. If two or more policy-based routes are left in the list, Google Cloud evaluates each of the remaining policy-based routes that have identical priorities. Google Cloud disregards any remaining policy-based routes if a packet's characteristics don't match it. After this step, your route selection model might contain one or more policy-based routes.

   • If your route selection model includes two or more matching highest-priority policy-based routes, Google Cloud selects a single policy-based route by using an internal algorithm. The selected policy-based route might not be the most specific match for the packet's source or destination. To avoid this ambiguity, we recommend that you create policy-based routes that have unique priorities.

   • If your route selection model includes only a single highest-priority policy-based route that is configured to skip other policy-based routes, Google Cloud disregards all policy-based routes and continues to the subnet routes step.

   • If your route selection model includes only a single highest-priority policy-based route that is not configured to skip other policy-based routes, Google Cloud delivers the packet to the next hop internal passthrough Network Load Balancer, and disregards all non-policy-based routes.

3. Subnet routes: Google Cloud determines whether the packet's destination fits within the destination range of a local, peering, or Network Connectivity Center subnet route in the VPC network.

   • If a packet's destination doesn't match the destination range of any local, peering, or Network Connectivity Center subnet route, Google Cloud disregards all subnet routes and continues to the Most specific destination step.

   • If a packet's destination does match the destination range of a local, peering, or Network Connectivity Center subnet route in the VPC network, the behavior is different depending on whether the subnet has been configured as a hybrid subnet:

     • For most subnets, Google Cloud exclusively uses the subnet route, attempting to send the packet to a resource in the subnet, like a VM network interface or internal forwarding rule. All other routes are disregarded, and evaluation stops at this step. If no resource is present using the packet's destination or if the resource is a stopped VM instance, the packet is dropped.

     • However, if the matched subnet route comes from a hybrid subnet, Google Cloud attempts to locate a matching destination resource in the subnet, like a VM network interface or internal forwarding rule:

       • If a resource exists in the subnet, Google Cloud exclusively uses the subnet route, attempting to send the packet to the resource. All other routes are disregarded, and evaluation stops at this step. If no resource is present at the packet's destination, the packet is dropped. If the resource is a VM that isn't running, the packet is also dropped.

       • If a resource doesn't exist in the subnet, Google Cloud ignores all subnet routes, including the matched subnet route, and continues to the Most specific destination step.

4. Most specific destination: At the beginning of this step, your route selection model contains no special routing paths, no policy-based routes, and no local, peering, or Network Connectivity Center subnet routes.

   Google Cloud determines which of the remaining applicable routes have the most specific destination that contains the destination IP address of the packet. Google Cloud disregards all other routes with less specific destinations. For example, 10.240.1.0/24 is a more specific destination than 10.240.0.0/16.

   At the end of this step, your route selection model contains only custom routes with identical destinations.

5. Select only the most favorable custom route type: In this step, Google Cloud removes all custom routes except the most favorable custom route type. Local custom routes are preferred over Network Connectivity Center dynamic routes, and Network Connectivity Center dynamic routes are preferred over peering custom routes.

   The following table summarizes the logic that Google Cloud uses in this step.

   Custom route category	What happens
   Local dynamic and local static routes	If your route model contains at least one local dynamic or local static route for the destination, Google Cloud removes the following custom route types, if they are present in the route model: Network Connectivity Center dynamic routes from hybrid spokes, in different VPC networks Peering dynamic routes (imported from other VPC networks connected using VPC Network Peering)
   Network Connectivity Center dynamic routes	If all of the following conditions are met, Google Cloud removes all peering dynamic and peering static routes from the route model: Your route model doesn't contain any local custom routes for the destination Your route mode does contain at least one Network Connectivity Center dynamic route for the destination The Network Connectivity Center dynamic route comes from from a hybrid spoke in a different VPC network
   Peering dynamic and peering static routes	The least favorable custom route type contains peering custom routes. Peering custom routes for the destination are used only when the route model doesn't contain any local custom routes or Network Connectivity Center dynamic routes for the destination.

6. Select next hops for peering custom routes from a single VPC network: Next hops for the same destination must be located in the same VPC network. This step only applies if your route model contains peering dynamic or peering static routes that are imported from two or more different VPC networks connected using VPC Network Peering.

   Google Cloud uses an internal algorithm to import peering custom routes from a single VPC network. The peer network that Google Cloud selects might change if your VPC network peers with a new VPC network or if it disconnects from an existing peer VPC network.

7. Disregard static and dynamic routes with unusable next hops: This step models situations where Google Cloud disregards next hops that are down or invalid.

   • Invalid next hop VM IP address specification: The next-hop-address of a static route must match an IP address that is assigned to a VM in the route's VPC network. The IP address must be assigned to the VM's network interface as one of the following:

     • A primary internal IPv4 address
     • An internal IPv6 address
     • An external IPv6 address

     If the IP address specified by next-hop-address matches a different type of resource (like an alias IP range) or doesn't match any resource, Google Cloud disregards the route.

   • Next hop VM stopped or deleted: Google Cloud disregards each static route whose next hop VM instance has been stopped or deleted. This behavior applies to routes whose next hops are specified using either next-hop-instance or next-hop-address. For more information, see Behavior when instances are stopped or deleted.

   • Invalid next hop load balancer IP address specification: For static routes that have a next hop load balancer specified by IP address, the IP address must match a forwarding rule of an internal passthrough Network Load Balancer that is located in the route's VPC network or in a peered VPC network. If the next hop IP address matches the forwarding rule of a different type of load balancer or doesn't match any forwarding rule, Google Cloud disregards the route.

   • Unestablished next hop Classic VPN tunnel: Google Cloud disregards each static route with a next hop Classic VPN tunnel that doesn't have an active Phase 1 (IKE) security association (SA). For more details, see Order of routes in the Classic VPN documentation.

   • Dynamic route with nonfunctional next hop: Even before the BGP session responsible for programming a dynamic route goes down, Google Cloud disregards a dynamic route if its next hop Cloud VPN tunnel, VLAN attachment, or Router appliance VM isn't functional. This situation generally only exists for a few seconds before the dynamic route is removed when the corresponding Cloud Router BGP session goes down.

   Google Cloud doesn't validate whether the guest OS of a next hop VM or a backend VM for a next hop load balancer is processing packets. For more information, see Considerations common to instance and internal passthrough Network Load Balancer next hops.

8. Disregard low priority routes: This step models how Google Cloud discards all routes except for those with the highest priority.

   After this step, your route model might be empty, or it might contain one or more routes. If your model isn't empty, all routes in your model have the following characteristics:

   • Identical priorities
   • Next hops that haven't been disregarded
   • Identical destinations
   • Route types that aren't policy-based or subnet routes

9. Select next hops for Network Connectivity Center dynamic routes from a single VPC network: Next hops for the same destination must be located in the same VPC network. This step only applies if your route model contains Network Connectivity Center dynamic routes imported from two or more hybrid spokes located in different VPC networks.

   Google Cloud uses an internal algorithm to import Network Connectivity Center dynamic routes from hybrid spokes located in a single VPC network. The selected hybrid spokes might change if you add hybrid spokes to or remove hybrid spokes from the Network Connectivity Center hub. To avoid this ambiguity, ensure that Network Connectivity Center dynamic routes have unique priorities when the following applies:

   • The routes have identical destinations.
   • The routes are imported from two or more hybrid spokes in different VPC networks.

10. Select only the most favorable preference category: Google Cloud doesn't perform equal-cost multipath (ECMP) among routes that belong to different preference categories, as defined in this step.

    Preference category	Route type and next hop type
    First preference (most preferred)	One or more static routes with next hop instances (next-hop-instance or next-hop-address) or next hop Classic VPN tunnels.
    Second preference	One or more dynamic routes of a single type.
    Third choice	A single static route with next hop internal passthrough Network Load Balancer.
    Fourth preference (least preferred)	One or more static routes with next hop default-internet-gateway.

    In this step, when two or more static routes with next hop load balancer exist, Google Cloud selects a single static route using an internal algorithm—Google Cloud doesn't perform ECMP among multiple load balancers. For more information, see Considerations for internal passthrough Network Load Balancer next hops.

    After this step, your route model might be empty, or it might contain one or more routes. If your model isn't empty, all routes in your model have these characteristics:

    • Identical preference category
    • Identical priorities
    • Next hops that haven't been disregarded
    • Next hops in one VPC network
    • Identical destinations
    • Route types that aren't policy-based or subnet routes

11. Send or drop packet: Depending on the number of routes remaining in the route model, Google Cloud sends or drops the packet:

    • If your route model contains a single route, Google Cloud sends the packet to the next hop, with the following exception:

      Next hop internal passthrough Network Load Balancers that don't have global access enabled aren't reachable from regions outside of the load balancer's region. Consequently, if a next hop load balancer doesn't have global access enabled, Google Cloud drops all packets sent from VM instances, VLAN attachments, and Cloud VPN tunnels in regions different from the load balancer's region. To change this behavior, enable global access.

    • If your route model contains two or more routes, Google Cloud performs ECMP, distributing packets among the next hops. Selection of the next hop depends on a hash calculation and the number of next hops. Google Cloud uses a five-tuple hash if the packet contains port information; otherwise, it uses a three-tuple hash. If the route model changes as subsequent packets are sent, Google Cloud might direct those packets to a different next hop even if the hash is the same.

    • If your route model is empty, Google Cloud drops the packet with an ICMP type 3, code 0 (network unreachable) message.

What's next

• To create and manage routes, see Use routes.
• To learn more about static routes, see Static routes.
• To get an overview of Google Cloud VPC networks, see VPC networks.
• To create, modify, or delete VPC networks, see Create and manage VPC networks.