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 by way of Cloud Interconnect VLAN attachments that you specify. 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 mode networks.

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 has a set of applicable routes, which are a subset of all routes in the VPC network. Applicable routes are the possible egress paths that a packet can take when sent from the instance.

• Special routing paths apply when routing back to proxy load balancers, health check systems, and other Google services. For more information, see special routing paths. These routes are not shown in any route table.

• Policy-based routes can apply to packets sent from Compute Engine VM instances or to packets received by Cloud Interconnect VLAN attachments. Policy-based routes only apply if a packet matches the criteria of the policy-based route.

• Local and peering subnet routes apply to all instances. Except for policy-based routes, no other route type can have a destination that matches or fits within the destination of a local or peering subnet route. For more details about conflict resolution among subnet, static, and dynamic routes, see Subnet and static route interactions and Subnet and dynamic route interactions.

• Custom static routes can apply to all instances or specific instances. Static routes with a tag attribute apply to instances that have that same network tag. If the route doesn't have a network tag, the route applies to all instances in the network.

• Dynamic routes apply to instances 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

The following process models the VPC network route-selection behavior, starting with the set of applicable routes that's described in the previous section.

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 most specific destination 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 most specific destination 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 evaluates non-policy-based routes in the most specific destination step and disregards all policy-based routes.

   • 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. Most specific destination: Google Cloud determines which of the 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.

   After this step, your route selection model contains no special routing paths and no policy-based routes. It includes only the routes with the most specific destinations.

4. 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 which 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.

5. 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: IP addresses specified by using next-hop-address must resolve to one of the following configurations in the same VPC network as the route:

     • A primary internal IPv4 address of a VM's network interface
     • An internal or external IPv6 address of a VM's network interface

   • Next hop VM not running: Google Cloud disregards every local or peering static route whose next hop VM instance has been stopped or deleted. This behavior applies to routes configured with next-hop-instance or next-hop-address. For more information, see Behavior when instances are stopped or deleted in the Considerations for next hop instances section.

   • Invalid next hop internal passthrough Network Load Balancer IP address specification: If a local or peering static route has a next hop load balancer by IP address, the next hop IP address must resolve to a forwarding rule for an internal passthrough Network Load Balancer, located in the route's VPC network or in a peered VPC network. If the next hop IP address resolves to a forwarding rule for a different type of load balancer or doesn't resolve a forwarding rule at all, Google Cloud disregards the route.

   • Next hop internal passthrough Network Load Balancer inaccessible: If a local or peering static route has a next hop load balancer, and if the Google Cloud resource sending the packet is located in a region different from the load balancer's region, Google Cloud disregards the route if the forwarding rule doesn't have global access enabled. The route is discarded whether the next hop is specified by name or IP address.

   • Unestablished next hop Classic VPN tunnel: Google Cloud disregards every local or peering static route whose next hop Classic VPN tunnel 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 local or peering dynamic route goes down, Google Cloud disregards a next hop Cloud VPN tunnel, Cloud Interconnect VLAN attachment, or Router appliance VM if the next hop is not 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.

6. 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 selection model might be empty, or it might contain one or more routes. If your model does contain routes, all of the routes have all of these characteristics:

   • Identical, most-specific destinations
   • Next hops all in one VPC network—the local VPC network or a single peer VPC network
   • Next hops which are not known to be down
   • Identical, highest priorities

7. Select only the most favorable preference category: Google Cloud avoids ECMP routing among different types of next hops. You can model this behavior by considering the preference category system described in the following table. This step refines your route model so that it only contains routes which are of the same route type or combination of route type and next hop type.

   Preference category	Category and next hop combination
   First choice (highest preference)	Local or peering static routes with next hop instances (next-hop-instance or next-hop-address) or next hop Classic VPN tunnels.
   Second choice	Local or peering dynamic routes.
   Third choice	Local or peering static routes with next hop internal passthrough Network Load Balancer (regardless of how the next hop is specified). Note that Google Cloud doesn't load balance among multiple static routes with different internal passthrough Network Load Balancer next hops. For more information, see Considerations for internal passthrough Network Load Balancer next hops.
   Fourth choice	Local static routes with next hop default-internet-gateway.

   At the end of this step, there could be zero routes, one route, or two or more routes in the route model.

