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
Policy-based routes: Policy-based routes are evaluated before any other type of route.
Policy-based route Policy-based routes can apply to packets based on source IP address, destination IP address, protocol, or a combination thereof.	An option to skip evaluating other policy-based routes An internal passthrough Network Load Balancer	Policy-based routes can apply to all VMs in the network, to certain VMs selected by network tag, or to traffic entering the VPC network through VLAN attachments for Cloud Interconnect (in only one region, or in all regions). Policy-based routes are never exchanged through VPC Network Peering.
Subnet routes: All subnet route types are evaluated after policy based routes but before custom routes.
Local subnet route Created automatically for each subnet IP address range	VPC network	Created, updated, and removed automatically by Google Cloud during subnet lifecycle events. Local subnet routes apply to the whole VPC network.
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.
NCC subnet route Represents a subnet IP address range in a VPC spoke (a different VPC network connected to the NCC hub)	NCC hub	NCC spoke administrators can exclude the export of subnet routes. Created, updated, and removed automatically by Google Cloud during subnet lifecycle events. Imported NCC subnet routes apply to the whole VPC network.
Custom routes: Custom routes are evaluated after policy based routes and after subnet routes.
Local static route Supports various destinations	Forwards packets to a static route next hop	For details about each static route next hop, see considerations for: Instances and internal passthrough Network Load Balancers Next hop instances Internal passthrough Network Load Balancer next hops Classic VPN tunnel next hops
Local 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.
Peering static route, peering dynamic route 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. 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.
NCC dynamic route Dynamic routes imported from NCC hybrid spokes located in different VPC networks	NCC hub	A NCC hub can have both VPC spokes and hybrid spokes. NCC dynamic routes apply to one region or all regions of the VPC network according to the dynamic routing mode of the VPC network that contains the hybrid spoke.
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 routes

Each subnet has at least one subnet route for each IP address range that is associated with the subnet. For more information about subnet IP ranges, see Subnets.

Types of subnet routes

A VPC network can include the following types of subnet routes:

• Subnet routes for subnets in the same VPC network, referred to as local subnet routes.
• NCC subnet routes that are imported from VPC spokes of a NCC hub.
• Peering subnet routes that are imported from networks connected using VPC Network Peering.

Destination ranges for all types of subnet routes must be unique. For more information, see:

• Options for exchanging subnet routes and Subnet and peering subnet route interactions in the VPC Network Peering documentation

• Subnet route uniqueness and VPC spokes overview in the NCC documentation

Hybrid subnet routes

Local subnet routes and peering subnet routes can be hybrid subnet routes if the corresponding subnet is configured to use hybrid subnet routing.

Lifecycle of subnet routes

All IP address ranges that are part of a subnet—primary IPv4 address ranges, secondary IPv4 address ranges, and IPv6 address ranges—have a corresponding subnet route. Google Cloud creates and deletes subnet routes in these scenarios:

• You make a subnet configuration change, for example:

  • Add or delete a subnet.
  • Expand a primary IPv4 range.
  • Add or delete a secondary IPv4 range.
  • Add or delete an IPv6 range.

• Google Cloud adds a new region, which automatically adds a new subnet to auto VPC mode networks. For information about the IPv4 address ranges for each subnet by its region, see auto mode IPv4 ranges.

Dynamic routes

Cloud Routers instruct the VPC network to create, update, and remove dynamic routes based on received Border Gateway Protocol (BGP) messages, applicable BGP route policies, and Cloud Router custom learned routes.

Dynamic routes are created in one region or in all regions based on the dynamic routing mode and best path selection mode of the VPC network that contains the Cloud Router. For more information, see the following:

• How Cloud Router works
• Learned routes

The next hop of a dynamic route can be one of the following:

• A VLAN attachment backed by either a Dedicated Interconnect connection or a Partner Interconnect connection

• A Cloud VPN tunnel, either a HA VPN tunnel or a Classic VPN configured to use dynamic routing

• A Router appliance VM instance

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. For more information, see BGP state changes.

Types of dynamic routes

A VPC network can include the following types of dynamic routes:

• Dynamic routes learned by Cloud Routers in the same VPC network are referred to as local dynamic routes.
• Peering dynamic routes that are imported with custom route exchange from networks connected using VPC Network Peering .
• NCC dynamic routes that are imported from hybrid spokes located in different VPC networks of a NCC hub.

Google Cloud resolves conflicts between dynamic routes and subnet routes as described in Interactions with dynamic routes.

