Cloud Router overview

Cloud Router is a fully distributed and managed Google Cloud service that programs custom dynamic routes and scales with your network traffic. Cloud Router works with both legacy networks and Virtual Private Cloud (VPC) networks.

Cloud Router isn't a connectivity option, but a service that works over Cloud VPN or Interconnect connections to provide dynamic routing by using the Border Gateway Protocol (BGP) for your VPC networks. Cloud Router isn't supported for Direct Peering or Carrier Peering connections.

Cloud Router isn't a physical device that might cause a bottleneck, and it can't be used by itself. However, it is required or recommended in the following cases:

  • Required for Cloud NAT
  • Required for Cloud Interconnect and HA VPN
  • A recommended configuration option for Classic VPN

When you extend your on-premises network to Google Cloud, use Cloud Router to dynamically exchange routes between your Google Cloud networks and your on-premises network. Cloud Router peers with your on-premises VPN gateway or router. The routers exchange topology information through BGP.

Topology changes automatically propagate between your VPC network and your on-premises network. When using Cloud Router, you don't need to configure static routes.

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 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

Static routing

With static routes, you must create or maintain a routing table. A topology change on either network requires you to manually update static routes. If a link fails, static routes can't automatically reroute traffic.

Static routing is suitable for small networks with stable topologies. You also have strict control over the routing tables. Routers don't send advertisements between networks.

Static routing for Cloud VPN tunnels

Without Cloud Router, you can use only static routes to configure your Cloud VPN tunnels. The disadvantages of using static routes are as follows:

  • A network configuration change on either side of a Cloud VPN tunnel requires manually creating and deleting static routes corresponding to these changes. In addition, static route changes are slow to converge.
  • When you create a Cloud VPN tunnel to work with static routes, you must specify the list of IP prefixes on either side of the tunnel before the tunnel is created. This means that every time the routes must change, you must delete and recreate the Cloud VPN tunnel and configure new routes, which disrupts existing traffic.
  • There is no standard way to configure static routes. Different vendors use different commands.

You can avoid configuration changes to static routes and Cloud VPN tunnels by deploying a Cloud Router. Cloud Router peers with your Cloud VPN gateway by using BGP to exchange topology information. In effect, network topology changes in your Google Cloud network propagate automatically to your own network by using BGP so that you don't have to configure static routes for your Cloud VPN tunnels.

Dynamic routing

With Cloud Router, you can use BGP to exchange routing information between networks. Instead of manually configuring static routes, networks automatically and rapidly discover topology changes through BGP. Changes are seamlessly implemented without disrupting traffic. This method of exchanging routes through BGP is called dynamic routing.

Dynamic routing is suitable for any size network. It frees you from maintaining static routes. If a link fails, dynamic routing can automatically reroute traffic if possible. To enable dynamic routing, you create a Cloud Router. You then configure a BGP session between the Cloud Router and your on-premises gateway or router.

Dynamic routing requirements for Cloud Interconnect and Cloud VPN

You must have an existing Cloud Router before you can do the following:

When you create a Cloud Router, you can choose the Google-side ASN. If you don't specify an ASN, Google Cloud chooses an ASN for you. However, you must manually specify the ASN of your on-premises (peer) router in the configuration settings for Cloud Router.

You can specify BGP IP addresses in the following ways:

  • For Dedicated Interconnect, you can either specify IP address ranges or have Google Cloud select them.
  • For Partner Interconnect, you never specify BGP IP addresses.
  • For HA VPN and Classic VPN using dynamic routing, you can specify the BGP IP addresses when you create the BGP interface on the Cloud Router.

The following two sections describe examples for regional dynamic routing and global dynamic routing. For more information about the dynamic routing modes of VPC networks, see the VPC network overview in the VPC documentation.

For information about dynamic routing mode and load balancers, see Internal load balancers and connected networks in the Cloud Load Balancing documentation.

Regional dynamic routing example

With regional dynamic routing, you might have a Cloud VPN tunnel and virtual machine (VM) instances in a single Google Cloud region. The tunnel extends your on-premises network to a VPC network. VMs in other regions might need to connect to the on-premises network, but they can't reach the tunnel. To get around this constraint, you could create static routes. However, maintaining static routes can be prone to errors and might disrupt traffic.

In the following diagram, Cloud Router has visibility to resources only in the us-west1 region. VMs in other regions, such as us-central1, can't reach the Cloud VPN tunnel.

Cloud Router regional dynamic routing.
Cloud Router regional dynamic routing (click to enlarge)

Global dynamic routing example

With global dynamic routing, Cloud Router has visibility to resources in all regions. For example, if you have VMs in one region, they can reach a Cloud VPN tunnel in another region automatically without maintaining static routes.

The following diagram shows a VPC network with global dynamic routing. The Cloud Router in us-west1 advertises subnets in two different regions: us-west1 and us-central1. VMs in both regions dynamically learn about on-premises hosts.

