ハイブリッド スポークで Private Service Connect の伝播が機能するようにするには、ルーティング VPC ネットワークを VPC スポークとしても追加する必要があります。
スポークの作成後に、スポークに対する --exclude-export-ranges フィルタを変更することはできません。このため、Private Service Connect エンドポイントをホストする 2 つのサブネットを作成することをおすすめします。1 つは VPC 内ネットワーク専用の Private Service Connect エンドポイント用のサブネット、もう 1 つはハブと共有する Private Service Connect エンドポイント用のサブネットです。VPC ネットワークをスポークとしてハブに追加する場合は、VPC 内ネットワーク専用の VPC ネットワークをホストするサブネットの IP アドレス範囲を --exclude-export-ranges フィルタに追加して、ハブと共有されないようにします。
VPC スポークのサブネットが、Network Connectivity Center ハブにアクセスするように Private NAT を使用して構成されている場合、そのサブネットから伝播 Private Service Connect サービスへのトラフィックは破棄されます。--nat-all-subnet-ip-ranges を使用して Private NAT ゲートウェイが構成されている場合、Network Connectivity Center を介した Private Service Connect の伝播は、このスポーク VPC 内のすべてのサブネットで機能しません。この VPC スポークの重複しないサブネットから伝播を機能させるには、Private NAT ゲートウェイに --nat-custom-subnet-ip-ranges を使用します。NAT を使用して、重複しないサブネットから Network Connectivity Center ハブにトラフィックをルーティングしないでください。
Private Service Connect エンドポイントを短期間で作成、削除、再作成すると、伝播ステータスが正確でなくなる可能性があります。ただし、しばらくすると、伝播ステータスは正確になり、伝播接続の実際の状態が反映されます。これには最大で 15 分かかることがあります。
Private Service Connect 接続の伝播は、スポークの作成後または削除後に非同期になります。VPC スポークがハブから削除されると、Private Service Connect の伝播接続の更新に時間がかかることがあります。Private Service Connect の伝播接続の更新が進行中である場合、VPC スポークが新しいハブに追加された後も、VPC ネットワーク内の VM からのトラフィックがバックエンドに流れることがあります。バックエンドへのトラフィック フローを避けるには、スポークを別のハブに追加する前に、ソーススポークかターゲット スポークかを問わず、以前のハブの VPC ネットワークの伝播ステータス エントリがすべて削除されていることを確認します。
Private Service Connect 接続の伝播ステータス
Network Connectivity Center を使用すると、Network Connectivity Center ハブ内の Private Service Connect 接続の伝播ステータスを表示できます。ステータスの概要を表示したり、特定のエラーをドリルダウンしてエラーの詳細を確認したりできます。
ターゲット スポークの VPC ネットワークまたはプロジェクトが、プロデューサーによって設定された伝播接続の上限を超えたため、Private Service Connect 接続の伝播に失敗しました。この問題に対処するには、プロデューサーのドキュメントを参照するか、サポートチームにお問い合わせください。
Error, producer NAT IP space exhausted
NAT IP サブネット空間が使い果たされたため、Private Service Connect 接続の伝播に失敗しました。これは PSC 接続の Needs attention ステータスと同等です。詳細については、Private Service Connect のドキュメントの接続ステータスをご覧ください。
Error, producer quota exceeded
プロデューサー VPC ネットワークの PSC_ILB_CONSUMER_FORWARDING_RULES_PER_PRODUCER_NETWORK 割り当てを超えたため、Private Service Connect 接続の伝播に失敗しました。
Error, consumer quota exceeded
コンシューマー VPC ネットワークの PSC_PROPAGATED_CONNECTIONS_PER_VPC_NETWORK 割り当てを超えたため、Private Service Connect 接続の伝播に失敗しました。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-08-21 UTC。"],[],[],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)."]]
