Use the following guide to troubleshoot common issues with Cloud Router:

Configuration issues

BGP session failed to establish

  • Check that the settings on your on-premises BGP router and the settings on your Cloud Router are correct. View the Cloud Router logs for detailed information.
  • If you're creating a Cloud VPN tunnel, check that the status of the tunnel is ESTABLISHED. If it isn't, view VPN troubleshooting to troubleshoot the issue.

External and internal IP addresses (RFC 1918) don't work for BGP peering

Currently, Cloud Router doesn't support external (public) and internal (private) IP addresses for BGP peering. You must use link-local IP addresses (

Error: Invalid value for field 'resource.bgp.asn': '######'. Local ASN conflicts with peer ASN specified by a router in the same region and network.

Cloud Router is attempting to establish a BGP session with an on-premises device that has the same ASN as the Cloud Router. Change the ASN of your device or Cloud Router to resolve this issue.

iBGP between Cloud Routers in a single region doesn't work

Although you can create two Cloud Routers with the same ASN, iBGP isn't supported.

Cloud Router issues

BGP resets originating from GCP appear on your router

Cloud Router tasks are software processes in the GCP control plane that are normally migrated from machine to machine. During such migrations, Cloud Router might be down for a few seconds. Normal migrations do not cause traffic to be dropped.

Cloud Router is not located in the data path and is not acting as a Layer 3 switch, but as a manager for route programming. Routing is actually handled by the Cloud Interconnect attachment or the Cloud VPN tunnel.

Route processing issues

On-premises routes without a MED value are taking priority

If Cloud Router receives an on-premises route that doesn't have a MED value, Cloud Router follows the behavior described in RFC 4271. Cloud Router treats the route with the highest priority by assuming the lowest possible MED value (0).

Some on-premises IP prefixes aren't available

Check that your Cloud Routers haven't exceed the quota for learned routes. The quota applies regionally or globally, depending on the VPC network's dynamic routing mode. To view the number of learned routes for a Cloud Router, view its status. If the number exceeds your quota, reduce the number of advertised routes from your on-premises router. You can also view the logs to check if routes are being dropped because of the quota. To check the available quota for resources in your project, go to the Quotas page in the Google Cloud Platform Console.

Also, check that a VPC subnet's IP range doesn't fully overlap with route advertisements from your on-premises network. Overlapping IP ranges can cause routes to be dropped. For more information, see Overlapping IP ranges between a VPC subnet and on-premises route advertisement in the Cloud Router Overview.

For collisions with static route, the BGP MED value determines which route takes precedence.

Routes that are learned from an on-premises network aren't being propagated to other GCP VPC networks

A single Cloud Router can't advertise routes learned from one BGP peer to other BGP peers. This a Cloud Router limitation. For example, you can't implement a hub and spoke topology, as shown in the following example:

Cloud Router hub and spoke (click to enlarge)
Cloud Router hub and spoke (click to enlarge)

If you have a similar topology and are using a VPN tunnel, or are using Cloud Interconnect VLAN attachments, you can use one of the following alternatives:

  • Create a single VPC network to replace multiple existing VPC networks. Connect the replacement VPC network to your on-premises network using Cloud VPN or Cloud Interconnect. If you need to maintain a configuration that delegates administrative capabilities among projects with a single VPC network, use Shared VPC. Note that you must recreate virtual machine instances and other resources in the single replacement network. You cannot simply move them from one network to another.
  • Continue to maintain separate VPC networks. Connect each network to your on-premises network using Cloud VPN or Cloud Interconnect, and use Cloud Router in each network to exchange routing information.
  • Use VPC peering.

Cloud Router doesn't use Equal-cost multi-path (ECMP) across routes with different origin ASNs

For cases where you have multiple on-premises routers peering with a single Cloud Router, the Cloud Router learns and propagates routes from the router with the lowest ASN. Cloud Router ignores advertised routes from routers with higher ASNs, which might result in unexpected behavior. For example, you might have two on-premises routers advertise routes that are using two different VPN tunnels. You expect traffic to be load balanced between the tunnels, but GCP uses only one of the tunnels because Cloud Router only propagated routes from the on-premises router with the lower ASN.

Regardless of the on-premises ASNs, Cloud Router can learn and propagate routes from all on-premises routers. To do so, you must create a Cloud Router for each unique ASN. Then, establish a BGP session between each Cloud Router and on-premises router with the same ASN.

On a multi-NIC VM, each NIC gets different routes

This is the expected behavior. Each network interface card (NIC) and Cloud Router belong to a single VPC network. Cloud Router propagates routes to the NIC that belongs in its VPC network. Packets leaving a NIC aren't aware of routes from other VPC networks.

Traffic is being routed asymmetrically

Traffic is routed asymmetrically when ingress and egress traffic use different paths. For example, you might have two VPN tunnels. Egress traffic from your VPC network might use the first tunnel, while ingress traffic into your VPC network might use the second tunnel.

Typically, asymmetric routing happens when the preferred path that's being advertised by your on-premises router and Cloud Router don't align. For ingress traffic into your VPC network, use Cloud Router to configure advertised route priorities. For more information, see Best path for egress traffic from GCP to your on-premises network.

For egress traffic out of your VPC network, check your on-premises router's local preference or MED values.

The default route ( is sending traffic to the Internet gateway

Every VM in a VPC network has a primary default route that sends traffic to the Internet gateway. The VM's default route has a base advertised priority of 1000. VMs also have backup default route that blackholes traffic so that traffic doesn't reach the Internet, such as cases where the VM doesn't have an external IP address.

If the routes that Cloud Router propagates have a priority that's less than 1000, those routes take precedence. If the priority is higher than 1000, the VM's primary and backup default routes always take precedence.

Also, if an advertised route with a priority less than 1000 goes bad, the packets use the VM's primary or backup default route. To suppress these routes, create an egress firewall rule.

Next hop isn't clear

For egress traffic leaving your VPC network, traffic might have multiple paths for reaching a particular destination IP prefix. The path with the lowest priority takes precedence. If multiple next hops have equal priority, GCP uses ECMP to balance traffic between each path.

For example, assume that you have the following setup:

  • Next hop 1: priority 100
  • Next hop 2 and 3: priority 270
  • Next hop 4 and 5: priority 330

Next hop 1 gets all the traffic. If it goes down, then next hop 2 and 3 use ECMP to route traffic. If next hop 2 goes down, next hop 3 get all the traffic. If next hop 1, 2, and 3 are down, then next hop 4 and 5 use ECMP to route traffic.

Was this page helpful? Let us know how we did:

Send feedback about...

Cloud Router