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 that ASN assignments are set up as described in ASN requirements for spoke resources.
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.