Cloud Router overview

Cloud Router is a fully distributed and managed Google Cloud service that uses the Border Gateway Protocol (BGP) to advertise IP prefixes. It programs dynamic routes based on the BGP advertisements that it receives from a peer. Instead of a physical device or appliance, each Cloud Router consists of software tasks that act as BGP speakers and responders. A Cloud Router also serves as the control plane for Cloud NAT. Cloud Router provides BGP services for the following Google Cloud products:

• Cloud Interconnect
• Cloud VPN, specifically HA VPN
• Router appliance (part of Network Connectivity Center)

Each Cloud Router works with at least one of the networking connectivity products listed previously.

Note: You can use Cloud Router with Classic VPN, but only to support dynamic routing for tunnels that connect to third-party VPN gateway software running within a Google Cloud VM instance. All other dynamic routing functionality for Classic VPN is deprecated. For more information, see Classic VPN dynamic routing partial deprecation.

When you connect an on-premises or multicloud network to Google Cloud, Cloud Router uses BGP to dynamically exchange routes between your Google Cloud VPC network and the remote network. Prefix and next hop changes automatically propagate between your VPC network and the other network without the need for static routes.

You can also use Cloud Router to connect two VPC networks in Google Cloud. In this scenario, you connect the VPC networks by using two HA VPN and two Cloud Routers, one HA VPN and its associated Cloud Router on each network.

Direct Peering and Carrier Peering do not use Cloud Routers.

Specifications

A Cloud Router can advertise VPC subnet routes and custom prefixes on its BGP sessions. Unless you configure custom advertisement mode, a Cloud Router only advertises VPC subnet routes. Custom advertisement mode also lets you configure a Cloud Router to omit advertising VPC subnet routes.

The dynamic routing mode of a VPC network—either regional or global— determines which VPC subnet routes the Cloud Routers in that network advertise. For details, see Default advertisement mode.

The dynamic routing mode also controls how each Cloud Router applies learned prefixes as dynamic routes in a VPC network. For details about this behavior, see Effects of dynamic routing mode.

When you configure BGP for Cloud Interconnect, HA VPN, and Router appliance, you can optionally configure the router's peering sessions to use MD5 authentication.

Autonomous system number (ASN)

When you create a Cloud Router, you choose the Google-side ASN for all BGP sessions used by the Cloud Router. The directions for each network connectivity product listed in the Additional resources section provide details about how each product uses ASN.

Note: Cloud NAT does not use ASN information. Cloud NAT gateways can be connected to Cloud Routers that have any ASN or that have no ASN specified.

BGP peering IP addresses

BGP sessions for the following network connectivity products use link-local IPv4 addresses in the 169.254.0.0/16 range as BGP peering IP addresses:

• For Dedicated Interconnect, you can either specify candidate link-local addresses for BGP peering addresses, or Google Cloud can select unused link-local addresses automatically.
• For Partner Interconnect, Google Cloud selects unused link-local IPv4 addresses automatically.
• For HA VPN and Classic VPN using dynamic routing, you can specify the BGP peering IP addresses when you create the BGP interface on the Cloud Router.

Router appliances use internal IPv4 addresses of Google Cloud VMs as BGP IP addresses. For details, see Creating router appliance instances.

Access to internal load balancers

For details about how to access internal load balancers from a connected on-premises network, see Internal load balancers and connected networks in the Cloud Load Balancing documentation.

IPv6 support

Cloud Router supports Multiprotocol BGP (MP-BGP) and can exchange IPv6 prefixes over BGP IPv4 sessions. Native IPv6-only sessions are not supported.

Cloud Router advertises IPv6 prefixes for VPC networks that include dual-stack subnets. By default, internal IPv6 subnet ranges are advertised automatically. External IPv6 subnet ranges are not advertised automatically, but you can advertise them manually by using custom advertised routes.

You can enable IPv6 prefix exchange in BGP sessions that are created for HA VPN tunnels and VLAN attachments. For details, see the following documents:

