Routes

Google Cloud routes define the paths that network traffic takes from a virtualmachine (VM) instance to other destinations. These destinations can be insideyour Google Cloud Virtual Private Cloud (VPC) network (for example, inanother VM) or outside it.

In a VPC network, a route consists of a singledestinationprefix in CIDR format and a singlenext hop. When an instance in aVPC network sends a packet, Google Cloud delivers thepacket to the route's next hop if the packet's destination address is within theroute'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 routingmechanism. There is no physical device that's assigned to the network. Someroutes can be applied selectively, but theroutingtable for aVPC network is defined at the VPC network level.

Each VM instance has a controller that is kept informed of allapplicableroutes from the network's routing table. Each packetleaving a VM is delivered to the appropriate next hop of an applicable routebased on a routing order. When you add or delete a route, the set of changes ispropagated to the VM controllersby using an eventually consistentdesign.

Route types

The following tables summarize how Google Cloud categorizes routes inVPC networks.

Subnet routes

Each subnet has at least one subnet route for each IP address range that isassociated with the subnet. For more information about subnet IP ranges, seeSubnets.

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 toaslocal subnet routes.
• Network Connectivity Center subnet routes that are imported from VPCspokes of a Network Connectivity Center hub.
• Peering subnet routes that are imported from networks connected usingVPC Network Peering.

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

• Options for exchanging subnetroutes andSubnet and peeringsubnet route interactionsin the VPC Network Peering documentation

• Subnet routeuniquenessandVPC spokesoverviewin the Network Connectivity Center documentation

Hybrid subnet routes

Local subnet routes and peering subnet routes can be hybrid subnet routes ifthe corresponding subnet is configured as ahybridsubnet.

Lifecycle of subnet routes

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

• You make asubnet configurationchange, 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 toauto VPC mode networks. For information about the IPv4 addressranges for each subnet by its region, seeauto 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 routepolicies(Preview), andCloud Router customlearnedroutes.

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

• How Cloud Routerworks
• Learned routes

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

• A VLAN attachment backed by either aDedicated Interconnectconnection or aPartner Interconnectconnection

• A Cloud VPN tunnel, either aHA VPNtunnel or aClassic VPN configured to use dynamicrouting

• ARouter appliance VMinstance

If a next hop for a dynamic route becomes inaccessible, theCloud Router that manages its BGP session instructs theVPC network to remove the dynamic route. For more information,seeBGP statechanges.

Types of dynamic routes

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

• Dynamic routes learned by Cloud Routers in the sameVPC network are referred to aslocal dynamic routes.
• Peering dynamic routes that are imported withcustom routeexchange from networksconnected using VPC Network Peering .
• Network Connectivity Center dynamic routes that areimported from hybrid spokeslocated in different VPCnetworksof a Network Connectivity Center hub.

Google Cloud resolves conflicts between dynamic routes and subnet routesas described inInteractions with dynamicroutes.

System-generated default routes

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

The absence of a default route doesn't necessarily isolate your network from theinternet because special routingpaths for external passthrough Network Load Balancers and externalprotocol forwarding don't depend on a default route.

When youcreate a VPCnetwork,Google Cloud adds a system-generated IPv4defaultroute to theVPC network. The system-generated IPv4 default route is a localstatic route that has a0.0.0.0/0 destination and default internet gatewaynext hop. A local static route with the0.0.0.0/0 destination and defaultinternet gateway next hop provides a path toexternal IPv4addresses, including IPv4 addresses on the internet.The following example resources use this path:

• VMs with external IPv4 addresses assigned to their network interfaces, whenthe packets they send have sources matching the network interface primaryinternal IPv4 address.
• Apublic Cloud NAT gatewayconfigured to provide NAT services to subnets used by VM network interfaces.For both NAT44 and NAT64, public Cloud NAT gateways always depend ona local IPv4 static route that uses the default internet gateway next hop.For more information about which traffic can be translated by publicCloud NAT gateways, seeGeneral specifications.

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

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

Accessing global Google APIssometimes depends on a local IPv4 or IPv6 defaultroute with default internet gateway next hop:

• If you access global Google APIs and services by sending packets to aPrivate Service Connect endpoint for global GoogleAPIs, yourVPC network doesn't require a default route with defaultinternet gateway next hop. Google Cloud adds aspecial routingpath to the endpoint.

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

  • If your VMs have only internal IP addresses, seeRoutingoptions forPrivate Google Access.
  • If your VMs have external IP addresses, seeRoutingoptions.

