Assigned
Status Update
Comments
go...@google.com <go...@google.com> #2
I would like to add on to this
It would be great to have tags be applied at the VPC subnet level as stated. I have two major reasons as to why this would be an excellent addition.
1. When using a Shared VPC design, one of the key sellers is that admins can maintain rules and networking all from the Host project. The flaw with no subnet tags is that users in service must create their own tags. This causes an issue at point 2..
2) Using network tags in firewall rules is the best way to make granular rules. However if a user can control the network tags from their service project that causes an issue with consistency amongst the org. Having subnet level tags can enforce that I continue to use the network tag option in firewall rules as the target and network admins maintain that control and consistency. Also if I have many subnetworks in a VPCs i can have a firewall rule for a specific subnet instead of instance tags which is a problem when service account users have that control.
It would be great to have tags be applied at the VPC subnet level as stated. I have two major reasons as to why this would be an excellent addition.
1. When using a Shared VPC design, one of the key sellers is that admins can maintain rules and networking all from the Host project. The flaw with no subnet tags is that users in service must create their own tags. This causes an issue at point 2..
2) Using network tags in firewall rules is the best way to make granular rules. However if a user can control the network tags from their service project that causes an issue with consistency amongst the org. Having subnet level tags can enforce that I continue to use the network tag option in firewall rules as the target and network admins maintain that control and consistency. Also if I have many subnetworks in a VPCs i can have a firewall rule for a specific subnet instead of instance tags which is a problem when service account users have that control.
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: