[[["易于理解","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,["# Hub administration overview\n\nThis page provides an overview of the [Network Connectivity Center hub administrator role\n(`roles/networkconnectivity.hubAdmin`)](/network-connectivity/docs/network-connectivity-center/concepts/access-control#networkconnectivity-roles).\nAn Identity and Access Management (IAM) principal who has the hub administrator role can\ndo the following:\n\n- [Create a hub](/network-connectivity/docs/network-connectivity-center/how-to/vpc-configure-hub) and create Virtual Private Cloud (VPC) spokes for VPC networks that are in the same project as the hub.\n- [Give access to spoke administrators](/network-connectivity/docs/network-connectivity-center/how-to/vpc-give-access) so they can create VPC spoke proposals for VPC networks located in different projects.\n- [Review, accept, and reject VPC spoke\n proposals](/network-connectivity/docs/network-connectivity-center/how-to/vpc-review-proposed-spokes) or [set up *auto-accept* for spoke groups](/network-connectivity/docs/network-connectivity-center/how-to/vpc-review-proposed-spokes#manage_auto-accept_for_spoke_groups).\n- [View hub route tables](/network-connectivity/docs/network-connectivity-center/how-to/vpc-view-hub-route-table).\n\nCustom roles can also be used if they at least include the same permissions of\nthe Network Connectivity Center hub administrator role.\n\nHow VPC spokes join a hub\n-------------------------\n\nIf a VPC network and a Network Connectivity Center hub are located in the\nsame project, creating a VPC spoke for the VPC\nnetwork immediately establishes connectivity to the hub without any additional\nsteps.\n\nIf a VPC network and a Network Connectivity Center hub are located in\ndifferent projects, the process for creating a VPC spoke is as\nfollows:\n\n1. A hub administrator establishes IAM policy bindings that let spoke administrators in other projects create VPC *spoke\n proposals* . Note: Hub administrators can change IAM policy bindings at any time. For example, a hub administrator might revoke access later, preventing a spoke administrator from creating additional spoke proposals. This is true when [auto-accept](#auto-accept-projects) for spokes is not enabled.\n2. During hub creation, the hub administrator chooses the connectivity topology between the default mesh topology and star topology.\n3. A spoke administrator [proposes a VPC\n spoke](/network-connectivity/docs/network-connectivity-center/how-to/vpc-propose-a-spoke). If the spoke proposal is for a hub that is configured to use the star topology, the spoke administrator assigns the spoke to either the *center* or the *edge* group. For mesh topology, all spokes belong to the single default group.\n4. A hub administrator reviews each spoke proposal, and then accepts or rejects the proposal. The following describes how hub connectivity works following accepting or rejecting a proposal:\n - A spoke becomes active only after a hub administrator accepts the spoke proposal. Network Connectivity Center only provides network connectivity to active spokes.\n - A hub administrator can reject a previously accepted VPC spoke, making the spoke inactive. When a previously active VPC spoke becomes inactive, Network Connectivity Center does not provide network connectivity to the spoke.\n\nHow spoke update proposals work\n-------------------------------\n\nWhen a VPC or a producer\nVPC spoke exists in a project different from the hub, a hub\nadministrator must accept or reject update proposals unless auto-accept for\nspokes is enabled. These spoke updates can be changes to the include or\nexclude IPv4 subnet ranges ([Preview](/products#product-launch-stages)).\n\nFor more information about updating\nspokes, see [Update a spoke](/network-connectivity/docs/network-connectivity-center/how-to/working-with-hubs-spokes#update-spoke).\n\n### Auto-accept projects\n\nA hub administrator can enable auto-accept for spoke groups in a hub.\nWhen enabled, VPC spokes located in the auto-accept projects\nlist are added or updated immediately after the VPC spoke\ncreation or update proposal. Manual review and approval from a hub\nadministrator is skipped.\n\nThe hub route table\n-------------------\n\nThe hub route table shows subnet routes imported from the VPC\nspokes. When a new VPC spoke is created, all *local* subnet\nroutes from the VPC network are exported to the hub *unless*\nthe spoke administrator uses 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. For more\ninformation, see [subnet route\nuniqueness](/network-connectivity/docs/network-connectivity-center/concepts/vpc-spoke-admin#subnet-uniqueness).\n\nWhen you create a new VPC spoke, the following occurs:\n\n- A spoke *belongs* to exactly one group.\n- Each group has a corresponding route table.\n- Spokes are *associated* with that route table.\n- Spoke subnets are *propagated* to one or more route tables.\n\nBecause there is only one default group in a mesh topology connectivity, the\nsubnet routes are propagated to a single hub route table. Spokes connected to a\nhub that supports star topology\nbelong to one of two different groups, namely, *center* and *edge* .\nSo, two hub route tables are generated, one associated with each\nspoke group. Spokes in the center group have their subnet routes *propagated*\nto the center and edge route tables. Spokes in the edge group have their subnet\nroutes *propagated* to the center route table.\n\nFor detailed information about connectivity topologies, see\n[Preset connectivity topologies](/network-connectivity/docs/network-connectivity-center/concepts/connectivity-topologies).\n\nGoogle Cloud automatically updates the VPC network route\ntable of each VPC spoke and the Network Connectivity Center hub route\ntable when any of the following occur:\n\n- You perform [a subnet lifecycle activity](/vpc/docs/routes#subnet-lifecycle), such as adding or deleting a subnet.\n- You add or remove VPC spokes from the hub.\n\nFor more information, see [Route tables that show subnet\nroutes](/network-connectivity/docs/network-connectivity-center/concepts/vpc-spoke-admin#vpc-route-table)\nand [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 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 Router appliance issues, see [Troubleshooting](/network-connectivity/docs/network-connectivity-center/support/troubleshooting#troubleshooting-ra).\n- To get details about API and `gcloud` commands, see [APIs and reference](/network-connectivity/docs/network-connectivity-center/apis)."]]