• Create an HA VPN to a peer VPN gateway
• Create an HA VPN to another HA VPN gateway
• Create VLAN attachments (Dedicated)
• Enable or disable IPv6 prefix exchange in BGP IPv4 sessions

For details about IPv6 route advertisements, see Route advertisement modes.

IPv6 limitations

IPv6 prefix exchange is not supported in BGP sessions for the following resources:

• Partner Interconnect VLAN attachments
• Classic VPN tunnels
• Router appliance (part of Network Connectivity Center)

Cloud Router software tasks

Cloud Routers are implemented by one, two, or in rare cases, three software tasks.

The following table provides example scenarios and the number of software tasks used by Google Cloud to implement the Cloud Router in each scenario.

• For the HA configurations listed in the table, two software tasks are used to provide software redundancy.
• For VLAN attachments, a separate software task handles each edge availability domain with attachments.

Note: AS path length selection does not work when Cloud Router is implemented by more than one software task. However, if Cloud Router is implemented by more than one software task, all prefixes advertised to Google Cloud by BGP peers must use the same AS path length. This ensures that Google Cloud uses only MED to select the best routes.

Example scenario	Number of software tasks used to implement the Cloud Router
One or more interfaces, each connected to a Classic VPN tunnel.	One
One or more interfaces, each connected to a VLAN attachment, where the VLAN attachments are in the same edge availability domain.	One
Any number of interfaces, each connected to an HA VPN tunnel, where the tunnels are all connected to the same interface number on one or more HA VPN gateways—for example, two tunnels, each connected to interface 0 on different HA VPN gateways.	One
At least two interfaces, one connected to a VLAN attachment in a single edge availability domain, and another connected to a single HA VPN tunnel, where the edge availability domain and VPN gateway interface numbers are the same—for example, the first edge availability domain in a pair of edge availability domains and the first VPN gateway interface.	One
At least two interfaces, each connected to a router appliance instance, where one of the interfaces is configured as a redundant interface. To create a redundant interface, use the redundant-interface flag (Google Cloud CLI) or the redundantInterface field (Compute Engine API). Router appliance is part of Network Connectivity Center.	Two
At least two interfaces, each connected to a VLAN attachment, where the VLAN attachments are in different edge availability domains.	Two
At least two interfaces, each connected to an HA VPN tunnel, where each tunnel is connected to different HA VPN gateway interface numbers—for example, one tunnel connected to interface 0 of an HA VPN gateway and another tunnel connected to interface 1 of the same gateway or a different gateway.	Two
A Cloud Router with at least the following: One interface connected to a VLAN attachment in edge availability domain 0 and/or one interface connected to an HA VPN tunnel that is connected to interface 0 of an HA VPN gateway. One interface connected to a VLAN attachment in edge availability domain 1 and/or one interface connected to an HA VPN tunnel that is connected to interface 1 of an HA VPN gateway. One interface connected to a Classic VPN tunnel.	Three

Software maintenance and automated task restarts

Google Cloud performs regular maintenance events to release new features and to improve reliability. During maintenance, new software tasks are provisioned. Your on-premises router logs indicate that BGP sessions managed by those software tasks went down and came back up (a BGP flap).

Cloud Router maintenance is an automatic process, and it is designed so that it does not interrupt routing. Maintenance events are expected to take no more than 60 seconds. Before maintenance, the Cloud Router sends a graceful restart notification (a TCP FIN packet) to the on-premises router.

If your on-premises router can process graceful restart events, it logs a graceful restart event during Cloud Router maintenance. For on-premises routers that do not support graceful restart, ensure that the on-premises router's hold timer is set to 60 seconds. For details, see Manage BGP timers.

Cloud Router maintenance events are not announced in advance because routes are not lost on properly configured on-premises routers. To get details about completed maintenance events, see Identify router maintenance events.

For information about how graceful restart works with Bidirectional Forwarding Detection (BFD), see Graceful restart and BFD.

Route advertisement modes

By using BGP and a network connectivity product listed in the Additional resources section, a Cloud Router advertises IP address ranges to your on-premises network. This allows clients in your on-premises network to send packets to and receive packets from resources in your VPC network.

