An enterprise organization operates a central Hub VPC network connected to on-premises datacenters via Dedicated Interconnect using Cloud Routers configured with global dynamic routing. Two independent spoke VPC networks (Spoke-A and Spoke-B) maintain VPC Network Peering connections to the central Hub VPC network to reach shared services. Software components deployed in Spoke-A now require direct, low-latency private connectivity to backend instances located in Spoke-B. However, network traffic initiated from Spoke-A fails to reach Spoke-B endpoints. Which network topology modification should you implement to enable communication between Spoke-A and Spoke-B according to Google Cloud networking rules?
- Configure a direct VPC Network Peering connection between Spoke-A and Spoke-B networks.Answer
- BEnable custom dynamic route advertisements on the Hub VPC Cloud Routers to forward Spoke-B subnets across existing peering links to Spoke-A.
- CReplace the Dedicated Interconnect connection with an HA VPN Gateway in the Hub VPC to enable BGP route reflection across peered networks.
- DInclude Spoke-A and Spoke-B in a single VPC Service Controls perimeter so that network traffic is automatically routed across the Hub VPC.
Answer
Establish a direct VPC Network Peering connection between Spoke-A and Spoke-B.
Google Cloud VPC Network Peering is non-transitive. If VPC network A is peered with VPC network B, and VPC network B is peered with VPC network C, workloads in network A cannot reach workloads in network C through network B. To allow workloads in Spoke-A to reach backend workloads in Spoke-B over internal IP addresses, a direct VPC Network Peering connection between Spoke-A and Spoke-B must be established.
Step-by-Step Solution
Key Concept
VPC Network Peering Non-Transitivity