Cloud Router global dynamic routing.
Cloud Router global dynamic routing (click to enlarge)

For redundant topologies, dynamic routing (BGP) provides enough information to the VPC and on-premises networks so that when a path fails, traffic is rerouted. If a connection in one region has an issue, traffic can fail over to another region.

Route advertisements

Through BGP, Cloud Router advertises the IP addresses that clients in your on-premises network can reach. Your on-premises network sends packets to your VPC networks that have a destination IP address that matches an advertised IP range. After reaching Google Cloud, your VPC network's firewall rules and routes determine how Google Cloud handles the packets.

You can use Cloud Router's default advertisements or explicitly specify which CIDR ranges to advertise. If you don't specify advertisements, Cloud Router uses the default.

Default route advertisements

By default, Cloud Router advertises subnets in its region for regional dynamic routing, or all subnets in a VPC network for global dynamic routing. Cloud Router automatically advertises new subnets. Also, if a subnet has a secondary IP range for configuring alias IP addresses, Cloud Router advertises both the primary and secondary IP addresses.

Each BGP session for a Cloud Router also has a default advertisement. By default, Cloud Router propagates its route advertisements to all its BGP sessions. If you configure custom route advertisements on a Cloud Router, its BGP sessions inherit those custom advertisements.

Specify custom route advertisements in the following cases:

  • To advertise IP addresses outside of a subnet's primary IP range or one of its secondary IP ranges—for example, advertising external IP addresses.

  • To advertise routes from a different VPC network connected to your VPC network by using VPC Network Peering. In this case, subnet routes and imported custom routes in a peer network aren't automatically advertised by a Cloud Router in your VPC network. To advertise them, you must create custom route advertisements on the Cloud Router in your VPC network. You must also ensure that the VPC Network Peering connections are configured to exchange the custom routes.

When you use custom advertisements, you can selectively advertise subnets or parts of a subnet. That way, you can withhold certain subnets from being advertised. If you don't need these capabilities, use the default advertisements.

Custom route advertisements

When you configure custom route advertisements, you explicitly specify the routes that a Cloud Router advertises. In most cases, custom advertisements are useful for supplementing the default subnet advertisement with custom IP addresses. Custom IP addresses are addresses outside a subnet's IP range, such as reserved external IP addresses. Without custom route advertisements, you would be required to create and maintain static routes for custom IP addresses.

When you configure custom route advertisements, you can choose to advertise all subnets, which emulates the default behavior. You can choose not to advertise all subnets, and instead advertise specific subnets or certain CIDR blocks within a subnet. For example, you might want to prevent Cloud Router from advertising particular subnets. To do that, you advertise only the subnets that you want to expose. However, when you selectively advertise subnets, you must manually add new subnets to the custom route advertisement. Cloud Router doesn't automatically advertise new subnets.

You can specify custom route advertisements on a Cloud Router or on a BGP session. Custom route advertisements on the Cloud Router apply to all its BGP sessions. However, if you specify a custom route advertisement on a BGP session, the BGP session's route advertisement ignores and overrides the Cloud Router's route advertisement.

For each Cloud Router, you can specify a maximum of 200 CIDR ranges. Each BGP session has the same limit of 200.

Examples of route advertisements

The following examples show the Cloud Router's default behavior and scenarios where custom route advertisements might be useful. The examples assume an existing connection between the VPC and on-premises networks, such as an IPsec VPN tunnel or Dedicated Interconnect connection.

Default route advertisement

For regional dynamic routing, Cloud Router advertises subnets in its region. In the following diagram, Cloud Router advertises subnets in the us-central1 region. It also advertises the secondary IP range of alias-subnet. If you create new subnets in us-central1, Cloud Router automatically advertises them. Cloud Router doesn't advertise IP addresses that aren't included in a subnet's IP range, such as external IP addresses.

Cloud Router default route advertisement.
Cloud Router default route advertisement (click to enlarge)

External IP address advertisement

You might use an external static IP address for a Google Cloud application that serves clients in your on-premises network. When you perform maintenance on the application, you can remap the static IP address to another VM to minimize downtime. With Cloud Router's default advertisements, you're required to configure and maintain a static route. Instead, you can use custom advertisements to advertise the external IP address through BGP.

In the following diagram, the Cloud Router advertises the proxy server's external IP address 1.2.3.4. The external IP address maps to the server's internal IP address 10.20.0.2. Cloud Router doesn't advertise the internal IP address of the proxy server or any VMs in the my-subnet subnet. On-premises clients are only aware of the proxy server's external IP address.

External IP address advertisement.
External IP address advertisement (click to enlarge)

For more information, see Advertising custom IP ranges.

Restrict subnet advertisement

You can prevent instances from being advertised so that they're hidden. In the following diagram, Cloud Router advertises subnet-1 and subnet-2. Clients in the on-premises network can reach VMs in those subnets but not VMs in the unadvertised-subnet subnet.

Advertise specific subnets on the Cloud Router.
Advertise specific subnets on the Cloud Router (click to enlarge)