8. Send or drop packet: What happens depends on the number of routes remaining in the route model:

   • If the route model is empty, the packet is dropped with an ICMP destination or network unreachable error. Google Cloud never falls back to a less specific route which might have a working next hop.

   • If the route model contains a single route, Google Cloud sends the packet to the next hop. For VM next hops, Google Cloud doesn't validate that the VM next hop can process packets. For details, see Considerations common to instance and internal passthrough Network Load Balancer next hops. If the single route is a subnet route or a peering subnet route, and there's no Google Cloud resource at the packet's destination IP address, the packet is dropped.

   • If the route model contains two or more routes, the routes share the same most specific destination, are located in a single VPC network, have next hops which are not known to be down, have the same highest priority, and belong to one route type and next hop combination (preference category). Google Cloud distributes packets among the next hops implementing equal-cost multipath (ECMP) using a hashing algorithm. Hash calculations are done for each packet at the time it is sent, based on the current 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.

Static routes

You can create static routes in one of two ways:

• You can create static routes manually using the Google Cloud console, gcloud compute routes create, or the routes.insert API.

• If you use the Google Cloud console to create a Classic VPN tunnel that doesn't use dynamic routing, Cloud VPN might create corresponding static routes automatically. For more information, see Cloud VPN networks and tunnel routing.

You can exchange static routes with a peered VPC network as described in Options for exchanging custom static routes in the VPC Network Peering documentation.

Note: In auto mode VPC networks, don't create custom static routes whose destinations fit inside the 10.128.0.0/9 range. That range contains automatically created subnets. Static routes with destinations inside 10.128.0.0/9 that exist in an auto mode network might be disabled unexpectedly when a new Google Cloud region becomes available. This happens because a new subnet route is created for the primary IPv4 address range of the new region's automatically created subnet. For more information, see auto mode IP ranges and considerations for auto mode VPC networks.

Route parameters

Static routes support the following attributes:

• Name and Description. These fields identify the route. A name is required, but a description is optional. Every route in your project must have a unique name.

• Network. Each route must be associated with exactly one VPC network.

• Next hop. The next hop identifies the network resource to which packets are sent. All next hop types support IPv4 destinations, and some next hop types support IPv6 destinations. For more information, see Next hops and features.

• Destination range. The destination range is a single IPv4 or IPv6 CIDR notation

  Destinations for static routes must follow the rules described in Interactions with static routes and Subnet and static route interactions. The broadest possible destination for an IPv4 static route is 0.0.0.0/0. The broadest possible destination for an IPv6 static route is ::/0.

• Priority. Lower numbers indicate higher priorities. The highest possible priority is 0, and the lowest possible priority is 65,535.

• Network tags. You can make a static route apply to only select VM instances in the VPC network, identified by a network tag. If you don't specify a network tag, Google Cloud makes the static route apply to all instances in the network. Static routes with tags are never exchanged when using VPC Network Peering.

Next hops and features

The following table summarizes static route feature support by next hop type:

Next hop type	IPv4	IPv6	ECMP^1
Next hop gateway (next-hop-gateway) Specify a default internet gateway to define a path to external IP addresses.
Next hop instance by name and zone (next-hop-instance) Send packets to a next hop VM that is identified by name and zone and is in the same project as the route. For more information, see Considerations for next hop instances.
Next hop instance by address (next-hop-address) Send packets to a next hop VM that is identified by the primary internal IPv4 address, or an internal or external IPv6 address, of its network interface. For more information, see Consideration for next hop instances.		(Preview)
Next hop internal passthrough Network Load Balancer by forwarding rule name (next-hop-ilb) and region (next-hop-ilb-region) Send packets to backends of an internal passthrough Network Load Balancer that is identified by the forwarding rule's name, region, and, optionally, project. For more information, see Considerations for internal passthrough Network Load Balancer next hops.
Next hop internal passthrough Network Load Balancer by address (next-hop-ilb) Send packets to backends of an internal passthrough Network Load Balancer that is identified by the IP address of the load balancer's forwarding rule. For more information, see Considerations for internal passthrough Network Load Balancer next hops.
Next hop Classic VPN tunnel (next-hop-vpn-tunnel) Send packets to a next hop Classic VPN tunnel by using either policy-based routing or route-based VPN. For more information, see Considerations for Classic VPN tunnel next hops.

