Order of routes

This page describes how routes for Cloud VPN tunnels are interpreted in VPC and legacy networks. Review the Routes Overview for important background information about routes in GCP. This document assumes that you understand route applicability and order.

VPN routes

VPN routes define an egress path for traffic leaving your GCP network:

  • Routes for Cloud VPN tunnels using dynamic routing are managed by a Cloud Router. These routes cannot be edited or removed manually. Routes with destinations to peer networks are automatically created and removed by the Cloud Router associated with the tunnel based on the BGP advertisements of the peer VPN gateway. The next hop for a dynamic route is the BGP IP address of the peer.

  • If you use the GCP Console to create tunnels using policy based routing or route based VPNs, GCP creates a static route with a matching destination for each IP range in the remote traffic selector. If you create the tunnels using gcloud commands, you must manually create the corresponding static routes. The next hop for a VPN static route is the appropriate Cloud VPN tunnel.

Routing examples

GCP follows a specific procedure for selecting the next hop for a packet. The following examples illustrate how VPN routes work in conjunction with subnet routes. For more information about how GCP selects a specific route, see Routing order in the VPC documentation.

In each example, 10.2.0.0/16 represents an on-premises network IP address range:

  • GCP subnet with the same IP range: If your GCP network contains a subnet using the 10.2.0.0/16 range, GCP prevents you from creating a Cloud VPN tunnel using policy based routing or route based VPN if a remote traffic selector includes 10.2.0.0/16. If the Cloud VPN tunnel uses dynamic routing, the associated Cloud Router ignores any advertised routes with a destination of 10.2.0.0/16. Traffic destined for 10.2.0.0/16 remains in GCP.

  • GCP subnet with a broader IP range: If your GCP network contains a subnet using a larger, encompassing IP range such as 10.0.0.0/8, GCP prevents you from creating a Cloud VPN tunnel using policy based routing or route based VPN if a remote traffic selector includes 10.0.0.0/8 or a more specific range. If the Cloud VPN tunnel uses dynamic routing, the associated Cloud Router ignores any advertised routes with destinations that fit in 10.0.0.0/8 (including more specific ranges). All traffic destined for 10.0.0.0/8 remains in GCP.

  • GCP subnet with a narrower IP range: If your GCP network contains a subnet with a narrower, included IP range like 10.2.99.0/24, you can create a Cloud VPN tunnel to the broader 10.2.0.0/16 range using any routing option: Traffic destined to 10.2.99.0/24 is still routed to the GCP subnet. Traffic destined to 10.2.0.0/16 but outside of 10.2.99.0/24 (such as to 10.2.100.8) is sent through the VPN tunnel.

With other VPN routes

If no destination is found with a subnet route, GCP resolves routes for VPN tunnels in the following way:

  • Routes that use a Cloud VPN tunnel as a next hop are ignored if the tunnel is not up.

  • GCP sends the packet to the next hop of the route with the most specific destination.

  • If more than one route has the same most-specific destination, the priority of the route is used:

    • If a single route with the highest priority is available, the packet is sent to its next hop.

    • If more than one route has the same highest priority, the packet is delivered to the next hop of either route using ECMP. This means that traffic is distributed among multiple next hops, so it is balanced among the applicable, available Cloud VPN tunnels. This balancing method is based on a hash, so all packets from the same flow use the same tunnel as long as that tunnel is up.

When tunnels are down

When Cloud VPN tunnels are not available, GCP interprets their associated routes as follows:

  • If a Cloud VPN tunnel uses dynamic routing, its associated Cloud Router automatically removes the learned routes when the tunnel goes down. The learned routes are those with a next hop of the BGP IP for the corresponding peer VPN gateway. Provided there are no conflicts with subnet routes, the learned routes are re-added when the tunnel comes back up. Depending on your network, it can take the associated Cloud Router up to 40 seconds of processing time to remove them.

  • Tunnels using policy based routing or route based VPNs have corresponding static routes. GCP ignores static routes with next hops that point to Cloud VPN tunnels that are down.

If a second Cloud VPN tunnel provides an alternate path to the same destination, you should still expect packet loss whenever one Cloud VPN tunnel goes down. In-flight packets may be dropped, and dynamic routes are removed only after the associated Cloud Router has completed its processing.

What's next

Was this page helpful? Let us know how we did:

Send feedback about...