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

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

When you create a VPC network, it includes a system-generated IPv4 default route (0.0.0.0/0). When you create a dual-stack subnet with an external IPv6 address range in a VPC network, a system-generated IPv6 default route (::/0) is added to that network if the route doesn't already exist. Default routes serve these purposes:

Google Cloud only uses a default route if a route with a more specific destination does not apply to a packet. For information about how destination specificity and route priority are used to select a route, see routing order.

If you want to completely isolate your network from the internet or if you need to replace the default route with a custom route, you can delete the default route:

  • IPv4 only: If you want to route internet traffic to a different next hop, you can replace the default route with a custom static or dynamic route. For example, you could replace it with a custom static route whose next hop is a proxy VM.

  • IPv4 and IPv6: If you delete the default route and do not replace it, packets destined to IP ranges that are not covered by other routes are dropped.

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.

Subnet routes always have the most specific destinations. They cannot be overridden by other routes, even if another route has a higher priority. This is because Google Cloud considers destination specificity before priority when selecting a route. Google Cloud uses 0 as the priority for all subnet routes.

Interactions with static routes

Local subnet routes and imported peering subnet routes interact with custom static routes in the following ways:

  • Google Cloud does not let you create a custom static route that has an equal or narrower destination than any subnet route or peering subnet route. For example:

    • If a local subnet route or a peering subnet route exists for the 10.70.1.0/24 destination, you cannot create a new custom static route for 10.70.1.0/24, 10.70.1.0/25, 10.70.1.128/25, or any other destinations that fit within 10.70.1.0/24.

    • If a local subnet route or a peering subnet route exists for the 2001:0db8:0a0b:0c0d::/64 destination, you cannot create a new custom static route for 2001:0db8:0a0b:0c0d::/64 or any destination that fits within 2001:0db8:0a0b:0c0d::/64, such as 2001:0db8:0a0b:0c0d::/96.

  • Conversely, Google Cloud does not let you create a new subnet route or a peering subnet route whose destination exactly matches or is broader than (contains) an existing custom static route. For example:

    • If your VPC network has a custom static route for the 10.70.1.128/25 destination, Google Cloud prohibits the creation of any subnet route or peering subnet route that has a primary or secondary subnet IPv4 address range of 10.70.1.128/25, 10.70.1.0/24, or any other range that contains all the IPv4 addresses in 10.70.1.128/25.

    • If your VPC network has a custom static route for the 2001:0db8:0a0b:0c0d::/96 destination, Google Cloud prohibits the creation of any dual-stack subnet route or peering subnet route that has an IPv6 address range of 2001:0db8:0a0b:0c0d::/64 or any other range that contains all the IPv6 addresses in 2001:0db8:0a0b:0c0d::/96.

Interactions with dynamic routes

Local subnet routes and imported peering subnet routes interact with Cloud Routers in the following ways:

  • When Cloud Routers learn a prefix that exactly matches the destination of an existing subnet or peering subnet route, Google Cloud does not create any custom dynamic route for the conflicting prefix. For example, when a subnet or peering subnet route with destination 10.70.1.0/24 exists, if Cloud Routers in the VPC network receive the 10.70.1.0/24 prefix through BGP, Google Cloud uses the subnet or peering subnet route, and does not create any custom dynamic route for 10.70.1.0/24.

    • When a subnet or peering subnet route whose destination exactly matches a prefix learned by Cloud Routers in the VPC network is created, Google Cloud removes the custom dynamic route for the conflicting prefix in order to make room for the subnet or peering subnet route.
  • When Cloud Routers learn prefixes that fit within the destination of an existing subnet or peering subnet route, Google Cloud does not create any custom dynamic routes for the conflicting prefixes. For example, when a subnet or peering subnet route with destination 10.70.1.0/24 exists, if Cloud Routers in the VPC network receive the 10.70.1.0/25 and 10.70.1.128/25 prefixes through BGP, Google Cloud uses the subnet or peering subnet route, and does not create any custom dynamic routes for 10.70.1.0/25 and 10.70.1.128/25.

    • When a subnet or peering subnet route whose destination contains prefixes learned by Cloud Routers in the VPC network is created, Google Cloud removes the custom dynamic routes for the conflicting prefixes in order to make room for the subnet or peering subnet route.

Lifecycle of subnet routes