¹Equal-cost multipath (ECMP) means that two or more static routes can share the same destination range and priority. Although you can create two or more static routes in a VPC network with the same destination, same priority, and default internet gateway next hop, the effect is the same as having a single static route that uses the default internet gateway next hop for that destination and priority.

Next hop project and network

A static route next hop is associated with both a VPC network and a project:

• Network: Except as indicated in the table below, the next hop's VPC network must match the route's VPC network.

• Project: Except as indicated in the table below, the next hop must be located in the project that contains the next hop's VPC network (a standalone project or a Shared VPC host project). Some next hops can be located in Shared VPC service projects.

Next hop type	Can be in a peered VPC network	Can be in a Shared VPC service project
Next hop gateway (next-hop-gateway)
Next hop instance by name (next-hop-instance)
Next hop instance by address (next-hop-address)
Next hop internal passthrough Network Load Balancer by forwarding rule name and region (next-hop-ilb)
Next hop internal passthrough Network Load Balancer by address (next-hop-ilb)
Next hop Classic VPN tunnel (next-hop-vpn-tunnel)

Considerations common to instance and internal passthrough Network Load Balancer next hops

Instance-based routing refers to a static route with a next hop that is a VM instance (next-hop-instance or next-hop-address).

Internal passthrough Network Load Balancer as a next hop refers to a static route with a next hop that is an internal passthrough Network Load Balancer (next-hop-ilb).

When you configure instance-based routing or an internal passthrough Network Load Balancer as a next hop, consider the following guidelines:

• You must configure the backend VMs or the next hop instance to forward packets from any source IP address. To configure forwarding, enable IP forwarding (can-ip-forward) on a per-VM basis when you create the VM. For VMs created automatically as part of a managed instance group, enable IP forwarding in the instance template used by the instance group. You must make this configuration change in addition to any operating system configuration necessary to route packets.

• Software running on the backend VM or the next hop instance must be configured appropriately. For example, third-party appliance VMs that act as routers or firewalls must be configured according to the manufacturer's instructions.

• Backend VMs or the next hop instance must have appropriate firewall rules. You must configure firewall rules that apply to the packets being routed. Keep the following in mind:

  • Ingress firewall rules applicable to instances that perform routing functions must include the IP addresses of routed packet sources. The implied deny ingress rule blocks all incoming packets, so you must at least create custom ingress allow firewall rules.
  • Egress firewall rules applicable to instances that perform routing functions must include the IP addresses of routed packet destinations. The implied allow egress rule permits this unless you've created a specific egress deny rule to override it.
  • Take into account whether the backend VM or Next Hop Instance is performing Network Address Translation (NAT) when creating your firewall rules.

  For more information, see Implied firewall rules.

• The source region of a packet sent by a backend VM or a next hop instance is the region where the backend VM or next hop instance is located. For example, packets processed by backend VMs or next hop instances in us-west1 can be sent to destinations that are accessible only in us-west1 even if the backend VM or next hop instance originally received the packet from a resource in a region different from us-west1. Examples of resources that are accessible only in the same region as a VM sending a packet include the following:

  • Internal passthrough Network Load Balancers, internal Application Load Balancers, and regional internal proxy Network Load Balancers with global access turned off
  • Cloud VPN tunnels, Cloud Interconnect VLAN attachments, and Network Connectivity Router appliance VMs if the VPC network uses regional dynamic routing

Considerations for next hop instances

• Next hop by instance name and zone (next-hop-instance): When you create a static route that has a next hop instance specified by instance name and zone, Google Cloud requires that an instance with that name exists in the specified zone, and meets the following:

  • The instance is located in the same project as the route.
  • The instance has a network interface (NIC) in the route's VPC network (not a peered VPC network).

  As long as the static route exists, the following applies:

  • Google Cloud automatically updates programming for the next hop in either of the following cases:

    • The primary internal IPv4 address of the next hop instance changes, or
    • You replace the next hop instance, and the replacement instance has the same name, is in the same zone and project, and has a network interface in the route's VPC network.

  • Google Cloud doesn't update programming for the next hop in the following cases:

    • When the instance is deleted.
    • The IPv6 address range assigned to the instance's NIC changes.
    • When the IPv4 or IPv6 address of the instance is unassigned.

