Singapore vs Japan traceroute and ping

edited September 2016 in Features and Ideas
The following are performed on my laptop in Singapore.

Taking the IP (45.32.100.168) from http://sgp-ping.vultr.com and traceroute:
traceroute to 45.32.100.168 (45.32.100.168), 64 hops max, 52 byte packets
1 router.asus.com (192.168.1.1) 1.058 ms 0.936 ms 0.764 ms
2 27.54.54.1 (27.54.54.1) 2.759 ms 2.753 ms 2.490 ms
3 182.55.0.14 (182.55.0.14) 3.008 ms 2.853 ms 3.027 ms
4 182.55.0.13 (182.55.0.13) 2.719 ms 3.108 ms 2.736 ms
5 xe-0-0-0-18.r01.tokyjp01.jp.bb.gin.ntt.net (61.213.145.201) 69.836 ms 69.751 ms 70.043 ms
6 ae-9.r31.tokyjp05.jp.bb.gin.ntt.net (129.250.3.248) 69.841 ms 69.600 ms 69.801 ms
7 * ae-5.r21.sngpsi05.sg.bb.gin.ntt.net (129.250.7.39) 138.503 ms 143.533 ms
8 ae-3.r00.sngpsi05.sg.bb.gin.ntt.net (129.250.7.21) 70.869 ms 71.934 ms 70.445 ms
9 116.51.18.134 (116.51.18.134) 72.243 ms 70.782 ms 79.169 ms
10 45.32.96.10 (45.32.96.10) 71.243 ms 78.126 ms 71.219 ms
11 * * *
12 45.32.100.168 (45.32.100.168) 82.995 ms 71.541 ms 71.832 ms

Taking the IP (45.32.100.168) from http://sgp-ping.vultr.com and ping:
PING 45.32.100.168 (45.32.100.168): 56 data bytes
64 bytes from 45.32.100.168: icmp_seq=0 ttl=51 time=75.175 ms
64 bytes from 45.32.100.168: icmp_seq=1 ttl=51 time=74.998 ms
64 bytes from 45.32.100.168: icmp_seq=2 ttl=51 time=77.581 ms
64 bytes from 45.32.100.168: icmp_seq=3 ttl=51 time=75.171 ms
64 bytes from 45.32.100.168: icmp_seq=4 ttl=51 time=75.268 ms
64 bytes from 45.32.100.168: icmp_seq=5 ttl=51 time=75.265 ms
64 bytes from 45.32.100.168: icmp_seq=6 ttl=51 time=74.968 ms
64 bytes from 45.32.100.168: icmp_seq=7 ttl=51 time=75.074 ms
64 bytes from 45.32.100.168: icmp_seq=8 ttl=51 time=75.149 ms
64 bytes from 45.32.100.168: icmp_seq=9 ttl=51 time=75.367 ms

--- 45.32.100.168 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 74.968/75.402/77.581/0.736 ms

Taking the IP (108.61.201.151) from http://hnd-jp-ping.vultr.com and traceroute:
traceroute to 108.61.201.151 (108.61.201.151), 64 hops max, 52 byte packets
1 router.asus.com (192.168.1.1) 3.833 ms 0.857 ms 0.674 ms
2 27.54.54.1 (27.54.54.1) 2.902 ms 2.649 ms 2.579 ms
3 182.55.0.14 (182.55.0.14) 3.443 ms 3.341 ms 3.177 ms
4 182.55.0.13 (182.55.0.13) 2.660 ms 3.225 ms 2.963 ms
5 xe-0-0-0-18.r01.tokyjp01.jp.bb.gin.ntt.net (61.213.145.201) 70.137 ms 70.212 ms 70.070 ms
6 ae-9.r31.tokyjp05.jp.bb.gin.ntt.net (129.250.3.248) 70.157 ms
ae-9.r30.tokyjp05.jp.bb.gin.ntt.net (129.250.3.80) 69.837 ms 69.899 ms
7 ae-16.r01.tokyjp05.jp.bb.gin.ntt.net (129.250.7.85) 70.391 ms
ae-17.r01.tokyjp05.jp.bb.gin.ntt.net (129.250.7.89) 69.993 ms 70.256 ms
8 120.88.53.66 (120.88.53.66) 79.186 ms 128.157 ms 70.246 ms
9 * * *
10 108.61.201.151.vultr.com (108.61.201.151) 70.137 ms 70.070 ms 70.289 ms

