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:

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

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 Virtual Private Cloud (VPC) subnet routes and custom prefixes on its Border Gateway Protocol (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 product listed in the Additional resources section provide details about how each product uses ASN.

BGP peering addresses

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

  • For Dedicated Interconnect, you can either specify candidate IPv4 link-local addresses for BGP peering addresses, or Google Cloud can select unused IPv4 link-local addresses automatically.
  • For Partner Interconnect, Google Cloud selects unused IPv4 link-local addresses automatically.
  • For HA VPN and Classic VPN using dynamic routing, you can specify the BGP peering addresses when you [create the BGP interface on the Cloud Router](/network-connectivity/docs/router/how-to/configuring-bgp).

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

Cloud Router also supports IPv6 addresses for BGP peering. With the configuration of IPv6 BGP peers, you can create IPv6 BGP sessions over HA VPN tunnels and Dedicated Interconnect VLAN attachments. Support for IPv6 BGP sessions is in Preview.

For HA VPN tunnels, you can use IPv6 unique local addresses (ULA) in the fdff:1::/64 range as the BGP peering addresses. The peering addresses for IPv6 BGP sessions must use a mask length of 126 or a lower bit-count value, such as /122. When you configure an IPv6 BGP session in HA VPN, you can configure the peering IPv6 addresses manually or have Google Cloud assign them automatically for you.

For Dedicated Interconnect, the peering IPv6 addresses are automatically assigned from the Google-owned global unicast address (GUA) range 2600:2d00:0:1::/64. You can't specify a candidate range for these peering IPv6 addresses or configure these peering IPv6 addresses manually.

Access to internal load balancers

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

IPv6 support

Cloud Router supports IPv6 route exchange over IPv4 BGP sessions by using multiprotocol BGP (MP-BGP). Cloud Router also supports IPv6 route exchange by using IPv6 BGP peering; however, IPv6 BGP session support is in Preview.

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 create the following types of BGP sessions:

  • IPv4 BGP sessions that exchange only IPv4 routes
  • IPv6 BGP sessions that exchange only IPv6 routes (Preview)
  • IPv4 BGP sessions that exchange IPv4 routes but also IPv6 routes by using MP-BGP
  • IPv6 BGP sessions that exchange IPv6 routes but also IPv4 routes by using MP-BGP (Preview)
  • Both IPv4 BGP sessions and IPv6 sessions that run in parallel over the same HA VPN tunnel or Dedicated Interconnect VLAN attachment; the IPv4 BGP session exchanges only IPv4 routes, and the IPv6 BGP session exchanges only IPv6 routes

For details, see the following documents:

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

IPv6 limitations

IPv6 BGP peering and IPv6 route exchange are not supported for the following resources:

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

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.
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 product listed in the Additional resources section, a Cloud Router advertises 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 address ranges. The dynamic routing mode of the VPC network controls whether the advertised subnet address ranges only come from the same region as the Cloud Router or whether they come from all regions:

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 for IPv4 routes or ::/0 for IPv6 routes) 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:

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:

Conditions for IPv6 route advertisement

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

  • The product used with Cloud Router, such as the HA VPN gateway, is configured to use the IPv4 and IPv6 dual stack type.
  • The IPv4 BGP session is specifically configured to enable IPv6 route exchange or the IPv6 BGP session (Preview) is configured and enabled.

    For more information about configuring BGP sessions, see Establish BGP sessions.

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.

Guidance for base priorities

When you configure a Border Gateway Protocol (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 specify 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 among Cloud Routers in a region are recommended to 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 10200 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.

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.
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 IPv4 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 IPv4 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 IPv4 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 IPv4 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 IPv4 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 IPv4 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.
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 IPv4 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 IPv4 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 IPv4 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 routes to Google Cloud exported to your on-premises router. However, your on-premises router might override this route priority, depending on its configuration.

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

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 IPv4 or IPv6 address ranges

In cases where you have a VPC subnet and an on-premises route advertisement with overlapping address ranges, Google Cloud directs egress traffic depending on their address 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 don't 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

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 IPv4 or IPv6 destination, traffic is sent to a default route, which is the 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 is 0.0.0.0/0 and for IPv6 is ::/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 identifier (router ID)

Each Cloud Router has a BGP identifier, also known as a router ID. The BGP identifier is unique to each Cloud Router in your Virtual Private Cloud as required by RFC 6286.

Generally, the BGP identifier is automatically assigned, but you can configure your Cloud Router with an explicit BGP identifier range. If you choose to assign your own BGP identifier range, your Cloud Router is assigned a stable BGP identifier within your selected range. A Cloud Router that isn't configured with a BGP identifier range is assigned a BGP identifier based upon its highest IPv4 interface address.

Support for IPv6 BGP sessions and BGP identifier ranges is in Preview.

When you add the first IPv6 interface to a Cloud Router that isn't configured with a BGP identifier range, a BGP identifier range is assigned automatically.

For more information, see Configure the BGP identifier range for Cloud Router.

BGP session restarts

An active Cloud Router's BGP identifier can change due to any of the following:

  • You manually update or remove the configured BGP identifier range.
  • You remove an IPv4 interface from the Cloud Router, and it doesn't have an assigned BGP identifier range.

When an active Cloud Router's BGP identifier changes, each BGP session on that Cloud Router restarts.

A Cloud Router's identifier range can also change when the router is restarted for periodic maintenance and it doesn't have an assigned BGP identifier range.

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.