Cloud Router offers two route advertisement modes: default advertisement mode and custom advertisement mode.

Default advertisement mode

Using the default advertisement mode configures a Cloud Router or BGP session to advertise prefixes for the following types of subnet IP address ranges. The dynamic routing mode of the VPC network controls whether the advertised subnet IP address ranges only come from the same region as the Cloud Router or whether they come from all regions:

• Regional dynamic routing mode: Each Cloud Router in the VPC network advertises primary and secondary IPv4 subnet ranges in the same region as the Cloud Router. If conditions for IPv6 route advertisement are met, Cloud Router advertises internal (ipv6-access-type=INTERNAL) IPv6 subnet ranges in the same region as the Cloud Router.

• Global dynamic routing mode: Each Cloud Router in the VPC network advertises primary and secondary IPv4 subnet ranges from all regions in the VPC network. If conditions for IPv6 route advertisement are met, Cloud Router advertises internal (ipv6-access-type=INTERNAL) IPv6 subnet ranges from all regions in the VPC network.

If you advertise privately used public IPv4 addresses, on-premises systems might be unable to access internet resources, which use those public IPv4 addresses.

Subnet route advertisements are updated automatically, as described in Automatic updates for subnet route advertisements.

Custom advertisement mode

Custom advertisement mode gives you control over the prefixes that a Cloud Router advertises. You can specify custom advertised routes (including default route prefixes, 0.0.0.0/0 or ::/0) for all BGP sessions on a Cloud Router or on a per-BGP session basis. There are two categories of custom advertised routes:

• You can advertise only custom IPv4 and IPv6 prefixes. This type of custom advertised route omits the subnet routes that would be advertised using default advertisement mode.

• You can advertise custom IPv4 and IPv6 prefixes in addition to subnet routes. This type of custom advertised route includes the same subnet routes advertised using default advertisement mode.

If you choose to advertise subnet routes, their advertisements are updated automatically as described in Automatic updates for subnet route advertisements.

If conditions for IPv6 route advertisement are met, Cloud Router advertises internal IPv6 subnet ranges whenever you choose to advertise subnet routes. You must add any external IPv6 subnet ranges to your list of custom routes in order to advertise them.

For the maximum number of custom advertised routes that can be advertised on each BGP session, see maximum number of custom advertised routes per BGP session on the Cloud Router limits page. This maximum applies to custom advertised routes for the whole Cloud Router and individually per BGP session.

For more information, see the following documents:

• Advertise custom IP ranges
• Advertise specific VPC subnets

Effective advertised prefixes

The route advertisement mode is configurable on both the whole Cloud Router and on individual BGP sessions of the Cloud Router. The following table describes which prefixes are advertised on the BGP session, based on the selected advertisement mode of the Cloud Router and the BGP session.

Mode for Cloud Router	Mode for BGP session	Effective advertised prefixes on the BGP session
default	default	The BGP session inherits the Cloud Router configuration. Subnet routes are advertised as described in Default advertisement mode.
custom	default	The BGP session inherits the Cloud Router configuration. Custom routes configured on the whole Cloud Router are advertised as described in Custom advertisement mode. Advertised routes might contain some or all subnet routes.
default or custom	custom	The BGP session does not inherit the Cloud Router configuration. Custom advertised routes configured on the BGP session itself are advertised as described in Custom advertisement mode. Advertised routes might contain some or all subnet routes.

Automatic updates for subnet route advertisements

Cloud Router automatically updates subnet route advertisements in the following situations:

• When you create an IPv4 only subnet

• When you create a dual-stack subnet with internal IPv6 enabled

• When you delete a subnet

• When you enable internal IPv6 on an existing IPv4 only subnet

• When you expand a subnet's primary IPv4 range

• When you edit a subnet's secondary IPv4 ranges

Conditions for IPv6 route advertisement

Cloud Router can advertise IPv6 routes when all of the following conditions are met:

• The network connectivity product used with Cloud Router, such as the HA VPN gateway, is configured to use the IPv4 and IPv6 dual stack type.
• The BGP session is specifically configured to enable IPv6 prefix exchange. See Enabling or disabling IPv6 prefix exchange.