• Next hop instance IP address (next-hop-address): Valid next hop VM IP addresses are the following:
  • The primary internal IPv4 address of a VM network interface.
  • Any internal or external IPv6 address in the /96 IPv6 address range assigned to a VM network interface.

  When you create a static route with a next hop instance specified by an IP address, Google Cloud accepts any VM-assigned IP address that fits within a subnet range of a subnet in the same VPC network as the route. However, Google Cloud only programs the route if the next hop address is a valid next hop VM IP address. For example, if you create a route and specify the next hop as an IP address that comes from an alias IP range, the route is created. However, because alias IP addresses aren't valid next hop VM IP addresses, the route is not programmed.

  Google Cloud automatically updates programming for the next hop if the next hop IP address is moved to a different VM, if the IP address remains a valid next hop VM IP address.

• Next hop instances in Shared VPC service projects: When you specify a next hop VM by IP address, the VM can be located in either the same project as the route (a standalone project or a Shared VPC host project) or the VM can be located in a Shared VPC service project. When you specify a next hop VM by instance name and zone, the next hop VM must be located in the same project as the route and VPC network (a standalone project or a Shared VPC host project).

• Region-to-region costs and latency: When you use a VM as a next hop, the next hop is located in a zone of a region. The route that uses the next hop is available to all instances in the same VPC network or to select instances with a matching network tag. Google Cloud doesn't consider regional distance for routes that use an instance as a next hop, so it is possible to create a route that sends traffic to a next hop VM in a different region. Sending packets from one region to another adds outbound data transfer costs and introduces network latency.

• No health checking, no configuration validation: Google Cloud never checks whether a next hop instance meets all requirements outlined in the Considerations common to instance and internal passthrough Network Load Balancer next hops section. Disabling the VM's network interface by configuring the guest operating system of the instance doesn't cause Google Cloud to disregard the next hop instance.

• No symmetric hashing when connecting two VPC networks: Google Cloud doesn't offer symmetric hashing when using two or more next hop VMs that have multiple network interfaces in a configuration that meets all of the following criteria:

  • The VMs have one network interface in one VPC network and another interface in a second VPC network.
  • In each VPC network, there exists a set of at least two custom static routes for the same destination, using the same priority, where each route in the set references a unique next hop VM.

  If you use two or more VMs with multiple interfaces to connect VPC networks, and you require that the same VM processes packets for a given connection in both directions, you need symmetric hashing, which is only supported by next hop internal passthrough Network Load Balancers. For more information, see Symmetric hashing.

• Behavior when instances are stopped or deleted: Google Cloud doesn't prevent you from stopping or deleting a static route next hop VM (specified by either name and zone or internal address). When a next hop VM is not running, routing for the destination depends on whether other routes for the exact same destination exist and whether those other routes have next hops that are running. To illustrate this behavior, consider the following examples:
  • Packets whose destinations fit in 192.168.168.0/24 are sent to the next hop of route-vm-b in the following situation where the next hop for the highest priority route is not running. This routing happens because Google Cloud disregards next hops that are not running before considering the disregard low priority routes step of the routing order:
  • route-vm-a, destination 192.168.168.0/24, priority 10, next hop VM is stopped
  • route-vm-b, destination 192.168.168.0/24, priority 20, next hop VM is running

  • route-vm-c, destination 192.168.168.0/24, priority 30, next hop VM is running

  • Packets whose destinations fit in 192.168.168.0/24 are dropped in this next example where all next hop VMs for the 192.168.168.0/24 routes are not running, even though a route for the broader 192.168.0.0/16 has a next hop VM that is running. The packets are dropped because Google Cloud disregards routes with broader (shorter subnet mask length) destination ranges at the most specific destination step, which happens before the disregard custom static routes whose next hops are not running step of the routing order:

  • route-vm-x, destination 192.168.168.0/24, priority 10, next hop VM is stopped

  • route-vm-y, destination 192.168.168.0/24, priority 20, next hop VM is stopped

  • route-vm-z, destination 192.168.0.0/16, priority 0, next hop VM is running

Considerations for internal passthrough Network Load Balancer next hops