Route interactions

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

Interactions between subnet routes and static routes

Google Cloud enforces the following rules for local subnet routes, peeringsubnet routes, and Network Connectivity Center subnet routesunless the correspondingsubnet has been configured as ahybrid subnet.

• Google Cloud doesn't let you create a new static route if thedestination of the new static route exactly matches or fits within thedestination of an existing local, peering, or Network Connectivity Center subnetroute. For example:

  • If a local, peering, or Network Connectivity Center subnet route exists with the10.70.1.0/24 destination, you cannot create a new static route for10.70.1.0/24,10.70.1.0/25,10.70.1.128/25, or any other destinationthat fits within10.70.1.0/24.

  • If a local or peering subnet route exists with the2001:0db8:0a0b:0c0d::/64 destination, you can't create a new staticroute for2001:0db8:0a0b:0c0d::/64,2001:0db8:0a0b:0c0d::/96, or anyother destination that fits within2001:0db8:0a0b:0c0d::/64.

• Google Cloud doesn't let you make anychanges tosubnets that result in a subnet IP address range thatexactly matches or contains the destination of an existing local or peeringstatic route. For example:

  • If your VPC network has a static route with the10.70.1.128/25 destination, you can't create a new subnet that has aprimary or secondary IPv4 address range of10.70.1.128/25,10.70.1.0/24, or any other IP address range that contains all the IPv4addresses in10.70.1.128/25.

  • If your VPC network has a static route with the2001:db8:a0b:c0d:e0f:f0e::/96 destination, Google Cloud prohibitsthe creation of a new local or peering subnet route that has an IPv6address range of2001:db8:a0b:c0d::/64 or any other range that containsall the IPv6 addresses in2001:db8:a0b:c0d:e0f:f0e::/96.

Interactions between subnet routes and dynamic routes

Google Cloud enforces the following rulesunless a subnet has beenconfigured as ahybrid subnet.

• Google Cloud doesn't create a dynamic route if a Cloud Routersends a prefix that either exactly matches or fits within the destination ofan existing local, peering, or Network Connectivity Center subnet route. For example:

  • If a local, peering, or Network Connectivity Center subnet route exists with the10.70.1.0/24 destination, and if a Cloud Router in theVPC network, a peered VPC network, or anetwork containing a Network Connectivity Center hybrid spoke receives10.70.1.128/25,10.70.1.0/24, or any other prefix that fits within10.70.1.0/24, Google Cloud doesn't create any local, peering, orNetwork Connectivity Center dynamic routes for the received conflicting prefixes.

  • If a local, peering, or Network Connectivity Center subnet route exists with the2001:0db8:0a0b:0c0d::/64 destination, and if a Cloud Router inthe VPC network, a peered VPC network, or anetwork containing a Network Connectivity Center hybrid spoke receives2001:0db8:0a0b:0c0d::/96,2001:0db8:0a0b:0c0d::/64, or any other prefixthat fits within2001:0db8:0a0b:0c0d::/64, Google Cloud doesn'tcreate any local, peering, or Network Connectivity Center dynamic routes for thereceived conflicting prefixes.

• Google Cloud removes any existing dynamic route if anychange tosubnets results in the creation of a new local, peering,or Network Connectivity Center subnet route whose destination exactly matches orcontains the destination of the existing local, peering, orNetwork Connectivity Center dynamic route. For example:

  • If your VPC network has a local, peering, orNetwork Connectivity Center dynamic route with the10.70.1.128/25 destination,Google Cloud removes the dynamic route when a new local, peering, orNetwork Connectivity Center subnet route for10.70.1.128/25,10.70.1.0/24, orany other IP address range that contains all the IPv4 addresses in10.70.1.128/25 is created.

  • If your VPC network has a local, peering, orNetwork Connectivity Center dynamic route with the2001:db8:a0b:c0d::/96destination, Google Cloud removes the dynamic route when a new local,peering, or Network Connectivity Center subnet route for2001:db8:a0b:c0d::/64 iscreated.

Applicability and order

Applicable routes

Each instance, Cloud VPN tunnel, and VLAN attachment has a set ofapplicable 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 VMinstances, 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 bynetworktags
  • 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 dynamicroute's next hop or all regions, based on the dynamic routing mode of theVPC network.

Special routing paths

