Routing problem.

Forums › 2degrees (including Slingshot, Orcon, Flip, Stuff Fibre, MyRepublic, 2talk and Vocus) › Routing problem.

peiau

3 posts

Wannabe Geek

#220319 6-Aug-2017 05:10

Recently my latency has increased significantly by ~60ms to Beauharnois, Canada - which is the location of OVH's Canadian Data center, only 50km north is Montreal where my ping has been unaffected and remains around ~200ms.

traceroute to Beauharnois.

traceroute to proof.ovh.ca (192.99.19.165), 30 hops max, 60 byte packets
1 gateway (192.168.1.1) 0.448 ms 0.643 ms 0.847 ms
2 121.32.69.111.static.snap.net.nz (111.69.32.121) 8.449 ms 8.651 ms 8.652 ms
3 * * *
4 two-degrees-new-zealand.as23655.any2ix.coresite.com (206.72.211.83) 158.623 ms 158.607 ms 158.805 ms
5 * * *
6 be100-1367.lax-la1-bb1-a9.ca.us (178.32.135.161) 216.613 ms 215.981 ms 215.978 ms
7 be100-1317.chi-5-a9.il.us (198.27.73.88) 242.395 ms 242.456 ms 242.644 ms
8 192.99.146.140 (192.99.146.140) 250.981 ms 259.656 ms 249.831 ms
9 * * *
10 * * *
11 * * *
12 bhs.proof.ovh.net (192.99.19.165) 259.828 ms 257.842 ms 257.870 ms

traceroute to Montréal.

traceroute to 208.88.110.58 (208.88.110.58), 30 hops max, 60 byte packets
1 gateway (192.168.1.1) 1.221 ms 1.408 ms 1.607 ms
2 121.32.69.111.static.snap.net.nz (111.69.32.121) 5.073 ms 5.274 ms 5.275 ms
3 * * *
4 TWO-DEGREES.bar1.SanFrancisco1.Level3.net (4.16.192.146) 129.360 ms 129.559 ms 129.563 ms
5 xe-4-2-0.bar1.SanFrancisco1.Level3.net (4.16.192.145) 131.056 ms 130.841 ms 131.041 ms
6 ae-1-11.bear1.Montreal2.Level3.net (4.69.203.133) 203.111 ms 199.723 ms 199.342 ms
7 te0-7-0-0.asr01.mtlsunl.fibrenoire.ca (4.59.178.46) 199.142 ms 200.590 ms 200.785 ms
8 te0-0-2-2.asr03.mtlsunl.fibrenoire.ca (192.252.143.221) 202.265 ms 202.083 ms 201.896 ms
9 pbx3.telecodex.com (208.88.110.58) 201.673 ms 200.197 ms 200.203 ms

also

canada

timmmay

20574 posts

Uber Geek

Trusted

Lifetime subscriber

#1839698 6-Aug-2017 06:22

This is probably related to the problems discussed on this thread. In that thread we found using AWS data centers that the US west coast was fast, but the east coast was much much slower. 2degrees are looking into it.

peiau

3 posts

Wannabe Geek

#1839699 6-Aug-2017 06:47

timmmay:

This is probably related to the problems discussed on this thread. In that thread we found using AWS data centers that the US west coast was fast, but the east coast was much much slower. 2degrees are looking into it.

I'm not so sure, this problem of mine seems to be isolated to Beauharnois (all servers not just ovh) and I think it's been going on for over a month.

Out of curiosity, what is your ping to OVH?

timmmay

20574 posts

Uber Geek

Trusted

Lifetime subscriber

#1839705 6-Aug-2017 07:38

I can see from your traceroutes that the two servers are taking quite diffent paths through the internet. After NZ one is going to two-degrees-new-zealand.as23655.any2ix.coresite.com, the other is going to TWO-DEGREES.bar1.SanFrancisco1.Level3.net

Given that you'd have to think there's at least a chance the known problem could be related to the one you've found. You can log the problem, or you can hope 2degrees sees this. I'd wait, personally.

I'm on 2degrees fiber as well, my traceroute's look much like yours. Here's the pings.

ping proof.ovh.ca

Pinging proof.ovh.ca [192.99.19.165] with 32 bytes of data:
Reply from 192.99.19.165: bytes=32 time=258ms TTL=54
Reply from 192.99.19.165: bytes=32 time=257ms TTL=54
Reply from 192.99.19.165: bytes=32 time=260ms TTL=54
Reply from 192.99.19.165: bytes=32 time=259ms TTL=54

Ping statistics for 192.99.19.165:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 257ms, Maximum = 260ms, Average = 258ms

ping 208.88.110.58

Pinging 208.88.110.58 with 32 bytes of data:
Reply from 208.88.110.58: bytes=32 time=211ms TTL=57
Reply from 208.88.110.58: bytes=32 time=210ms TTL=57
Reply from 208.88.110.58: bytes=32 time=209ms TTL=57
Reply from 208.88.110.58: bytes=32 time=210ms TTL=57

Ping statistics for 208.88.110.58:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 209ms, Maximum = 211ms, Average = 210ms

Jase2985

13457 posts

Uber Geek

ID Verified

Lifetime subscriber

#1839706 6-Aug-2017 07:42

FYI on my spark connection it gets 220ms to the first one and 310ms for the second one, which seems to route via japan hong kong china.

yitz

2074 posts

Uber Geek

#1839821 6-Aug-2017 12:37

To see what's going on in the other direction use https://lg.ovh.net/ choose node BHS, IPv4, traceroute command.

There is more than one path between west and east coast USA and also more than one path between Auckland and west coast USA (direct and via Sydney). Each of those could easily contribute 30 ms round trip which could be what you are seeing.

Going by posts in the other thread I think 2degrees have recently augmented their international network capacity.

peiau

3 posts

Wannabe Geek

#1841361 8-Aug-2017 18:57

I'll probably just move to spark if this continues.

sbiddle

30853 posts

Uber Geek

Retired Mod

Trusted

Biddle Corp

Lifetime subscriber

#1841417 8-Aug-2017 19:36

peiau:

I'll probably just move to spark if this continues.

While routing issues can be annoying they can be completely beyond the control of any NZ ISP or upstream provider once they hit the US.

What application or service do you have that's impacted by 50ms when you're already 200ms away? I wouldn't have expected it to make any difference at all for 99% of use cases.

Equinox IT

Cloud spending continues to surge globally, but most organisations haven’t made the changes necessary to maximise the value and cost-efficiency benefits of their cloud investments. Download the whitepaper From Overspend to Advantage now.

hio77

12999 posts

Uber Geek

ID Verified

Trusted

Lizard Networks

#1841441 8-Aug-2017 20:33

sbiddle:

peiau:

I'll probably just move to spark if this continues.

While routing issues can be annoying they can be completely beyond the control of any NZ ISP or upstream provider once they hit the US.

What application or service do you have that's impacted by 50ms when you're already 200ms away? I wouldn't have expected it to make any difference at all for 99% of use cases.

i'd suspect given the location and such, likely streaming where tcp window size would have a difference in 50ms...

#include <std_disclaimer>

Any comments made are personal opinion and do not reflect directly on the position my current or past employers may have.