• Supported forwarding rules. Google Cloud supports only next hop internal passthrough Network Load Balancer forwarding rules. Google Cloud does not support next hop forwarding rules used by other load balancers, protocol forwarding, or as Private Service Connect endpoints.

• Specification methods and forwarding rule network and project. You can specify a next hop forwarding rule by using one of following three methods. The specification method that you use determines whether the forwarding rule's network must match the route's network and in what project the forwarding rule can be located:

  • By forwarding rule name (--next-hop-ilb) and region (--next-hop-ilb-region): When you specify a next hop forwarding rule by name and region, the forwarding rule's network must match the route's VPC network. The forwarding rule must be located in the same project that contains the forwarding rule's network (a standalone project or a Shared VPC host project).

  • By forwarding rule resource link: A forwarding rule's resource link uses the format /projects/PROJECT_ID/regions/REGION/forwardingRules/FORWARDING_RULE_NAME, where PROJECT_ID is the project ID of the project that contains the forwarding rule, REGION is the forwarding rule's region, and FORWARDING_RULE_NAME is the forwarding rule's name. When you specify a next hop forwarding rule by its resource link, the forwarding rule's network must match the route's VPC network. The forwarding rule can be located in either the project that contains the forwarding rule's network (a standalone project or a Shared VPC host project) or a Shared VPC service project.

  • By a forwarding rule IPv4 address: When you specify a next hop forwarding rule by its IPv4 address, the forwarding rule's network can be either the route's VPC network or a peered VPC network. The forwarding rule can be located in either the project that contains the forwarding rule's network (a standalone project or a Shared VPC host project) or a Shared VPC service project.

• Effect of global access. Custom static routes using internal passthrough Network Load Balancer next hops are programmed in all regions. Whether the next hop is usable depends on the load balancer's global access setting. With global access enabled, the load balancer next hop is accessible in all regions of the VPC network. With global access disabled, the load balancer next hop is only accessible in the same region as the load balancer. With global access disabled, packets sent from another region to a route using an internal passthrough Network Load Balancer next hop are dropped.

• When all backends are unhealthy. When all backends of an internal passthrough Network Load Balancer fail health checks, the routes using that load balancer next hop are still in effect. Packets processed by the route are sent to one of the next hop load balancer's backends according to traffic distribution.

• Forwarding rules that use a common internal IP address (--purpose=SHARED_LOADBALANCER_VIP) are not supported. Next hop internal passthrough Network Load Balancers and internal passthrough Network Load Balancer forwarding rules with a common IP address are mutually exclusive features. A next hop internal passthrough Network Load Balancer must use an IP address that is unique to the load balancer's forwarding rule so that only one backend service (one load balancer) is unambiguously referenced. It's possible for forwarding rules that use a common internal IP address to reference different backend services (different internal passthrough Network Load Balancers).

• Multiple routes with the same destinations and priorities, but different next hop internal passthrough Network Load Balancers. Google Cloud never distributes traffic among two or more next hop internal passthrough Network Load Balancers using ECMP. Instead, Google Cloud selects just one next hop internal passthrough Network Load Balancer using a deterministic, internal algorithm. To avoid this ambiguity, you can use unique network tags for each route.

  

  Google Cloud selects a single next hop when static routes with different internal passthrough Network Load Balancer next hops have the same priority and destination.

• Multiple routes with the same destinations, priorities, and next hop internal passthrough Network Load Balancers. Without a network tag, Google Cloud does not allow you to create multiple static routes that have the same combination of destination, priority, and internal passthrough Network Load Balancer next hop. With network tags, you can create multiple static routes having the same combination of destination, priority, and internal passthrough Network Load Balancer next hop.

Considerations for Classic VPN tunnel next hops

• Region-to-region costs and latency: Google Cloud doesn't consider regional distance for routes that use a next hop Classic VPN tunnel. Sending traffic to a next hop Classic VPN tunnel in another region adds outbound data transfer costs and introduces network latency. As a best practice, use an HA VPN tunnel with dynamic routing instead because that configuration considers regional distance.

• Behavior when Classic VPN tunnels are not running: Custom static routes whose next hops are Classic VPN tunnels are not automatically removed when the Classic VPN tunnels are not running. For details about what happens when tunnels are not running, see When tunnels are down in the Classic VPN documentation.

What's next

• To create and manage routes, see Use 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.