Field techs and their support lack basic tech skills and company knowledge

[waxriot]

One day my scp bandwidth to Media Temple dropped and stayed there:

approved_pair_dump.sql 100% 171MB 7.0MB/s 00:24
approved_pair_dump.sql 100% 172MB 8.0MB/s 00:21
approved_pair_dump.sql 100% 172MB 297.1KB/s 09:51
approved_pair_dump.sql 100% 172MB 318.1KB/s 09:13

The Sonic tech was unable to measure sustained download bandwidth on his laptop, meaning a wasted visit. I was also told by him and a supervisor that that was the best support Sonic could provide - there was no further recourse. Simple knowledge of wget and traceroute could have solved the issue, but according to a third supervisor who called me back after the visit, the only way to reach people who know about wget and traceroute is to post in a forum and hope someone literate picks up on it.

%%%% is the first word that comes to mind here, and now I'm only here for the net neutrality, and thinking of using my own router too, since another issue is seeing wireless nets advertised that shouldn't be there (e.g. Sonic-XXXX_3). If the field techs had known to tell me to try the forums, it might have helped. What bad customer relations to say take it or leave it, in effect!

[dane]

Performance to other sites is fine? If so, sounds like a Media Temple problem, probably best to contact them.

[waxriot]

Media Temple diagnosed it as an intermediate Level3 site in 15 seconds over the phone, by asking me to run traceoute.

Total and Utter Support Fail on Sonic's part. It seems you are blind to service issues in your focus on speed, and should get help.

If anyone can recommend a plain wired router with 2 out lines and a firewall, I'm all ears.

[waxriot]

I wasted a day debugging, made several innocent Sonic folk cringe with my anger, all because you can't provision your employees properly. In this case, a traceroute applet on your web site would have even shifted blame appropriately without human intervention.

[miken]

Can you upload or email Support pictures of the traceroute where the problem is present?

[waxriot]

A big win would be a 15 sec traceroute on the phone (or done by you from inside the router), followed by Sonic reporting it as a peer to Level3.

Here's all I've collected:

$ wget https://cdimage.debian.org/debian-cd/cu ... -DVD-1.iso

Comcast+weak_wireless

4.0-amd64-DVD-1.iso 3%[ ] 121.88M 4.17MB/s

Sonic fiber, no router

debian-9.4.0-amd6 3%[ ] 139.99M 4.68MB/s

$ wget http://phobrain.com/pr/home/gallery/x

Comcast+weak_wireless

x.2 0%[ ] 8.51M 229KB/s

Sonic fiber, no router

x 0%[ ] 9.29M 264KB/s

-- Sonic

% traceroute phobrain.com
traceroute to phobrain.com (70.32.90.126), 64 hops max, 52 byte packets
1 lo0.bras1.snfcca13.sonic.net (50.0.79.105) 1.764 ms 0.872 ms 0.283 ms
2 0.xe-0-0-15.cr2.colaca01.sonic.net (142.254.59.213) 51.942 ms 98.438 ms 21.884 ms
3 0.ae0.cr3.colaca01.sonic.net (198.27.244.130) 28.631 ms 17.952 ms 38.744 ms
4 0.ae0.cr2.lsatca11.sonic.net (50.0.79.174) 3652.367 ms * 4911.397 ms
5 50.ae4.gw.pao1.sonic.net (50.0.2.5) 1.995 ms 1.842 ms 1.963 ms
6 palo-b22-link.telia.net (213.248.81.254) 2.114 ms 2.005 ms 3.241 ms
7 sjo-b21-link.telia.net (62.115.125.1) 3.117 ms 3.267 ms 3.426 ms
8 * * *
9 * * *
10 4.14.98.38 (4.14.98.38) 71.969 ms 71.765 ms 71.694 ms
11 e3.1.cr01.iad01.mtsvc.net (70.32.64.102) 70.400 ms
e3.1.cr02.iad01.mtsvc.net (70.32.64.110) 71.384 ms
e3.1.cr01.iad01.mtsvc.net (70.32.64.102) 71.307 ms
12 e1.4.as01.iad01.mtsvc.net (70.32.64.250) 69.876 ms
e1.4.as02.iad01.mtsvc.net (70.32.64.246) 82.000 ms
e1.4.as01.iad01.mtsvc.net (70.32.64.250) 77.716 ms
13 vzs355.mediatemple.net (70.32.95.10) 71.461 ms 70.439 ms 71.488 ms
14 70.32.90.126 (70.32.90.126) 71.625 ms 71.563 ms 71.515 ms

--- Comcast

% traceroute phobrain.com
traceroute to phobrain.com (70.32.90.126), 64 hops max, 52 byte packets
1 10.0.0.1 (10.0.0.1) 20.896 ms 5.737 ms 10.507 ms
2 96.120.89.205 (96.120.89.205) 60.877 ms 24.719 ms 15.038 ms
3 po-101-rur01.sfgeary.ca.sfba.comcast.net (68.86.248.37) 12.029 ms 17.446 ms 16.758 ms
4 162.151.78.89 (162.151.78.89) 15.808 ms 15.360 ms 27.835 ms
5 be-299-ar01.santaclara.ca.sfba.comcast.net (68.86.143.93) 23.600 ms 20.076 ms 15.158 ms
6 lag-14.ear3.sanjose1.level3.net (4.68.72.105) 17.349 ms 15.193 ms 16.450 ms
7 * * *
8 4.14.98.38 (4.14.98.38) 85.397 ms 90.148 ms 83.458 ms
9 e3.1.cr02.iad01.mtsvc.net (70.32.64.110) 86.766 ms 85.081 ms 86.402 ms
10 e1.4.as02.iad01.mtsvc.net (70.32.64.246) 96.494 ms 87.131 ms
e1.4.as01.iad01.mtsvc.net (70.32.64.250) 146.076 ms
11 vzs355.mediatemple.net (70.32.95.10) 104.192 ms 83.180 ms 83.410 ms
12 70.32.90.126 (70.32.90.126) 84.435 ms 84.425 ms 93.741 ms

[miken]

It looks like both of those traceroutes are reaching the recipient at 70.32.90.126 fine - although the Sonic connection is about 22ms faster.

When reading a traceroute, the hops in-between can be ignored if there is no packet loss to the final recipient. This is because a lot of routers aren't designed with high priority for ICMP requests and can either take awhile to respond to those requests or even just flat out ignore them (but that doesn't mean they have any problem passing on traffic).

I don't see any problem with the route to the endpoint from what you posted, so if you are still seeing problems I'd contact the owners of the server for further troubleshooting.

[waxriot]

Thanks! Good to have knowledge, but also good to prove. Any chance you (or anyone else reading) could

$ wget http://phobrain.com/pr/home/gallery/x

from a point that doesn't go through 4.14.98.38, and see if they get better than 400Kish?

FYI, x= openssl rand -out x -base64 $(( 2**30 * 3/4 ))

Another thought: could this be net neutrality related?

Oh for the days when I did support myself, and had an account at half the supercomputer centers in the world. I always had another point to test the net from, and anyone who does net-related support should have at least 3 points they can test from, and a 5-second script for an overview, IMNHO. I guess that could be a business, giving simple automated net diagnostics in a web form for consumers. I presume it's available to customers of CDN's. Speaking of birds,

https://forums.craigslist.org/?ID=291163578

[miken]

I do not understand why that specific server is under suspicion as the problem. Both paths utilize all of these same hops:

4.14.98.38
7.32.64.110
70.32.64.250
70.32.64.246
70.32.95.10
70.32.90.126

Any one of those hops can be the problem (but it's probably the end server). As we've recommended a few times now, reaching out to the owner of the end server and having them do some advanced digging on their end is going to be the best thing you can do. While I'm happy to help if you have any other relevant information. Currently from my experience this looks like their server was able to upload and provide a specific connection speed previously that they are no longer able to. Since it's not our server or tied to our service (since it happens on Comcast too) there's not a whole lot more I can help with.

[waxriot]

Am I going crazy? Can't you see the slowdown at that point??? Can't you try to learn something by experimenting???

Also, as I have mentioned, the end server support diagnosed the problem already, and gave me the lay of the land in the industry and about the frequency of Level3 issues, whereas you come across as a temporary standin for a bot at this point.

I'm just trying to fix Sonic because of net neutrality - I'd be gone by now if I had a choice.

Please escalate higher.