System-generated default routes

A default route has the broadest possible destination: 0.0.0.0/0 for IPv4 and ::/0 for IPv6. Google Cloud only uses a default route to deliver a packet when the packet doesn't match a more specific route in the routing order.

The absence of a default route doesn't necessarily isolate your network from the internet because special routing paths for external passthrough Network Load Balancers and external protocol forwarding don't depend on a default route.

When you create a VPC network, Google Cloud adds a system-generated IPv4 default route to the VPC network. The system-generated IPv4 default route is a local static route that has a 0.0.0.0/0 destination and default internet gateway next hop. A local static route with the 0.0.0.0/0 destination and default internet gateway next hop provides a path to external IPv4 addresses, including IPv4 addresses on the internet. The following example resources use this path:

• VMs with external IPv4 addresses assigned to their network interfaces, when the packets they send have sources matching the network interface primary internal IPv4 address.
• A public Cloud NAT gateway configured to provide NAT services to subnets used by VM network interfaces. For both NAT44 and NAT64, public Cloud NAT gateways always depend on a local IPv4 static route that uses the default internet gateway next hop. For more information about which traffic can be translated by public Cloud NAT gateways, see General specifications.

When you create a subnet that has an external IPv6 address range, Google Cloud adds a system-generated IPv6 default route to the VPC network if it doesn't already have one. The system-generated IPv6 default route is a local static route that has a ::/0 destination and default internet gateway next hop. A local static route with the ::/0 destination and default internet gateway next hop provides a path to external IPv6 addresses, including IPv6 addresses on the internet. This path can be used by the following:

• VMs with /96 external IPv6 address ranges assigned to their network interfaces, when the packets they send have sources in that /96 address range.

Accessing global Google APIs sometimes depends on a local IPv4 or IPv6 default route with default internet gateway next hop:

• If you access global Google APIs and services by sending packets to a Private Service Connect endpoint for global Google APIs, your VPC network doesn't require a default route with default internet gateway next hop because the internal forwarding rule of the Private Service Connect endpoint is the route. For more information, see Private Service Connect endpoints for global Google APIs.

• If you access global Google APIs and services by sending packets to IPv4 or IPv6 addresses for the default domains, the IPv4 or IPv6 addresses for private.googleapis.com, or the IPv4 or IPv6 addresses for restricted.googleapis.com, you can either use default IPv4 and IPv6 routes that have default internet gateway next hops, or you can create and use IPv4 and IPv6 static routes that have more specific destinations and default internet gateway next hops:

  • If your VMs have only internal IP addresses, see Routing options for Private Google Access.
  • If your VMs have external IP addresses, see Routing options.

Route interactions

The following sections describe the interactions between subnet routes and other route types.

Interactions between subnet routes and static routes

Google Cloud enforces the following rules for local subnet routes, peering subnet routes, and NCC subnet routes unless the corresponding subnet has been configured to use hybrid subnet routing.

• Google Cloud doesn't let you create a new static route if the destination of the new static route exactly matches or fits within the destination of an existing local, peering, or NCC subnet route. For example:

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

  • If a local or peering subnet route exists with the 2001:0db8:0a0b:0c0d::/64 destination, you can't create a new static route for 2001:0db8:0a0b:0c0d::/64, 2001:0db8:0a0b:0c0d::/96, or any other destination that fits within 2001:0db8:0a0b:0c0d::/64.

• Google Cloud doesn't let you make any changes to subnets that result in a subnet IP address range that exactly matches or contains the destination of an existing local or peering static route. For example:

  • If your VPC network has a static route with the 10.70.1.128/25 destination, you can't create a new subnet that has a primary or secondary IPv4 address range of 10.70.1.128/25, 10.70.1.0/24, or any other IP address range that contains all the IPv4 addresses in 10.70.1.128/25.

  • If your VPC network has a static route with the 2001:db8:a0b:c0d:e0f:f0e::/96 destination, Google Cloud prohibits the creation of a new local or peering subnet route that has an IPv6 address range of 2001:db8:a0b:c0d::/64 or any other range that contains all the IPv6 addresses in 2001:db8:a0b:c0d:e0f:f0e::/96.

Interactions between subnet routes and dynamic routes

Google Cloud enforces the following rules unless a subnet has been configured to use hybrid subnet routing.