VPC networks have special routes for certain services. Thesespecial routing paths don't appear in your VPC network routetable. You can't remove any special routing paths. However, you can allow ordeny 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 andexternal protocolforwarding useMaglevsystems to route packets from clients on the internet to backend VMs and targetinstances in your VPC network. These Maglev systems route packetsthat have destinations that match the destination of the external forwardingrule.

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

• Packets sent by backend VMs or target instances can be either outboundresponse packets (sent back to the client) or they can be outbound packetsthat initiate a new connection.
• Packet sources must match the forwarding rule's IP address. Packet protocoland source port don't have to match the forwarding rule's protocol and portspecification.
• Forwarding rule routing paths don't depend on a default route or the use ofthe 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 andexternal proxy Network Load Balancers use Google Front Ends (GFEs).Second layer GFEs open TCP connections to your backend VMs and send packets fromthe following sources:

• 35.191.0.0/16 and130.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 thosesource ranges to backend VMs in your VPCnetwork. Each VPC network includes routing paths that allow VMsto send response packets to the ranges.

Paths for health checks

Health checks for all load balancers and formanaged instance groupautohealing sendpackets to your backend VMs fromhealth check probe IP addressranges.

Google Cloud uses routes in Google's network to deliver packets fromhealth check probe systems to VMs in your VPCnetwork. Each VPC network includes routing paths that allow VMsto send response packets to the health check probe systems.

Paths for Identity-Aware Proxy (IAP)

IAP for TCP forwardinguses35.235.240.0/20 (IPv4) and2600:2d00:1:7::/64 (IPv6). Theseranges are used exclusively within Google's production network, andcan't be used for any other purpose:

• Google edge routers drop packets from the internet if the packets spoofsource IP addresses from the IAP ranges. Google edgerouters also don't have valid next hops for destinations in theseranges.

• Each VPC network includes non-removable routes whosedestinations are the IAP ranges. These routes providecommunication between IAP proxies and VMs (foradministrative protocols like SSH and RDP). You can't privately usethe IAP ranges as subnet ranges in VPCnetworks.

Paths for Cloud DNS and Service Directory

The following Cloud DNS and Service Directory features use35.199.192.0/19:

• Cloud DNSforwarding targets that use private routing
• Cloud DNSalternative name servers that use private routing
• Private network access for Service Directory

This range is used exclusively within Google's production network, and can'tbe used for any other purpose:

• Google edge routers drop packets from the internet if the packets spoofsource IP addresses from the Cloud DNS and Service Directoryfeature range. Google edge routers also don't have valid next hops fordestinations in this range.

• Each VPC network includes a non-removable route whosedestination is the Cloud DNS and Service Directory range. Thisroute allows Cloud DNS and Service Directory proxies tocommunicate with resources in a VPC network. You can'tprivately use the Cloud DNS and Service Directory range asa subnet range in a VPC network.

Paths for Serverless VPC Access

Serverless VPC Access uses35.199.224.0/19. This range is used exclusively within Google's productionnetwork, and can't be used for any other purpose:

• Google edge routers drop packets from the internet if the packets spoofsource IP addresses from the Serverless VPC Access range. Googleedge routers also don't have valid next hops for destinations in thisrange.

• Each VPC network includes a non-removable route whosedestination is the Serverless VPC Access range. This route allowsthe VM instances that power Serverless VPC Access connectors tocommunicate with serverless products. You can't privately use theServerless VPC Access range as a subnet range in aVPC network.

Paths for Chrome Enterprise Premium

Chrome Enterprise Premiumuses34.158.8.0/21 and136.124.16.0/20. These ranges are usedexclusively within Google's production network, and can't be used for anyother purpose:

• Google edge routers drop packets from the internet if the packets spoofsource IP addresses from the Chrome Enterprise Premium ranges. Google edge routersalso don't have valid next hops for destinations in these ranges.

• Each VPC network includes non-removable routes whosedestinations are the Chrome Enterprise Premium ranges. These routes providecommunication between Chrome Enterprise Premium secure gateways and privateapplications running on resources in a VPC network.You can't privately use the Chrome Enterprise Premium ranges as subnet ranges inVPC networks.

Paths for Private Service Connect endpoints for global Google APIs

When you create aPrivate Service Connect endpoint for global GoogleAPIs,Google Cloud adds a route for the endpoint to your VPCnetwork. The route's destination is the global internal IP address of theendpoint.

Routing order

There might be more than oneapplicable route for a givenpacket. The following steps model the process that Google Cloud uses toselect a route.

