Static routes

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 cancreate static routes manually using theGoogle Cloud console,gcloud compute routescreate, ortheroutes.insert API.

• If you use the Google Cloud console to create a Classic VPN tunnelthat doesn't use dynamic routing, Cloud VPN might createcorresponding static routes automatically. For more information, seeCloud VPN networks and tunnelrouting.

You can exchange static routes with a peered VPC network asdescribed inOptions for exchanging custom staticroutes in theVPC Network Peering documentation.

Route parameters

Static routes support the following attributes:

• Name andDescription. These fields identify the route. A name isrequired, but a description is optional. Every route in yourproject musthave a unique name.

• Network. Each route must be associated with exactly oneVPC network.

• Next hop. The next hop identifies the network resource to which packetsare sent. All next hop types support IPv4 destinations, and some next hoptypes support IPv6 destinations. For more information, seeNext hops andfeatures.

• Destination range. The destination range is a single IPv4 or IPv6CIDRnotation.

  Destinations for static routes must follow the rules described inInteractions between subnet routes and staticroutes andVPC Network PeeringSubnet and static routeinteractions. Thebroadest possible destination for an IPv4 static route is0.0.0.0/0. Thebroadest possible destination for an IPv6 static route is::/0.

• Priority. Lower numbers indicatehigher priorities. The highestpossible priority is0, and the lowest possible priority is65,535.

• Network tags. You can make a static route apply toonly select VMinstances in the VPC network, identified by anetworktag:

  • A static routewithout a network tag applies to all resources in theVPC network, including all VM instances,Cloud VPN tunnels, Cloud Interconnect VLAN attachments,Router appliances, and Envoy proxies in proxy-only subnets.

  • A static routewith a network tagonly applies to VM instances thathave that network tag. It doesn't apply to any other resources.

  • Static routes with tags are never exchanged when usingVPC Network Peering.

Next hops and features

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

Next hop project and network

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

• Network: except as indicated in the following table, the next hop'sVPC network must match the route's VPC network.

• Project: except as indicated in the following table, the next hop mustbe located in the project that contains the next hop's VPCnetwork (a standalone project or a Shared VPC host project). Some nexthops 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 VMinstance (next-hop-instance ornext-hop-address).

Internal passthrough Network Load Balancer as a next hop refers to a static route with a next hopthat 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 forwardpackets from any source IP address. To configure forwarding,enable IPforwarding (can-ip-forward) on aper-VM basis when you create the VM. For VMs created automatically as partof a managed instance group, enable IP forwarding in the instance templateused by the instance group. You must make this configuration changeinaddition to any operating system configuration necessary to route packets.

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

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

  • Ingress firewall rules applicable to instances that perform routingfunctions must include the IP addresses ofrouted packet sources. Theimplied deny ingress rule blocks all incoming packets, so you must at leastcreate custom ingress allow firewall rules.
  • Egress firewall rules applicable to instances that perform routingfunctions must include the IP addresses ofrouted packet destinations.The implied allow egress rule permits this unless you've created a specificegress deny rule to override it.
  • Take into account whether the backend VM or Next Hop Instance isperforming Network Address Translation (NAT) when creating your firewallrules.

  For more information, seeImplied firewall rules.

• The source region of a packet sent by a backend VM or a next hop instanceis the region where the backend VM or next hop instance is located. Forexample, packets processed by backend VMs or next hop instances inus-west1can be sent to destinations that are accessible only inus-west1 even if thebackend VM or next hop instance originally received the packet from a resourcein a region different fromus-west1. Examples of resources that areaccessible only in the same region as a VM sending a packet include thefollowing:

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

Considerations for next hop instances

• Next hop by instance name and zone (next-hop-instance): When youcreate a static route that has a next hop instance specified by instancename and zone, Google Cloud requires that an instance with that nameexists 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'sVPC 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 ineither 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 thesame name, is in the same zone and project, and has a network interfacein the route's VPC network.

  • Google Clouddoesn't update programming for the next hop in thefollowing 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 rangeassigned to a VM network interface.

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

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

  When you specify a next hop instance by IP address, packets are routed tothe network interface of the instance, not the specific IP address.

• Next hop instances in Shared VPC service projects: When youspecify a next hop VM by IP address, the VM can be located ineither thesame project as the route (a standalone project or a Shared VPC hostproject)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 VMmust be located in the same project as the route and VPCnetwork (a standalone project or a Shared VPC host project).

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

• No health checking, no configuration validation: Google Cloudnever checks whether a next hop instance meets all requirements outlined intheConsiderations common to instance and internal passthrough Network Load Balancer next hopssection. Disabling the VM's network interface by configuring the guestoperating system of the instancedoesn't cause Google Cloud todisregard the next hop instance.

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

  • The VMs have one network interface in one VPC network andanother interface in a second VPC network.
  • In each VPC network, there exists a set of at least twocustom 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 connectVPC networks, and you require that the same VM processespackets for a given connection in both directions, you need symmetrichashing, which is only supported by next hop internal passthrough Network Load Balancers. For moreinformation, seeSymmetrichashing.

