Obsolete
Status Update
Comments
ra...@google.com <ra...@google.com>
ra...@google.com <ra...@google.com>
te...@google.com <te...@google.com>
te...@google.com <te...@google.com>
am...@google.com <am...@google.com>
am...@google.com <am...@google.com> #2
Hello Kévin
Thank you for contacting Google Cloud Platform Support. I understand you are having an issue with internal load balancing and I will do my best to advise you.
Internal load balancers are regional resources, the scope of an internal TCP/UDP load balancer is regional, not global. This means that an internal TCP/UDP load balancer cannot span multiple regions. Within a single region, the load balancer services all zones. [1]
A feature request exists to enable an internal load balancer which can handle requests from multiple regions[2]. But I can neither provide you with an ETA for its implementation, nor a guarantee that it will ever be supported. If you would like to create your own feature request, follow the link to Google issue tracker to search or create feature request [3].
Your VMs are able to talk to each other from one region to another as they are connected through the same VPC. Resources within a VPC network can communicate with one another using internal (private) IPv4 addresses, subject to applicable network firewall rules.[4] However, for ILB the behaviour is handled differently due to the regional nature of the ILB(s).
The reason VM instances attached to a network with a specific address mask getting assigned IP with /32 mask is a design requirement of GCP. However, let me explain why VM instances are assigned with the /32 mask on Google Compute Engine (GCE). Please note that the /32 is an artificial construct. The instance talks to the software defined network, which creates and manages the "real" subnets. So, it is really a link between the single address and the gateway for the subnet. As long as the link layer is there, communication is established, and everything works.
In addition to that, network masks are enforced at the network layer, not the host layer. This helps avoid generation of unnecessary broadcast traffic (which underlying network wouldn't distribute anyway), this might further clarify why VM instances are assigned with a /32 netmask, when they are attached to a subnet, for example, /24 mask.
I hope that makes things clearer for you. If you have any other questions or concerns about your issue, please do not hesitate to contact me by replying to this message. I will be more than happy to help at that time.
[1]ILB Scope:https://cloud.google.com/load-balancing/docs/internal/#protocols_scheme_and_scope
[2]Feature Request for multi-region ILB:https://issuetracker.google.com/111021512
[3]Create and Search feature requests:https://cloud.google.com/support/docs/issue-trackers#search_and_create_feature_requests_by_product
[4]VPC Specifications:https://cloud.google.com/vpc/docs/vpc#specifications
Thank you for contacting Google Cloud Platform Support. I understand you are having an issue with internal load balancing and I will do my best to advise you.
Internal load balancers are regional resources, the scope of an internal TCP/UDP load balancer is regional, not global. This means that an internal TCP/UDP load balancer cannot span multiple regions. Within a single region, the load balancer services all zones. [1]
A feature request exists to enable an internal load balancer which can handle requests from multiple regions[2]. But I can neither provide you with an ETA for its implementation, nor a guarantee that it will ever be supported. If you would like to create your own feature request, follow the link to Google issue tracker to search or create feature request [3].
Your VMs are able to talk to each other from one region to another as they are connected through the same VPC. Resources within a VPC network can communicate with one another using internal (private) IPv4 addresses, subject to applicable network firewall rules.[4] However, for ILB the behaviour is handled differently due to the regional nature of the ILB(s).
The reason VM instances attached to a network with a specific address mask getting assigned IP with /32 mask is a design requirement of GCP. However, let me explain why VM instances are assigned with the /32 mask on Google Compute Engine (GCE). Please note that the /32 is an artificial construct. The instance talks to the software defined network, which creates and manages the "real" subnets. So, it is really a link between the single address and the gateway for the subnet. As long as the link layer is there, communication is established, and everything works.
In addition to that, network masks are enforced at the network layer, not the host layer. This helps avoid generation of unnecessary broadcast traffic (which underlying network wouldn't distribute anyway), this might further clarify why VM instances are assigned with a /32 netmask, when they are attached to a subnet, for example, /24 mask.
I hope that makes things clearer for you. If you have any other questions or concerns about your issue, please do not hesitate to contact me by replying to this message. I will be more than happy to help at that time.
[1]ILB Scope:
[2]Feature Request for multi-region ILB:
[3]Create and Search feature requests:
[4]VPC Specifications:
mb...@gmail.com <mb...@gmail.com> #3
Thanks for your quick reply on ILB and thank you also for details on networking on gcp.
I hope that this feature requesthttps://issuetracker.google.com/111021512 will be considered :).
I am surprised that it has been designed like this because it's a pretty big drawbacks compared to AWS for example.
Do you know if there is another solution for me to interconnect local service to another region except create loadbalancer in a dedicated instance ?
Thanks in advance,
Kévin
I hope that this feature request
I am surprised that it has been designed like this because it's a pretty big drawbacks compared to AWS for example.
Do you know if there is another solution for me to interconnect local service to another region except create loadbalancer in a dedicated instance ?
Thanks in advance,
Kévin
mo...@gmail.com <mo...@gmail.com> #4
At the time of writing this, creating a dedicated instance which will serve as a load balancer between regions, is the best workable option for this type of scenario.
su...@google.com <su...@google.com> #5
I have the exact same feature request to access ILB from multi regions. It would be great if Google can prioritize this feature. Thanks.
Description