1. Special routing paths: SomeGoogle Cloud special routing paths not shown inVPC network route tables. For details, seeSpecial routingpaths.

   If a special routing path is applicable, your route selection model containsonly the special path. All other routes are disregarded, and evaluationstops at this step.

2. Policy-based routes: Policy-basedroutes are evaluated after special routing paths but before other types ofroutes. If no policy-based routes exist in the VPC network,Google Cloud skips this step and continues to thesubnet routes step.

   Google Cloud evaluates policy-based routes solely by their priority.Google Cloud evaluates a packet's source and destination for eachpolicy-based route, starting with the highest priority policy-based route orroutes. If a packet's characteristics don't match a policy-based route,Google Cloud disregards that policy-based route and continues toevaluate the next policy-based route in the sorted list. The nextpolicy-based route to evaluate might share the same priority as thedisregarded policy-based route, or it might have a lower priority.

   • If a packet's characteristicsdon't match any policy-based routeafter evaluating all policy-based routes in your route selection model,Google Cloud disregards all policy-based routes and continues tothesubnet routes step.

   • If a packet's characteristics match a highest-priority policy-basedroute, Google Cloud first disregards all lower-prioritypolicy-based routes. If two or more policy-based routes are left in thelist, Google Cloud evaluates each of the remaining policy-basedroutes that have identical priorities. Google Cloud disregards anyremaining policy-based routes if a packet's characteristics don't matchit. After this step, your route selection model might contain one ormore policy-based routes.

   • If your route selection model includes two or more matchinghighest-priority policy-based routes, Google Cloud selects asingle policy-based route by using an internal algorithm. The selectedpolicy-based route might not be the most specific match for the packet'ssource or destination. To avoid this ambiguity, we recommend that youcreate policy-based routes that have unique priorities.

   • If your route selection model includes only a single highest-prioritypolicy-based route that is configured toskip other policy-basedroutes, Google Clouddisregards all policy-based routes and continues to thesubnet routes step.

   • If your route selection model includes only a single highest-prioritypolicy-based route thatis not configured to skip other policy-basedroutes, Google Cloud delivers the packet to the next hopinternal passthrough Network Load Balancer, and disregards all non-policy-based routes.

3. Subnetroutes: Google Cloud determines whether thepacket's destination fits within the destination range of a local, peering,or Network Connectivity Center subnet route in the VPC network.

   • No matching subnet route: If a packet's destinationdoesn't matchthe destination range of any subnet route, Google Cloud disregardsall subnet routes. Remove all subnet routes from your route selectionmodel and continue to theMost specificdestination step to evaluate static and dynamic routes.

   • Matching regular subnet route: For most subnets, if a packet'sdestination matches the destination range of a regular subnet route,Google Cloud exclusively uses the subnet route. Google Clouddisregards all other routes, and evaluation stops at this step. If thepacket's destination isn't associated with a resource or belongs to astopped VM instance, the packet is dropped.

   • Matching hybrid subnet route: If a packet's destination matches thedestination range of ahybrid subnet route,and the destination matches an IP address that's associated with arunning VM instance or an internal forwarding rule, Google Cloudroutes the packet using the hybrid subnet route. Google Clouddisregards all other routes, and evaluation stops at this step.

     If the destination doesn't match a running VM or an internal forwardingrule, seeUnmatched resources in hybridsubnets.

4. Most specific destination: At thebeginning of this step, Google Cloud has disregarded all specialrouting paths, policy-based routes, and subnet routes.

   Google Cloud determines which applicable static or dynamic routes havethe most specific destination that contains the destination IP address of thepacket. Google Cloud disregards all routes except those with the mostspecific destination. For example,10.240.1.0/24 is a more specificdestination than10.240.0.0/16.

   At the end of this step, your route selection model only contains static ordynamic routes with identical destinations.

5. Select only the mostfavorable custom route type: In this step, Google Cloudremoves all custom routes except the most favorable custom route type. Localcustom routes are preferred over Network Connectivity Center dynamic routes, andNetwork Connectivity Center dynamic routes are preferred over peering custom routes.

   The following table summarizes the logic that Google Cloud uses inthis step.

   Custom route category	What happens
   Local dynamic and local static routes	If your route model contains at least one local dynamic or local static route for the destination, Google Cloud removes the following custom route types, if they are present in the route model: Network Connectivity Center dynamic routes from hybrid spokes, in different VPC networks Peering dynamic routes (imported from other VPC networks connected using VPC Network Peering)
   Network Connectivity Center dynamic routes	Ifall of the following conditions are met, Google Cloud removes all peering dynamic and peering static routes from the route model: Your route modeldoesn't contain any local custom routes for the destination Your route mode does contain at least one Network Connectivity Center dynamic route for the destination The Network Connectivity Center dynamic route comes from from a hybrid spoke in a different VPC network
   Peering dynamic and peering static routes	The least favorable custom route type contains peering custom routes. Peering custom routes for the destination are used only when the route modeldoesn't contain any local custom routes or Network Connectivity Center dynamic routes for the destination.

