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 Cloud 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 or two software tasks, depending on what their interfaces connect to:
- If a Cloud Router has at least two interfaces, each connected to a Cloud VPN tunnel in the same HA VPN tunnel pair (connected to the same HA VPN gateway), Google Cloud uses two software tasks to implement the Cloud Router to provide software redundancy.
- In all other situations, Google Cloud implements the Cloud Router using a single software task.
Static versus dynamic 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. Also, static routes can't automatically reroute traffic if a link fails.
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.
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 dynamic routing.
Dynamic routing is suitable for any size network. It frees you from maintaining static routes. Also, if a link fails, dynamic routing can automatically reroute traffic if possible. To enable dynamic routing, create a Cloud Router. Then, configure a BGP session between the Cloud Router and your on-premises gateway or router.
Static routing for Cloud VPN tunnels
Without Cloud Router, you can configure your Cloud VPN by using only static routes. 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 and vice versa by using BGP so that you don't have to configure static routes for your Cloud VPN tunnels.
Dynamic routing requirements for Cloud Interconnect and Cloud VPN
You must have an existing Cloud Router before you can do the following:
- Create an interconnect attachment (VLAN) for Dedicated Interconnect
- Create an interconnect attachment (VLAN) for Partner Interconnect
- Create a VPN tunnel connected to an HA VPN gateway
- Create a Cloud NAT gateway
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 addresses in the following ways:
- For Dedicated Interconnect, you can either specify address ranges or have Google Cloud select them. For more information, see Creating Cloud Interconnect. (VLAN) attachments.
- For Partner Interconnect, you never specify BGP addressing.
- 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.
Dynamic routing mode
This section describes examples for regional dynamic routing and global dynamic routing. For more information about the dynamic routing modes of VPC networks, see VPC network overview.
For information about dynamic routing mode and load balancers, see Internal TCP/UDP Load Balancing and connected networks.
Regional dynamic routing example
With regional dynamic routing, you might have a Cloud VPN tunnel and VMs 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 example, Cloud Router has visibility to resources
only in the
us-west1 region. VMs in other regions, such as
can't reach the Cloud VPN tunnel.
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 example shows a VPC network with global dynamic
routing. The Cloud Router in
us-west1 advertises subnets in two
us-central1. VMs in both regions dynamically
learn about on-premises hosts.
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.
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 network that have a destination IP address matching 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.
By default, Cloud Router advertises subnets in its region for regional dynamic routing or all subnets in a VPC network for global dynamic routing. New subnets are automatically advertised by Cloud Router. 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 of its BGP sessions. If you configure custom route advertisements on a Cloud Router, its BGP sessions inherit those custom advertisements.
You must 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 are not 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, and 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.
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 just the ones you want to expose. However, when you selectively advertise subnets, new subnets must be manually added to the custom route advertisement. Cloud Router won'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 Cloud Router's route advertisement is ignored and overridden by the session's advertisement.
For each Cloud Router, you can specify a maximum of 200 CIDR ranges. Also, each BGP session has the same limit of 200.
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.
Default route advertisement
For regional dynamic routing, Cloud Router advertises subnets in its
region. In the following example, Cloud Router advertises subnets in
us-central1 region. It also advertises the secondary IP range of
alias-subnet. If you create new subnets in
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.
Advertise an external IP address
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 example, the Cloud Router advertises the proxy
server's external IP address
18.104.22.168. 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
subnet. On-premises clients are only aware of the proxy server's external IP
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 example, Cloud Router advertises
Clients in the on-premises network can reach VMs in those subnets but not VMs in
For more information, see Advertising specific VPC subnets.
Route advertisement per BGP session
Assume that you have production and test resources in your VPC
and on-premises networks, 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 example shows
two BGP sessions:
prod-bgp that advertises only the
bgp that advertises only the
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. This section describes 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 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 regional cost.
You can define the route priority for to Google Cloud routes exported to your on-premises router. However, this route priority might be overridden by your on-premises router, 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 depriotized so that a different next hop for the same destination (prefix) with a shorter AS path length is selected. MED is considered only when the AS path lengths of the next hops are 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. See Routing order for details about how Google Cloud selects a route.
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
231 -1(inclusive), Cloud Router sets the base priority to the MED value.
- If the MED value for a destination's prefix is between
232 -1(inclusive), Cloud Router sets base priority to
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, refer to Effects of dynamic routing mode.
See the Routing order section in the VPC routing documentation.
Overlapping IP ranges between a VPC subnet and an on-premises route advertisement
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 on how to properly exchange dynamic routes with multiple VPC networks, see IP prefixes not propagating or are unavailable on the Cloud Router Troubleshooting page.
When Cloud Router advertises or propagates routes, it uses route metrics to specify route priorities. When you have multiple paths between your VPC network and on-premises network, route metrics determine a preferred path. This value is equivalent to the MED value. A lower route metric (MED) indicates higher priority.
A route metric is composed of a base advertised route priority and a regional cost. The base priority is a user-specified value, whereas the regional cost is a Google-generated value that you can't modify. The regional cost represents the cost of communicating between two regions in a VPC network. Cloud Router adds these two values together to generate a route metric.
For regional dynamic routing, because Cloud Router handles only routes in its region, it doesn't add any regional costs to route metrics. Cloud Router uses only the base advertised route priority.
For global dynamic routing, all Cloud Routers advertise and propagate the same routes. However, each Cloud Router might use different route metrics due to regional costs.
- Base advertised route priority
When calculating route metrics, Cloud Router starts with the base advertised route priority value and then adds any regional costs. This base value is the minimum route metric for advertised routes. When you configure a BGP session on a Cloud Router, you can specify a base advertised route priority, which applies to all routes for that session. By default, the base advertised priority value is
100and takes a positive integer as a value. Cloud Router considers a base advertised priority that has a numerical value of
1as the highest priority route. This value takes precedence over lower priorities that have a value of
The base advertised route priority enables you to set priorities for routes. For example, you might have a Cloud VPN tunnel and a Dedicated Interconnect connection connecting your VPC and on- premises networks. You can set the base advertised route priority so that traffic prefers Dedicated Interconnect. If the Cloud Interconnect connection is unavailable, traffic traverses the tunnel. For more information, see the example topologies.
- Regional cost
When a Cloud Router advertises routes from regions other than its region (routes from remote Google Cloud regions) or propagates routes to remote regions, it adds a regional cost.
The regional cost can range from 201 to 9999, inclusive. The value depends on the distance, latency, and other factors between two regions. Google generates the regional cost value, and you can't modify it. For more information about regional costs, see the example topologies.
Regional costs help prioritize paths based on region proximity. For example, imagine that you have two connections between your VPC and on- premises network, such as two Cloud VPN tunnels with their own Cloud Routers. One connection is in
us-central1and another in
europe-west1. By adding a regional cost to the route metrics, traffic between networks in
us-central1tunnel. Similarly, traffic between networks in
europe-west1tunnel. Without regional costs, traffic is directed equally through both connections, leading to inconsistent network performance.
For learned routes, Cloud Router adds regional costs when it propagates the learned routes to remote Google Cloud regions. This helps maintain symmetry between ingress and egress traffic between VPC and on-premises networks. Cloud Router adds regional costs to the MED value that's advertised by your on-premises router.
Suggested base priority values
To adjust priorities between routes in a single region, use
values less than
201. This guarantees that regional costs won't impact global
route priorities. A route from another region (a remote region) can't have a
priority lower than
201. If you use higher values, regional costs might impact
your route priorities. For example, suppose you have a primary and a backup
connection. If you set the backup connection's base priority too high, you
might unintentionally prefer routes from other regions instead of the backup
To globally deprioritize a route in a VPC network, use values higher than
10,200. This ensures that all other routes lower than
201 have priority
regardless of regional costs.
In cases where all routes in a region are equally preferred, you can use the
default value of
The following examples explain how regional costs influence route metrics when you use global dynamic routing.
Suppose you have a VPC network with two Cloud VPN
tunnels with their own Cloud Routers. One tunnel is in
and the other is in
us-west1. By default, ingress traffic to those regions use
the corresponding tunnels in their respective regions. However, what happens if
you want to reach VMs that aren't in those regions, such as VMs in
europe-west1? The following diagram shows how the regional costs affect route metrics.
Both Cloud Routers advertise routes to
europe-west1 but with different
route metrics. The Cloud Router in
us-central1 advertises routes to
europe-west1 with a lower route metric than to
us-west1 due to distance, latency, and
other factors. The example assumes that the regional cost to
us-west1. Ingress traffic uses the
us-central1 tunnel, which has a lower route metric. It has a route metric of
400 for the
Similarly, Cloud Router adds a regional cost to the MED value of
learned routes (specified by your on-premises router). By default, egress
traffic from the
europe-west1 region also uses the
us-central1 tunnel because it
has a lower route metric. This way ingress and egress traffic maintain symmetry.
Route priorities within a region
For redundancy in
us-west1, suppose you create a backup tunnel. You specify a
higher base priority for the backup tunnel so that ingress traffic to
prefers the primary tunnel, as shown in the following example.
If the primary tunnel fails, ingress traffic to
us-west1 prefers the backup
tunnel with a route metric of
51 over the
us-central1 tunnel, which has a route
Similarly, for egress traffic from the VPC network to your on-
premises network, use MED values lower than
201 to prioritize one path over
another. Otherwise, egress traffic from the VPC network to your
on-premises network might not be symmetric with ingress traffic.
In cases where all tunnels or Cloud Interconnect connections in a
region are equally preferred, you can use the default base route priority of
Globally preferred route
Suppose you have Dedicated Interconnect and a Cloud VPN
tunnel in different regions. You want to prioritize
Dedicated Interconnect because it's more cost effective for your
workloads than the Cloud VPN tunnel. Specify a base priority of
10,051 for the Cloud VPN tunnel routes to deprioritize it. As a
result, all ingress traffic uses Dedicated Interconnect,
independent of regional costs. Route metrics for
Dedicated Interconnect won't exceed
10,051. Traffic uses the
Cloud VPN tunnel only if the connection fails.
You'll also need to make the same adjustments to your on-premises router so that egress traffic from the VPC network to the on-premises network always prefers to use Dedicated Interconnect.
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.
In some cases, 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
0.0.0.0/0 in Destination IP range, and view
Default internet gateway in
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.
We recommend setting the graceful restart timer to 1 second on your on-premises router if you want your router to behave in the same way that Cloud Router does.
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. If you set your on-premises router's graceful restart time to a greater value than one second, your on-premises router might send return traffic to a next hop that's no longer active, instead of switching to a configured secondary next hop that is active.
- 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.
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.
The 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 of your BGP sessions to restart. The router ID can also change if Cloud Router restarts for periodic maintenance.
To troubleshoot common issues with Cloud Router, see the Troubleshooting documentation.
For more information about using static and dynamic routing with a supported service, see the following 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 Google Cloud to Google Cloud HA VPN gateways