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.
Comments
You're doing it wrong. A review requires supervision, benchmarks don't.
I guess it's come to having to defend fucking Cogent. For the record, I'm not associated with AVSISP, I'm not even their customer and I've never been. Similarly, I'm not associated with Cogent, and I've never been their direct customer. But they are an upstream of many of my upstreams, so I have some experience.
jsg, I don't think you understand how Internet routing / BGP works, or you put 0% effort into trying to understand why you were seeing scenic routes and 100% effort into ranting about it. The 'review' is very light on specifics to look into, but I think I found a good example. You've posted 0 mtrs / traceroutes showing problematic routes, and even the hosts you test against don't seem to be fully included. This kind of handwaving isn't really how to write a service review fairly and transparently. E.g. you talk about multiple test targets in Romania, with a at least one taking a scenic route, but you only mentioned explicitly 'RO BUC mirrors.hosterion.ro', with 12ms RTT that seems perfectly fine.
Anyway, back on topic. I said I found a good example in the review. That is 'JP TOK ftp.udx.icscoe.jp' aka 219.100.92.228. Cogent routes traffic to this IP address in Japan from Europe via the US, which is one of the things you were ranting about. Confirmed via the Cogent looking glass, e.g. from Frankfurt:
traceroute to 219.100.92.228 (219.100.92.228), 30 hops max, 60 byte packets
1 * *
2 be7942.ccr42.fra05.atlas.cogentco.com (154.54.57.18) 0.710 ms 0.837 ms
3 be2950.ccr42.ams03.atlas.cogentco.com (154.54.72.41) 7.537 ms 7.870 ms
4 be2182.ccr21.lpl01.atlas.cogentco.com (154.54.77.246) 17.053 ms 17.026 ms
5 be3043.ccr22.ymq01.atlas.cogentco.com (154.54.44.166) 86.485 ms 86.456 ms
6 be3259.ccr31.yyz02.atlas.cogentco.com (154.54.41.205) 93.957 ms 94.283 ms
7 be4941.ccr82.sea08.atlas.cogentco.com (154.54.94.73) 148.463 ms be3424.ccr81.sea08.atlas.cogentco.com (154.54.82.253) 148.190 ms
8 be9342.ccr22.sea02.atlas.cogentco.com (154.54.160.238) 147.552 ms 147.810 ms
9 te0-4-0-27.ccr21.sea02.atlas.cogentco.com (38.104.126.85) 146.743 ms 146.608 ms
10 tky009bb11.IIJ.Net (58.138.88.229) 240.808 ms *
11 tky009ix54.IIJ.Net (58.138.112.107) 240.581 ms tky009ix54.IIJ.Net (58.138.112.105) 234.273 ms
12 202.232.6.18 (202.232.6.18) 240.570 ms 235.027 ms
13 150.99.21.20 (150.99.21.20) 235.088 ms 234.831 ms
14 icscoe-1.gw.sinet.ad.jp (150.99.181.146) 246.838 ms 246.791 ms
15 * *
So it goes Frankfurt -> Amsterdam -> Liverpool -> Montreal -> Toronto -> Seattle -> Tokyo.
Ok, but why? Let's look at the BGP table entry, also via the Cogent looking glass for Frankfurt:
Paths: (1 available, best #1)
Path #1: Received by speaker 0
2497 2907 2907 2907 63770
66.28.1.34 (metric 244680) from 38.28.1.83 (66.28.1.34)
Origin IGP, metric 1000, localpref 130, valid, internal, best, group-best, import-candidate
Received Path ID 0, Local Path ID 1, version 1303984668
Community: 174:3000 174:10022 174:20999 174:21001 174:22013
Originator: 66.28.1.34, Cluster list: 38.28.1.83, 38.28.2.71, 38.28.1.123, 66.28.1.3
First, let's figure out how Cogent learnt this route. Looking at the AS path, it's announced to Cogent by AS2497 (aka IIJ, a Japanese tier 2), who are an upstream of the immediate upstream (AS2907) for the originating network AS63770. A quick check on bgp.tools (https://bgp.tools/prefix/219.100.92.0/22#connectivity) will show that indeed this prefix from AS63770 is single homed to AS2907 and itself single homed to AS2497. AS2907 also announces it to BBIX Tokyo, but that doesn't really come into play outside of the region or with T1 routing generally.
Now let's look at the BGP communities. We have:
174:21001 - Route is NA internal or customer route
174:22013 - United States
So IIJ are a Cogent customer and they announce the prefix to them in the United States! And presumably IIJ then backhaul the traffic back to Japan themselves. And there are no traffic engineering communities applied other than 174:3000 - Do not announce to peers - which means IIJ don't want traffic from other Tier 1s to be routed to Cogent. Cogent for example has BGP communities that would allow IIJ to set a low local pref on different continents (174:9x2), which would allow Cogent to route via other T1s if a better route was available. But IIJ doesn't use them.
I also checked the Cogent looking glass for Singapore, and it also only knows of the US route. So I'm reasonably sure that IIJ only announce this prefix to Cogent in the US. So there you go, they route via US because that's where IIJ announces the prefix to them.
Bonus content: let's check routing from other networks in Europe to 219.100.92.228 via ping.pe. I see another route via Cogent from Spain (going via US obviously), 232 ms. Then a second route from Spain to GTT in London and then entering the private IIJ backbone. And what do you know, 275 ms. Then I see a route via NTT entering the NTT backbone in London and routed to LA. The prefix also seems to be announced to Tata in London, and then backhauled from there by IIJ: 238ms.
So if you want blame someone, blame IIJ for only announcing the prefix to Cogent in the US, and not allowing them to route to peers. But even traffic backhauled by IIJ themselves from London has RTT in the same ballpark.
It seems to me you saw Cogent and then confirmation bias kicked in - oh they must have poor routing.
Rating: 3/10 reviewer - would not base decisions on his work.
I didn't even pretend to check, just how I interpreted what he said "I can do it again in 2 weeks but 3 weeks would be too late". Maybe @jsg was just finessing a free month but that hardly seems in character. I won't be dragged into your contentious love affair!
Funny, so their routing table is paranoid/schizophrenic? Because the route from the tested VPS to jingk.ai (SGP) almost completely is derpent and goes via undersea cable in one hop from Marseille to Singapore, while the route to sg.gs (SGP) is different relatively early and goes via Paris to the NA East-Coast where it's changed to NTT and in total has almost double to the travel time (350 ms vs 180 ms).
And btw, that I do collect routing data at all is a bonus and not an integral feature of benchmarking a VPS - at all, and indeed to the best of my knowledge no other benchmarker does offer that.
Am I a networking expert? I never said I am, and one doesn't need to be one to collect routing data and sharing some observations.
You blindly defended him, your ass is the one showing...
I disagree, but feel free to take a picture and remind me!
To solve the (not at all) riddle: I did purchase that VPS but wasn't ready at all to pay any longer for a VPS that IMO (others might have a different view) was, to put it politely, mediocre bang per buck. I was however willing to test it again after the updates the provider had announced/promised and for that purpose and only that purpose I said something about an additional free month.