Routes Overview

This page describes Google Cloud Platform (GCP) routes. A route is a mapping of an IP range to a destination. Routes tell the VPC network where to send packets destined for a particular IP address.

By default, every network has routes that let instances in a network send traffic directly to each other, even across subnets. In addition, every network has a default route that directs packets to destinations that are outside the network. You can override the default route by creating custom static routes that direct traffic for specific IP ranges to other destinations. For example, you could create a route that forwards packets destined for the Internet to a proxy server first.

The fact that a packet has a route to a destination does not mean that it can get there, however. Firewall rules must also allow the packet. The default network has preconfigured firewall rules that allow all instances in the network to talk with each other. Manually created networks do not have such rules, so you must create them.

Routes allow you to implement more advanced networking functions in your virtual machines, such as setting up many-to-one NAT and transparent proxies. If you do not need any advanced routing solutions, the default routes should be sufficient for handling most outgoing traffic.

Types of routes

GCP routes can either be provided automatically provided by GCP or manually provided by you.

  • System-generated routes are ones provided by GCP for each network automatically.
  • Custom routes are provided by you, either statically or dynamically through BGP.
System-generated or Custom Route type Description
System-generated default route The route to outside the network. All traffic that does not match another route follows this path. This route is automatically provided by GCP but can be deleted if needed.
System-generated subnet routes When you create a VPC network, or add subnets to a VPC network, GCP automatically provisions the VPC network with a route for each subnet. These routes cannot be deleted or modified.
Custom static routes A manually entered route. You cannot create static routes with destinations CIDR ranges either identical or more specific than an existing subnet routes in the same or peered VPC networks.
Custom dynamic routes Routes learned via BGP from an on-premises or other network connected via VPN, Interconnect, and Cloud Router.

System-generated routes

System-generated routes are generated automatically by GCP when you create a network or add a subnet to a network.

For instructions on creating additional routes, see the Adding a route.

For VPC networks

The following routes are created.

  • A default route for Internet traffic (0/0) is created when the network is created. This route has a priority of 1000.
  • One route is created for each subnet when the subnet is created. These routes are for local traffic in the network, which allows VM instances in any subnet to send traffic to instances in any other or same subnet in that network. All subnet routes have a priority of 1000.
    A static route for an IP address range overlapped by a subnet IP address range is automatically disabled. This is to protect local traffic and keep the connectivity between all instances in a VPC.

For auto mode VPC networks, we recommend that you not create static routes in the range. Auto mode subnets use addresses from this range, and your static routes could be disabled automatically if a new region launches that uses an overlapping range.

For legacy networks

Two routes are created at network creation time.

  • A default route for Internet traffic (0/0) is created when the network is created. This route has a priority of 1000.
  • For the destination IP range within the IPv4 range of the network, a virtual network route is defined. This route has a priority of 1000.

Instance routing tables

Each route in the routes collection may apply to zero or more instances. GCP applies a route to an instance if the tag applied to the route and the tag applied to that instance match. If the route has no tag, then the route applies to all instances in the network. GCP uses this information to create an overall routes collection for the network. GCP then assigns routes to instances individually based on the information in the collection.

A good way to visualize this is to imagine a massively scalable virtual router at the core of each network. Every virtual machine instance in the network is directly connected to this router, and all packets leaving a virtual machine instance are first handled at this layer before they are forwarded on to their next hop. The virtual network router selects the next hop for a packet by consulting the routing table for that instance. The diagram below describes this relationship, where the green boxes are virtual machine instances, the router is at the center, and the individual routing tables are indicated by the tan boxes.

Routes and VMs (click to enlarge)
Routes and VMs (click to enlarge)

The Routes collection for the legacy network in the diagram might look like this:

NAME                           NETWORK DEST_RANGE    NEXT_HOP                 PRIORITY
default-route-68079898SAMPLEe7 default     default-internet-gateway   1000
default-route-78SAMPLEd2bc5762 default                            1000
vpngateway                     default us-central1-a/instances/vpngateway  1000

A closer look at the vpngateway route exposes the vpn tag on the route:

gcloud compute routes describe vpngateway
creationTimestamp: '2014-07-28T15:26:27.023-07:00'
id: '12304245498973864442'
kind: compute#route
name: vpngateway
priority: 1000
- vpn

The vpngateway route ensures that any instance with the vpn tag automatically has a routing table that contains the vpngateway route alongside the two default routes. In the diagram, both vm1 and vm2 have these routes in their routing table, so all outgoing traffic destined for the external IP range is handled by the vpngateway instance.

An instance's routing table is a read-only entity. You cannot directly edit these tables. If you want to add, remove, or edit a route, you must do so through the Routes collection.

Static routes

A single static route is made up of the following:

[Required] The user-friendly name for this route. For example, internetroute for a route that allows access to the Internet.
[Required] The name of the network this route applies to. For example, the default network.
[Required] The destination IP range that this route applies to. If the destination IP of a packet falls in this range, it matches this route. For example, specifying as the destination range forces all packets headed out of the network to follow this route instead. See the Route Selection section to understand how the VPC network uses all matching routes to select a single next hop for a packet. Routes do not support IPv6.
[Required] The list of instance tags this route applies to. If this is empty, this route applies to all instances within the specified network. In the API, this is a required field. In the gcloud command-line tool, this is an optional field and the gcloud command assumes an empty list if this field is not specified.