In order to advertise internal IPv6 subnet ranges, your VPC network must have an assigned internal (ULA) IPv6 range and you must have created at least one dual-stack subnet with an internal IPv6 subnet range.

Advertised prefixes and priorities

When a Cloud Router advertises prefixes to a BGP peer, it includes a priority for each prefix in the advertisement (BGP message). The advertised priority is implemented as a MED.

You can control what prefixes Cloud Router advertises to all or some of its BGP sessions. You control the advertised priority (MED) by defining a base priority for the prefixes.

• If your VPC network uses regional dynamic routing mode, unless you advertise custom ranges, each Cloud Router only advertises the subnet ranges in the same region as the Cloud Router. Each range is advertised as a prefix with the MED being the base priority.

• If your VPC network uses global dynamic routing mode, unless you advertise custom ranges, each Cloud Router advertises subnet ranges from its local region as prefixes whose MED matches the base priority. In addition, Cloud Routers advertise subnet ranges from different regions as prefixes whose MEDs equal the base priority plus a region-to-region cost. Google Cloud calculates a region-to-region cost automatically based on factors such as network performance, distance, and available bandwidth between regions. Each region-to-region cost has a value specific to a pair of regions—the subnet's region and the region of the advertising Cloud Router.

When your on-premises routers receive the advertised prefixes and their priorities, they create routes that are used to send packets to your VPC network.

Note: Region-to-region costs can periodically change based on factors such as network performance. These changes can affect how packets are routed. If you notice routing changes, it might be due to updated region-to-region costs.

Caution: The route selection process in the on-premises network might not prioritize the lower-MED route. Because other attributes (such as router ID or origin ASN) can affect how the BGP best path selection works, see your device documentation.

For example, see the following resources:

• Cisco: BGP Path Selection

• Fortinet: BGP Handbook

• Juniper: BGP Path Selection

Guidance for base priorities

When you configure a BGP session on a Cloud Router, you can specify a base advertised priority for the BGP session. The base advertised priority applies to all prefixes (destinations) advertised by that BGP session.

Base priorities are whole numbers from 0 to 65535. The highest possible base priority is 0. The default base priority is 100. If you don't specify a base priority, the default priority is used.

Base priorities let you control which Cloud VPN tunnels or VLAN attachments on-premises systems use to send packets to your VPC network. You can create active/active, active/passive, or a custom combination of these topologies by using the base priority. For an example using HA VPN tunnels, see Active/active and active/passive routing options for HA VPN in the Cloud VPN documentation.

When choosing base priorities, keep the following in mind:

• Region-to-region costs are between 201 and 9999, inclusive. The value depends on the distance, latency, and other factors between two regions. Google generates the region-to-region cost values, and you can't modify them.

• Base priorities for BGP sessions among Cloud Routers in a region should be between 0 and 200, inclusive. Because region-to-region costs are at least 201, if you use base priorities of 201 or more, you might accidentally assign a Cloud VPN tunnel or VLAN attachment a lower priority than you intend. Another BGP session in a different region might advertise the same prefix with an overall higher priority (MED, which equals base priority plus region-to-region cost). Without carefully setting base priorities in other regions, you might cause on-premises traffic to be delivered to your VPC network by way of an unexpected Cloud VPN tunnel or VLAN attachment.

• Base priorities of 10,200 or more ensure that a prefix's overall advertised priority (MED, base priority plus region-to-region cost) is always lower than any other advertised prefix with a base priority of 200 or less.

Note: Because advertised prefixes are used to create routes in your on-premises network, verify that advertised prefixes have been implemented by looking at the route tables of your on-premises devices, and not at the routes in your VPC network.

For more information about setting a base priority, see Updating the base advertised route priority.

Examples

This section provides examples that show how region-to-region costs influence advertised MEDs when you use global dynamic routing.

HA VPNs with active/active tunnels

In this example, you have a VPC network with the following:

• One subnet in each of the following regions: us-central1, europe-west1, and us-west-1
• One Cloud Router that manages two BGP sessions for two HA VPN tunnels in us-central1
• One Cloud Router that manages two BGP sessions for two HA VPN tunnels in us-west1

