All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
OVH Singapore: Weird routing behavior
I have an OVH singapore VPS. I've had it for several months, and it's always shown a peculiar problem.
When you try to access the VPS from various points around the world, the traffic is often handed over to the nearest OVH network.
So, even though the server is in Singapore, and I try to traceroute to it from the US West Coast, the traffic will head to OVH, Canada. From there, it will go to OVH France and from there to Singapore. So, instead of a 170 ms latency, you end up with a 300 ms latency.
Similarly, if I try to ping the Singapore server from some of the ISPs in India, the traffic is handed over to OVH France, and from there, it comes to Singapore.
Does this have to do with
1) poor peering on part of OVH, or
2) some misconfiguration on their network that prevents other networks from 'seeing' the real location of the IP?
3) or some other explanation?
Can I somehow increase the 'visibility' of the IP from my end? I've changed the reverse IP from a '.eu' domain to an international domain. That didn't help.
PS: There are some others also that are similarly affected. But this seems to be the worst case.
Comments
Edited this post like 3 times, can't read lol.
That's how OVH works. They always keep it in house, but there's definitely something wrong with going from Canada to France, seems counterproductive.
The safest bet is to go with either France or Canada, the powerhouse locations. The newer locations don't seem to be as good, usually because it's basically the same shit in a new location routed from an old location (such as OVH BHS -> OVH US).
Send an email on the respective regions OVH mailing list or try emailing one of the network/peering people on the corp.ovh addresses, you can find them around online or check on Twitter for them. They will fix issues like this most of the time when they are made aware. It is annoying but most of the old issues were fixed.
Hot potato routing, your isp will try to hand it over to OVH as soon as possible, which for NA means in Canada. From there, OVH routes it internally and have decided that they prefer to route it via the EU, which makes sense since they have capacity over the Atlantic but probably not over the Pacific.
Try checking with them though.
Not necessarily, they have PoPs across the US too, including Seattle, Palo Alto or LA, going to which would make more sense from West Coast than to Canada.
https://www.ovh.com/world/about-us/network.xml
Enabling their permanent firewall (mitigation) may also force routing through Fr.
It shouldn't, there is now VAC in SG as well.
In any case, better to report such issues to their "traceroute" mailing list.
subscribe: [email protected]
post: [email protected]
I brought this to the attention of their customer service. They took a couple of days to examine it, and finally suggested that I should host in France if I wanted better latency to India, and not in Singapore (or something to that effect.)
Can they really fix it? I'll try emailing them again, but my hopes are not very high.
They're actually on LET now, if you can get ahold of them. Maybe try tagging them. Might get less of a canned reply.
@OVH_APAC
But is that the default behavior for all ISPs? Do they try to hand over to the receiving ISP as soon as possible, without looking at the geolocation of the destination IP? Or is it the case here that the geolocation of the OVH IP is being shown as France (actually if you go by RIR and ASN, it is).
Or do they hand over as soon as possible irrespective of such issues as a standard practice? I have another VPS on Tata. There too, I can see that the ISPs hand over to Tata as soon as possible, but not in Asia.
In other words, if I'm tracerouting from the US or Europe, it is handed over to Tata immediately at those locations. But if I'm tracerouting from Japan, it's not taken to Europe or US, but to India and handed over. That's still acceptable. But in case of OVH, it goes from Asia to Europe to Asia (except from some originating ISPs who are correctly able to locate the destination IP in Singapore and take it all the way to Singapore and hand it over)
Thanks.
If they can only fix this, I can move my production units to them easily.
Hi @elos42,
I agree, this routing is less than ideal and I'm sorry it has become an inconvenience.
OVH is continuously working to improve the network, and this is especially relevant in countries where we are still relatively new. This network improvement includes working with local Internet providers to improve these fixed routes, which are often configured on the side of the ISP.
I need to specify that my intention is not to put blame on others. Routing on the Internet is extremely complex, and sometimes these issues are tricky to resolve because of a poor peering connection from the ISP. Quite often, you can have a good route from OVH to the ISP but the journey back might end up taking a longer path. We're constantly in contact with local providers as we work towards a better integration with the global OVH network.
Over the coming months we plan to add new equipment to improve routing in the Asia region, which will enable us to improve the routing rules. In the mean time, as an OVH customer we encourage you to raise a support ticket so we can collect further information, like your public IP address, that might help us troubleshoot this routing even further and hopefully find a short-term solution.
You can also send a traceroute to our public mailing for further investigation:
If you aren't an OVH customer, simply replace OVH server IP address with "sgp.smokeping.ovh.net".
Thanks for your patience.
Your friends at OVH.
See, now that didn't seem to be a canned response.
That reminds me, when I do traceroute from my VPS to my Indian IP, it goes 'direct' from Singapore to India. But when I ping from my IP to my VPS, it takes the France route.
Apart from peering, could it be something to do with the fact that the Singapore IP is show to belong to Canada? Could this be forcing these non-peered ISPs to route the traffic westward?
I have several VPSes in Singapore from providers like Linode, DO and Upcloud, but none of them show the IP as belonging to another continent. Usually, it's Australia or Singapore.
Can you sort of transfer these IPs from ARIN to APNIC? I believe once these are transferred to APNIC, many of the ISPs will start looking up the IP address in Asia, instead of sending traffic abroad. I am no expert, but this seems logical.
See the results from https://rdpguard.com/free-whois.aspx for your smokeping sgp address (and see Linode and Upcloud results below that).
Notice that the 'country' field is shown as Canada in case of OVH.
-------------- OVH -----------------------
WHOIS Source: ARIN
IP Address: 139.99.127.250
Country: caCanada
Network Name: OVH-CUST-6463783
Owner Name: f1domain.com
CIDR: 139.99.113.32/28
From IP: 139.99.113.32
To IP: 139.99.113.47
Allocated: Yes
Contact Name: OVH Singapore PTE. LTD
Address: 6296 Ash Shuayb Al Balad Jaddah Makkah Saudi Arabia, Jaddah Makkah
Email: [email protected]
Abuse Email: [email protected]
Phone: +1-855-684-5463
Fax:
NetRange: 139.99.0.0 - 139.99.255.255
CIDR: 139.99.0.0/16
NetName: HO-2
NetHandle: NET-139-99-0-0-1
Parent: NET139 (NET-139-0-0-0-0)
NetType: Direct Allocation
OriginAS:
Organization: OVH Hosting, Inc. (HO-2)
RegDate: 2016-09-09
Updated: 2016-09-09
Ref: https://whois.arin.net/rest/net/NET-139-99-0-0-1
------------------ Linode -----------------------
WHOIS Source: RIPE NCC
IP Address: 139.162.23.4
Country: sgSingapore
Network Name: LINODE-AP
Owner Name: Linode, LLC
CIDR:
From IP: 139.162.0.1
To IP: 139.162.31.255
Allocated: Yes
Contact Name: Thomas Asaro
Address: 329 E. Jimmie Leeds Road, Suite A, Galloway, NJ 08205, USA
Email:
Abuse Email: [email protected]
Phone: +16093807504
Fax:
inetnum: 139.162.0.1 - 139.162.31.255
netname: LINODE-AP
descr: Linode, LLC
country: SG
admin-c: TA2589-RIPE
tech-c: LA538-RIPE
status: LEGACY
remarks: This block is used for static customer allocations
remarks: Please send abuse reports to [email protected]
mnt-by: LINODE-LEG-MNT
created: 2015-01-31T05:10:06Z
last-modified: 2015-01-31T05:10:54Z
source: RIPE
-------------UPCLOUD---------------------
WHOIS Source: RIPE NCC
IP Address: 94.237.65.58
Country: sgSingapore
Network Name: UPCLOUD-SG-SIN1-NET
Owner Name:
CIDR: 94.237.64.0/22
From IP: 94.237.64.0
To IP: 94.237.67.255
Allocated: Yes
Contact Name: UpCloud Ltd
Address: Etelaranta 12, 00130 Helsinki, Finland
Email: [email protected]
Abuse Email: [email protected]
Phone:
Fax:
inetnum: 94.237.64.0 - 94.237.67.255
netname: UPCLOUD-SG-SIN1-NET
country: SG
admin-c: UPC-RIPE
tech-c: UPC-RIPE
status: ASSIGNED PA
mnt-by: MNT-UPCLOUD
created: 2017-03-09T13:43:02Z
last-modified: 2017-03-09T13:43:02Z
source: RIPE
role: UpCloud Ltd
address: Etelaranta 12
address: 00130 Helsinki
address: Finland
e-mail: [email protected]
abuse-mailbox: [email protected]
nic-hdl: UPC-RIPE
mnt-by: MNT-UPCLOUD
admin-c: JP1584-RIPE
created: 2013-05-14T13:13:07Z
last-modified: 2017-07-03T10:56:27Z
source: RIPE
@elos42 BGP doesn’t care about such parameters like geolocation. It’s not something you can configure in your route maps on any gear. Hence why it’s quite often useful to have the same set of carriers at all locations to ease these handover issues. It is however not possible when some of them are not present in the region like, I think might be in this case, making it harder (bot not impossible) to play the ball using the regular techniques.
@OVH_APAC just wanted to update that the weird routing affects only IPv4 traffic. The same machine that sends IPv4 traffic from India to France to get to Singapore gets a direct route from India to Singapore on IPv6.
If you want to see this in action, spin up a VPS on DO Bangalore DC, do a traceroute to one of your IPv4 addresses in Singapore and then do one to the same instance, but this time using IPv6. You'll see that IPv6 goes directly.
Try a vps with leaseweb SGP if your target is India .
It gives me consistently 60-95ms even on 3g/4g, and their bandwidth allowances are generous on 4GB ram plan (8TB IIRC)
@elos42,
Thank you for the update and please note we have made some improvement on the route from DO Bangalore to OVH in Singapore.
You may check this out directly here:
http://sgp.smokeping.ovh.net/smokeping?target=APAC.AS14061-APAC-BLR1-1
Latency reduced from 200ms to **38 ms **.
Our network is still relatively new in the Asia-Pacific region but is constantly evolving.
OVH aims to improve it day after day by adding providers, capacity and new rules to reduce the latency.
We are currently working with providers based in India and maybe in the near future, we will even add a PoP to better manage connections with these providers.
Once again, we encourage you to raise a support ticket for routing issues so we can assist you quicker than a forum post.
Hope this helps.
I think the main issue here is that West Coast USA -> SGP got routed thru EU...
Just reproduced this on he.net looking glass:
@OVH_APAC If it's so easy to fix these things, can I suggest that you fix the routing with the following ISPs?
1) Bharti Airtel
2) Idea Cellular
3) Vodafone.
Connectivity with the largest ISP, Reliance Jio, is already working fine.
These four account for about 96% of the consumer traffic.
We did have an issue with the LAX -> SGP link on that day so that might have been bad timing. We have also added a new link (Singapore to San Jose) that should help. I tested using the he.net looking glass and I'm now getting 168ms.
For more information about the network issue: http://status.ovh.net/?do=details&id=15331
--
We have contacted Bharti Airtel and Idea Cellular in order to improve the network with those providers but it may take some time to get that up and running. We have made some changes and are monitoring our existing connections to see if we can make any improvements.
Please see:
http://sgp.smokeping.ovh.net/smokeping?target=APAC.AS55410-1
Thanks
@OVH_APAC ref vodafone result, please note that most of the time, the traffic flows direct from OVH to the ISP, but takes weird routes from ISP to OVH.
1 > 139.99.127.252 (139.99.127.252) [AS16276] 0.099ms 0.145ms 0.115ms
2 > 10.95.209.14 (10.95.209.14) [] 0.128ms 0.160ms 0.106ms
3 > 10.75.248.4 (10.75.248.4) [] 1.114ms 0.949ms 0.830ms
4 > sin-gss1-bb1-a9.sng.asia (103.5.15.16) [AS16276] 1.093ms 1.071ms 0.837ms
5 > tata.as6453.sng.asia (103.5.15.19) [AS16276] 0.496ms 3.740ms 4.399ms
6 > if-ae-7-2.tcore2.LVW-Los-Angeles.as6453.net (64.86.252.36) [AS6453] 172.158ms 171.688ms 172.345ms
7 > if-ge-11-0-0-4.mcore5.LAA-Los-Angeles.as6453.net (64.86.252.46) [AS6453] 171.561ms 171.523ms 171.718ms
8 > 209.58.33.150 (209.58.33.150) [AS6453] 213.270ms 213.249ms 213.191ms
9 > 218.248.235.217 (218.248.235.217) [AS9829] 215.560ms 217.350ms 215.606ms
10 > 218.248.114.30 (218.248.114.30) [AS9829] 226.509ms 226.480ms 226.549ms
11 > ns12.bsnl.in (218.248.240.209) [AS9829] 226.354ms 226.477ms 226.352ms
why need to route through LA ?
OVH Sucks. Do not buy their service.
Correction: Anything not in Canada or France sucks. OVH itself is pretty good though and working through some growth pains (wouldn't recommend new locations ATM).
I agree, OVH in their Canadian and French DCs are great, but anything else is terrible, they just depend on those DCs to route their internet, why don't I just use the Canada or France one if your routing via those ones anyway?
I live in BC, Canada and OVH has a PoP (which they need to upgrade) in Seattle. Yet all the traffic goes to BHS first before anywhere else, there's no point for me to purchase any other location except the ones that actually have good peers to hand the traffic off to.
Same here: Trace route to CloudFlare
There are some other hosts too who have poor peering. But what I really hate about the OVH situation is that their hardware is too good to be wasted like this.
Hi @hanoi. We are currently in contact with CloudFlare, and we're trying to determine why they aren't making subnet 104.27.128.0/20 available to OVH in Singapore. Stay tuned.
@elos42. We looked into it and we improved the peering link to Airtel. You can see the difference here: http://sgp.smokeping.ovh.net/smokeping?target=APAC.AS24560