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:
The IPv4 and IPv6 default routes defines a path out of the VPC network to external IP addresses on the internet.
The default route can serve as the path to Google APIs and services. For more information, see Configure Private Google Access and Access APIs from VMs with external IP addresses. The default route is not used if you access Google APIs through Private Service Connect endpoints.
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 for10.70.1.0/24
,10.70.1.0/25
,10.70.1.128/25
, or any other destinations that fit within10.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 for2001:0db8:0a0b:0c0d::/64
or any destination that fits within2001:0db8:0a0b:0c0d::/64
, such as2001: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 of10.70.1.128/25
,10.70.1.0/24
, or any other range that contains all the IPv4 addresses in10.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 of2001:0db8:0a0b:0c0d::/64
or any other range that contains all the IPv6 addresses in2001: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 the10.70.1.0/24
prefix through BGP, Google Cloud uses the subnet or peering subnet route, and does not create any custom dynamic route for10.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 the10.70.1.0/25
and10.70.1.128/25
prefixes through BGP, Google Cloud uses the subnet or peering subnet route, and does not create any custom dynamic routes for10.70.1.0/25
and10.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.
If you expand a subnet's primary IP address range, Google Cloud updates the corresponding subnet route's destination.
If you add or remove a secondary IP address range in a subnet, Google Cloud creates or destroys a corresponding subnet route for the secondary 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, applicable BGP route policies (Preview), 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:
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 in Network Connectivity Center
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:
The peer router's graceful restart timer has expired (if the BGP peer supports graceful restart).
The Cloud Router's hold timer has expired. The Cloud Router hold timer is proportional to the configurable Cloud Router keepalive timer.
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 routing paths apply when routing back to proxy load balancers, health check systems, and other Google services. For more information, see special routing 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 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 do not have to match the forwarding rule's protocol and port specification.
- Forwarding rule routing paths do not depend on a default route or the use of the default internet gateway next hop.
- Backend VMs and target instances do not 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
130.211.0.0/22
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 35.191.0.0/16
and 130.211.0.0/22
.
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.
Google Cloud uses routes in Google's network to deliver packets from health check probe systems to VMs in your VPC network. Each VPC network includes routing paths that allow VMs to send response packets to the health check probe systems.
Paths for Identity-Aware Proxy (IAP)
TCP forwarding using IAP uses
35.235.240.0/20
as an internal-only range with next hops that are entirely
within Google's network. Google does not publish routes to 35.235.240.0/20
on
the internet.
Routes in Google's network deliver packets from 35.235.240.0/20
to VMs in your
VPC network when you use IAP TCP forwarding. Each
VPC network includes routing paths that allow VMs to send
response packets to 35.235.240.0/20
.
Paths for Cloud DNS and Service Directory
The following Cloud DNS and Service Directory features use
35.199.192.0/19
as an internal-only range with next hops that are entirely
within Google's network. Google does not publish routes to 35.199.192.0/19
on
the internet.
- Cloud DNS forwarding targets that use private routing
- Cloud DNS alternative name servers that use private routing
- Private network access for Service Directory
Routes in Google's network deliver packets from 35.199.192.0/19
to VMs in your
VPC network when you use these Cloud DNS and
Service Directory features. Each VPC network includes routing
paths that allow VMs to send response packets to 35.199.192.0/19
.
Paths for Serverless VPC Access
Serverless VPC Access uses
35.199.224.0/19
as an internal-only range with next hops that are entirely
within Google's network. Google does not publish routes to 35.199.224.0/19
on
the internet.
Routes in Google's network deliver packets from 35.199.224.0/19
to
Serverless VPC Access connector instances. Each VPC
network includes routing paths that allow connector instances to send response
packets to 35.199.224.0/19
.
Paths for Private Service Connect endpoints for global Google APIs
When you create a Private Service Connect endpoint for global Google APIs, Google Cloud adds a route for the endpoint to your VPC network. The route's destination is the global internal IP address of the endpoint.
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.
Special routing paths: Some Google Cloud special routing paths not shown in your VPC network route table. For details, see Special routing paths.
If a special routing path is applicable, your route selection model contains only the special path. All other routes are disregarded, and evaluation stops at this step.
Policy-based routes: Policy-based routes are evaluated after special routing 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.
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 than10.240.0.0/16
. The most specific destination could be any type of route; however, subnet routes, peering subnet routes, and special routing paths are the most specific by definition.After this step, your route selection model contains no special routing paths or policy-based routes. It includes only the routes with the most specific destinations.
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.
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
ornext-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.
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
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
ornext-hop-address
) or IKE SA established next hop Classic VPN tunnelSecond 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 hopAt the end of this step, there could be zero routes, one route, or two or more routes in the route model.
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 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 does not 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 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 is65,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. |
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 inus-west1
even if the backend VM or next hop instance originally received the packet from a resource in a region different fromus-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 ofroute-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
, destination192.168.168.0/24
, priority10
, next hop VM is stoppedroute-vm-b
, destination192.168.168.0/24
, priority20
, next hop VM is runningroute-vm-c
, destination192.168.168.0/24
, priority30
, next hop VM is runningPackets whose destinations fit in
192.168.168.0/24
are dropped in this next example where all next hop VMs for the192.168.168.0/24
routes are not running, even though a route for the broader192.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
, destination192.168.168.0/24
, priority10
, next hop VM is stoppedroute-vm-y
, destination192.168.168.0/24
, priority20
, next hop VM is stoppedroute-vm-z
, destination192.168.0.0/16
, priority0
, next hop VM is running
- Packets whose destinations fit in
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).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 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
- To create and manage routes, see Use routes.
- To get an overview of Google Cloud VPC networks, see VPC networks.
- To create, modify, or delete VPC networks, see Create and manage VPC networks.