For an illustration of this example, see the following diagram, which includes example values for region-to-region cost.

HA VPNs with active/active tunnels (click to enlarge)

Assume that each BGP session has the default base priority of 100.

The following tables show how base priority and region-to-region cost are used to calculate the advertised MED values for traffic from your on-premises network to each subnet.

10.0.1.0/24 (us-central1)

This table shows the BGP sessions that advertise subnet IP address range 10.0.1.0/24, which is located in us-central1.

Traffic from your on-premises network uses the HA VPN tunnel in us-central1 because its BGP sessions have the lowest advertised MED.

VPN tunnel	Base priority	Region-to-region cost	Advertised MED	Path ranking
central-tunnel-0, central-tunnel-1	100	0	100	1st choice
west-tunnel-0, west-tunnel-1	100	250	350	2nd choice

10.0.2.0/24 (europe-west1)

This table shows the BGP sessions that advertise subnet IP address range 10.0.2.0/24, which is located in europe-west1.

Traffic from your on-premises network uses the HA VPN tunnel in us-central1 because its BGP sessions have the lowest advertised MED.

VPN tunnel	Base priority	Region-to-region cost	Advertised MED	Path ranking
central-tunnel-0, central-tunnel-1	100	300	400	1st choice
west-tunnel-0, west-tunnel-1	100	350	450	2nd choice

10.0.3.0/24 (us-west1)

This table shows the BGP sessions that advertise subnet IP address range 10.0.3.0/24, which is located in us-west1.

Traffic from your on-premises network uses the HA VPN tunnel in us-west1 because its BGP sessions have the lowest advertised MED.

VPN tunnel	Base priority	Region-to-region cost	Advertised MED	Path ranking
central-tunnel-0, central-tunnel-1	100	250	350	2nd choice
west-tunnel-0, west-tunnel-1	100	0	100	1st choice

HA VPNs with active/passive tunnels

This example uses the same topology as in the previous example, but with modified base priorities in order to achieve an active/passive HA VPN tunnel pair in each region:

• A primary tunnel whose BGP session has the default base priority of 100
• A secondary tunnel whose BGP session has a lower priority of 351

The following tables show how base priority and region-to-region cost are used to calculate the advertised MED values for traffic from your on-premises network to each subnet.

10.0.1.0/24 (us-central1)

This table shows the BGP sessions that advertise subnet IP address range 10.0.1.0/24, which is located in us-central1.

Traffic from your on-premises network uses the primary VPN tunnel in us-central1 because its BGP session has the lowest advertised MED. If that tunnel is not available, traffic uses the primary tunnel in us-west1.

VPN tunnel	Base priority	Region-to-region cost	Advertised MED	Path ranking
central-tunnel-0	100	0	100	1st choice
central-tunnel-1	351	0	351	3rd choice
west-tunnel-0	100	250	350	2nd choice
west-tunnel-1	351	250	601	4th choice

10.0.2.0/24 (europe-west1)

This table shows the BGP sessions that advertise subnet IP address range 10.0.2.0/24, which is located in europe-west1.

Traffic from your on-premises network uses the primary VPN tunnel in us-central1 because its BGP session has the lowest advertised MED. If that tunnel is not available, traffic uses the primary tunnel in us-west1.

VPN tunnel	Base priority	Region-to-region cost	Advertised MED	Path ranking
central-tunnel-0	100	300	400	1st choice
central-tunnel-1	351	300	651	3rd choice
west-tunnel-0	100	350	450	2nd choice
west-tunnel-1	351	350	701	4th choice

10.0.3.0/24 (us-west1)

This table shows the BGP sessions that advertise subnet IP address range 10.0.3.0/24, which is located in us-west1.

Traffic from your on-premises network uses the primary VPN tunnel in us-west1 because its BGP session has the lowest advertised MED. If that tunnel is not available, traffic uses the primary tunnel in us-central1.