Subnet routes are created, updated, and deleted when you create, modify, or delete subnets or their subnet IP address ranges:

  • When you add a subnet, Google Cloud creates a corresponding subnet route for the subnet's primary IP address range.

  • Auto mode VPC networks create a subnet route for the primary IP ranges of each of their automatically created subnets. You can delete these subnets only if you convert the auto mode VPC network to custom mode.

  • You cannot delete a subnet route unless you modify or delete the subnet:

    • When you remove a secondary range from a subnet, the subnet route for that secondary range is deleted automatically.

    • When you delete a subnet, all subnet routes for both primary and secondary ranges are deleted automatically. You cannot delete the subnet route for the subnet's primary range in any other way.

The number of subnet routes in a VPC network is limited by the Maximum number of subnet IP ranges (primary and secondary).

Dynamic routes

Cloud Routers instruct the VPC network to create, update, and remove dynamic routes based on Border Gateway Protocol (BGP) messages they receive 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:

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:

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:

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 return paths apply when routing back to proxy load balancers, health check systems, and other Google services. For more information, see load balancer return 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 return paths

VPC networks have special routes for certain services. These routes are defined outside of your VPC network, in Google's production network. They don't appear in your VPC network route table. You cannot remove or override them, even if you delete or replace a default route in your VPC network. However, you can allow or deny packets by using VPC firewall rules, network firewall policies, or hierarchical firewall policies.

Load balancer return paths

Google Cloud uses special routes outside your VPC network to deliver packets between:

  • Client systems and load balancer backends (for external passthrough Network Load Balancers)
  • Proxy systems and load balancer backends (for external proxy load balancers)
  • Health check probers and load balancer backends
Paths between Google Front End (GFE) proxies and backends

Global external Application Load Balancers, Classic Application Load Balancers, classic proxy Network Load Balancers, and global external proxy Network Load Balancers use Google Front End (GFE) systems as proxies.

When a client sends a request to the load balancer, GFEs terminate that first TCP connection. The GFEs then open a second TCP connection to the backend VMs. Google Cloud uses routes defined outside your VPC network to route packets between the GFE proxies and the backend VMs.

Paths to external passthrough Network Load Balancer backends

For external passthrough Network Load Balancers, Google Cloud uses routes defined outside your VPC network to route packets between clients and backend VMs.

Health checks for all load balancer types

Packets sent from Google Cloud health check probe systems use packet sources documented in Probe IP ranges and firewall rules.

IAP

Google Cloud includes routes to and from 35.235.240.0/20 in each VPC network to support TCP forwarding using IAP. Google's production network uses 35.235.240.0/20 as an internal-only range. Next hops for 35.235.240.0/20 are entirely within Google's production network.

Cloud DNS and Service Directory

Google Cloud includes routes to and from 35.199.192.0/19 in each VPC network to support Cloud DNS forwarding targets that use private routing, Cloud DNS alternative name servers that use private routing, and private network access for Service Directory. Google's production network uses 35.199.192.0/19 as an internal-only range. Next hops for 35.199.192.0/19 are entirely within Google's production network.

Serverless VPC Access

