I purchased a GCP VM instance in asia-southeast1 and reserved an external IP in the same region for this.
The instance and IP information that is shown in GCP console seems to be okay but when I deploy my website into it, the response is really slow.
My static IP
VM instance
So I lookup my IP and the tool show my IP is from US
IP lookup result
I am not sure what wrong with my IP or instance, I am new in GCP please help. Thank you.
Asked
Active
Viewed 1,770 times
1
-
Possible duplicate of [Why do Google Cloud Platform static IP addresses list Mountain View, CA in reverse lookup regardless of region assignment?](https://stackoverflow.com/questions/41988170/why-do-google-cloud-platform-static-ip-addresses-list-mountain-view-ca-in-rever) – mensi Dec 05 '18 at 22:05
3 Answers
1
If I search the whois data for external IP address of a Virtual Machines in GCP zone asia-southeast1 I can see that the address points to Google's headquarters in Mountain View, CA. The whois data has no indication of where in the world the actual hardware is located...
Many external Geo IP services depend on a SWIP database. Most of Google IP's are SWIP'ed to be Mountain View, CA. That means a VM living in a datacenter outside of the U.S. might show a linked U.S. IP address, as in your case. I suspect that most of Google's addresses will be originally US allocated.
astro8891
- 502
- 2
- 7
- 18
-
I got you but the problem is the response is too slow from this IP although my instance is in Singapore (zone *asia-southeast1*). I have the same website on the equivalent AWS instance, fast response. In this cloud platform I never faced any problem like this before. – BinhTran Mar 28 '18 at 03:49
-
As mentioned above, go to VPC Network -> External IP addresses -> Reserve static address and you can choose the region where the external IP will be located, this should improve latency. – astro8891 Mar 28 '18 at 20:47
-
@binhtran Did this really solve the problem? Doesn't seem like it to me. Astro: the OP mentions in the question that the ip is in their region so that's not the problem. – Oliver Mar 29 '18 at 14:07
-
Not really but it leads me to find out what causes the issue. My problem is not related to the IP at all. This is caused by my DB instance region and connection methods that provided by GCP. You can see my answer below @Oliver – BinhTran Mar 30 '18 at 04:10
-
@binhtran then please accept your own answer, it is ok to do that, you can still leave your upvote on astro's answer since it helped but rit is important to know what actually solved the problem. – Oliver Mar 30 '18 at 05:49
-
That make sense @Oliver but I cannot vote up for astro8891 due to insufficient reputation – BinhTran Mar 30 '18 at 06:31
0
The external IPs that are assigned to Google Cloud customer's projects are from an address block(s) that belongs to Google and is Geolocated there:
# The following results may also be obtained via:
# https://whois.arin.net/rest/nets;q=35.193.232.48?showDetails=true&showARIN=false&showNonArinTopLevelNet=false&ext=netref2
#
NetRange: 35.192.0.0 - 35.207.255.255
CIDR: 35.192.0.0/12
NetName: GOOGLE-CLOUD
NetHandle: NET-35-192-0-0-1
Parent: NET35 (NET-35-0-0-0-0)
NetType: Direct Allocation
OriginAS:
Organization: Google LLC (GOOGL-2)
RegDate: 2017-03-21
Updated: 2018-01-24
Comment: *** The IP addresses under this Org-ID are in use by Google Cloud customers ***
Comment:
Comment: Direct all copyright and legal complaints to
Comment: https://support.google.com/legal/go/report
Comment:
Comment: Direct all spam and abuse complaints to
Comment: https://support.google.com/code/go/gce_abuse_report
Comment:
Comment: For fastest response, use the relevant forms above.
Comment:
Comment: Complaints can also be sent to the GC Abuse desk
Comment: (google-cloud-compliance@google.com)
Comment: but may have longer turnaround times.
Ref: https://whois.arin.net/rest/net/NET-35-192-0-0-1
OrgName: Google LLC
OrgId: GOOGL-2
Address: 1600 Amphitheatre Parkway
City: Mountain View
StateProv: CA
PostalCode: 94043
Country: US
RegDate: 2006-09-29
Updated: 2017-12-21
(...)
That does not mean that your VM's address is responding from Mountain View, if your instance is in Asia. In your case, your instance in asia-southeast1 and is physically located in Singapore.
You can also choose the region for your static external IP, just go to VPC Network -> External IP addresses -> Reserve static address and you can choose the region where the external IP will be located. It will still be displayed as from the US by the whois databases, because it belongs to the Google bloc, but the entry point will be routed in Singapore, that should improve your latency.
0
Thank guys for clarification about the IP, it is not related to my issue. I got confused with GeoIP at first.
After all, I found out that the slow response is caused by 2 things below:
- Database region: My Google Cloud Sql (mysql) region is in Australia because GCP Cloud Database has no server in SEA. I tried to change database region to asia-east (exactly is in Taiwan) and got doubly faster response.
- Connection method: GCP provide 2 ways to connect to its cloud sql: Database External IP (with IP whitelist config) and via Cloud SQL Proxy that both have network latency. I think GCP should support database communication inside a VPC. I am not sure why GCP does not support this way currently.
The response of my website is now better but much slower as compared with the same one I deployed into AWS. In AWS the communication between my App and database is done inside a VPC, no public IP exposed and no network latency. Moreover, AWS database have server in SEA that why AWS is much faster in my case
Response time: GCP vs AWS
BinhTran
- 11
- 7
-
If your app is running within gcp then talking to the DB does not use the external ip, it stays within Google's petabyte network so likely the only issue is region. I'm sure that will change soon. – Oliver Mar 30 '18 at 05:55
-
It does use external IP @Oliver. Agree, I gravitate toward the region as well. Anyway, the reality AWS is specifically better for me than GCP in term of network latency – BinhTran Mar 30 '18 at 06:29
-