Taking the IP (108.61.201.151) from http://hnd-jp-ping.vultr.com and ping:
PING 108.61.201.151 (108.61.201.151): 56 data bytes
64 bytes from 108.61.201.151: icmp_seq=0 ttl=52 time=72.807 ms
64 bytes from 108.61.201.151: icmp_seq=1 ttl=52 time=72.517 ms
64 bytes from 108.61.201.151: icmp_seq=2 ttl=52 time=72.966 ms
64 bytes from 108.61.201.151: icmp_seq=3 ttl=52 time=73.580 ms
64 bytes from 108.61.201.151: icmp_seq=4 ttl=52 time=70.015 ms
64 bytes from 108.61.201.151: icmp_seq=5 ttl=52 time=72.891 ms
64 bytes from 108.61.201.151: icmp_seq=6 ttl=52 time=72.717 ms
64 bytes from 108.61.201.151: icmp_seq=7 ttl=52 time=74.404 ms
64 bytes from 108.61.201.151: icmp_seq=8 ttl=52 time=73.168 ms
64 bytes from 108.61.201.151: icmp_seq=9 ttl=52 time=72.624 ms

--- 108.61.201.151 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 70.015/72.769/74.404/1.059 ms

Comments

  • Did you have a question here?
  • edited October 2016
    @devicenull haha! I'm guessing it was meant to be a reply to https://discuss.vultr.com/discussion/comment/4325#Comment_4325

    It;s still not a correct response though, as nowhere is China mentioned. Also, if he's in Singapore, why does his first traceroute go via Japan? !
  • edited October 2016
    That's the question. Why is my traceroute from Singapore go via Japan if the server location is in Singapore? Consequently, the ping latency from Singapore to Vultr's Singapore server is greater than Vultr's Japan server. @devicenull
  • This really comes down to where your ISP and our providers interconnect. Just because two providers offer services in the same location, does not mean that they are connected to each other in that location.
  • edited October 2016
    @devicenull I realise that, but I'd have to think it was unusual these days.

    As an example, if anyone is curious (this not directed to devicenull) :

    When public internet first came to the UK, it was mainly taken up by students wanting to access their university accounts (the provided dialup modems at each university were rarely adaquate)

    Anyway, the Uk univeristy network (JANET) admins had a policy that they would not connect or peer with any commerical companies (there were a few exceptions, but they were companies collaborating on university projects etc.)

    So, how was JANET connected to the internet? Well, they connected to the USA NSFnet - I'm not sure where, they peered, but it meant that for anyone connecting from home to their local university, their connection went from Uk to UK via America!. And back then, the trans-atlantic links were sloooow!

    Demon internet (the aforementioned first public ISP) tried to arrange direct peering with JANET, but no joy.

    I don't think it was resolved until Linx (London internet exchange) came about, and JANET peers there (amongst others these days)

    [ Even now, universities don't connect directly, they all connect to JANET, - if you traceroute to any university system it will pass through ja.net at some stage - usually via London or Manchester. Think of JANET as a large ISP that only has univesities/colleges/techs etc. as it's customer) - this is fine now, as JANET runs truely top-of-the range networking, and the UK is only an ittie bittie little place. ]
  • It's unusual in the US/EU, but when you get outside those locations interconnect agreements get.... weird
  • @devicenull Ahh ok, thanks. I don't know much about the Asian networks other than apperently there is a lot of carrier grade nat, and ip6 only nodes

    Cheers!
  • edited October 2016
    @joelchen If you want to take this further, you need to talk to your ISP (Starhub) and ask them why their link to NTT(Singapore) has to first go to Japan and through NTT(Japan) rather than peering directly in Singapore.

    Though I'm sure they have a valid reason, so I wouldn't count on them saying "oops, you are right! let me fix some tables" making everything OK!!

    But anyway, the issue is "your side" not vultrs side.

    cheers
  • edited October 2016
    @devicenull I see.

    @jamie Thank you. I have not used Vultr yet, so it is not an existing problem on my side. Although this issue is not on Vultr's side, potential customers (myself included), will head to other cloud providers with shorter latencies.

    Here are the traceroute and ping from another of Singapore's ISP (SingNet) for those interested:

    traceroute to 45.32.100.168 (45.32.100.168), 64 hops max, 52 byte packets
    1 192.168.1.254 (192.168.1.254) 5.002 ms 1.872 ms 2.723 ms
    2 bb220-255-191-254.singnet.com.sg (220.255.191.254) 6.267 ms 4.003 ms 4.166 ms
    3 202.166.123.50 (202.166.123.50) 6.043 ms 13.001 ms 5.426 ms
    4 ae3-10.tp-ar11.singnet.com.sg (202.166.123.49) 5.914 ms 3.252 ms 3.976 ms
    5 ae8-0.tp-cr03.singnet.com.sg (202.166.122.50) 4.369 ms 3.951 ms 3.970 ms
    6 ae4-0.tp-er03.singnet.com.sg (202.166.123.70) 4.102 ms 4.093 ms 3.810 ms
    7 203.208.191.113 (203.208.191.113) 3.782 ms 3.706 ms
    203.208.191.197 (203.208.191.197) 6.594 ms
    8 203.208.149.138 (203.208.149.138) 5.519 ms 4.604 ms 3.930 ms
    9 203.208.151.250 (203.208.151.250) 10.034 ms
    203.208.166.41 (203.208.166.41) 36.172 ms
    203.208.151.254 (203.208.151.254) 6.578 ms
    10 203.208.154.73 (203.208.154.73) 40.626 ms
    xe-0-7-0-8.r01.tkokhk01.hk.bb.gin.ntt.net (129.250.8.197) 37.997 ms
    203.208.154.73 (203.208.154.73) 40.070 ms
    11 ae-3.r22.tkokhk01.hk.bb.gin.ntt.net (129.250.6.232) 39.302 ms
    203.208.158.225 (203.208.158.225) 40.000 ms
    ae-3.r22.tkokhk01.hk.bb.gin.ntt.net (129.250.6.232) 39.186 ms
    12 ae-7.r20.sngpsi05.sg.bb.gin.ntt.net (129.250.6.46) 40.456 ms
    203.208.154.73 (203.208.154.73) 42.344 ms
    203.208.152.30 (203.208.152.30) 38.703 ms
    13 ae-1.r00.sngpsi05.sg.bb.gin.ntt.net (129.250.7.19) 41.415 ms
    ae-3.r22.tkokhk01.hk.bb.gin.ntt.net (129.250.6.232) 38.620 ms 39.211 ms
    14 116.51.18.134 (116.51.18.134) 39.706 ms
    ae-7.r20.sngpsi05.sg.bb.gin.ntt.net (129.250.6.46) 42.623 ms
    116.51.18.134 (116.51.18.134) 41.604 ms
    15 ae-3.r22.tkokhk01.hk.bb.gin.ntt.net (129.250.6.232) 36.414 ms
    45.32.96.10 (45.32.96.10) 42.607 ms 42.425 ms
    16 116.51.18.134 (116.51.18.134) 40.770 ms * *
    17 45.32.100.168 (45.32.100.168) 41.918 ms 38.227 ms 41.125 ms

    PING 45.32.100.168 (45.32.100.168): 56 data bytes
    64 bytes from 45.32.100.168: icmp_seq=0 ttl=44 time=81.654 ms
    64 bytes from 45.32.100.168: icmp_seq=1 ttl=44 time=42.579 ms
    64 bytes from 45.32.100.168: icmp_seq=2 ttl=44 time=45.015 ms
    64 bytes from 45.32.100.168: icmp_seq=3 ttl=44 time=46.985 ms
    64 bytes from 45.32.100.168: icmp_seq=4 ttl=44 time=40.943 ms
    64 bytes from 45.32.100.168: icmp_seq=5 ttl=44 time=89.596 ms
    64 bytes from 45.32.100.168: icmp_seq=6 ttl=44 time=43.893 ms
    64 bytes from 45.32.100.168: icmp_seq=7 ttl=44 time=48.715 ms
    64 bytes from 45.32.100.168: icmp_seq=8 ttl=44 time=43.080 ms
    64 bytes from 45.32.100.168: icmp_seq=9 ttl=44 time=41.570 ms

    --- 45.32.100.168 ping statistics ---
    10 packets transmitted, 10 packets received, 0.0% packet loss
    round-trip min/avg/max/stddev = 40.943/52.403/89.596/16.855 ms
  • Digital Ocean and Linode I believe had this issue until they got with Equinix on this...
Sign In or Register to comment.