Troubleshoot BGP routes and route selection
This guide is for troubleshooting issues related to BGP routes, including route selection, route propagation, and route priorities.
For additional troubleshooting information, see the following:
IPv6 BGP session is established but does not exchange IPv4 routes
Verify that the VLAN attachment or HA VPN gateway has the required stack type of
IPV4_IPV6
. If the stack type is incorrect for the VLAN attachment, modify the VLAN attachment. For a HA VPN gateway, recreate the HA VPN gateway and its tunnels.Ensure that your Cloud Router is configured properly. Run the following command:
gcloud compute routers describe ROUTER-NAME
In the output, check the following values:
bgpPeers.enableIpv4
istrue
bgpPeers.ipv4NexthopAddress
andbgpPeers.peerIpv4NexthopAddress
are present
Some on-premises IPv4 or IPv6 prefixes aren't available
If some on-premises IPv4 or IPv6 prefixes aren't available, check quotas and limits or overlapping subnet ranges.
Custom learned routes are inactive
If you have configured a custom learned route but are experiencing traffic loss, ping errors, or other problems related to the route, do the following:
- Check that the route is configured properly on the BGP session.
- Check that the BGP session is up.
- Check for dropped routes.
- Check quotas and limits.
- Check for overlapping subnet ranges.
For more information, see Check the status of custom learned routes.
Check for dropped routes
To see if a route is dropped, run the following command:
gcloud compute routers get-status ROUTER_NAME \
--region=REGION
Replace the following:
ROUTER_NAME
: the name of your Cloud Router.REGION
: the region that your Cloud Router is located in.
The output is similar to the following; look for the routeStatus
set to
active
:
kind: compute#routerStatusResponse
result:
bestRoutesForRouter:
- asPaths:
- asLists:
- 65200
pathSegmentType: AS_SEQUENCE
creationTimestamp: '2024-03-22T13:57:15.533-07:00'
destRange: 10.128.0.0/20
kind: compute#route
network: https://www.googleapis.com/compute/v1/projects/PROJECT/global/networks/VPC_NAME
nextHopIp: 169.254.73.246
nextHopVpnTunnel: https://www.googleapis.com/compute/v1/projects/PROJECT/regions/REGION/vpnTunnels/VPN_NAME
priority: 100
routeStatus: ACTIVE
routeType: BGP
bgpPeerStatus:
- advertisedRoutes:
- destRange: 10.128.0.0/20
kind: compute#route
network: https://www.googleapis.com/compute/v1/projects/PROJECT/global/networks/aneta-vpc
nextHopIp: 169.254.73.245
nextHopVpnTunnel: https://www.googleapis.com/compute/v1/projects/PROJECT/regions/REGION/vpnTunnels/VPN_NAME
priority: 100
routeType: BGP
enableIpv6: false
ipAddress: 169.254.73.245
linkedVpnTunnel: https://www.googleapis.com/compute/v1/projects/PROJECT/regions/REGION/vpnTunnels/VPN_NAME
md5AuthEnabled: false
name: aneta-bgp
numLearnedRoutes: 1
peerIpAddress: 169.254.73.246
state: Established
status: UP
uptime: 10 hours, 11 minutes, 0 seconds
uptimeSeconds: '36660'
network: https://www.googleapis.com/compute/v1/projects/PROJECT/global/networks/VPC_NAME
The bestRoutesForRouter.routeStatus
value displays ACTIVE
for an active
route, and DROPPED
for a dropped route.
Check quotas and limits
Check that your Cloud Routers haven't exceeded the limits for learned routes. To view the number of learned routes for a Cloud Router, view its status.
For information about the limits, related log messages, and metrics, and how to resolve issues, see the following table.
Limits | Guidance |
---|---|
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 prefixes:
The first limit is relevant regardless of the dynamic routing mode used by the VPC network. The second limit only makes sense if the VPC network uses global dynamic routing mode. For details about Cloud Router limits, see Limits. |
Logs | When you encounter either of these limits, you'll see a
limit-exceeded message in Cloud Logging. For
information about how to create an advanced query to view this message,
see the related
query
in the logging documentation for Cloud Router. |
Metrics | You can also use the following metrics to understand your current
limits and usage. These metrics are prepended with
These metrics are available through the |
Resolving issues | You can do the following 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 IPv4 and IPv6 address ranges for a VPC subnet don't fully overlap with advertised routes from your on-premises network. Overlapping IPv4 and IPv6 ranges can cause routes to be dropped. This also applies to custom static routes that overlap with a dynamic route learned by a 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 IPv4 or IPv6 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 IPv4 or IPv6 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.
For example, in the following hub and spoke topology, Cloud Router cannot support route advertisement between multiple VPC networks.
To review recommendations for network topologies in Google Cloud, see Best practices and reference architectures for VPC design.
In addition, to build and manage hub and spoke topologies in Google Cloud, you can use Network Connectivity Center.
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 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.
On a multi-NIC VM, each NIC gets different routes
This is the expected behavior. You must configure each network interface controller (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 the Cloud Router don't align. For ingress traffic into your VPC network, use the Cloud Router to configure advertised route priorities. For more information, see Learned routes.
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:
Cisco: BGP Best Path Selection
Fortinet: BGP Handbook
Juniper: BGP Path Selection
For egress traffic out of your VPC network, check your on-premises router's MED value.
The default route (0.0.0.0/0
or ::/0
) is sending traffic to the internet gateway
When you create a VPC network, Google Cloud automatically
creates a default route with a
priority of 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/0
or::/0
that has a higher priority than the automatically created default route.
The next hop isn't clear
To learn how Google Cloud's route selection algorithm works, see Applicability and order in the VPC Routes documentation.
IPv6 traffic is not being routed
If you are experiencing difficulty connecting to IPv6 hosts, do the following:
Verify that IPv4 routes are being correctly advertised. By checking IPv4 traffic first, you can rule out general network issues. If IPv4 routes are not being advertised, perform the general troubleshooting procedures listed in this document.
Inspect firewall rules to ensure that you are allowing IPv6 traffic between your VPC network and your on-premises network.
Verify that you don't have overlapping IPv6 subnet ranges in your VPC network and your on-premises network. See Check overlapping subnet ranges.
Determine whether you have exceeded any quotas and limits for your learned routes. If you have exceeded your quota for learned routes, IPv6 prefixes are dropped before IPv4 prefixes. See Check quotas and limits.
Verify that all components that require IPv6 configuration have been configured correctly.
The VPC subnet is configured to use the
IPV4_IPV6
stack type.The VPC subnet has
--ipv6-access-type
set toINTERNAL
.The Compute Engine VMs on the subnet are configured with IPv6 addresses.
The HA VPN gateway or the VLAN attachment for Dedicated Interconnect is configured to use the
IPV4_IPV6
stack type.The BGP peer is enabled to use IPv6, and correct IPv6 next hop addresses are configured for the BGP session.
To view Cloud Router status and routes, see View Cloud Router status and routes.
To view BGP session configuration, see View BGP session configuration.
What's next
For more information about how to use Cloud Logging to monitor Cloud Router, see View logs and metrics.
For additional support, see Getting support.
For information about BGP session states, see BGP session states.
For information about diagnostic messages and session states related to Bidirectional Forwarding Detection (BFD), see BFD diagnostic messages and session states.
For issues related to using Cloud Router with Router appliance, see Troubleshooting Router appliance in the Network Connectivity Center documentation.