• Behavior wheninstances are stopped or deleted: Google Clouddoesn't preventyou from stopping or deleting a static route next hop VM (specified byeither name and zone or internal address). When a next hop VM is notrunning, routing depends on whether other routesfor the exact samedestination exist and whether those other routes have next hops that arerunning. To illustrate this behavior, consider the following examples:

  • You have the following routes and VM states:

    • route-a, destination192.168.168.0/24, priority10, nexthop VMvm-a is stopped
    • route-b, destination192.168.168.0/24, priority20, nexthop VMvm-b is running
    • route-c, destination192.168.168.0/24, priority30, nexthop VMvm-c is running

    In this example, packets whose destinations fit in192.168.168.0/24are sent to thevm-b next hop because thevm-a next hop of thehighest priorityroute-a is not running. This happens because thedisregard static and dynamic routes with unusable nexthops step precedesthedisregard low priorityroutes step in theGoogle Cloud routing order.

  • You have the following routes and VM states:

    • route-x, destination192.168.168.0/24, priority10, nexthop VMvm-x is stopped
    • route-y, destination192.168.168.0/24, priority20, nexthop VMvm-y is stopped
    • route-z, destination192.168.0.0/16, priority0, next hopVMvm-z is running

    In this example, packets whose destinations fit in192.168.168.0/24are dropped because the next hop VMs for the two192.168.168.0/24routes (route-x androute-y) are not running, even though a routefor the broader192.168.0.0/16 destination exists (route-z) with arunning next hop VM. This happens because themost specificdestination step precedes thedisregard static and dynamic routes with unusable nexthops step in theGoogle Cloud routing order.

Considerations for internal passthrough Network Load Balancer next hops

• Supported forwarding rules. Google Cloud supports only next hopinternal passthrough Network Load Balancer forwarding rules. Google Cloud doesnot support nexthop forwarding rules used by other load balancers, protocol forwarding, oras Private Service Connect endpoints.

• Specification methods and forwarding rule network and project. You canspecify a next hop forwarding rule by using one of following three methods.The specification method that you use determines whether the forwardingrule's network must match the route's network and in what project theforwarding 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 forwardingrule by name and region, the forwarding rule's network must match theroute's VPC network. The forwarding rule must be locatedin the same project that contains the forwarding rule'snetwork (a standalone project or a Shared VPC host project).

  • By forwarding rule resource link: a forwarding rule's resourcelink uses the format/projects/PROJECT_ID/regions/REGION/forwardingRules/FORWARDING_RULE_NAME, wherePROJECT_ID is theproject ID of the project that contains the forwarding rule,REGION is the forwarding rule's region, andFORWARDING_RULE_NAME is the forwarding rule'sname. Whenyou specify a next hop forwarding rule by its resource link, theforwarding rule's network must match the route's VPCnetwork. The forwarding rule can be located ineither the project thatcontains the forwarding rule's network (a standalone project or aShared VPC host project)or a Shared VPC serviceproject.

  • By a forwarding rule IP address: when you specify a next hopforwarding rule by its IPv4 or IPv6 address, the forwardingrule's network can beeither the route's VPC networkor a VPC network that's connected to the route'sVPC network by using either VPC Network Peering orNCC. NCC supports a next hop internal passthrough Network Load Balancerin a VPC spoke subject toNCCrequirements for connectivity.The forwarding rule can be located ineither the project thatcontains the forwarding rule's network (a standalone project or aShared VPC host project)or a Shared VPC serviceproject.

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

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

• Forwarding rules that use a common internal IP address(--purpose=SHARED_LOADBALANCER_VIP) are not supported. Next hopinternal passthrough Network Load Balancers andinternal passthrough Network Load Balancer forwarding rules that use a common IPaddress to reference different backend services (differentinternal passthrough Network Load Balancers)are mutually exclusive features. A next hop internal passthrough Network Load Balancer must use an IPaddress that is unique to the load balancer's forwarding rule so that onlyone backend service (one load balancer) is unambiguously referenced.Traffic sent to a next-hop internal passthrough Network Load Balancer configured with a shared IPaddress is silently dropped.

• Multiple routes with the same destinations and priorities, but differentnext hop internal passthrough Network Load Balancers. Google Cloudnever distributes trafficamong 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 adeterministic, internal algorithm. To avoid this ambiguity, you can useunique network tags for each route.

  

• Multiple routes with the same destinations, priorities, and next hopinternal passthrough Network Load Balancers. Without a network tag, Google Cloud does notallow you to create multiple static routes that have the same combination ofdestination, priority, and internal passthrough Network Load Balancer next hop. With network tags, youcan 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 considerregional distance for routes that use a next hop Classic VPNtunnel. Sending traffic to a next hop Classic VPN tunnel inanother region adds outbound data transfer costs and introduces networklatency. As a best practice, use anHA VPNtunnel withdynamicroutinginstead because that configuration considers regional distance.

• Behavior when Classic VPN tunnels are not running: Customstatic routes whose next hops are Classic VPN tunnels are notautomatically removed when the Classic VPN tunnels are notrunning. For details about what happens when tunnels are not running, seeWhen tunnels aredownin the Classic VPN documentation.

Considerations for NCC

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

What's next

• To create and manage routes, seeUse routes.
• To get a general overview of routes Google Cloud, seeRoutes.