[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-08-12。"],[],[],null,["# Spoke administration overview\n\nThis page provides an overview from the perspective of a\nVirtual Private Cloud (VPC) spoke administrator.\n\nIf the Network Connectivity Center hub and VPC spoke are in the same\nproject, VPC spoke administrators must have both of the\nfollowing Identity and Access Management (IAM) bindings on that project:\n\n- The [Compute Network Admin role\n (`roles/compute.networkAdmin`)](/compute/docs/access/iam#compute.networkAdmin).\n\n- The [Network Connectivity Center Spoke Admin role\n (`roles/networkconnectivity.spokeAdmin`)](/network-connectivity/docs/network-connectivity-center/concepts/access-control#networkconnectivity.spokeAdmin).\n\nIf the Network Connectivity Center hub and VPC spoke are in different\nprojects, IAM policies must have the following bindings.\n\n- VPC spoke administrators must have both of the following\n IAM bindings on the project that contains the\n VPC network (spoke):\n\n - The [Compute Network Admin role\n (`roles/compute.networkAdmin`)](/compute/docs/access/iam#compute.networkAdmin).\n - The [Network Connectivity Center spoke administrator role\n (`roles/networkconnectivity.spokeAdmin`)](/network-connectivity/docs/network-connectivity-center/docs/network-connectivity-center/concepts/access-control#networkconnectivity-roles).\n- VPC spoke administrators must also have both of the following\n IAM bindings on the Network Connectivity Center hub or on the project\n that contains the Network Connectivity Center hub:\n\n - The [Network Connectivity Center Group User role\n (`roles/networkconnectivity.groupUser`)](/network-connectivity/docs/network-connectivity-center/concepts/access-control#networkconnectivity.groupUser).\n - The [Network Connectivity Center Hub \\& Spoke Viewer role\n (`roles/networkconnectivity.hubViewer`)](/network-connectivity/docs/network-connectivity-center/concepts/access-control#networkconnectivity.hubViewer).\n\nYou can also use custom roles as long as the custom role includes the same\npermissions as the predefined roles listed earlier.\n\nWhen a VPC network and the Network Connectivity Center hub are located in\ndifferent projects, a VPC spoke administrator must create a spoke\nproposal to request that a VPC network join the hub. A hub\nadministrator reviews the proposal. If the hub administrator accepts the\nproposal, the VPC network is connected to the hub. A hub\nadministrator can also reject spoke proposals. Spoke administrators can check\nthe status of a VPC spoke proposal at any time.\n\nYou can propose updates to an existing VPC spoke to change the\nset of subnet ranges that are exported to hub route tables.\n\nFor more information, see the following sections.\n\n- [Propose a VPC spoke in a different project](/network-connectivity/docs/network-connectivity-center/how-to/vpc-propose-a-spoke)\n- [Check the status of a VPC spoke](/network-connectivity/docs/network-connectivity-center/how-to/vpc-check-spoke-status)\n- [View the VPC route table](/network-connectivity/docs/network-connectivity-center/how-to/vpc-view-route-table)\n- [VPC spokes overview](/network-connectivity/docs/network-connectivity-center/concepts/vpc-spokes-overview)\n- [Change exported subnet address ranges](/network-connectivity/docs/network-connectivity-center/how-to/working-with-hubs-spokes#update-spoke-export-ranges) ([Preview](/products#product-launch-stages))\n\nSubnet route uniqueness\n-----------------------\n\nSimilar to VPC Network Peering, Google Cloud prohibits subnet IP\naddress range conflicts among VPC spokes connected to a\nNetwork Connectivity Center hub. A subnet IP address range *conflicts* with another\nsubnet IP address range when one of the following is true:\n\n- A subnet IP address range in one VPC network *exactly matches* a subnet IP address range in another VPC network.\n- A subnet IP address range in one VPC network *fits within* a subnet IP address range in another VPC network.\n- A subnet IP address range in one VPC network *contains* a subnet IP address range in another VPC network.\n\nVPC spokes can't export conflicting subnet IP address ranges\ninto the same Network Connectivity Center hub. You can use the [`exclude-export-ranges`\nflag](/sdk/gcloud/reference/network-connectivity/spokes/linked-vpc-network/create#--exclude-export-ranges)\nin the Google Cloud CLI or the `excludeExportRanges` field in the API to prevent\na subnet IP address range from being shared from a VPC spoke into\na Network Connectivity Center hub. For example, suppose you have two VPC\nnetworks that you want to connect to the same Network Connectivity Center hub:\n\n- 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.\n- 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.\n\nThe two subnet routes have conflicting subnet IP address ranges because\n100.64.0.0/24 fits within 100.64.0.0/16. You can't connect both networks\nas VPC spokes to the same Network Connectivity Center hub unless you\nresolve the conflict. You can use one of the following strategies to resolve the\nconflict:\n\n- 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.\n- Exclude 100.64.0.0/16 or the whole [RFC\n 6598](https://tools.ietf.org/html/rfc6598) space, 100.64.0.0/10, when you attach each VPC network.\n\n### Interaction with VPC Network Peering subnet routes\n\n[Peering subnet routes](/vpc/docs/routes#peering-subnet-routes) are those that\nare exchanged between VPC networks connected using\nVPC Network Peering. Even though peering subnet routes are never exchanged\namong VPC spokes connected to a Network Connectivity Center hub, you still\nneed to take peering subnet routes into consideration. From the perspective of\neach VPC spoke, all local subnet routes, imported peering subnet\nroutes, *and* imported Network Connectivity Center subnet routes can't conflict.\n\nTo illustrate this concept, consider the following configuration:\n\n- VPC network `net-a` is a VPC spoke connected to a Network Connectivity Center hub.\n- VPC network `net-b` is a VPC spoke connected to the same Network Connectivity Center hub.\n- VPC networks `net-b` and `net-c` are connected to each other using VPC Network Peering.\n\nSuppose that a local subnet IP address range for 100.64.0.0/24 exists in\n`net-c`. This creates a local subnet route in `net-c` *and* a peering subnet\nroute in `net-b`. Even though the peering subnet route for the 100.64.0.0/24\nIP address range is not exported into the Network Connectivity Center hub, its existence\nin `net-b` prevents `net-b` from being able to import a Network Connectivity Center\nroute whose destination exactly matches 100.64.0.0/24, fits within\n100.64.0.0/24, or contains 100.64.0.0/24. Consequently, no local subnet\nroutes for 100.64.0.0/24, 100.64.0.0/25, or 100.64.0.0/16 can exist in\n`net-a` *unless* you configure `net-a` to not export the conflicting range.\n\nRoute tables that show subnet routes\n------------------------------------\n\nGoogle Cloud shows Network Connectivity Center subnet routes imported from\nVPC spokes in two route tables:\n\n- The [Network Connectivity Center hub route\n table](/network-connectivity/docs/network-connectivity-center/concepts/vpc-hub-admin#hub-route-table).\n- The [VPC network route\n table](/vpc/docs/using-routes#listingroutes) for each VPC (spoke) network.\n\nGoogle Cloud automatically updates the VPC network route\ntable of each VPC spoke and the Network Connectivity Center hub route\ntable when one of the following conditions is met:\n\n- When you perform [a subnet route lifecycle\n activity](/vpc/docs/routes#subnet-lifecycle), like adding or deleting a subnet.\n- When VPC spokes are added to or removed from the hub.\n\nIn VPC network route tables, each imported route from other\nVPC spokes appears as a *Network Connectivity Center subnet route* whose\nnext hop is the Network Connectivity Center hub. These Network Connectivity Center subnet routes\nhave names that begin with the `ncc-subnet-route-` prefix. To see the actual\nnext hop for an imported Network Connectivity Center subnet route, you can [view the\nNetwork Connectivity Center hub route\ntable](/network-connectivity/docs/network-connectivity-center/how-to/vpc-view-hub-route-table) or you can [view the\nVPC network route\ntable](/vpc/docs/using-routes#listingroutes) of the VPC spoke\nthat exports the subnet route into the Network Connectivity Center hub.\n\nFor more information about VPC routes, see\n[Routes](/vpc/docs/routes) in the VPC documentation.\n\nWhat's next\n-----------\n\n- To create hubs and spokes, see [Work with hubs and spokes](/network-connectivity/docs/network-connectivity-center/how-to/working-with-hubs-spokes).\n- To create a spoke in a project different from the hub, see [Propose a VPC spoke in a different project](/network-connectivity/docs/network-connectivity-center/how-to/vpc-propose-a-spoke).\n- To view a list of partners whose solutions are integrated with Network Connectivity Center, see [Network Connectivity Center partners](/network-connectivity/docs/network-connectivity-center/partners).\n- To find solutions for common issues, see [Troubleshooting](/network-connectivity/docs/network-connectivity-center/support/troubleshooting).\n- To get details about API and `gcloud` commands, see [APIs and reference](/network-connectivity/docs/network-connectivity-center/apis)."]]