VPN tunnel	Base priority	Region-to-region cost	Advertised MED	Path ranking
central-tunnel-0	100	250	350	2nd choice
central-tunnel-1	351	250	601	4th choice
west-tunnel-0	100	0	100	1st choice
west-tunnel-1	351	0	351	3rd choice

Globally preferred Dedicated Interconnect

This example is similar to the previous examples, except that you have replaced the two Cloud VPN tunnels in the us-west1 region with two VLAN attachments.

For an illustration of this example, see the following diagram.

Globally preferred Dedicated Interconnect (click to enlarge)

You want to prioritize the VLAN attachments. You specify larger base priorities for the HA VPN tunnels in the us-central1 region to deprioritize them.

The following tables show how base priority and region-to-region cost are used to calculate the advertised MED values for traffic from your on-premises network to each subnet.

10.0.1.0/24 (us-central1)

This table shows the BGP sessions that advertise subnet IP address range 10.0.1.0/24, which is located in us-central1.

Traffic from your on-premises network uses the VLAN attachment in us-west1 because its BGP sessions have the lowest advertised MED.

VPN tunnel or VLAN attachment	Base priority	Region-to-region cost	Advertised MED	Path ranking
central-tunnel-0, central-tunnel-1	351	0	351	2nd choice
west-attachment-0, west-attachment-1	100	250	350	1st choice

10.0.2.0/24 (europe-west1)

This table shows the BGP sessions that advertise subnet IP address range 10.0.2.0/24, which is located in europe-west1.

Traffic from your on-premises network uses the VLAN attachment in us-west1 because its BGP sessions have the lowest advertised MED.

VPN tunnel or VLAN attachment	Base priority	Region-to-region cost	Advertised MED	Path ranking
central-tunnel-0, central-tunnel-1	351	300	651	2nd choice
west-attachment-0, west-attachment-1	100	350	450	1st choice

10.0.3.0/24 (us-west1)

This table shows the BGP sessions that advertise subnet IP address range 10.0.3.0/24, which is located in us-west1.

Traffic from your on-premises network uses the VLAN attachment in us-west1 because its BGP sessions have the lowest advertised MED.

VPN tunnel or VLAN attachment	Base priority	Region-to-region cost	Advertised MED	Path ranking
central-tunnel-0, central-tunnel-1	351	250	601	2nd choice
west-attachment-0, west-attachment-1	100	0	100	1st choice

Learned routes

Learned routes are routes that Cloud Router uses to reach another network. The other network might be your on-premises network, a network in another cloud service provider, or another VPC network. Learned routes are sometimes referred to as received routes.

In Google Cloud, there are two types of learned routes:

• Routes that are learned from external routers through BGP

• Routes that you manually configure for an individual BGP session (custom learned routes)

Using both types of learned routes, Cloud Router creates dynamic routes in your VPC network. Each dynamic route created by Cloud Router is derived from one or more of these learned routes.

If Cloud Router has multiple learned routes for the same destination prefix, Cloud Router uses route metrics and, in some cases, AS path length to create dynamic routes. The following sections describe more information about that process and about learned routes in general.

Custom learned routes

As described in the preceding section, you can configure a BGP session to have custom learned routes. When you configure custom learned routes, Cloud Router behaves as if it learned these routes from a BGP peer.

Custom learned routes can be helpful if you want to avoid the limitations of static routes. For example, static routes can't detect a loss of reachability in the next hop of a route. In contrast, custom learned routes can detect a loss of reachability, and they react accordingly to avoid dropping traffic without notification.

For more information, see Custom learned routes.

Effects of dynamic routing mode

The dynamic routing mode of a VPC network determines how learned routes are applied:

• In regional dynamic routing mode, Cloud Router creates a dynamic route for the destination and next hop in the same region as the Cloud Router. Cloud Router sets the priority for that dynamic route to the base priority, which Cloud Router derives from the multi-exit discriminator (MED) advertised by your on-premises router.

• In global dynamic routing mode, Cloud Router creates a dynamic route for the destination and next hop in each Google Cloud region. In the region that contains the Cloud Router that learned that route, Cloud Router sets the priority for the dynamic route to the base priority. In all other regions, Cloud Router sets the priority to the base priority plus an appropriate region-to-region cost.

