Use the following guide to troubleshoot common issues with Cloud Router:
- Configuration issues: View issues related to configuring and establishing BGP sessions.
- Router issues: View issues with Cloud Router itself.
- Route processing issues: View issues related to route propagation or route priorities.
- Router appliance issues: View issues related to using Cloud Router with Router appliance.
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 Cloud VPN troubleshooting to troubleshoot the issue.
IP addresses for BGP sessions
The IP addresses that you can use for a BGP session depend on which network connectivity product you use. For complete details, see BGP IP addresses.
Invalid value for field resource.bgp.asn
You may get this error: "Invalid value for field
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. To resolve this issue, change the ASN of your device or Cloud Router.
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 Google Cloud appear on your router
Cloud Router tasks are software processes in the Google Cloud control plane that are normally migrated from machine to machine. During such migrations, Cloud Router might be down for periods of up to 60 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 VLAN attachment or the Cloud VPN tunnel.
On-premises router experiences BGP flap
BGP flaps can be caused by a variety of things, including Cloud Router software maintenance and automated task restarts.
A Cloud Router maintenance event is not indicative of a problem if your on-premises router is configured as follows:
- The on-premises router can process graceful restart notifications.
- The on-premises router's hold timer is set to at least 60 seconds.
For a comprehensive overview of timer settings, see Managing BGP timers.
For help monitoring connectivity, see Verify connectivity between the on-premises router and the Cloud Router.
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
Cloud Router treats the route with the highest priority by assuming
the lowest possible MED value (
You can't send and learn MED values over an L3 Partner Interconnect connection
If you are using a Partner Interconnect connection where a Layer 3 service provider handles BGP for you, Cloud Router can't learn MED values from your on-premises router or send MED values to that router. This is because MED values can't pass through autonomous systems. Over this type of connection, you can't set route priorities for routes advertised by Cloud Router to your on-premises router. In addition, you can't set route priorities for routes advertised by your on-premises router to your VPC network.
Some on-premises IP prefixes aren't available
Check quotas and limits
See the following table for information about the limits, related log messages and metrics, and how to resolve issues:
|About the limits||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
|Logs||When you encounter either of these limits, you'll see a
|Metrics||You can also use the following metrics to understand your current limits and usage.
|Resolving issues||You can do the following things to resolve route limit issues. In situations
where the number of routes exceeds the limits by a large amount, it makes sense
to do both:
Check overlapping subnet ranges
Ensure that the IP address ranges for a VPC subnet don't fully overlap with route advertisements from your on-premises network. Overlapping IP ranges can cause routes to be dropped. This also applies to custom static routes that overlap with a dynamic route learned by Cloud Router. Prefixes received by Cloud Routers are ignored (custom dynamic routes are not created) in the following scenarios:
- When the prefix learned exactly matches a primary or secondary IP address range of a subnet in your VPC network.
- When the prefix learned exactly matches the destination of a custom static route in your VPC network.
- When the prefix learned is more specific (has a longer subnet mask) than a primary or secondary IP address range of a subnet in your VPC network.
- When the prefix learned is more specific (has a longer subnet mask) than the destination of a custom static route in your VPC network.
For more information, see Applicability and order of routes in the VPC Routes overview.
Routes learned from an on-premises network aren't propagating to other VPC networks
A single Cloud Router can't re-advertise routes learned from one BGP peer to other BGP peers, including to Cloud Routers in other VPC networks. The following hub and spoke topology describes this limitation.
Consider the following alternatives for this topology:
- Create a single VPC network to replace multiple existing VPC networks. Connect the replacement VPC network to your on-premises network by 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 (VM) 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 by using Cloud VPN or Cloud Interconnect.
- Use VPC Network Peering to connect two VPC networks together. Configure the network whose Cloud Router imports routes from on-premises to export its custom routes. For more information, see Importing and exporting custom routes.
Cloud Router doesn't use ECMP across routes with different origin ASNs
For cases where you have multiple on-premises routers connected to 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 Cloud VPN tunnels. You expect traffic to be load balanced between the tunnels, but Google Cloud uses only one of the tunnels because Cloud Router only propagated routes from the on-premises router with the lower ASN.
Prefixes aren't getting imported into BGP sessions (AS path prepending)
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.
On a multi-NIC VM, each NIC gets different routes
This is the expected behavior. You must configure each network interface (NIC) for a multi-NIC VM in a unique VPC network. Each Cloud Router creates custom dynamic routes in one VPC network. Thus, the routes learned by one Cloud Router are only applicable to one network interface of a multi-NIC VM. Packets sent from a VM's network interface use only the routes applicable to the VPC network for that interface.
Traffic is being routed asymmetrically
Traffic is routed asymmetrically when ingress and egress traffic use different paths. For example, you might have two Cloud 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.
Asymmetric routing happens when the preferred path 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 Google Cloud to your on-premises network.
Check your device documentation for how the BGP best path selection works because other attributes (such as router id or origin ASN) can affect it. For example, see the following resources:
For egress traffic out of your VPC network, check your on-premises router's local preference or MED values.
The default route (0.0.0.0/0) is sending traffic to the internet gateway
When you create a VPC network, Google Cloud automatically
creates a default route with a
1000 whose next hop is the default internet gateway.
Routes with a next hop of the default internet gateway can only be used by VMs that meet internet access requirements.
Using routes with a next hop of the default internet gateway is also required to access Google APIs and services. For example, when using Private Google Access.
The following examples describe situations that can cause traffic to the internet or to Google APIs and services to be blocked:
- If you delete the automatically-created default route (the route with a next hop of the default internet gateway)
- If you replace the automatically-created default route and the next hop of the replacement route is different from the default internet gateway
- If a Cloud Router learns a route with destination
0.0.0.0/0that has a higher priority than the automatically-created default route.
The next hop isn't clear
See Applicability and order in the VPC Routes documentation to learn how Google Cloud's route selection algorithm works.