IssueTracker

This feature request enhances a use case where one deploys workloads to multiple regions and chooses to use 3rd party network appliances (as VMs) for filtering/inspecting/logging outbound traffic. One-region scenario is well documented by multiple vendors leveraging constructs like ILB as next hop (for scalability and/or HA) and custom route export over VPC peering. Where this approach fails short though is when there's more than one region and more than one group of firewall appliances. As it's a common practice to use as little as possible VPCs/XPCs, the custom routes for multiple regional firewall groups are added to the same VPC and the active route is decided by internal algorithm (not accessible to infrastructure administrator). This also applies regardless of global access setting (if it's disabled the route might still be selected for any VM globally and the packets might be dropped).

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: https://medium.com/@ozcosta/google-cloud-networking-ilb-as-next-hop-with-tags-ab5f30a0e0c3) uses network tags and routes selecting by tag, but it is highly error-prone and depends on the routes added to all peered VPCs (vs a single route exported from "hub") and on proper tagging of the VMs.