6. Select next hops forpeering custom routes from a single VPC network:Next hops for the same destination must be located in the sameVPC network. This steponly applies if your route modelcontains peering dynamic or peering static routes that are imported from twoor more different VPC networks connected usingVPC Network Peering.

   Google Cloud uses an internal algorithm to import peering custom routesfrom asingle VPC network. The peer network thatGoogle Cloud selects might change if your VPC networkpeers with a new VPC network or if it disconnects from anexisting peer VPC network.

7. Disregard static anddynamic routes with unusable next hops: This step models situations whereGoogle Cloud disregards next hops that are down or invalid.

   • Invalid next hop VM IP address specification: Thenext-hop-addressof a static route must match an IP address that is assigned to a VM in theroute's VPC network. The IP address must be assigned to theVM's network interface as one of the following:

     • A primary internal IPv4 address
     • An internal IPv6 address
     • An external IPv6 address

     If the IP address specified bynext-hop-address matches a different typeof resource (like an alias IP range) or doesn't match any resource,Google Cloud disregards the route.

   • Next hop VM stopped or deleted: Google Cloud disregards eachstatic route whose next hop VM instance has been stopped or deleted. Thisbehavior applies to routes whose next hops are specified using eithernext-hop-instance ornext-hop-address. For more information, seeBehavior when instances are stopped ordeleted.

   • Invalid next hop load balancer IP address specification: For staticroutes that have a next hop load balancer specified by IP address, the IPaddress must match a forwarding rule of an internal passthrough Network Load Balancer that is locatedin the route's VPC network or in a peered VPCnetwork. If the next hop IP address matches the forwarding rule of adifferent type of load balancer or doesn't match any forwarding rule,Google Cloud disregards the route.

   • Unestablished next hop Classic VPN tunnel:Google Cloud disregards each static route with a next hopClassic VPN tunnel that doesn't have an active Phase 1(IKE) security association (SA). For more details, seeOrder ofroutesin the Classic VPN documentation.

   • Dynamic route with nonfunctional next hop: Even before the BGP sessionresponsible for programming a dynamic route goes down, Google Clouddisregards a dynamic route if its next hop Cloud VPN tunnel,VLAN attachment, or Router appliance VM isn't functional. Thissituation generally only exists for a few seconds before the dynamic routeis removed when the corresponding Cloud Router BGP session goesdown.

   Google Cloud doesn't validate whether the guest OS of a next hop VM ora backend VM for a next hop load balancer is processing packets. For moreinformation, seeConsiderations common to instance and internal passthrough Network Load Balancer nexthops.

8. Disregard low priorityroutes: This step models how Google Cloud discards all routes exceptfor those with the highest priority.

   After this step, your route model might be empty, or it might contain one ormore routes. If your model isn't empty, all routes in your model have thefollowing characteristics:

   • Identical priorities
   • Next hops that haven't been disregarded
   • Identical destinations
   • Route types that aren't policy-based or subnet routes

9. Select next hops forNetwork Connectivity Center dynamic routes from a single VPCnetwork: Next hops for the same destination must be located in the sameVPC network. This steponly applies if your route modelcontains Network Connectivity Center dynamic routes imported from two or more hybridspokes located indifferent VPC networks.

   Google Cloud uses an internal algorithm to import Network Connectivity Centerdynamic routes from hybrid spokes located in a single VPCnetwork. The selected hybrid spokes might change if you add hybrid spokes toor remove hybrid spokes from the Network Connectivity Center hub. To avoid thisambiguity, ensure that Network Connectivity Center dynamic routes have uniquepriorities when the following applies:

   • The routes have identical destinations.
   • The routes are imported from two or more hybrid spokes in differentVPC networks.

