Status Update
No update yet.
Comments
ch...@google.com
ch...@google.com
To solve this problem, create the two routes with different priorities, like this:
Route1: Destination:0.0.0.0/0<-------> Next hop: ILB(IN us-east1) <------> Priority:950
Route2: Destination:0.0.0.0/0<-------> Next Hop: ILB(IN us-west1) <------> Priority:951
As long as the forwarding rules aren't configured to be
From the perspective of us-west1, this route is available:
Route2: Destination:0.0.0.0/0<-------> Next Hop: ILB(IN us-west1) <------> Priority:951
From the perspective of us-east1, this one is available:
Route1: Destination:0.0.0.0/0<-------> Next hop: ILB(IN us-east1) <------> Priority:950
It doesn't matter that these have different priorities in the route table because only one is "active" in each region (as long as global access isn't configured).
ge...@google.com
Here's a quick update on this:
For VPC network peering, we have no plans to introduce transitive routing as described in
Our solutions to the transitive routing needs are two-fold:
-
Network Connectivity Center (NCC) VPC spokes:
https://cloud.google.com/network-connectivity/docs/network-connectivity-center/concepts/vpc-spokes-overview - Any VPC network connected to the hub can communicate with any other VPC network. At present, we only support the exchange of IPv4 subnet routes when using NCC VPC spokes, but the product will mature over time to provide functionality that matches what's possible with VPC network peering... while offering transitive routing among all networks on the hub.
-
Private Service Connect for managed services:
https://cloud.google.com/vpc/docs/about-accessing-vpc-hosted-services-endpoints - Service producers "export" a service attachment, and customers can create one or more forwarding rules (endpoints) that reference the same service attachment. This is a better solution than using private services access (which depends on VPC network epering).
Description
Please describe your requested enhancement. Good feature requests will solve common problems or enable new use cases.
What you would like to accomplish:
Transitivity between VPC peering.
How this might work:
When creating a hub & spoke infrastructure using VPC peering, we find some issues when trying to expose managed services like Apigee, Cloud SQL, etc.
Having transitive peering could make it easy to connect all the infrastructure in a hub & spoke design.
If applicable, reasons why alternative solutions are not sufficient:
At this moment some solutions are:
- Using Cloud VPN. Depending on the traffic, security policies, etc. this solution might be not a right solution.
- Creating a peering between the hub VPC and a VPC with all the Google Managed services. This will solve the transitivity issue, but can change some components on the initial infrastructure.
- Creating a network appliance. You could use a router appliance between the 2 peerings in order to route the traffic. This is not a Cloud native solution and you need to take care of your VM's, licenses, etc.