Cloud Router overview
Cloud Router is a fully distributed and managed Google Cloud service that uses the Border Gateway Protocol (BGP) to advertise IP prefixes. It programs dynamic routes based on the BGP advertisements that it receives from a peer. Instead of a physical device or appliance, each Cloud Router consists of software tasks that act as BGP speakers and responders. A Cloud Router also serves as the control plane for Cloud NAT. Cloud Router provides BGP services for the following Google Cloud products:
- Cloud 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 VPC subnet routes and custom prefixes on its BGP sessions. Unless you configure custom advertisement mode, a Cloud Router only advertises VPC subnet routes. Custom advertisement mode also lets you configure a Cloud Router to omit advertising VPC subnet routes.
The dynamic routing mode of a VPC network—either regional or global— determines which VPC subnet routes the Cloud Routers in that network advertise. For details, see Default advertisement mode.
The dynamic routing mode also controls how each Cloud Router applies learned prefixes as dynamic routes in a VPC network. For details about this behavior, see Effects of dynamic routing mode.
When you configure BGP for Cloud Interconnect, HA VPN, and Router appliance, you can optionally configure the router's peering sessions to use MD5 authentication.
Autonomous system number (ASN)
When you create a Cloud Router, you choose the Google-side ASN for all BGP sessions used by the Cloud Router. The directions for each network connectivity product listed in the Additional resources section provide details about how each product uses ASN.
BGP peering 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 peering IP addresses:
- For Dedicated Interconnect, you can either specify candidate link-local addresses for BGP peering addresses, or Google Cloud can select unused link-local addresses automatically.
- For Partner Interconnect, Google Cloud selects unused link-local IPv4 addresses automatically.
- For HA VPN and Classic VPN using dynamic routing, you can specify the BGP peering IP 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. Native IPv6-only sessions are not supported.
Cloud Router advertises IPv6 prefixes for VPC networks that include dual-stack subnets. By default, internal IPv6 subnet ranges are advertised automatically. External IPv6 subnet ranges are not advertised automatically, but you can advertise them manually by using custom advertised routes.
You can enable IPv6 prefix exchange in BGP sessions that are created for HA VPN tunnels and VLAN attachments. For details, see the following documents:
- Create an HA VPN to a peer VPN gateway
- Create an HA VPN to another HA VPN gateway
- Create VLAN attachments (Dedicated)
- Enable or disable IPv6 prefix exchange in BGP IPv4 sessions
For details about IPv6 route advertisements, see Route advertisement modes.
IPv6 limitations
IPv6 prefix exchange is not supported in BGP sessions for the following resources:
- 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.
Example scenario | Number of software tasks used to implement the Cloud Router |
---|---|
One or more interfaces, each connected to a Classic VPN tunnel. | One |
One or more interfaces, each connected to a VLAN attachment, where the VLAN attachments are in the same edge availability domain. | One |
Any number of interfaces, each connected to an HA VPN
tunnel, where the tunnels are all connected to the same interface number
on one or more HA VPN gateways—for example, two
tunnels, each connected to interface 0 on different
HA VPN gateways. |
One |
At least two interfaces, one connected to a VLAN attachment in a single edge availability domain, and another connected to a single HA VPN tunnel, where the edge availability domain and VPN gateway interface numbers are the same—for example, the first edge availability domain in a pair of edge availability domains and the first VPN gateway interface. | One |
At least two interfaces, each connected to a router appliance instance,
where one of the interfaces is configured as a redundant interface. To
create a redundant interface, use the redundant-interface
flag (Google Cloud CLI) or the redundantInterface field
(Compute Engine API). Router appliance is part of Network Connectivity Center. |
Two |
At least two interfaces, each connected to a VLAN attachment, where the VLAN attachments are in different edge availability domains. | Two |
At least two interfaces, each connected to an HA VPN
tunnel, where each tunnel is connected to different
HA VPN gateway interface numbers—for example, one
tunnel connected to interface 0 of an HA VPN
gateway and another tunnel connected to interface 1 of the
same gateway or a different gateway.
|
Two |
A Cloud Router with at least the following:
|
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 listed in the Additional resources section, 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 advertisement mode and custom advertisement mode.
Default advertisement mode
Using the default advertisement mode configures a Cloud Router or BGP session to advertise prefixes for the following types of subnet 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 route 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 route 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.
Custom advertisement mode
Custom advertisement mode gives you control over the prefixes that a
Cloud Router advertises. You can specify custom advertised routes
(including default route prefixes, 0.0.0.0/0
or ::/0
) for all BGP sessions
on a Cloud Router or on a per-BGP session basis. There are two
categories of custom advertised routes:
You can advertise only custom IPv4 and IPv6 prefixes. This type of custom advertised route omits the subnet routes that would be advertised using default advertisement mode.
You can advertise custom IPv4 and IPv6 prefixes in addition to subnet routes. This type of custom advertised route includes the same subnet routes advertised using default advertisement mode.
If you choose to advertise subnet routes, their advertisements are updated automatically as described in Automatic updates for subnet route advertisements.
If conditions for IPv6 route advertisement are met, Cloud Router advertises internal IPv6 subnet ranges whenever you choose to advertise subnet routes. You must add any external IPv6 subnet ranges to your list of custom routes in order to advertise them.
For the maximum number of custom advertised routes that can be advertised on each BGP session, see maximum number of custom advertised routes per BGP session on the Cloud Router limits page. This maximum applies to custom advertised routes for the whole Cloud Router and individually per BGP session.
For more information, see the following documents:
Effective advertised prefixes
The route advertisement mode is configurable on both the whole Cloud Router and on individual BGP sessions of the Cloud Router. The following table describes which prefixes are advertised on the BGP session, based on the selected advertisement mode of the Cloud Router and the BGP session.
Mode for Cloud Router | Mode for BGP session | Effective advertised prefixes on the BGP session |
---|---|---|
default | default | The BGP session inherits the Cloud Router configuration. Subnet routes are advertised as described in Default advertisement mode. |
custom | default | The BGP session inherits the Cloud Router configuration. Custom routes configured on the whole Cloud Router are advertised as described in Custom advertisement mode. Advertised routes might contain some or all subnet routes. |
default or custom | custom | The BGP session does not inherit the Cloud Router configuration. Custom advertised routes configured on the BGP session itself are advertised as described in Custom advertisement mode. Advertised routes might contain some or all subnet routes. |
Automatic updates for subnet route advertisements
Cloud Router automatically updates subnet route advertisements in the following situations:
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
Conditions for IPv6 route advertisement
Cloud Router can advertise IPv6 routes 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
and9999
, 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
and200
, inclusive. Because region-to-region costs are at least201
, if you use base priorities of201
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 of200
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
, andus-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.
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.
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 routes
Learned routes are routes that Cloud Router uses to reach another network. The other network might be your on-premises network, a network in another cloud service provider, or another VPC network. Learned routes are sometimes referred to as received routes.
In Google Cloud, there are two types of learned routes:
Routes that are learned from external routers through BGP
Routes that you manually configure for an individual BGP session (custom learned routes)
Using both types of learned routes, Cloud Router creates dynamic routes in your VPC network. Each dynamic route created by Cloud Router is derived from one or more of these learned routes.
If Cloud Router has multiple learned routes for the same destination prefix, Cloud Router uses route metrics and, in some cases, AS path length to create dynamic routes. The following sections describe more information about that process and about learned routes in general.
Custom learned routes
As described in the preceding section, you can configure a BGP session to have custom learned routes. When you configure custom learned routes, Cloud Router behaves as if it learned these routes from a BGP peer.
Custom learned routes can be helpful if you want to avoid the limitations of static routes. For example, static routes can't detect a loss of reachability in the next hop of a route. In contrast, custom learned routes can detect a loss of reachability, and they react accordingly to avoid dropping traffic without notification.
For more information, see Custom learned routes.
Effects of dynamic routing mode
The dynamic routing mode of a VPC network determines how learned routes are applied:
In regional dynamic routing mode, Cloud Router creates a dynamic route for the destination and next hop in the same region as the Cloud Router. Cloud Router sets the priority for that dynamic route to the base priority, which Cloud Router derives from the multi-exit discriminator (MED) advertised by your on-premises router.
In global dynamic routing mode, Cloud Router creates a dynamic route for the destination and next hop in each Google Cloud region. In the region that contains the Cloud Router that learned that route, Cloud Router sets the priority for the dynamic route to the base priority. In all other regions, Cloud Router sets the priority to the base priority plus an appropriate region-to-region cost.
You can define the route priority for 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 dynamic routes in the VPC network, according to the VPC network's dynamic routing mode. In global dynamic routing mode, the priority of each regional dynamic route is adjusted in regions different from the Cloud Router region. For details about how Google Cloud selects a route, see Routing order in the VPC documentation.
Base priority, MED, and origin
Cloud Router uses the MED value advertised by your peer router to compute a base priority:
- If the MED value for a destination's prefix is between
0
and231 -1
(inclusive), Cloud Router sets the base priority to the MED value. - If the MED value for a destination's prefix is between
231
and232 -1
(inclusive), Cloud Router sets the base priority to231 -1
.
For MED to take effect during best path selection between multiple learned routes for the same destination, the BGP origin attribute value for the received routes must be the same. Otherwise, selection happens based on the origin attribute value, which precedes the MED comparison step in the best path selection process (RFC 4271).
Cloud Router advertises BGP routes to its peers with the origin
attribute value set to Incomplete
. This value is the least preferred origin
type in route selection.
The final priority value that Cloud Router sets when it creates dynamic routes in a VPC network depends on the network's dynamic routing mode. For more information, see Effects of dynamic routing mode.
Static routes
When an instance sends a packet, Google Cloud attempts to select one route from the set of applicable routes according to routing order. For details, see the Routing order section in the VPC documentation.
Overlapping 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 advertised routes that match the learned prefixes). If you add a custom advertised route to one BGP session, and that advertised route overlaps a learned route from another BGP session, the learned route might be dropped.
Limits for learned routes
There are several limits that affect learned routes. For more information, see limits.
IPv4 and IPv6 routes count toward the same maximum and do not have separate limits.
To monitor your usage against the limits, use the following metrics:
router.googleapis.com/dynamic_routes/learned_routes/used_unique_destinations
router.googleapis.com/dynamic_routes/learned_routes/unique_destinations_limit
router.googleapis.com/dynamic_routes/learned_routes/any_dropped_unique_destinations
For information about log messages related to these limits, the metrics that you can use to monitor them, and how to resolve issues, see Check quotas and limits on the Troubleshooting page.
Default route
When no route is specified for a particular 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.
Without graceful restart support, deploying two on-premises gateways with one tunnel each provides redundancy and failover. This configuration enables one tunnel and its devices to go offline for software upgrades or maintenance without disrupting traffic. Also, if one tunnel fails, the other tunnel can keep the routes active and traffic flowing.
Maintenance events
Cloud Router undergoes periodic maintenance, which takes under 60 seconds. Cloud Router is not available during maintenance events. The BGP hold timer determines how long learned routes are preserved when the peered BGP router is unavailable. The BGP hold timer is negotiated to be the lower of the two values from both sides. Cloud Router uses a value of 60 seconds (by default) for the BGP hold timer. We recommend that you set the BGP hold timer on your on-premises (peer) router to 60 seconds or greater. As a result, both routers preserve their routes during these upgrades and traffic continues to flow.
During Cloud VPN gateway maintenance cycles with a single Cloud VPN gateway, the use of Cloud Router adds about 20 seconds to the tunnel recovery time because the BGP session is reset and routes have to be relearned. Cloud VPN gateway recovery times are usually about a minute. If there are redundant Cloud VPN gateways, traffic is unaffected because only one Cloud VPN gateway is taken down at a time.
BGP 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
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.