Question

A financial services company has three VPC networks: a central 'shared-services' VPC hosting logging and monitoring appliances, and two application VPCs ('app-prod' and 'app-dev'). The network team creates VPC Network Peering between shared-services and app-prod, and between shared-services and app-dev. They now report that app-prod instances cannot reach app-dev instances, even though both peer with shared-services. They want app-prod and app-dev to communicate while keeping the central VPC model. What is the correct explanation and recommended action?

Accepted Answer

VPC Network Peering is non-transitive; add a direct peering between app-prod and app-dev, or adopt Network Connectivity Center with VPC spokes to enable hub-and-spoke transitivity.

Answer

Peering is transitive by default but requires enabling the 'export custom routes' flag on the shared-services VPC to propagate routes between spokes.

Answer

The issue is caused by overlapping subnet ranges; re-IP one application VPC and the peered routes will automatically allow transit through shared-services.

Answer

Configure a Cloud Router in shared-services to advertise dynamic routes between the two application VPCs, enabling transitive reachability.