Static routes (original) (raw)

Skip to main content

• Technology areas

  • Overview
  • Guides
  • Reference
  • Resources

• Cross-product tools

• Console

• Discover

• Virtual Private Cloud overview

• Get started

• VPC networks

• Subnets

• IPv6 support

• Create and manage VPC networks

• Add networking features

• Configure VMs

• Add network tags

• Add capabilities

• Network Connectivity Center

• Hybrid Subnets

  • About migrating to Google Cloud with Hybrid Subnets
  • Prepare for Hybrid Subnets connectivity
  • Migrate to Google Cloud with Hybrid Subnets
  • Disable hybrid subnet routing

• Access APIs and services

• Choose a private access option

• Private Service Connect

  • Overview
  • Compatibility
  • Deployment patterns
  • Architecture
  • Security
  • Service consumers
    * Backends
    * About backends
    * Create a backend
    * Access published services
    * Access regional Google APIs
    * Access global Google APIs
    * Manage consumer security
  • Monitor connections

• Access APIs from VMs with external IP addresses

• Monitor

• VPC Flow Logs

  • Overview
  • About VPC Flow Logs records
  • About traffic flows
  • Configure VPC Flow Logs
  • Configure organization policy constraints
  • Access flow logs

• Control access

• Manage resources by using custom constraints

• Create and manage tags for VPC resources

• Troubleshoot

• Troubleshoot internal connectivity between VMs

• Troubleshoot policy and access problems

• Advanced topics

• Advanced VPC concepts

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

For a general overview of routes in Google Cloud, see theRoutes overview.

Considerations for creating 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 theroutes.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.

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 inInteractions between subnet routes and static routes and VPC Network Peering 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:
  • A static route without a network tag applies to all resources in the VPC network, including all VM instances, Cloud VPN tunnels, Cloud Interconnect VLAN attachments, Router appliances, and Envoy proxies in proxy-only subnets.
  • A static route with a network tag only applies to VM instances that have that network tag. It doesn't apply to any other resources.
  • 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:

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.

2IPv6 support depends on theNext hop project and network.

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 following table, the next hop's VPC network must match the route's VPC network.
• Project: except as indicated in the following table, 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.

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-west1can 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.
    When you specify a next hop instance by IP address, packets are routed to the network interface of the instance, not the specific 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 hopssection. 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 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:
  • You have the following routes and VM states:
    * route-a, destination 192.168.168.0/24, priority 10, next hop VM vm-a is stopped
    * route-b, destination 192.168.168.0/24, priority 20, next hop VM vm-b is running
    * route-c, destination 192.168.168.0/24, priority 30, next hop VM vm-c is running

  In this example, packets whose destinations fit in 192.168.168.0/24are sent to the vm-b next hop because the vm-a next hop of the highest priority route-a is not running. This happens because thedisregard static and dynamic routes with unusable next hops step precedes the disregard low priority routes step in the Google Cloud routing order.

  • You have the following routes and VM states:
    * route-x, destination 192.168.168.0/24, priority 10, next hop VM vm-x is stopped
    * route-y, destination 192.168.168.0/24, priority 20, next hop VM vm-y is stopped
    * route-z, destination 192.168.0.0/16, priority 0, next hop VM vm-z is running

  In this example, packets whose destinations fit in 192.168.168.0/24are dropped because the next hop VMs for the two 192.168.168.0/24routes (route-x and route-y) are not running, even though a route for the broader 192.168.0.0/16 destination exists (route-z) with a running next hop VM. This happens because the most specific destination step precedes thedisregard static and dynamic routes with unusable next hops step in the Google Cloud routing order.

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.
  Choose one of the following methods and ensure that the IP version of your forwarding rule matches the IP version of the static route that you create:
  • 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, wherePROJECT_ID is the project ID of the project that contains the forwarding rule,REGION is the forwarding rule's region, andFORWARDING_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 IP address: when you specify a next hop forwarding rule by its IPv4 or IPv6 address, the forwarding rule's network can be either the route's VPC network_or_ a VPC network that's connected to the route's VPC network by using either VPC Network Peering or NCC. NCC supports a next hop internal passthrough Network Load Balancer in a VPC spoke subject to NCC requirements for connectivity. 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 that use a common IP address to reference different backend services (different internal passthrough Network Load Balancers)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. Traffic sent to a next-hop internal passthrough Network Load Balancer configured with a shared IP address is silently dropped.
• 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 withdynamic routinginstead 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, seeWhen tunnels are downin the Classic VPN documentation.

Considerations for NCC

• You can create static routes from your VPC spokes to internal passthrough Network Load Balancers that are accessible through the NCC hub.
• Additional limitations apply to these NCC static routes. For more information, see thestatic routes overview.

What's next

• To create and manage routes, see Use routes.
• To get a general overview of routes Google Cloud, see Routes.

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2026-06-15 UTC.