Troubleshoot Network Connectivity Center, Router appliance, and VPC spokes

Learn about troubleshooting steps that you might find helpful if you run into problems using Network Connectivity Center, Router appliance, and VPC spokes.

For known issues, see Considerations on the Overview page.

Common issues with command syntax

When updating a spoke, you must specify the location that the spoke is in.

Attach 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 VPC network's dynamic routing mode is set to global.

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:

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.

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:

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.

Troubleshoot Router appliance

The following issues and solutions are unique to Router appliance.

The documentation for troubleshooting Cloud Routeralso applies to Router appliance, along with the issues described in the following sections.

For more information, see the following:

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 179 is allowed. To configure firewall settings for Router appliance, see Create 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 Create router appliance instances.

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.

Troubleshoot VPC spokes

Permissions

If permission is denied when creating a spoke in a different project from the hub, check with the hub administrator to confirm that you have been granted the required networkconnectivity.groups.use permission on the hub.

VPC spoke creation failures

If your VPC spoke creation has failed, it could be due to one of the following reasons:

  • The VPC network is already peered with one or more of the existing spokes using VPC peering.
  • Subnets overlap with existing VPC spokes.
  • Subnets overlap with peers of existing VPC spokes.
  • You have exceeded the VPC spokes quota.
  • You have exceeded the routes per hub route table quota.
  • More than 16 export filters are specified.
  • Subnets in the VPC network are larger than one or more filters specified.

For quota-related errors, see Quotas and limits.

VPC spoke creation failures after deleting a spoke

After you delete a spoke, the following cool-down periods apply:

  • You must wait for a cool-down period of at least 10 minutes before creating a new spoke for the same VPC network attached to the same hub.
  • For a new spoke for the same VPC network attached to a different hub, you must wait for the cool-down period of at least 24 hours.
  • It is possible that the spoke creation for the same VPC network might not have its filters applied properly. The workaround is to delete the spoke, wait for a longer period of time, and then recreate the spoke.

Subnet creation failures in a VPC spoke

If you encounter subnet creation failure in a VPC spoke, it could be due to one of the following reasons:

  • There are overlapping subnets in other VPC spokes or peers of VPC spokes.
  • You have exceeded the routes per hub route table quota.
  • Subnets in the VPC network are larger than one or more filters specified.

The VPC spoke is created but dataplane connectivity is missing

If your VPC spoke is showing as created, but dataplane connectivity is missing, it could be due to one of the following reasons:

  • The spoke is in a different project from the hub and the hub administrator has not accepted the spoke proposal.
  • All subnets in the VPC network are filtered and excluded from connectivity.
  • Destination subnets are filtered by their corresponding VPC spoke filters.

The hub route table doesn't show some subnets in VPC spokes

If your hub route table doesn't show some of the subnets in the VPC spokes, it could be due to one of the following reasons:

  • The subnets are filtered using export filters.
  • The subnets were created within the last 5-10 minutes and the hub route table has not refreshed yet.