You can define the route priority for to Google Cloud routes exported to your on-premises router. However, your on-premises router might override this route priority, depending on its configuration—for example, if your on-premises router modifies the route priority.

For to on-premises routes learned by Cloud Router, Cloud Router gets the AS path length and MED values and computes a base priority as described in the next two sections.

AS path prepending and AS path length

Note: AS path length selection does not work in the following situations:

• If Cloud Router is used as part of an HA VPN configuration that connects multiple VPN tunnels from the same VPN gateway.
• If Cloud Router is used as part of a Cloud Interconnect configuration that connects multiple VLAN attachments, where the VLAN attachments are in different edge availability domains.

AS path length selection doesn't work in these situations because multiple software tasks are used in such an arrangement. For more information, see Cloud Router software tasks.

AS path prepending is a means by which a next hop for a destination (prefix) is intentionally deprioritized so that a different next hop for the same destination with a shorter AS path length is selected. MED is considered only when the AS path lengths of the next hops are the same.

Google Cloud can use AS path to select a next hop among BGP sessions implemented by the same Cloud Router software task.

How Google Cloud uses AS path

AS path prepending is irrelevant to the control plane and VPC network. AS path length is only considered within each Cloud Router software task as described in the following scenarios.

If a single Cloud Router software task learns the same destination from two or more BGP sessions:

• The software task picks a next hop BGP session that has the shortest AS path length.
• The software task submits destination, next hop, and MED information to the Cloud Router control plane.
• The control plane uses the information to create one or more candidate routes. Each candidate's base priority is set to the MED received.

If two or more Cloud Router software tasks learn the same destination from two or more BGP sessions:

• Each software task picks a next hop BGP session that has the shortest AS path length.
• Each software task submits destination, next hop, and MED information to the Cloud Router control plane.
• The control plane uses the information to create two or more candidate routes. Each candidate's base priority is set to the MED received.

The Cloud Router control plane then installs one or more dynamic routes in the VPC network, according to the VPC network's dynamic routing mode. In global dynamic routing mode, the priority of each regional dynamic route is adjusted in regions different from the Cloud Router region. For details about how Google Cloud selects a route, see Routing order in the VPC documentation.

Base priority, MED, and origin

Cloud Router uses the MED value advertised by your peer router to compute a base priority:

• If the MED value for a destination's prefix is between 0 and 231 -1 (inclusive), Cloud Router sets the base priority to the MED value.
• If the MED value for a destination's prefix is between 231 and 232 -1 (inclusive), Cloud Router sets the base priority to 231 -1.

For MED to take effect during best path selection between multiple learned routes for the same destination, the BGP origin attribute value for the received routes must be the same. Otherwise, selection happens based on the origin attribute value, which precedes the MED comparison step in the best path selection process (RFC 4271).

Cloud Router advertises BGP routes to its peers with the origin attribute value set to Incomplete. This value is the least preferred origin type in route selection.

The final priority value that Cloud Router sets when it creates dynamic routes in a VPC network depends on the network's dynamic routing mode. For more information, see Effects of dynamic routing mode.

Static routes

When an instance sends a packet, Google Cloud attempts to select one route from the set of applicable routes according to routing order. For details, see the Routing order section in the VPC documentation.

Overlapping IP ranges

In cases where you have a VPC subnet and an on-premises route advertisement with overlapping IP ranges, Google Cloud directs egress traffic depending on their IP ranges.

For more information, see Applicable routes in the VPC documentation.

Site-to-site data transfer

If you need to transfer data between two sites that are external to Google Cloud, use Network Connectivity Center. Network Connectivity Center works with Cloud Router to let you dynamically advertise routes between BGP sessions.

Cloud Router by itself doesn't support this functionality (either dynamically, or by configuring custom advertised routes that match the learned prefixes). If you add a custom advertised route to one BGP session, and that advertised route overlaps a learned route from another BGP session, the learned route might be dropped.

Limits for learned routes

There are several limits that affect learned routes. For more information, see limits.

