Cloud Router overview

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 is implemented by 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:

You can also use Cloud Router for Classic VPN if your on-premises VPN gateway supports BGP. However, certain functionality is being deprecated on March 31, 2022. For more information, see Classic VPN partial deprecation.

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

Each Cloud Router works with one of the networking connectivity products listed previously. 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.

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 IP addresses in the 169.254.0.0/16 range as BGP IP addresses:

  • For Dedicated Interconnect, you can either specify candidates for link-local BGP IP 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 IP addresses when you create the BGP interface on the Cloud Router.

Router appliances use internal IP 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.

Cloud Router software tasks

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

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

  • For the HA configurations listed in the table, two software tasks are used to provide software redundancy.
  • For VLAN attachments, a separate software task handles each edge availability domain with attachments.
Example scenario Number of software tasks used to implement the Cloud Router
One or more interfaces, each connected to a Classic VPN tunnel. One
One or more interfaces, each connected to a VLAN attachment, where the VLAN attachments are in the same edge availability domain. One
Any number of interfaces, each connected to an HA VPN tunnel, where the tunnels are all connected to the same interface number on one or more HA VPN gateways—for example, two tunnels, each connected to interface 0 on different HA VPN gateways. One
At least two interfaces, one connected to a VLAN attachment in a single edge availability domain, and another connected to a single HA VPN tunnel, where the edge availability domain and VPN gateway interface numbers are the same—for example, the first edge availability domain in a pair of edge availability domains and the first VPN gateway interface. One
At least two interfaces, each connected to a router appliance instance, where one of the interfaces is configured as a redundant interface. To create a redundant interface, use the redundant-interface flag (gcloud command-line tool) 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:
  • One interface connected to a VLAN attachment in edge availability domain 0 and/or one interface connected to an HA VPN tunnel that is connected to interface 0 of an HA VPN gateway.
  • One interface connected to a VLAN attachment in edge availability domain 1 and/or one interface connected to an HA VPN tunnel that is connected to interface 1 of an HA VPN gateway.
  • One interface connected to a Classic VPN tunnel.
Three

Software maintenance and automated task restarts

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

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

If your on-premises router can process graceful restart events, it logs a graceful restart event during Cloud Router maintenance. For on-premises routers that do not support graceful restart, ensure that the on-premises router's hold timer is set to 60 seconds. For details, see Managing 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 Identifying router maintenance events.

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

Automated task restarts when router identifiers change

Cloud Router software tasks use an internal identifier based on the last interface in the Cloud Router's interface list. If you delete that interface, Google Cloud restarts the Cloud Router software tasks to assign them new identifiers. Consequently, deleting one BGP session can sometimes cause all other BGP sessions to restart as if software maintenance happened. Routes are preserved on properly configured on-premises routers if this happens.

The internal identifier is not visible to you, and the identifier sometimes changes during software maintenance and automated task restarts.

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 advertisements

When using the default route advertisement mode, a Cloud Router advertises prefixes for subnet routes according to the dynamic routing mode of the VPC network:

  • When using regional dynamic routing mode, each Cloud Router in the VPC network only advertises subnet routes in the same region as the Cloud Router.

  • When using global dynamic routing mode, each Cloud Router in the VPC network advertises all subnet routes from all regions of the VPC network.

The primary internal IP address of a VM must come from a subnet's primary IPv4 range. VMs can also use addresses from alias IP ranges. Alias IP ranges can come from either a subnet's primary or secondary IPv4 range. Cloud Routers automatically update their default route advertisements in the following situations:

Custom route advertisements

Custom route advertisement mode gives you control over the routes that a Cloud Router advertises. You can specify custom route advertisements for all BGP sessions on a Cloud Router or for individual BGP sessions. When you configure custom route advertisements, you can do the following:

  • In addition to custom ranges, you can configure the Cloud Router to continue advertising subnet IPv4 ranges in the same way as the default route advertisement mode. Continuing to advertise subnet ranges can be useful because Cloud Router continues to automatically update the subnet route advertisements when you add a subnet, delete a subnet, expand a subnet's primary IPv4 range, or edit a subnet's secondary IPv4 ranges.

  • You can disable automatic subnet route advertisement. This allows you to selectively advertise subnet ranges, portions of subnet ranges, aggregated subnet ranges, or no subnet ranges at all. To advertise specific subnet ranges, see Advertising specific VPC subnets.

For more information, see Advertising custom IP ranges.

Scope of route advertisement mode

When you create a Cloud Router, you select the route advertisement mode for the whole Cloud Router. Unless you specify a different route advertisement mode for a BGP session, the Cloud Router's route advertisement mode applies to each BGP session on the Cloud Router.

If a Cloud Router uses the default route advertisement mode, each of its BGP sessions uses the default route advertisement mode unless you have configured a BGP session to use custom route advertisements.

If a Cloud Router uses the custom route advertisement mode, each of its BGP sessions uses the custom route advertisement mode with the custom route advertisements configured for the whole Cloud Router unless you have configured a BGP session to use a different set of custom route advertisements.

For the maximum number of 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 regardless of how the BGP session's custom route advertisements are defined—for the whole Cloud Router or individually per BGP session.

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

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.

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.

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.

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

What's next