New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Who should I submit a ticket on Routing issue in Singapore?
Hi.
I'm not good at networks. Latency varies in Singapore.
I have four Hosthatch VMs and one OVH VM in Singapore. The latency between the Hosthatch VMs and the OVH VM ranges from as little as 2ms to as much as 70ms.
Contrary to the title, I won't do a ticket. I'd just like to know if the issue is with Hosthatch or OVH.
4 vm from HostHatch (Their ips are from different subnet)
1 vm from OVH
Scroll sideways to see more detailed latency
Hosthatch A -> OVH VM
Latency : 33ms
1. 31.57.224.1 0.0% 122 30.1 54.4 9.2 281.8 56.0
2. l880.sg-eqxsg3-cr7.globalsecurelayer.com 0.0% 122 0.9 0.9 0.8 1.2 0.1
3. po7.sg-eqxsg3-cr2.globalsecurelayer.com 0.0% 121 1.0 0.9 0.9 1.2 0.1
4. 16276.sgw.equinix.com 0.8% 121 73.4 73.7 73.1 91.5 2.4
5. (waiting for reply)
6. (waiting for reply)
7. (waiting for reply)
8. sin-sgcs2-g2-nc5.sgp.asia 0.0% 121 1.9 5.6 1.6 121.6 15.9
9. (waiting for reply)
10. (waiting for reply)
11. (waiting for reply)
12. (waiting for reply)
13. (waiting for reply)
14. (waiting for reply)
15. (waiting for reply)
16. OVH VM 0.0% 121 33.2 33.1 32.9 34.6 0.2
Hosthatch B -> OVH VM
Latency : 74ms
1. 31.57.224.1 0.0% 178 17.8 57.7 9.3 406.4 65.7
2. l880.sg-eqxsg3-cr7.globalsecurelayer.com 0.0% 178 1.0 0.9 0.9 1.3 0.1
3. po7.sg-eqxsg3-cr2.globalsecurelayer.com 0.0% 178 0.9 0.9 0.9 1.3 0.1
4. 16276.sgw.equinix.com 0.0% 178 33.2 33.3 32.5 59.8 3.5
5. (waiting for reply)
6. (waiting for reply)
7. (waiting for reply)
8. sin-sgcs2-g2-nc5.sgp.asia 0.0% 178 1.6 5.1 1.5 106.3 16.1
9. (waiting for reply)
10. (waiting for reply)
11. (waiting for reply)
12. (waiting for reply)
13. (waiting for reply)
14. (waiting for reply)
15. (waiting for reply)
16. OVH VM 0.0% 177 73.7 73.7 73.6 75.3 0.1
HostHatch C -> OVH VM
Latency : 2ms
1. 31.57.224.1 0.0% 225 10.9 37.6 1.9 355.8 58.0
2. l880.sg-eqxsg3-cr7.globalsecurelayer.com 0.0% 225 1.0 0.9 0.9 1.2 0.1
3. po7.sg-eqxsg3-cr2.globalsecurelayer.com 0.0% 225 1.0 0.9 0.8 1.1 0.1
4. 16276.sgw.equinix.com 0.4% 225 73.5 73.8 73.0 92.7 2.7
5. (waiting for reply)
6. (waiting for reply)
7. (waiting for reply)
8. sin1-sgcs2-g1-nc5.sgp.asia 0.0% 224 33.1 38.1 32.8 150.1 19.2
9. (waiting for reply)
10. (waiting for reply)
11. (waiting for reply)
12. (waiting for reply)
13. (waiting for reply)
14. (waiting for reply)
15. (waiting for reply)
16. OVH VM 0.0% 224 1.9 1.8 1.7 2.2 0.1
Hosthatch D -> OVH VM
Latency : 2ms
1. 31.57.224.1 0.0% 246 20.2 30.6 2.1 405.4 49.7
2. l880.sg-eqxsg3-cr7.globalsecurelayer.com 0.0% 246 1.0 0.9 0.9 1.1 0.1
3. po7.sg-eqxsg3-cr2.globalsecurelayer.com 0.0% 246 1.0 0.9 0.8 1.2 0.1
4. 16276.sgw.equinix.com 0.4% 246 32.6 33.4 32.5 54.9 3.2
5. (waiting for reply)
6. (waiting for reply)
7. (waiting for reply)
8. sin-sgcs2-g2-nc5.sgp.asia 0.0% 245 1.8 6.9 1.6 119.8 19.1
9. (waiting for reply)
10. (waiting for reply)
11. (waiting for reply)
12. (waiting for reply)
13. (waiting for reply)
14. (waiting for reply)
15. (waiting for reply)
16. OVH VM 0.0% 245 1.9 1.8 1.8 2.1 0.1
Comments
Have you tried to do reverse trace route from OVH VM?
In this case whichever is your preferred direction, contact that provider first and see what they got to offer
They may or may not do any changes
Ideally you want to check Looking Glass before purchase if latency is important.
With peoviders the blend usually is dynamic and depending on things out of control traffic may be routed differently
From what I understand HostHatch has been decent to listen and try to optimize thr route whenever possible.
Good luck.
Reverse MTR
OVH VM -> Hosthatch A
OVH VM -> Hosthatch B
OVH VM -> Hosthatch C
OVH VM -> Hosthatch D
If I were you I would reach HostHatch. Latency is impacted by GSL as I can see, but you aren't GSL customer so I wouldn't expect them to listen to you.
Actually, I’d take the opposite approach: if the OP is experiencing connectivity issues accessing OVH VM, and traceroutes from OP IP address or from multiple other locations - consistently point to problems within OVH’s network, then the evidence strongly suggests the issue lies with OVH. In that case, I’d recommend contacting OVH support directly and providing them with the traceroute data and any other relevant diagnostics to demonstrate the network problem originates on their end.
within OVH network there are nothing influencing latency difference.
Hijacking this thread to share about my situation where I am based on SG but connecting to SG infras as such Advin Servers or OrangeVPS I get 100ms+ latency which is crazy and my ISP has yet to respond back to me or helped me improved their routing
Based on my preliminary research it looks like my ISP does not care about improving customers' network route which is sad
Lately I've had similar issues with some GSL IPs from connecting from another ISP (while connecting to other GSL IPs were fine). I thought it might be the other ISP's fault for choosing a weird outbound path, but seeing as OVH is also facing the same issue, I am guessing that it's because some of these IPs are not getting announced to GSL peers in Equinix Singapore and thus the other ISP has to find another way to reach GSL in the next closest IX in Hong Kong that advertised these IPs.
Have you ticketed in with @hosthatch with the affected IPs? They should be able to escalate the issue to GSL if needed.
which ISP are you using?
Hi, I'm using Singtel
For more context the latency to my HostHatch servers are around 15ms (and compared to Starhub and other providers it's like ~5ms)
Singtel (and its cousin Optus in Australia) is a lost cause as a lot of LE providers rely on IX peering to reach local ISPs, and Singtel will for any reason refuse to do settlement-free peering with small networks to protect their network's profits. It's best to switch ISPs or stick with GSL-based networks that can use Lumen to reach Singtel directly.
adding to this ... there is Starhub as well
Thank you guys, but unfortunately I am still stuck with them one more year before the contract expires
yeah... definitely gonna switch providers after this lmao
Strong evidence suggesting that it is OVH's issue.
And it affects some specific prefixes: 139.99.0.0/17
However other prefixes are not affected, like 15.235.128.0/17
SG.GS is reaching OVH via GNM-IX which is a completely different path.
However OVH has zero support.
thats untrue
ticket in and sometimes a qualified rep would surprisingly offer a good solution.
OVH issue.
they're preferring routes from HK GSL instead of Equinix SG / SGIX.
nothing hosthatch/gsl can do.
as far as I know, OVH receive BBIX hong kong routes (which both GSL & OVH are there)
Starhub have private peering with GSL, so low latency it is!
It looks like they have helped improved the latency to Advin Servers from a crazy ~200ms to ~50ms
but sadly OrangeVPS still remains at ~100ms
I will take this improvement ig lol
We're going to be fully moving to GSL soon which should improve this.
Latency Changes
A -> OVH from 33ms -> 77ms
B -> OVH from 77ms -> 2ms
C -> OVH 2 ms ( no changes)
D -> OVH 2 ms ( no changes)
Ipv6
A -> OVH 2ms
B -> OVH 74ms
C -> OVH 33ms
D -> OVH 33ms
Pinging with TCP from the same VM gets me either 2ms, 33ms or 73ms. Confirms that it is not an IP issue but ECMP on OVH's end fluctuating its outbound routes. They likely do not set the local pref higher for the peering session they have with GSL in Singapore. I heard that GSL tends to tag its route announcements with MEDs and that helps peers decide which peering point is best for the corresponding IP prefix, so it is likely that OVH fails to honor it.
Ticket with OVH since you are a customer. It is an easy fix on their end but it's whether they will do it.