IPv4 and IPv6 routes count toward the same maximum and do not have separate limits.

To monitor your usage against the limits, use the following metrics:

• router.googleapis.com/dynamic_routes/learned_routes/used_unique_destinations
• router.googleapis.com/dynamic_routes/learned_routes/unique_destinations_limit
• router.googleapis.com/dynamic_routes/learned_routes/any_dropped_unique_destinations

Note: The metrics for learned routes are available through the gce_network_region monitored resource.

For information about log messages related to these limits, the metrics that you can use to monitor them, and how to resolve issues, see Check quotas and limits on the Troubleshooting page.

Default route

When no route is specified for a particular IP destination, traffic is sent to a default route, which acts like a last resort when no other options exist. For example, Google Cloud VPC networks automatically include a default route that sends traffic to the internet gateway. The default route for IPv4 only is 0.0.0.0/0 and for dual stack IPv4 and IPv6 is 0.0.0.0/0, ::/0.

Sometimes, you might want traffic to be directed to your on-premises network by default. To do that, you can advertise a default route from your on-premises router to Cloud Router. With Cloud Router, you don't need to create and manage static routes. If you advertise a default route from your on-premises network, check that it's prioritized over other automatically created default routes (has a lower MED value). Go to the Routes page and view the Priority for routes with 0.0.0.0/0 in Destination IP range, and view Default internet gateway in Next hop.

Redundant Cloud VPN tunnels

If the on-premises gateway doesn't support graceful restart, a failure on either side of the BGP session causes the session to fail, and traffic is disrupted. After the BGP timeout is exceeded, which is 60 seconds for Cloud Router, routes are withdrawn from both sides.

Without graceful restart support, deploying two on-premises gateways with one tunnel each provides redundancy and failover. This configuration enables one tunnel and its devices to go offline for software upgrades or maintenance without disrupting traffic. Also, if one tunnel fails, the other tunnel can keep the routes active and traffic flowing.

Maintenance events

Cloud Router undergoes periodic maintenance, which takes under 60 seconds. Cloud Router is not available during maintenance events. The BGP hold timer determines how long learned routes are preserved when the peered BGP router is unavailable. The BGP hold timer is negotiated to be the lower of the two values from both sides. Cloud Router uses a value of 60 seconds (by default) for the BGP hold timer. We recommend that you set the BGP hold timer on your on-premises (peer) router to 60 seconds or greater. As a result, both routers preserve their routes during these upgrades and traffic continues to flow.

During Cloud VPN gateway maintenance cycles with a single Cloud VPN gateway, the use of Cloud Router adds about 20 seconds to the tunnel recovery time because the BGP session is reset and routes have to be relearned. Cloud VPN gateway recovery times are usually about a minute. If there are redundant Cloud VPN gateways, traffic is unaffected because only one Cloud VPN gateway is taken down at a time.

BGP router ID and BGP session restarts

Cloud Router selects its highest interface IP address for its BGP router ID and keeps that ID as long as the address is available. If you delete the Cloud Router interface that is being used for the BGP router ID, Cloud Router must select a new router ID. This selection causes all your BGP sessions to restart. The router ID can also change if Cloud Router restarts for periodic maintenance.

Additional resources

For more information about using static and dynamic routing with a supported service, see the following documentation.

Product	Routing	Documentation
Dedicated Interconnect	Requires dynamic routing with Cloud Router	Creating VLAN attachments
Partner Interconnect	Requires dynamic routing with Cloud Router	Creating VLAN attachments
Router appliances	Requires dynamic routing with Cloud Router	Creating router appliance instances
HA VPN	Requires dynamic routing with Cloud Router	Creating an HA VPN gateway to a peer VPN gateway Creating an HA VPN between Google Cloud networks
Classic VPN	Dynamic routing using Cloud Router is optional	Creating a Classic VPN using dynamic routing Creating a Classic VPN using static routing

What's next

• To help build your network topology with Cloud Router, see Best practices.

• To find definitions for Cloud Router terminology, see Key terms.

• To troubleshoot issues when using Cloud Router, see Troubleshooting.