10. Select only the most favorablepreference category: Google Cloud doesn't performequal-costmultipath (ECMP)among routes that belong to different preference categories, as defined inthis step.

    Preference category	Route type and next hop type
    First preference (most preferred)	One or more static routes with next hop instances (next-hop-instance ornext-hop-address) or next hop Classic VPN tunnels.
    Second preference	One or more dynamic routes of a single type.
    Third choice	A single static route with next hop internal passthrough Network Load Balancer.
    Fourth preference (least preferred)	One or more static routes with next hopdefault-internet-gateway.

    In this step, when two or more static routes with next hop load balancerexist, Google Cloud selects a single static route using an internalalgorithm—Google Cloud doesn't perform ECMP among multiple loadbalancers. For more information, seeConsiderations for internal passthrough Network Load Balancer nexthops.

    After this step, your route model might be empty, or it might contain one ormore routes. If your model isn't empty, all routes in your model have thesecharacteristics:

    • Identical preference category
    • Identical priorities
    • Next hops that haven't been disregarded
    • Next hops in one VPC network
    • Identical destinations
    • Route types that aren't policy-based or subnet routes

11. Send or drop packet: Depending on thenumber of routes remaining in the route model, Google Cloud sends ordrops the packet:

    • If your route model contains a single route, Google Cloud sendsthe packet to the next hop, with the following exception:

      Next hop internal passthrough Network Load Balancers that don't have global access enabled aren'treachable from regions outside of the load balancer's region.Consequently, if a next hop load balancerdoesn't have global accessenabled, Google Cloud drops all packets sent from VM instances,VLAN attachments, and Cloud VPN tunnels in regions differentfrom the load balancer's region. To change this behavior,enable globalaccess.

    • If your route model contains two or more routes, Google Cloudperforms ECMP, distributing packets among the next hops. Selection ofthe next hop depends on a hash calculation and the number of next hops.Google Cloud uses a five-tuple hash if the packet contains portinformation; otherwise, it uses a three-tuple hash. Consistent next hopselection for a given hash is not guaranteed—Google Cloudmight direct packets to a different next hop even if the hash is thesame and the route model is unchanged.

    • If your route model is empty, Google Cloud drops the packet withanICMP type 3, code 0 (network unreachable)message.

Unmatched resources in hybrid subnets

If your route model contains a hybridsubnet route,and the packet's destination matches an IP address that's associated with astopped VM, or isn't associated with any resource in the hybrid subnet,Google Cloud uses a different process to route the packet. The followingsteps model the process that Google Cloud uses to route these packets:

1. Identify the VPC network that contains the hybrid subnet:

   • The hybrid subnet and the resource that sends packets to the hybrid subnetmight use the same VPC network. In this case, the hybridsubnet creates a corresponding local subnet route in thatVPC network.

   • The hybrid subnet and the resource that sends packets to the hybrid subnetmight be in different VPC networks connected usingVPC Network Peering. In this case, the hybrid subnet creates acorresponding peering subnet route in the VPC networkused by the resource that sends packets.

2. Start with all routes of the VPC network that contains thehybrid subnet and then remove the following routes:

   • All policy-based routes
   • All subnet routes
   • All static routes that have network tags
   • All routes whose destinations are broader than and contain the hybrid subnetroute that was matched in the first route model

3. Perform themost specific destination throughselect only the most favorable preference categorysteps in the routing order.

4. Use the following rules to determine if Google Cloud sends or drops thepacket:

   • If the route model contains a single route,and the route's nexthop is in the same region as the hybrid subnet, Google Cloud sendsthe packet to the next hop.

   • If the route model contains two or more routes, Google Cloudperforms ECMP among those routes. When a next hop is in the same region asthe hybrid subnet, Google Cloud sends the packet to the next hop.

   • Google Cloud drops the packet with anICMP type 3, code 0 (networkunreachable) message if theroute model is empty, or if a next hop is in a region differentfrom the region of the hybrid subnet.

   The following routes have next hops in regions different from the hybridsubnet's region, so they always result in packet drops:

   • Dynamic routes learned by Cloud Routers in regions different fromthe hybrid subnet's region, even if the dynamic routing mode of theVPC network that contains the Cloud Routers isglobal
   • Static routes that have next hops in regions different from the hybridsubnet's region, including all internal passthrough Network Load Balancers in different regions evenif they have global access enabled

What's next

• To create and manage routes, seeUse routes.
• To learn more about static routes, seeStatic routes.
• To get an overview of Google Cloud VPC networks, seeVPC networks.
• To create, modify, or delete VPC networks, seeCreate andmanage VPC networks.