Spoke administration overview

This page provides an overview from the perspective of a Virtual Private Cloud (VPC) spoke administrator.

If the Network Connectivity Center hub and VPC spoke are in the same project, VPC spoke administrators must have both of the following Identity and Access Management (IAM) bindings on that project:

If the Network Connectivity Center hub and VPC spoke are in different projects, IAM policies must have the following bindings.

You can also use custom roles as long as the custom role includes the same permissions as the predefined roles listed earlier.

When a VPC network and the Network Connectivity Center hub are located in different projects, a VPC spoke administrator must create a spoke proposal to request that a VPC network join the hub. A hub administrator reviews the proposal. If the hub administrator accepts the proposal, the VPC network is connected to the hub. A hub administrator can also reject spoke proposals. Spoke administrators can check the status of a VPC spoke proposal at any time.

For more information, see the following sections.

Subnet route uniqueness

Similar to VPC Network Peering, Google Cloud prohibits subnet IP address range conflicts among VPC spokes connected to a Network Connectivity Center hub. A subnet IP address range conflicts with another subnet IP address range when one of the following is true:

  • A subnet IP address range in one VPC network exactly matches a subnet IP address range in another VPC network.
  • A subnet IP address range in one VPC network fits within a subnet IP address range in another VPC network.
  • A subnet IP address range in one VPC network contains a subnet IP address range in another VPC network.

VPC spokes cannot export conflicting subnet IP address ranges into the same Network Connectivity Center hub. You can use the exclude-export-ranges flag in the Google Cloud CLI or the excludeExportRanges field in the API to prevent a subnet IP address range from being shared from a VPC spoke into a Network Connectivity Center hub. For example, suppose you have two VPC networks that you want to connect to the same Network Connectivity Center hub:

  • The first VPC network has a subnet whose primary internal IPv4 address range is 100.64.0.0/16, resulting in a subnet route for 100.64.0.0/16.
  • The second VPC network has a subnet with a secondary internal IPv4 address range of 100.64.0.0/24, resulting in a subnet route for 100.64.0.0/24.

The two subnet routes have conflicting subnet IP address ranges because 100.64.0.0/24 fits within 100.64.0.0/16. You cannot connect both networks as VPC spokes to the same Network Connectivity Center hub unless you resolve the conflict. You can use one of the following strategies to resolve the conflict:

  • Either exclude the 100.64.0.0/16 IP address range when you attach the first VPC network to the hub, or exclude the 100.64.0.0/24 IP address range when you attach the second VPC network to the hub.
  • Exclude 100.64.0.0/16 or the whole RFC 6598 space, 100.64.0.0/10, when you attach each VPC network.

Interaction with VPC Network Peering subnet routes

Peering subnet routes are those that are exchanged between VPC networks connected using VPC Network Peering. Even though peering subnet routes are never exchanged among VPC spokes connected to a Network Connectivity Center hub, you still need to take peering subnet routes into consideration. From the perspective of each VPC spoke, all local subnet routes, imported peering subnet routes, and imported Network Connectivity Center subnet routes cannot conflict.

To illustrate this concept, consider the following configuration:

  • VPC network net-a is a VPC spoke connected to a Network Connectivity Center hub.
  • VPC network net-b is a VPC spoke connected to the same Network Connectivity Center hub.
  • VPC networks net-b and net-c are connected to each other using VPC Network Peering.

Suppose that a local subnet IP address range for 100.64.0.0/24 exists in net-c. This creates a local subnet route in net-c and a peering subnet route in net-b. Even though the peering subnet route for the 100.64.0.0/24 IP address range is not exported into the Network Connectivity Center hub, its existence in net-b prevents net-b from being able to import a Network Connectivity Center route whose destination exactly matches 100.64.0.0/24, fits within 100.64.0.0/24, or contains 100.64.0.0/24. Consequently, no local subnet routes for 100.64.0.0/24, 100.64.0.0/25, or 100.64.0.0/16 can exist in net-a unless you configure net-a to not export the conflicting range.

Route tables that show subnet routes

Google Cloud shows Network Connectivity Center subnet routes imported from VPC spokes in two route tables:

Google Cloud automatically updates the VPC network route table of each VPC spoke and the Network Connectivity Center hub route table when one of the following conditions is met:

In VPC network route tables, each imported route from other VPC spokes appears as a Network Connectivity Center subnet route whose next hop is the Network Connectivity Center hub. These Network Connectivity Center subnet routes have names that begin with the ncc-subnet-route- prefix. To see the actual next hop for an imported Network Connectivity Center subnet route, you can view the Network Connectivity Center hub route table or you can view the VPC network route table of the VPC spoke that exports the subnet route into the Network Connectivity Center hub.

For more information about VPC routes, see Routes in the VPC documentation.

What's next