For more information, see Advertising specific VPC subnets.

Route advertisement per BGP session

Assume that you have production and test resources in your VPC network and on-premises network, and you organized those resources in different subnets. Accordingly, you set up two BGP sessions that advertise different IP address ranges. By using two different BGP sessions, traffic bound for one subnet doesn't inadvertently go to another subnet. The following diagram shows two BGP sessions: prod-bgp that advertises only the prod-subnet, and test-bgp that advertises only the test-subnet.

Advertise specific subnets on a BGP session.
Advertise specific subnets on a BGP session (click to enlarge)

For more information, see Advertising custom IP ranges or Advertising specific VPC subnets.

Learned custom dynamic routes

When a Cloud Router receives multiple next hops for the same destination prefix, Google Cloud uses route metrics and, in some cases, AS path length to create custom dynamic routes in your VPC network. The following sections describe that process.

Effects of dynamic routing mode

The dynamic routing mode of a VPC network determines how custom dynamic routes learned from Cloud Routers are applied:

  • In regional dynamic routing mode, Cloud Router creates a custom dynamic route for the destination and next hop in the same region as the Cloud Router. Cloud Router sets the priority for that custom 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 custom 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 custom 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

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 custom 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 custom 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 and MED

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.

The final priority value that Cloud Router sets when it creates custom 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.

Advertising a route learned from one BGP session to another BGP session

Cloud Router doesn't currently support advertising (through static route advertisements) an on-premises route learned from one BGP session to another BGP session. Attempting to do so can result in the route being dropped.

For more information about how to properly exchange dynamic routes with multiple VPC networks, see Some on-premises IP prefixes aren't available on the Cloud Router Troubleshooting page.

Limits for learned routes

There are two limits for learned routes. These limits don't directly define a maximum number of learned routes. Instead, they define the maximum number of unique destination prefixes. For information about these limits, see limits.

To monitor your usage against these 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 you can use to monitor them, and how to resolve issues, see Check quotas and limits on the Troubleshooting page.

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 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.

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 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.
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

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 (0.0.0.0/0) that sends traffic to the internet gateway.

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.

Graceful restart

Cloud Router honors graceful restart messages sent by your on-premises router. If you've configured your on-premises router with graceful restart, it can send a notification to Cloud Router whenever your router needs to install software updates or perform periodic maintenance. Cloud Router retains custom dynamic routes learned from your on-premises router for the time period defined by the graceful restart timer setting on your on-premises router.

For more information about graceful restart timers, see BGP timer settings.

BGP timer settings

Cloud Router and your on-premises router maintain communication by using the following set of timer settings.

Keepalive timer
This is the interval between periodic BGP heartbeats exchanged between a Cloud Router and its corresponding on-premises peer router. In conjunction with the hold timer, the keepalive timer indicates each router's availability to the other. Set the keepalive timer to 20 seconds on your on-premises router.
Hold timer
This timer keeps track of the minimum amount of time since the last successful keepalive heartbeat was detected. It indicates how long either the Cloud Router or your on-premises router should wait before removing the routes it learned from the other router. Set the hold timer to 60 seconds on your on-premises router.
Graceful restart timer

This is the amount of time that your on-premises router waits, without periodic keepalive heartbeats, after it receives a graceful restart notification message from the corresponding Cloud Router, before expecting new keepalive heartbeats. If new keepalive heartbeats are not received, your on-premises router removes the routes it learned from the Cloud Router.

Cloud Router sets this value to 1 second. For your on-premises router, set the graceful restart timer to a value that is appropriate for your needs. Each router communicates its graceful restart timer value to the peer through the OPEN message when establishing a BGP session.

Cloud Router withdraws the custom dynamic routes it learns from on- premises devices when it determines that a next hop Cloud VPN tunnel is down or that a Cloud Interconnect connection is down.

Stalepath timer

This setting determines how long a router waits before deleting learned routes after it receives an end-of-record (EOR) message from the other router. This timer starts when the BGP session is reinitialized after a graceful restart, but the prefix in question hasn't been addressed by an UPDATE message. We recommend setting the stalepath timer to 300 seconds on your on-premises router to match the setting for Cloud Router.

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. Dynamically routed Cloud VPN traffic no longer enters the tunnel. Static routes for the tunnel continue to be serviced.

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.

Upgrade cycles

Cloud Router gets upgraded periodically, which takes under 60 seconds. Cloud Router is not available during the upgrade. 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 for the BGP hold timer. We recommend that you set your peer BGP hold timer to 60 seconds or greater (the default value is 3 minutes). 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 Static Not supported
Dedicated Interconnect Dynamic Creating VLAN attachments
Classic VPN Policy-based, static Creating a Classic VPN using static routing
Classic VPN or HA VPN Dynamic Creating a Classic VPN using dynamic routing
Creating an HA VPN gateway to a peer VPN gateway
Creating an HA VPN between Google Cloud networks

What's next