[[["易于理解","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,["# Private Service Connect connection propagation through Network Connectivity Center\n\n[Private Service Connect](/vpc/docs/private-service-connect)\nlets *consumers* access *managed services* privately from\ninside their Virtual Private Cloud (VPC) network. Similarly, it lets managed service\n*producers* host these services in their own separate VPC\nnetworks and projects and offer a private connection to their consumers.\nPrivate Service Connect connections aren't transitive between\nVPC spokes. The\npropagation of Private Service Connect services through the\nNetwork Connectivity Center hub enables these services to be reachable by any other\nspoke VPC in the same hub through the route table.\n\nNetwork Connectivity Center also supports regional endpoint propagation. For more\ninformation about regional endpoints, see\n[About accessing regional endpoints through Private Service Connect endpoints](/vpc/docs/about-accessing-regional-google-apis-endpoints).\n\nThe Network Connectivity Center Private Service Connect connection\npropagation feature benefits the following use cases:\n\n- You can use a common services VPC network to create multiple\n Private Service Connect consumer endpoints. By adding a single\n common services VPC network to the Network Connectivity Center hub, all\n Private Service Connect consumer endpoints in the VPC\n network become transitively accessible to other VPC spokes\n through the Network Connectivity Center hub. This connectivity eliminates the need to\n individually manage each Private Service Connect endpoint in\n each VPC network.\n\n- You can access managed services in a VPC spoke network from\n on-premises networks that are reachable by hybrid spokes.\n\nWhen you connect a VPC spoke to a hub that has propagated\nconnections enabled, Network Connectivity Center creates propagated\nconnections in that spoke for any endpoints that are\nattached to the same hub, unless the endpoint's subnet is excluded from being\nexported. After a VPC network is added to a Network Connectivity Center\nhub as a VPC spoke, new Private Service Connect\nendpoints are also propagated, unless the endpoint's subnet is excluded from\nexport.\n\nTo set up a hub with a Private Service Connect propagated connection\nenabled, the hub administrator must [create a hub](/network-connectivity/docs/network-connectivity-center/how-to/vpc-configure-hub)\nwith Private Service Connect propagation or update the\npropagation setting by using the\n`--export-psc` flag. Then the hub administrator must\nadd the VPC networks as spokes to the hub. The spoke owner\ncan use the `--exclude-export-ranges` and `--include-export-ranges` flags to exclude specific\nPrivate Service Connect allocated subnets from the\nNetwork Connectivity Center routing so that specified subnets can't be reached from other\nVPC networks, thus keeping them private to the local\nVPC network.\n| **Note:** Connections are propagated asynchronously and could take up to 24 hours to propagate.\n\nFor information about Private Service Connect propagated\nconnections, see [About propagated connections](/vpc/docs/about-propagated-connections).\n\nFor information about the `--exclude-export-ranges` and\n`--include-export-ranges` flags, see [VPC connectivity with export filters](/network-connectivity/docs/network-connectivity-center/concepts/vpc-spokes-overview#vpc-connectivity-with-export-filters).\n\nFor detailed information about setting up a hub for a Private Service Connect\npropagated connection, see [Configure a hub](/network-connectivity/docs/network-connectivity-center/how-to/vpc-configure-hub).\n\nConnection propagation limit\n----------------------------\n\nFor details about propagated connection limits, see\n[Propagated connection limit](/vpc/docs/about-vpc-hosted-services#propagated-connection-limit).\n\nConsiderations\n--------------\n\nConsider the following before you enable a Private Service Connect\npropagated connection:\n\n- A Private Service Connect propagated connection works only with\n VPC spokes.\n\n- Private Service Connect IPv6 propagated connections across\n VPC spokes aren't supported.\n\n- If you need to make propagated Private Service Connect\n connections available to on-premises networks connected to hybrid spokes:\n\n - Your Network Connectivity Center hub must have only one [routing\n VPC\n network](/network-connectivity/docs/network-connectivity-center/concepts/dynamic-route-exchange-with-vpc-spokes#routing-vpc) that contains all of\n its hybrid spokes.\n\n - The hub's single routing VPC network must also be a\n VPC spoke.\n\n If a hub has two or more routing VPC networks, none of the\n routing VPC networks can also be VPC spokes.\n Consequently, hubs with two or more routing VPC networks can't\n make propagated Private Service Connect connections available\n to on-premises networks.\n- For Private Service Connect propagation to work with hybrid\n spokes, the routing VPC network must also be added as a\n VPC spoke.\n\n- Because the `--exclude-export-ranges` filter is not mutable for a spoke after\n the spoke is created, we recommend that you create two subnets to host\n Private Service Connect endpoints---one subnet for\n within-VPC-network-only Private Service Connect\n endpoints and the other for the Private Service Connect\n endpoints shared to the hub. When you add the VPC network to a\n hub as a spoke, add the IP address range of the subnet that hosts the\n within-VPC-network-only VPC network to the\n `--exclude-export-ranges` filter so that it is not shared with the hub.\n\n- Private Service Connect endpoints using privately used public\n IP address ranges aren't propagated to the Network Connectivity Center hub.\n\n- If a subnet in a VPC spoke is configured with Private NAT\n to access the Network Connectivity Center hub, the traffic from the subnet to the\n propagated Private Service Connect service is dropped.\n If the Private NAT gateway is configured with `--nat-all-subnet-ip-ranges`,\n then Private Service Connect propagation through\n Network Connectivity Center doesn't work for all subnets in this spoke\n VPC. To get it to work from non-overlapping subnets of this\n VPC spoke, use `--nat-custom-subnet-ip-ranges` for the\n Private NAT gateway. Don't use NAT to route traffic from\n non-overlapping subnets to the Network Connectivity Center hub.\n\n- The propagation status might be inaccurate if you\n create, delete, and re-create the Private Service Connect\n endpoint within a short timeframe. However, after some time,\n the propagation status becomes accurate and reflects the actual state of the\n propagated connection. This could take up to 15 minutes.\n\n- Private Service Connect connection propagation is asynchronous\n after spoke creation or deletion. When a VPC spoke is removed\n from a hub, it can take some time to update propagated\n Private Service Connect connections. While the\n Private Service Connect propagation connection update is\n in progress, traffic from the VM within the VPC network can flow to\n the backend, even after the VPC spoke is added to a new hub.\n To avoid traffic flow to the backend, before adding the spoke to another hub,\n make sure that all of the propagation status entries for the\n VPC network in the\n previous hub, whether as a source spoke or a target spoke, are deleted.\n\nPrivate Service Connect connection propagation status\n-----------------------------------------------------\n\nNetwork Connectivity Center lets you view the status of the\nPrivate Service Connect connection propagation within a\nNetwork Connectivity Center hub.\nYou can view a summary of statuses or drill down on specific\nerrors to view error details.\n\nThe following table lists the propagation status codes and what they mean.\n\nFor information about how to view Private Service Connect\nconnection propagation statuses, see\n[View the Private Service Connect connection propagation status](/network-connectivity/docs/network-connectivity-center/how-to/working-with-hubs-spokes#view-psc-propagation-status). For\nPrivate Service Connect connection propagation troubleshooting\ninformation, see [Troubleshoot Private Service Connect connection propagation errors](/network-connectivity/docs/network-connectivity-center/support/troubleshooting#troubleshoot-psc-propagation-errors).\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 common issues, see [Troubleshooting](/network-connectivity/docs/network-connectivity-center/support/troubleshooting).\n- To get details about API and Google Cloud CLI commands, see [APIs and reference](/network-connectivity/docs/network-connectivity-center/apis)."]]
