Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


OVH Singapore: Weird routing behavior
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.

OVH Singapore: Weird routing behavior

elos42elos42 Member
edited April 2018 in Providers

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.

Thanked by 1hanoi
«1

Comments

  • YokedEggYokedEgg Member
    edited April 2018

    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).

  • MikeAMikeA Member, Patron Provider

    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.

  • tomletomle Member, LIR
    edited April 2018

    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.

  • rm_rm_ IPv6 Advocate, Veteran
    edited April 2018

    tomle said: which for NA means in Canada.

    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

    Thanked by 1FHR
  • Shot2Shot2 Member

    Enabling their permanent firewall (mitigation) may also force routing through Fr.

  • rm_rm_ IPv6 Advocate, Veteran
    edited April 2018

    Shot2 said: 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.

  • YokedEggYokedEgg Member
    edited April 2018

    @elos42 said:
    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.

    Thanked by 1elos42
  • 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)

    @tomle said:
    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.

  • Thanks.
    If they can only fix this, I can move my production units to them easily.

  • OVH_APACOVH_APAC Member, Patron Provider
    edited April 2018

    @elos42 said:
    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.

    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:

    1. To run a traceroute on Linux, enter the following terminal command: traceroute your.ovh.vps.ip
    2. To run a traceroute on Windows, enter the following command line: tracert your.ovh.vps.ip
    3. Save the traceroute results
    4. Send a blank email to [email protected]
    5. Follow the instructions in the automated reply to sign up to the mailing list
    6. Send your traceroute results to [email protected] and the team will investigate

    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.

  • @OVH_APAC said:

    @elos42 said:
    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.

    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:

    1. To run a traceroute on Linux, enter the following terminal command: traceroute your.ovh.vps.ip
    2. To run a traceroute on Windows, enter the following command line: tracert your.ovh.vps.ip
    3. Save the traceroute results
    4. Send a blank email to [email protected]
    5. Follow the instructions in the automated reply to sign up to the mailing list
    6. Send your traceroute results to [email protected] and the team will investigate

    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

    Thanked by 1aglodek
  • ClouviderClouvider Member, Patron Provider

    @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)

    Thanked by 1Clouvider
  • OVH_APACOVH_APAC Member, Patron Provider

    @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:

    Looking_Glass_Hurricane_Electric_AS6939.png

  • @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.

  • OVH_APACOVH_APAC Member, Patron Provider

    @klikli said:
    I think the main issue here is that West Coast USA -> SGP got routed thru EU...

    Just reproduced this on he.net looking glass:

    Looking_Glass_Hurricane_Electric_AS6939.png

    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

    --

    @elos42 said:
    @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 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

    Thanked by 1klikli
  • @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.

  • hostdarehostdare Member, Patron Provider

    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.

  • @murshed said:
    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).

  • @YokedEgg said:

    @murshed said:
    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.

  • hanoihanoi Member
    edited April 2018

    Same here: Trace route to CloudFlare


    ~/pro# traceroute 104.27.128.209 traceroute to 104.27.128.209 (104.27.128.209), 30 hops max, 60 byte packets 1 139.99.96.1 (139.99.96.1) 0.192 ms 0.179 ms 0.172 ms 2 192.168.250.254 (192.168.250.254) 0.153 ms 0.147 ms 0.141 ms 3 10.29.193.62 (10.29.193.62) 0.203 ms 0.203 ms 0.214 ms 4 10.29.192.10 (10.29.192.10) 0.185 ms 0.212 ms 0.207 ms 5 10.133.2.24 (10.133.2.24) 0.445 ms 0.602 ms 0.718 ms 6 10.75.0.10 (10.75.0.10) 0.144 ms 10.75.0.8 (10.75.0.8) 0.220 ms 10.75.0.10 (10.75.0.10) 0.161 ms 7 10.75.248.4 (10.75.248.4) 0.751 ms 0.785 ms 10.75.248.2 (10.75.248.2) 0.904 ms 8 sin1-sgcs2-g1-nc5.sng.asia (103.5.15.224) 0.907 ms * * 9 cloudflare.mrs.franceix.net (37.49.232.29) 167.143 ms be10.mar-5-6k.fr.eu (178.33.100.254) 166.656 ms cloudflare.mrs.franceix.net (37.49.232.29) 167.203 ms 10 104.27.128.209 (104.27.128.209) 166.529 ms cloudflare.mrs.franceix.net (37.49.232.29) 167.274 ms 104.27.128.209 (104.27.128.209) 166.417 ms ~/pro# traceroute 104.28.1.133 traceroute to 104.28.1.133 (104.28.1.133), 30 hops max, 60 byte packets 1 139.99.96.1 (139.99.96.1) 0.163 ms 0.147 ms 0.140 ms 2 192.168.250.254 (192.168.250.254) 0.134 ms 0.127 ms 0.121 ms 3 10.29.193.62 (10.29.193.62) 0.154 ms 0.204 ms 0.199 ms 4 10.29.192.10 (10.29.192.10) 0.183 ms 10.29.192.12 (10.29.192.12) 0.181 ms 0.188 ms 5 10.133.2.24 (10.133.2.24) 0.526 ms 0.662 ms 0.760 ms 6 10.75.0.10 (10.75.0.10) 0.162 ms 10.75.0.8 (10.75.0.8) 0.177 ms 0.167 ms 7 10.75.248.4 (10.75.248.4) 1.168 ms 10.75.248.2 (10.75.248.2) 0.738 ms 0.818 ms 8 sin-sg1-bb1-a9.sng.asia (103.5.15.4) 1.196 ms sin1-sgcs2-g1-nc5.sng.asia (103.5.15.224) 0.857 ms sin-sg1-bb1-a9.sng.asia (103.5.15.4) 1.272 ms 9 sin-sg1-bb1-a9.sng.asia (103.5.15.4) 1.345 ms 13335.sgw.equinix.com (27.111.228.132) 0.643 ms 0.642 ms 10 104.28.1.133 (104.28.1.133) 0.500 ms 0.500 ms 13335.sgw.equinix.com (27.111.228.132) 0.634 ms
  • 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.

  • OVH_APACOVH_APAC Member, Patron Provider

    @hanoi said:
    Same here: Trace route to CloudFlare


    ~/pro# traceroute 104.27.128.209 traceroute to 104.27.128.209 (104.27.128.209), 30 hops max, 60 byte packets 1 139.99.96.1 (139.99.96.1) 0.192 ms 0.179 ms 0.172 ms 2 192.168.250.254 (192.168.250.254) 0.153 ms 0.147 ms 0.141 ms 3 10.29.193.62 (10.29.193.62) 0.203 ms 0.203 ms 0.214 ms 4 10.29.192.10 (10.29.192.10) 0.185 ms 0.212 ms 0.207 ms 5 10.133.2.24 (10.133.2.24) 0.445 ms 0.602 ms 0.718 ms 6 10.75.0.10 (10.75.0.10) 0.144 ms 10.75.0.8 (10.75.0.8) 0.220 ms 10.75.0.10 (10.75.0.10) 0.161 ms 7 10.75.248.4 (10.75.248.4) 0.751 ms 0.785 ms 10.75.248.2 (10.75.248.2) 0.904 ms 8 sin1-sgcs2-g1-nc5.sng.asia (103.5.15.224) 0.907 ms * * 9 cloudflare.mrs.franceix.net (37.49.232.29) 167.143 ms be10.mar-5-6k.fr.eu (178.33.100.254) 166.656 ms cloudflare.mrs.franceix.net (37.49.232.29) 167.203 ms 10 104.27.128.209 (104.27.128.209) 166.529 ms cloudflare.mrs.franceix.net (37.49.232.29) 167.274 ms 104.27.128.209 (104.27.128.209) 166.417 ms ~/pro# traceroute 104.28.1.133 traceroute to 104.28.1.133 (104.28.1.133), 30 hops max, 60 byte packets 1 139.99.96.1 (139.99.96.1) 0.163 ms 0.147 ms 0.140 ms 2 192.168.250.254 (192.168.250.254) 0.134 ms 0.127 ms 0.121 ms 3 10.29.193.62 (10.29.193.62) 0.154 ms 0.204 ms 0.199 ms 4 10.29.192.10 (10.29.192.10) 0.183 ms 10.29.192.12 (10.29.192.12) 0.181 ms 0.188 ms 5 10.133.2.24 (10.133.2.24) 0.526 ms 0.662 ms 0.760 ms 6 10.75.0.10 (10.75.0.10) 0.162 ms 10.75.0.8 (10.75.0.8) 0.177 ms 0.167 ms 7 10.75.248.4 (10.75.248.4) 1.168 ms 10.75.248.2 (10.75.248.2) 0.738 ms 0.818 ms 8 sin-sg1-bb1-a9.sng.asia (103.5.15.4) 1.196 ms sin1-sgcs2-g1-nc5.sng.asia (103.5.15.224) 0.857 ms sin-sg1-bb1-a9.sng.asia (103.5.15.4) 1.272 ms 9 sin-sg1-bb1-a9.sng.asia (103.5.15.4) 1.345 ms 13335.sgw.equinix.com (27.111.228.132) 0.643 ms 0.642 ms 10 104.28.1.133 (104.28.1.133) 0.500 ms 0.500 ms 13335.sgw.equinix.com (27.111.228.132) 0.634 ms

    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.

  • OVH_APACOVH_APAC Member, Patron Provider

    @OVH_APAC said:

    @klikli said:
    I think the main issue here is that West Coast USA -> SGP got routed thru EU...

    Just reproduced this on he.net looking glass:

    Looking_Glass_Hurricane_Electric_AS6939.png

    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

    --

    @elos42 said:
    @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 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

    @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

    Thanked by 1elos42
Sign In or Register to comment.