• Google Cloud doesn't create a dynamic route if a Cloud Router sends a prefix that either exactly matches or fits within the destination of an existing local, peering, or NCC subnet route. For example:

  • If a local, peering, or NCC subnet route exists with the 10.70.1.0/24 destination, and if a Cloud Router in the VPC network, a peered VPC network, or a network containing a NCC hybrid spoke receives 10.70.1.128/25, 10.70.1.0/24, or any other prefix that fits within 10.70.1.0/24, Google Cloud doesn't create any local, peering, or NCC dynamic routes for the received conflicting prefixes.

  • If a local, peering, or NCC subnet route exists with the 2001:0db8:0a0b:0c0d::/64 destination, and if a Cloud Router in the VPC network, a peered VPC network, or a network containing a NCC hybrid spoke receives 2001:0db8:0a0b:0c0d::/96, 2001:0db8:0a0b:0c0d::/64, or any other prefix that fits within 2001:0db8:0a0b:0c0d::/64, Google Cloud doesn't create any local, peering, or NCC dynamic routes for the received conflicting prefixes.

• Google Cloud removes any existing dynamic route if any change to subnets results in the creation of a new local, peering, or NCC subnet route whose destination exactly matches or contains the destination of the existing local, peering, or NCC dynamic route. For example:

  • If your VPC network has a local, peering, or NCC dynamic route with the 10.70.1.128/25 destination, Google Cloud removes the dynamic route when a new local, peering, or NCC subnet route for 10.70.1.128/25, 10.70.1.0/24, or any other IP address range that contains all the IPv4 addresses in 10.70.1.128/25 is created.

  • If your VPC network has a local, peering, or NCC dynamic route with the 2001:db8:a0b:c0d::/96 destination, Google Cloud removes the dynamic route when a new local, peering, or NCC subnet route for 2001:db8:a0b:c0d::/64 is created.

Applicability and order

Applicable routes

Each instance, Cloud VPN tunnel, and VLAN attachment has a set of applicable routes—routes that apply to that specific resource. Applicable routes are a subset of all routes in the VPC network.

The following route types always apply to all VM instances, VLAN attachments, and Cloud VPN tunnels:

• Special routing paths
• Subnet routes

The following route types can be configured to apply only to certain VM instances, VLAN attachments, or Cloud VPN tunnels:

• Policy-based routes can apply to:

  • All VM instances, VLAN attachments, and Cloud VPN tunnels
  • Only VM instances identified by network tags
  • Only VLAN attachments in a particular region

• Static routes can apply to:

  • All VM instances, VLAN attachments, and Cloud VPN tunnels
  • Only VM instances identified by network tags

• Dynamic routes can apply to VM instances, VLAN attachments, and Cloud VPN tunnels in either the region containing the dynamic route's next hop or all regions, based on the dynamic routing mode of the VPC network.

Special routing paths

VPC networks have special routes for certain services. These special routing paths don't appear in your VPC network route table. You can't remove any special routing paths. However, you can allow or deny packets by using VPC firewall rules or firewall policies.

Paths for external passthrough Network Load Balancers and external protocol forwarding

External passthrough Network Load Balancers and external protocol forwarding use Maglev systems to route packets from clients on the internet to backend VMs and target instances in your VPC network. These Maglev systems route packets that have destinations that match the destination of the external forwarding rule.

Each forwarding rule for an external passthrough Network Load Balancer or for external protocol forwarding also provides a routing path for its backend VMs or target instance to send packets to destinations outside of the VPC network:

• Packets sent by backend VMs or target instances can be either outbound response packets (sent back to the client) or they can be outbound packets that initiate a new connection.
• Packet sources must match the forwarding rule's IP address. Packet protocol and source port don't have to match the forwarding rule's protocol and port specification.
• Forwarding rule routing paths don't depend on a default route or the use of the default internet gateway next hop.
• Backend VMs and target instances don't need to have IP forwarding enabled.

Paths between Google Front Ends and backends

External Application Load Balancers and external proxy Network Load Balancers use Google Front Ends (GFEs). Second layer GFEs open TCP connections to your backend VMs and send packets from the following sources:

• 35.191.0.0/16 and 130.211.0.0/22 for IPv4
• 2600:2d00:1:1::/64 for IPv6

Google Cloud uses routes in Google's network to deliver packets from those source ranges to backend VMs in your VPC network. Each VPC network includes routing paths that allow VMs to send response packets to the ranges.

Paths for health checks

Health checks for all load balancers and for managed instance group autohealing send packets to your backend VMs from health check probe IP address ranges.