Learn about troubleshooting steps that you might find helpful if you run into problems using Network Connectivity Center.
For known issues, see Considerations on the Overview page.
Common issues with command syntax
When updating a spoke, you don't need to specify the hub, but you do need to specify the region that the spoke is located in.
Hubs are global resources, but spokes are regional resources.
Attaching resources to spokes
For detailed requirements, recommendations, and considerations for creating spokes and attaching resources to them, see Creating a spoke.
Routes are not distributed between regions
If routes are not being distributed properly between regions, verify that the
dynamic routing mode is set to
Data transfer traffic doesn't flow between two locations
If data transfer traffic isn't flowing between two locations, confirm that the following resources are correctly configured and working:
- Verify the functionality of HA VPN tunnels or VLAN attachments that are added as spokes.
- Verify the routes programmed between the two locations.
- Verify ASN assignments as described in the next section.
Assigning ASNs to spokes
To simplify your configuration, we recommend that you assign ASNs to spokes in the following way:
- Use a single Google autonomous system number (ASN) (
router.bgp.asn) on Cloud Router for all spoke resources attached to a single hub. For example, the HA VPN tunnels attached to a spoke would use that Google ASN on the Cloud Router that they use for peering. Follow the recommendations for numbering ASNs in the documentation for creating a Cloud Router.
- Assign a unique peer ASN to each spoke attached to the same hub
router.bgpPeers.asn). Within each spoke, make sure that all peer ASNs are the same. Because if two peers advertise the same prefix with different ASNs or AS paths, only one peer's ASN and AS path is readvertised for that prefix.
- We recommend configuring AS path loop detection on your peer routers, although
this feature is almost always on by default. In some cases, it can't be
disabled. For example, when the peer router is Cloud Router or
possibly when using routing capabilities from other cloud providers.
When AS path loop detection is enabled, if two spokes are configured with the same peer ASN, AS path loop detection on a peer router for one spoke drops all prefix advertisements from the other spoke.
In the following example, peer routers in the following spokes advertise the following prefixes and different ASNs:
A; peer router
65001, advertises prefixes
A: peer router
65002, advertises prefixes
B; peer router
65003, advertises prefixes
Cloud Router then advertises the following prefixes to a peer on Spoke
10.1.0.0/16, but the AS path could begin with any of these ASNs:
10.2.0.0/16with an AS path beginning with
10.3.0.0/16with an AS path beginning with
10.4.0.0/16with an AS path beginning with
By making sure that each prefix is advertised by only a single spoke, and that all peers within a spoke have the same ASN, this ambiguity is avoided.
Duplicate route advertisements from BGP sessions
If there are duplicate route advertisements (some from BGP sessions participating in data transfer and some from sessions not participating in data transfer), then data transfer traffic might use ECMP to distribute traffic to all available next hops, even if those next hops aren't explicitly participating in data transfer. This behavior will be fixed by General Availability.
Interconnect connection to an unsupported location
For an example of how to configure route advertisements when one of your redundant Interconnect connections is to an unsupported location, see Optimal route advertisement for Network Connectivity Center.
Troubleshoot network connectivity using Connectivity Tests
Connectivity Tests is a diagnostics tool that lets you check connectivity between endpoints in your network. It analyzes your configuration and in some cases performs run-time verification.
To analyze network configurations, Connectivity Tests simulates the expected forwarding path of a packet through your Virtual Private Cloud (VPC) network, Cloud VPN tunnels, VLAN attachments, or router appliance instances.
You can use the Connectivity Tests configuration analysis to evaluate reachability between two non-Google Cloud networks that are connected through Network Connectivity Center. In this context, a non-Google Cloud network is typically your on-premises data center or a branch office or another cloud provider's network.
Because Connectivity Tests doesn't have access to your on-premises network configuration, it can't verify the configuration of routes and firewall rules on your on-premises router. Thus, traffic from your on-premises network to your VPC network is always considered valid by the Connectivity Tests configuration analysis, and only configurations within Google Cloud are verified.
To run Connectivity Tests between two on-premises networks connected through Network Connectivity Center, see Running Connectivity Tests.
For more information, see the Connectivity Tests overview.
Troubleshooting Router appliance
The following issues and solutions are unique to Router appliance.
The documentation for troubleshooting Cloud Router also applies to Router appliance, along with the issues described in the following sections.
BGP sessions fail to establish
If BGP sessions between Cloud Router and Router appliance fail to establish, check for the following issues:
- Make sure that a VM acting as a router appliance instance is configured as part of a spoke in Network Connectivity Center. To configure a router appliance instance as part of a spoke, see Working with spokes.
- Check your firewall settings to ensure that TCP port
179is allowed. To configure firewall settings for Router appliance, see Creating router appliance instances.
- Make sure that neither Cloud Router nor your router appliance
instance are using link-local addresses (that is,
169.254.x.x) to peer with each other. For guidance, see Recommendations for allocating IP addresses.
- Make sure that Cloud Router has established two separate BGP sessions to your router appliance instance, one from each Cloud Router interface. The router appliance instance must advertise the same routes on both BGP sessions. If one of your BGP sessions goes down and your router appliance VM loses communication to Cloud Router, check the configuration of your Cloud Router interfaces. For more information, see Creating router appliance instances.
- If your deployment includes more than 1,000 VMs, you might be unable to establish BGP sessions between the router appliance instance and the Cloud Router. This 1,000-VM limit includes any VMs that are accessible through VPC Network Peering.
Issues with internal IP addresses for BGP sessions on router appliance instances
If you discover issues related to your IP address configuration for router appliance instances, make sure that you have configured RFC 1918 internal IP addresses for BGP sessions between Cloud Router and the VMs acting as router appliance instances.
Router appliance instances don't use
169.254.x.x addresses for BGP
sessions. Instead, they must use IP addresses in the same VPC
subnet as Cloud Router. For more information, see
Creating router appliance instances.