Status Update
Comments
go...@google.com <go...@google.com> #2
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).
Description
I'd like to have the route selection algorithm modified for a situation where more than one route can be applied with
- the same destination
- the same priority
- next-hop type of forwardingRule
by adding following steps:
- if any of the route next hops is in the same region as the traffic source - pick one of those routes
- else if any of the routes points to ILB with global access disabled - delete those routes from the list of potentially usable ones
- select route with next hop closest geographically to the traffic source
It is important that the solution works for:
- simple VPCs
- shared VPCs
- peered VPCs
Obviously the whole algorithm is applicable only for traffic initiated from VM, return packets for connections received by the VM should follow the same return path as the original packet.
Currently available alternative solution (described here: