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
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 route Created automatically for each subnet IP address range	VPC network Forwards packets to VMs and internal load balancers	Created, updated, and removed automatically by Google Cloud during subnet lifecycle events. Local subnet routes apply to the whole VPC network.
Custom routes
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
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.
VPC Network Peering routes
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.
Peering static and dynamic routes 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. Imported 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 routes
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.
Policy-based routes
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 are evaluated before other routes are evaluated. 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.

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.

Subnet routes

Subnet routes define paths to resources like VMs and internal load balancers in a VPC network.

Each subnet has at least one subnet route whose destination matches the primary IPv4 range of the subnet. If the subnet has secondary IP ranges, there's a corresponding subnet route for each of its secondary IP address ranges. If the subnet has an IPv6 range, there's a corresponding subnet route for the IPv6 address range. For more information about subnet IP ranges, see Subnets.

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.
• Peering subnet routes that are imported from networks connected using VPC Network Peering.
• Network Connectivity Center subnet routes that are imported from VPC spokes of an Network Connectivity Center hub.

Interactions with 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 with 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 for a prefix learned by a BGP session of a Cloud Router if the prefix 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 or a peered VPC network 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 local or peering 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 or a peered VPC network 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 local or peering dynamic routes for the received conflicting prefixes.

• Google Cloud removes any existing local or peering 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 or peering dynamic route. For example:

  • If your VPC network has a local or peering 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 or peering 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.

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 Border Gateway Protocol (BGP) messages they receive, applicable BGP route policies (Preview), and Cloud Router custom learned routes that you configure. The Cloud Router control plane installs dynamic routes regionally based on the dynamic routing mode of the VPC network:

• If a VPC network uses regional dynamic routing mode, the Cloud Routers in each region create dynamic routes only in the same region as the Cloud Router.

• If a VPC network uses global dynamic routing mode, the Cloud Routers in each region create dynamic routes in all regions of the VPC network.

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 in Network Connectivity Center

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 after one of the following conditions is met:

• The peer router's graceful restart timer has expired (if the BGP peer supports graceful restart).

• The Cloud Router's hold timer has expired. The Cloud Router hold timer is proportional to the configurable Cloud Router keepalive timer.

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

Peering subnet routes

Peering subnet routes define paths to resources in subnets in another VPC network that are connected through VPC Network Peering. For more information, see Options for exchanging subnet routes.

Local subnet and peering subnet routes cannot overlap. For more information, see Subnet and peering subnet route interactions.

The number of subnet routes per peering group is controlled by the per-network subnetwork ranges per peering group quota.

Peering static and dynamic routes

When you use VPC Network Peering to connect two VPC networks, you can export static and dynamic routes from one network and import them into the other network. For more information, see:

• Options for exchanging custom static routes

• Options for exchanging custom dynamic routes

The number of static routes per peering group and dynamic routes per region per peering group are limited by per-network static and dynamic route quotas.

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 the most specific custom routes.

5. Next hops in a single VPC network: This step is only applicable if the VPC network whose route behavior you are modeling is connected to one or more VPC networks using VPC Network Peering. With VPC Network Peering, custom routes with identical destinations might exist in more than one of the networks in the peering group. The requirement modeled at this step is that Google Cloud selects next hops that are all in a single VPC network.

   • If one or more of the routes in your route model have next hops inside the VPC network you're modeling, disregard all routes that have next hops in peer networks. In this situation, Google Cloud only uses next hops in the local VPC network, even if next hops for the same destination exist in one or more peer VPC networks.

   • If none of the routes in your route model have next hops inside the VPC network you're modeling, and all next hops exist in multiple peer networks, Google Cloud uses an internal algorithm to select a single peer network with the next hops for the most specific destinations. Route priority is not considered at this point. Further, if your VPC network peers with a new VPC network or if it disconnects from an existing peer VPC network, the VPC network selected for the next hops might change.

   After this step, your route selection model contains only the routes with the most specific destinations, and the next hops for these routes are all in a single VPC network.

6. 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.

7. 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
   • Next hops in one VPC network
   • Identical destinations
   • Route types that aren't policy-based or subnet routes

8. 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.
   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

9. 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.