Cloud Router is a fully distributed and managed Google Cloud service that uses the Border Gateway Protocol (BGP) to advertise IP address ranges. It programs custom 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:
- Dedicated Interconnect
- Partner Interconnect
- Cloud VPN, specifically HA VPN
- Router appliance (part of Network Connectivity Center)
Each Cloud Router works with at least one of the networking connectivity products listed previously.
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 subnet routes and custom prefixes on its BGP sessions. Unless you configure custom route advertisements, a Cloud Router only advertises subnet routes. Custom route advertisements also allow you to configure a Cloud Router to omit advertising subnet routes.
The dynamic routing mode of a VPC network—either regional or global— determines which subnet routes the Cloud Routers in that network advertise. See Default route advertisements for details.
The dynamic routing mode also controls how each Cloud Router applies learned prefixes as custom 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. This feature is in Preview.
Autonomous system number (ASN)
When you create a Cloud Router, you choose the Google-side ASN for all BGP sessions used by the Cloud Router. The directions for each network connectivity product listed in the Using Cloud Router section provide details about how each product uses ASN.
BGP IP addresses
BGP sessions for the following network connectivity products use link-local IPv4 addresses in the 169.254.0.0/16 range as BGP IP addresses:
- For Dedicated Interconnect, you can either specify candidate link-local addresses for BGP addresses, or Google Cloud can select unused link-local addresses automatically.
- For Partner Interconnect, Google Cloud selects unused link-local addresses automatically.
- For HA VPN and Classic VPN using dynamic routing, you can specify the BGP addresses when you create the BGP interface on the Cloud Router.
Router appliances use internal IPv4 addresses of Google Cloud VMs as BGP IP addresses. For details, see Creating router appliance instances.
Access to internal load balancers
For details about how to access internal load balancers from a connected on-premises network, see Internal load balancers and connected networks in the Cloud Load Balancing documentation.
IPv6 support
Cloud Router supports Multiprotocol BGP (MP-BGP) and can exchange IPv6 prefixes over BGP IPv4 sessions. IPv6-only BGP sessions are not supported.
Cloud Router advertises IPv6 prefixes for VPC networks that include dual-stack subnets.
Cloud Router can advertise IPv6 subnet ranges 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 route advertisements.
You can enable IPv6 prefix exchange in BGP sessions that are created for HA VPN tunnels. For details, see the following documents:
- Create an HA VPN to a peer VPN gateway
- Create an HA VPN to another HA VPN gateway
- Enable or disable IPv6 prefix exchange in BGP IPv4 sessions
For details about IPv6 route advertisements, see Route advertisement modes.
IPv6 limitations
Cloud Router supports only regional routing of IPv6 traffic in HA VPN tunnels. IPv6 traffic is routed within the region assigned to the HA VPN gateway. Global routing for IPv6 traffic in HA VPN tunnels is not supported.
IPv6 prefix exchange is not supported in BGP sessions for the following resources:
- Dedicated Interconnect VLAN attachments
- Partner Interconnect VLAN attachments
- Classic VPN tunnels
- Router appliance (part of Network Connectivity Center)
Cloud Router software tasks
Cloud Routers are implemented by one, two, or in rare cases, three software tasks.
The following table provides example scenarios and the number of software tasks used by Google Cloud to implement the Cloud Router in each scenario.
- For the HA configurations listed in the table, two software tasks are used to provide software redundancy.
- For VLAN attachments, a separate software task handles each edge availability domain with attachments.
| 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, which is in preview. | 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:
| Three |
Software maintenance and automated task restarts
Google Cloud performs regular maintenance events to release new features and to improve reliability. During maintenance, new software tasks are provisioned. Your on-premises router logs indicate that BGP sessions managed by those software tasks went down and came back up (a BGP flap).
Cloud Router maintenance is an automatic process, and it is designed so that it does not interrupt routing. Maintenance events are expected to take no more than 60 seconds. Before maintenance, the Cloud Router sends a graceful restart notification (a TCP FIN packet) to the on-premises router.
If your on-premises router can process graceful restart events, it logs a graceful restart event during Cloud Router maintenance. For on-premises routers that do not support graceful restart, ensure that the on-premises router's hold timer is set to 60 seconds. For details, see Manage BGP timers.
Cloud Router maintenance events are not announced in advance because routes are not lost on properly configured on-premises routers. To get details about completed maintenance events, see Identify router maintenance events.
For information about how graceful restart works with Bidirectional Forwarding Detection (BFD), see Graceful restart and BFD.
Route advertisement modes
By using BGP and a network connectivity product, a Cloud Router advertises IP address ranges to your on-premises network. This allows clients in your on-premises network to send packets to and receive packets from resources in your VPC network.
Cloud Router offers two route advertisement modes: default route advertisements and custom route advertisements.
Default route advertisement
Using default route advertisement configures a Cloud Router or BGP session to advertise prefixes for the following types of subnet IP address ranges. The dynamic routing mode of the VPC network controls whether the advertised subnet IP address ranges only come from the same region as the Cloud Router or whether they come from all regions:
Regional dynamic routing mode: Each Cloud Router in the VPC network advertises primary and secondary IPv4 subnet ranges in the same region as the Cloud Router. If conditions for IPv6 advertisement are met, Cloud Router advertises internal (ipv6-access-type=INTERNAL) IPv6 subnet ranges in the same region as the Cloud Router.
Global dynamic routing mode: Each Cloud Router in the VPC network advertises primary and secondary IPv4 subnet ranges from all regions in the VPC network. If conditions for IPv6 advertisement are met, Cloud Router advertises internal (ipv6-access-type=INTERNAL) IPv6 subnet ranges from all regions in the VPC network.
If you advertise privately used public IPv4 addresses, on-premises systems might be unable to access internet resources which use those public IPv4 addresses.
Subnet route advertisements are updated automatically as described in Automatic updates for subnet route advertisements.
IPv6 subnet route advertisement is in Preview.
Custom route advertisement
Custom route advertisement gives you control over the prefixes that a Cloud Router advertises. You can specify custom route advertisements (including default route prefixes, 0.0.0.0/0 or ::/0) for all BGP sessions on a Cloud Router or on a per-BGP session basis. There are two categories of custom route advertisements:
You can advertise only custom IPv4 and IPv6 prefixes. This type of custom advertisement omits the subnet routes that would be advertised using Default route advertisement.
You can advertise custom IPv4 and IPv6 prefixes in addition to subnet routes. This type of custom advertisement includes the same subnet routes advertised using Default route advertisement.
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 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 prefixes in order to advertise them.
For the maximum number of custom prefixes that can be advertised on each BGP session, see maximum number of custom route advertisements per BGP session on the Cloud Router limits page. This maximum applies to custom advertisements for the whole Cloud Router and individually per BGP session.
For more information, see the following documents:
- Advertising custom IP ranges
- Advertising specific VPC subnets
Effective advertised prefixes
The route advertisement mode is configurable on both the whole Cloud Router and on individual BGP sessions of the Cloud Router. The following table describes which prefixes are advertised on the BGP session, based on the selected advertisement mode of the Cloud Router and the BGP session.
| default | default | The BGP session inherits the Cloud Router configuration. Subnet routes are advertised as described in Default route advertisement. |
| custom | default | The BGP session inherits the Cloud Router configuration. Custom routes configured on the whole Cloud Router are advertised as described in Custom route advertisement. Custom routes might contain some or all subnet routes. |
| default or custom | custom | The BGP session does not inherit the Cloud Router configuration. Custom routes configured on the BGP session itself are advertised as described in Custom route advertisement. Custom routes might contain some or all subnet routes. |
Automatic updates for subnet route advertisements
Cloud Router automatically updates subnet route advertisements in the following situations:
When you create an IPv4 only subnet
When you create a dual-stack subnet with internal IPv6 enabled
When you delete a subnet
When you enable internal IPv6 on an existing IPv4 only subnet
When you expand a subnet's primary IPv4 range
When you edit a subnet's secondary IPv4 ranges
Conditions for IPv6 advertisement
Cloud Router can advertise IPv6 routes (Preview) when all of the following conditions are met:
- The network connectivity product used with Cloud Router, such as the HA VPN gateway, is configured to use the IPv4 and IPv6 dual stack type.
- The BGP session is specifically configured to enable IPv6 prefix exchange. See Enabling or disabling IPv6 prefix exchange.
In order to advertise internal IPv6 subnet ranges, your VPC network must have an assigned internal (ULA) IPv6 range and you must have created at least one dual-stack subnet with an internal IPv6 subnet range.
Advertised prefixes and priorities
When a Cloud Router advertises prefixes to a BGP peer, it includes a priority for each prefix in the advertisement (BGP message). The advertised priority is implemented as a MED.
You can control what prefixes Cloud Router advertises to all or some of its BGP sessions. You control the advertised priority (MED) by defining a base priority for the prefixes.
If your VPC network uses regional dynamic routing mode, unless you advertise custom ranges, each Cloud Router only advertises the subnet ranges in the same region as the Cloud Router. Each range is advertised as a prefix with the MED being the base priority.
If your VPC network uses global dynamic routing mode, unless you advertise custom ranges, each Cloud Router advertises subnet ranges from its local region as prefixes whose MED matches the base priority. In addition, Cloud Routers advertise subnet ranges from different regions as prefixes whose MEDs equal the base priority plus a region-to-region cost. Google Cloud calculates a region-to-region cost automatically based on factors such as network performance, distance, and available bandwidth between regions. Each region-to-region cost has a value specific to a pair of regions—the subnet's region and the region of the advertising Cloud Router.
When your on-premises routers receive the advertised prefixes and their priorities, they create routes that are used to send packets to your VPC network.
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.
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.
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. 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. 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. 10.0.1.0/24 (us-central1)
VPN tunnelBase priorityRegion-to-region costAdvertised MEDPath 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)
VPN tunnelBase priorityRegion-to-region costAdvertised MEDPath 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)
VPN tunnelBase priorityRegion-to-region costAdvertised MEDPath 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.
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. 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. 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. 10.0.1.0/24 (us-central1)
VPN tunnelBase priorityRegion-to-region costAdvertised MEDPath 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)
VPN tunnelBase priorityRegion-to-region costAdvertised MEDPath 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)
VPN tunnelBase priorityRegion-to-region costAdvertised MEDPath ranking central-tunnel-0
100
250
350
2nd choice
central-tunnel-1
351
250
601
4th choice
west-tunnel-0
100
0
100
1st choice
west-tunnel-1
351
0
351
3rd choice
Globally preferred Dedicated Interconnect
This example is similar to the previous examples, except that you have replaced the two Cloud VPN tunnels in the us-west1 region with two VLAN attachments.
For an illustration of this example, see the following diagram.
Globally preferred Dedicated Interconnect (click to enlarge)You want to prioritize the VLAN attachments. You specify larger base priorities for the HA VPN tunnels in the us-central1 region to deprioritize them.
The following tables show how base priority and region-to-region cost are used to calculate the advertised MED values for traffic from your on-premises network to each subnet.
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. 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. 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. 10.0.1.0/24 (us-central1)
VPN tunnel or VLAN attachmentBase priorityRegion-to-region costAdvertised MEDPath 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)
VPN tunnel or VLAN attachmentBase priorityRegion-to-region costAdvertised MEDPath 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)
VPN tunnel or VLAN attachmentBase priorityRegion-to-region costAdvertised MEDPath ranking central-tunnel-0,
central-tunnel-1
351
250
601
2nd choice
west-attachment-0,
west-attachment-1
100
0
100
1st choice
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, 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 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.
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 route advertisements that match the learned prefixes). If you add a custom route advertisement to one BGP session, and that advertisement overlaps a learned route from another BGP session, the learned route might be dropped.
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 assured unique destination prefixes. For information about these limits, see limits.
IPv4 and IPv6 routes count towards the same maximum and do not have separate 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.
Default route
When no route is specified for a particular IP destination, traffic is sent to a default route, which acts like a last resort when no other options exist. For example, Google Cloud VPC networks automatically include a default route that sends traffic to the internet gateway. The default route for IPv4 only is 0.0.0.0/0 and for dual stack IPv4 and IPv6 is 0.0.0.0/0, ::/0.
Sometimes, you might want traffic to be directed to your on-premises network by default. To do that, you can advertise a default route from your on-premises router to Cloud Router. With Cloud Router, you don't need to create and manage static routes. If you advertise a default route from your on-premises network, check that it's prioritized over other automatically created default routes (has a lower MED value). Go to the Routes page and view the Priority for routes with 0.0.0.0/0 in Destination IP range, and view Default internet gateway in Next hop.
Redundant Cloud VPN tunnels
If the on-premises gateway doesn't support graceful restart, a failure on either side of the BGP session causes the session to fail, and traffic is disrupted. After the BGP timeout is exceeded, which is 60 seconds for Cloud Router, routes are withdrawn from both sides. Peers on both sides of the tunnel exchange static routes, but not dynamic routes.
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 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 (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.
| 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.