Google Cloud includes routes to and from 35.199.224.0/19 in each VPC network to support Serverless VPC Access. Google's production network uses 35.199.224.0/19 as an internal-only range. Next hops for 35.199.224.0/19 are entirely within Google's production network.

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 return paths: Special return paths are not shown in your VPC network's route table. Routes that you configure in a VPC network do not apply to response packets for certain Google Cloud load balancers, health check systems, Identity-Aware Proxy (IAP), and Cloud DNS proxies. For details, see Special return paths.

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

  2. Policy-based routes: Policy-based routes are evaluated after special return 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 do not 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 do not 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. The most specific destination could be any type of route; however, subnet routes, peering subnet routes, and special return paths are the most specific by definition.

    After this step, your route selection model contains no special return paths or 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 custom static routes whose next hops are not running: This step models two situations where Google Cloud disregards next hops that it considers to be not running. This step only applies to custom static routes. Custom dynamic routes are automatically added and removed using BGP advertisements instead.

    • Google Cloud ignores every next hop VM instance (next-hop-instance or next-hop-address) if the next hop VM has been stopped or deleted. For more details, see Behavior when instances are stopped or deleted in the Considerations for next hop instances section. If your route model contains static routes whose next hop VMs are stopped or deleted, remove those routes from your model.

    • Google Cloud ignores every custom static route that uses a next hop Classic VPN tunnel if the tunnel does not have a Phase 1 (IKE) security association (SA). For more details, see Order of routes in the Classic VPN documentation. If your route model contains static routes whose next hops are Classic VPN tunnels without established IKE SAs, remove those routes from your model.

  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) Custom static routes with a running next hop instance (next-hop-instance or next-hop-address) or IKE SA established next hop Classic VPN tunnel
    Second choice Custom dynamic routes learned from any BGP session of any Cloud Router
    Third choice A single custom static route with an internal passthrough Network Load Balancer next hop
    Google Cloud uses an internal algorithm to select a single next hop internal passthrough Network Load Balancer, ignoring the other internal passthrough Network Load Balancer next hops with the same priority. For more details, see "Same destination and multiple next hop internal passthrough Network Load Balancers" in the Considerations for internal passthrough Network Load Balancer next hops section.
    Fourth choice A custom static route using the default-internet-gateway next hop

    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 exchange static routes with a peered VPC network as described in Options for exchanging custom static routes in the VPC Network Peering documentation.

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 ECMP1
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 by the primary IPv4 address of its network interface. For more information, see Considerations for next hop instances.
Next hop internal passthrough Network Load Balancer by forwarding rule name and region (next-hop-ilb)
Send packets to backends of an internal passthrough Network Load Balancer identified by the forwarding rule's name and region. 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.
1Equal-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:

    • 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 a static route whose next hop is specified by instance name and zone 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 does not 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 internal IP address (next-hop-address): When you create a static route that has a next hop instance specified by an internal IPv4 address, Google Cloud verifies that the next hop VM IPv4 address fits within a subnet IPv4 range of a subnet in the route's VPC network. However, Google Cloud programs the route only if the next hop address is a primary internal IPv4 address that is assigned to a VM NIC in the route's VPC network (not a peered VPC network).

    Google Cloud automatically updates programming for the next hop when the next hop IPv4 address is moved to a different VM, provided that the replacement VM meets the same requirements.

  • 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 does not 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 does not cause Google Cloud to disregard the next hop instance.

  • No symmetric hashing when connecting two VPC networks: Google Cloud does not 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 details about symmetric hashing, see Symmetric hashing in the internal passthrough Network Load Balancers as next hops documentation.

  • Behavior when instances are stopped or deleted: Google Cloud does not 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).

  • Same destination and multiple next hop internal passthrough Network Load Balancers. If you create two or more custom static routes with the same destination, using different internal passthrough Network Load Balancer next hops, Google Cloud never distributes traffic among the load balancer next hops using ECMP. If the routes have unique priorities, Google Cloud uses the next hop internal passthrough Network Load Balancer from the route with the highest priority. If the routes have equal priorities, Google Cloud still selects just one next hop internal passthrough Network Load Balancer. In this latter situation, as illustrated in the diagram below, Google Cloud uses a deterministic, internal algorithm to select a single next hop forwarding rule (forwarding-rule-a), ignoring other routes with the same priority.

    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 destinations and the same next hop internal passthrough Network Load Balancer.

    With instance tags:

    If you use instance tags (also called network tags), you can use the same next hop internal passthrough Network Load Balancer for multiple custom static routes with the same destination and priority.

    Without instance tags: Without instance tags, you cannot create multiple custom static routes having the same combination of destination, priority, and internal passthrough Network Load Balancer next hop. For example, route-x, route-y, and route-z can all be created, but route-x-copy cannot be created.

    Static routes that don't have instance tags cannot be created with the same destination, priority, and internal passthrough Network Load Balancer next hop.
  • Instance tags.

    You can specify instance tags (also called network tags) so that the next-hop route only applies to client instances that have been configured with the tag. This lets you select which client instances get populated with which tagged next-hop route and which set of appliances to route your traffic to.

    You don't need to segregate the different client instances into separate VPC networks, each pointing to their preferred internal passthrough Network Load Balancer front-ending a set of appliances.

  • Multiple routes to the same destination prefix. With instance tags, you can specify multiple routes to the same destination with different internal load balancers as next-hops. You can use different instance tags or different priorities for these same destination routes.

Considerations for Classic VPN tunnel next hops

  • Region-to-region costs and latency: Google Cloud does not 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