Exactly one of the following next hop specifications is required:


The fully-qualified URL of the instance that should handle matching packets. The instance must already exist and have IP forwarding enabled. For example:[PROJECT_ID]/zones/[ZONE]/instances/<instance>

If a next hop instance crashes and is restarted by the system, or if you delete an instance and recreate it with the same name in the same zone, the VPC network continues to route matching packets to the new instance.


The network IP address of an instance that should handle matching packets. The IP address must lie within the address space of the network. For example, if your network is, you cannot specify nextHopIp= The instance must already exist and have IP forwarding enabled. If the next hop instance crashes and is later restarted by the system with the same IP address or if the user deletes the instance and recreates it with the same IP address, GCP continues routing matching packets to the new instance.


[Read-Only] The URL of the local network handling matching packets. You cannot manually set this field.


The URL of a gateway that should handle matching packets. Currently, there is only the Internet gateway available:


The URL of a VPN tunnel that should handle matching packets.


[Required] The priority of this route. Priority is used to break ties in the case where there is more than one matching route of maximum length. A lower value is higher priority; a priority of 100 has higher priority than 200. For example, the following routes are tied because they have the same prefix length and they are in the same network. The differing priority breaks the tie so that vpnroute wins.

NAME                       NETWORK     DEST_RANGE         NEXT_HOP                            PRIORITY
vpnroute                   default     [ZONE]/instances/vpninstance          1000
vpnroute-backup            default     [ZONE]/instances/vpninstance-backup   2000

Under this configuration, VPN traffic would normally be handled by vpninstance, but would fall back to vpninstance-backup if vpnroute is deleted.

In the API, this is a required field. In the gcloud command-line tool, this is an optional field and the tool assumes a default priority of 1000 if the field is not specified.

Route selection

When an outgoing packet leaves a virtual machine instance, GCP uses the following steps to decide which route to use and where to forward the packet:

  1. GCP discards all but the most specific routes that match the packet’s destination address. For example, if destinationIP= and there is a route for and a route for, GCP selects the route because it is more specific.

  2. If there are multiple routes with the same prefix length, GCP discards all routes except the ones with the smallest priority value (smallest priority value indicates highest priority). There may still be more than one route left at this point.

  3. GCP computes a hash value of the IP protocol field, the source and destination IP addresses, and the source and destination ports. GCP uses this hash value to select a single next hop from the remaining ties.

  4. If a next hop is found, the VPC network forwards the packet. If a next hop is not found, the packet is dropped and the VPC network replies with an ICMP destination or network unreachable error.

It is important to note that GCP does not consider network distance when selecting a next hop. The next hop instance or gateway could be in a different zone than the instance sending the packet, so you should engineer your routing tables to control locality. For example, you can use tags to direct packets for instances in different zones to prefer a local transparent proxy or VPN gateway. By tagging instances by zone, you can ensure that packets leaving an instance in one zone will only be sent to a next hop in the same zone.

Consistency of route operations

When you make changes to the Routes collection, these changes are eventually consistent across all instances. This means that after you update, add, or remove a route, the operation sends a request to the routing service. A PENDING or RUNNING status means that the request is still in progress, and is yet to be accepted. Once the operation returns a status of DONE, the request has been successfully accepted by the routing service. The route is not guaranteed to be active immediately, and there can be a period of up to thirty seconds for the route to be live.

If you make a sequence of changes, these changes may be applied to your instances in any order. There is no guarantee that the order in which you make your requests will be the order in which these requests are processed. Since routing changes do not take effect instantaneously, different instances may observe different changes at different times.

Interacting with firewall rules

Just creating a route does not ensure that your packets will be received by the specified next hop. Firewall rules still determine whether incoming traffic is allowed into a network or instance. For example, if you create a route that sends packets through multiple instances, each instance must have an associated firewall rule to accept packets from the previous instance.

For IP address matching, only the source IP address of the packet is used, which is not necessarily the IP address of the instance sending the packet. If you have a firewall rule that specifies only packets from are accepted, all packets with that source IP address are accepted, regardless of the IP address of the instance that sent the packets.

  • If instance has canIpForward enabled and spoofs a packet to have source IP, the firewall will reject the packet.
  • If instance has canIpForward enabled and spoofs a packet to have source IP, the firewall will accept the packet.

Source tags are aliases for the source IPs of packets, not the IPs of the instances sending the packets. For example, if a source tag named mytag is assigned to an instance with IP, a rule that allows traffic from mytag would allow any packets with a source IP of, regardless of which instance sends the packet. This is important because an instance with IP forwarding enabled can send a packet with a source IP address different from the instance IP address. Target tags, on the other hand, are aliases for the IP of the receiving instance only, so there is no ambiguity.

For more information, see Firewalls.

Routing packets to the Internet

Currently, any packets sent to the Internet must be sent by an instance that has an external IP address. If you create a route that sends packets to the Internet from a particular instance, that instance must also have an external IP. If you create a route that sends packets to the Internet gateway, but the source instance doesn't have an external IP address, the packet will be dropped.

What's next

  • See Using Routes for information creating and using routes.
  • See the VPC Overview for information on GCP VPC networks.
  • See Using VPC for instructions on creating and modifying VPC networks.
Was this page helpful? Let us know how we did:

Send feedback about...