So you Start - Sentient?

HN-Matt · Sep 30, 2015

I've read some horror stories about So you Start's support. Blah blah long response times for hardware replacement and so on. On the other hand, I have some servers with OVH and have never had a problem with them, so I ended up giving SyS a try a few days ago. So far it seems to have been a mistake.

From the start there were problems from all angles. Potential hardware problems and possible problems with the custom OS they provide through their otherwise convenient automated OS re/installation platform (makes installing an OS super easy for beginners). It's still too early to draw conclusions, so I'll leave those issues aside for the time being and focus on a problematic 'failover IP' I was given (it would seem the term wins the day for ironic naming schemes).

I ordered a /30 at first and there were no connectivity problems (able to allocate the IPs and provision working VMs, etc.), so I bought another IP from a different location the next day and... well, here's a transcript from a ticket I submitted a couple days ago called "Extreme packet loss". Names and IP addresses have been removed to protect the innocent. My frustration is showing, having experienced problems with almost every aspect of the server so far.

Quote said:
Me - 28/09/2015 20:49Is there a problem with your network at this time?

I was finally able to get my newest FO IP to work, but now there's extreme packet loss.

--- xxx.xxx.xxx.xxx ping statistics ---
100 packets transmitted, 19 received, 81% packet loss, time 99206ms
rtt min/avg/max/mdev = 170.986/651.662/2997.093/698.113 ms

Support - 28/09/2015 23:51Good day,

Thank you for taking time to contact our support team. I'm sorry to hear that you're experiencing problems with the connection of your server. In order for us to look into this issue for you, we would need more information on the problem. I would ask that you please send us the following information:

-Results of a ping on your server.
-Results of a traceroute (preferably done with MTR) from your local host to your server.
-Results of a traceroute (preferably done with MTR) from your server to your local host.
-Results of the following command: iperf -c proof.ovh.ca -P 5 -r

Send us all the results (or screenshots of the results) and we'll be able to investigate the matter.

Thank you for choosing our services!

D
Customer Advocate.
FAQ: http://docs.ovh.ca/en/faqs.html

Me - 28/09/2015 23:57So you're saying there aren't any noticeable network issues on your end that wouldn't require me to execute those commands?

Me - 29/09/2015 00:00I would suggest doing some research on your end before asking me to send you any 'traceroute' results.

e.g. if you continually ping the IP from http://www.super-ping.com/?ping=xxx.xxx.xxx.xxx, you'll notice that every single host in the world often cannot connect to it at all.

Me - 29/09/2015 00:05See http://img.bs/i/8d4197c99ba2194f2db27b2eb0d01608.png (from ~3 minutes ago)

Me - 29/09/2015 00:06Ping results from ~10 minutes ago:

PING xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx) 56(84) bytes of data.
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=20 ttl=54 time=2283 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=21 ttl=54 time=1291 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=22 ttl=54 time=292 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=23 ttl=54 time=152 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=24 ttl=54 time=262 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=25 ttl=54 time=138 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=26 ttl=54 time=147 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=27 ttl=54 time=145 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=28 ttl=54 time=454 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=29 ttl=54 time=143 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=30 ttl=54 time=191 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=74 ttl=54 time=2855 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=75 ttl=54 time=1850 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=76 ttl=54 time=843 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=77 ttl=54 time=445 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=78 ttl=54 time=140 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=79 ttl=54 time=492 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=80 ttl=54 time=146 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=81 ttl=54 time=159 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=82 ttl=54 time=135 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=83 ttl=54 time=482 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=84 ttl=54 time=143 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=126 ttl=54 time=2111 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=127 ttl=54 time=1115 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=128 ttl=54 time=152 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=129 ttl=54 time=355 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=130 ttl=54 time=149 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=131 ttl=54 time=198 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=132 ttl=54 time=628 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=133 ttl=54 time=1012 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=134 ttl=54 time=147 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=135 ttl=54 time=854 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=185 ttl=54 time=841 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=186 ttl=54 time=147 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=187 ttl=54 time=142 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=188 ttl=54 time=609 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=189 ttl=54 time=161 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=190 ttl=54 time=701 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=191 ttl=54 time=141 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=192 ttl=54 time=150 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=193 ttl=54 time=177 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=244 ttl=54 time=1708 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=245 ttl=54 time=708 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=246 ttl=54 time=286 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=247 ttl=54 time=136 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=248 ttl=54 time=143 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=295 ttl=54 time=951 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=296 ttl=54 time=146 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=297 ttl=54 time=348 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=298 ttl=54 time=240 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=299 ttl=54 time=402 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=300 ttl=54 time=136 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=301 ttl=54 time=145 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=302 ttl=54 time=153 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=303 ttl=54 time=792 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=354 ttl=54 time=2002 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=355 ttl=54 time=1003 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=356 ttl=54 time=148 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=357 ttl=54 time=148 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=358 ttl=54 time=271 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=359 ttl=54 time=136 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=360 ttl=54 time=317 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=361 ttl=54 time=144 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=362 ttl=54 time=261 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=363 ttl=54 time=142 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=417 ttl=54 time=153 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=418 ttl=54 time=146 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=419 ttl=54 time=145 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=420 ttl=54 time=327 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=421 ttl=54 time=1000 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=473 ttl=54 time=561 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=474 ttl=54 time=148 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=475 ttl=54 time=147 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=476 ttl=54 time=142 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=477 ttl=54 time=468 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=478 ttl=54 time=151 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=479 ttl=54 time=511 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=586 ttl=54 time=2002 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=587 ttl=54 time=1002 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=588 ttl=54 time=142 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=589 ttl=54 time=140 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=590 ttl=54 time=414 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=591 ttl=54 time=540 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=592 ttl=54 time=536 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=692 ttl=54 time=1984 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=693 ttl=54 time=984 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=694 ttl=54 time=534 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=695 ttl=54 time=534 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=696 ttl=54 time=556 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=700 ttl=54 time=162 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=701 ttl=54 time=150 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=745 ttl=54 time=2017 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=746 ttl=54 time=1009 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=747 ttl=54 time=140 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=748 ttl=54 time=147 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=749 ttl=54 time=217 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=750 ttl=54 time=164 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=752 ttl=54 time=712 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=753 ttl=54 time=136 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=754 ttl=54 time=143 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=802 ttl=54 time=2876 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=803 ttl=54 time=1869 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=804 ttl=54 time=861 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=805 ttl=54 time=147 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=807 ttl=54 time=465 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=808 ttl=54 time=134 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=809 ttl=54 time=235 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=810 ttl=54 time=257 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=811 ttl=54 time=178 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=812 ttl=54 time=138 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=860 ttl=54 time=1002 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=861 ttl=54 time=340 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=862 ttl=54 time=134 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=863 ttl=54 time=282 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=864 ttl=54 time=304 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=865 ttl=54 time=329 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=866 ttl=54 time=136 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=867 ttl=54 time=270 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=868 ttl=54 time=293 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=916 ttl=54 time=1135 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=917 ttl=54 time=135 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=918 ttl=54 time=146 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=919 ttl=54 time=375 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=920 ttl=54 time=143 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=921 ttl=54 time=418 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=922 ttl=54 time=442 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=923 ttl=54 time=140 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=924 ttl=54 time=151 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=978 ttl=54 time=1595 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=979 ttl=54 time=595 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=980 ttl=54 time=144 ms

--- xxx.xxx.xxx.xxx ping statistics ---
1000 packets transmitted, 131 received, 86% packet loss, time 1001448ms
rtt min/avg/max/mdev = 134.313/517.850/2876.679/584.808 ms

Me - 29/09/2015 00:13Sorry to be frank, but I don't think I've ever seen such incredibly terrible routing as this. [...]

Me - 29/09/2015 00:20From www.ping.eu:

--- PING xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx) 56(84) bytes of data. ---
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=3 ttl=56 time=2004 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=4 ttl=56 time=1004 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=5 ttl=56 time=13.1 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=6 ttl=56 time=13.1 ms

--- xxx.xxx.xxx.xxx ping statistics ---

packets transmitted 6
received 4
packet loss 33 %
time 5002 ms

rtt min/avg/max/mdev = 13.144/758.953/2004.738/825.357 ms

Me - 29/09/2015 00:24From locaping.com:

Server Location Min RTT Avg RTT Max RTT Result
Malaysia, Kuala Lumpur, Kuala Lumpur - - - 100% packet loss.
Germany, North Rhine-Westphalia, Dusseldorf - - - 100% packet loss.
United Kingdom, England, London 4.775 155.937 307.099 OK.
Israel, Tel Aviv, Tel Aviv 60.656 60.694 60.732 OK.
Canada, Quebec, Montreal 81.382 81.404 81.427 OK.
Japan, Kanto, Tokyo - - - 100% packet loss.
France, Île-de-France, Paris - - - 100% packet loss.
Netherlands, North Holland, Amsterdam - - - 100% packet loss.
Singapore, Singapore, Singapore - - - 100% packet loss.

Me - 29/09/2015 00:31100% packet loss from https://www.site24x7.com/ping-test.html

Ping results:28 Sep 2015 11:29:11 PM
LocationStatusIPPacket Loss
(%)Min RTT
(ms)Max RTT
(ms)Avg RTT
(ms)Response Time (ms)
California - USxxx.xxx.xxx.xxx 100 - - - 0
Toronto - CAxxx.xxx.xxx.xxx 100 - - - 0
Singapore - SGxxx.xxx.xxx.xxx 100 - - - 0
Chennai - INxxx.xxx.xxx.xxx 100 - - - 0
Johannesburg - ZAxxx.xxx.xxx.xxx 100 - - - 0

So connectivity was globally atrocious with only 4 out of 36 hosts on 'Super-Ping' able to ping the IP at all, 86% packet loss from my home connection, some 'hilarious' results from ping.eu and more or less 100% packet loss from a few other test sites chosen at random. Seemingly this would suggest that any diagnosis of the problem will extend far beyond the results of a single traceroute from my home connection. The response?

Quote said:
Support - 29/09/2015 01:40Good day,

If you think that your server is having hardware issues, you can put it in Rescue Mode and run the hardware check to see if your RAM or CPU or HDD is having any kind of fault. Here's how to launch the rescue session:

1. Log into your Control Panel, and select the server if you have more than one.
2. Click on the "Netboot" button (top right corner of the panel)
3. Select the "Boot on rescue mode" option, and from the drop-down menu that appears, select rescue-pro. Click Next, and then click Confirm.
4. Click on the Reboot button in the Control Panel to restart the server in Rescue Mode.
5. The reboot will generate temporary access codes for the Rescue Mode session. They will be sent to your email.

More information here: http://docs.ovh.ca/en/guides-ovh-rescue.html

Thank you for choosing our services!

D
Customer Advocate.
FAQ: http://docs.ovh.ca/en/faqs.html

100% packet loss from almost everywhere in the world? Hrm, sounds like a hardware problem, why not try booting the server into rescue mode?

I responded emphasizing the insane packet loss again (as I probably hadn't done so enough) and asked them to forward the ticket to someone who actually reads the content of messages instead of just copy/pasting canned responses that have nothing to do with the issue at hand. The reply:

Quote said:
Support - 29/09/2015 21:51Good day,

Just to make this thing clear, do you have network or hardware issues with your server because all your tickets are not saying the same.

Do not hesitate to contact us back if you need more information.

Best Regards,

D
Customer Advocate.

I... I have other open tickets... and yes... it's true that each ticket contains different subject matter...

Alas, the concept of multiple tickets for different problems is too much and we have reached an either/or juncture. Is it a network or a hardware issue? Apparently you can only have one and it's up to me to find out!

Well, I've sent about 3 million ping tests from multiple locations around the globe so far and have a different ticket open regarding potential hardware problems (to which they replied with the same canned response as above). The situation is absurd, but I try to respond calmly.

Quote said:
Me - 29/09/2015 23:20I'm not entirely certain re: hardware issues yet, but it's certainly a network problem in this ticket.

To which I received this response about an hour and a half ago...

Quote said:
Support - 29/09/2015 23:33Good day,

I've seen the information you provided and the ping test is not enough to qualify this issue as packet loss. As already mentioned in my first message, we will also need a traceroute and Ipfer test:

-Results of a traceroute (preferably done with MTR) from your local host to your server.
-Results of a traceroute (preferably done with MTR) from your server to your local host.
-Results of the following command: iperf -c proof.ovh.ca -P 5 -r

Do not hesitate to contact us back if you need more information.

D
Customer Advocate.
FAQ: http://docs.ovh.ca/en/faqs.html

Right now I'm sincerely wondering if SyS's tech support is comprised of 'sentient beings'. Does anyone know? I would probably feel a bit better if it turned out I had been communicating with a primitive AI attempting to parse/interpret 'human input'.

Other than that, to their credit, I was given a 'better' server than the one I ordered. Bought something from their lowest priced range and was given an E3-1245v2 instead! How can I complain, right!?

HN-Matt · Sep 30, 2015

Another problem is there's no IPMI and they charge $30 per day for a KVM console. I didn't foresee this as IPMI is free with OVH's dedicated server line.

In other words, it seems I can't use any third party OS and am stuck with their custom OS templates?

Makes diagnosing certain problems a bit difficult to say the least.

I mean, come on, even SolusVM offers a console to every single VPS as a standard feature. It's not like it's some $30-per-day luxury to instantiate. I understand their prices are low, but I already paid the setup fee which was more than the monthly price of the server. There's no way I'm gonna pay an extra $30 just for the one-day 'privilege' of being able to install a third party OS!

EDIT: So you Start has now merged all of my tickets into one, lol. Usually I'll see tech support complain when different problems are all jumbled into the same ticket. 'One ticket per issue' etc. Not with SyS, I guess.

HN-Matt · Sep 30, 2015

More obliviousness and misdirection...

Quote said:
Support - 30/09/2015 07:10Hello,

In order to help you with your issue, we will need to see your network interface configuration of each IP failover:

For CentOS, we will need the /etc/sysconfig/network-scripts/ifcfg-eth0 or eth0:X

For Debian based OS, we will need the /etc/network/interfaces

We will also require to see the output of the following command:
ifconfig
netstat -nr

Also, please explain to us what configuration you are looking for. Is it IP Aliasing or IP Bridging?

We will be waiting for your response.

Thank you for trusting OVH and have a great evening!

For more information about IP aliasing please refer to our help page : http://docs.ovh.ca/en/guides-network-ipaliasing.html
M.
Customer Advocate

I'm not sure what copious packet loss from 52 different test sites around the world has to do with the "network interface configuration of each IP failover" at the level of config files in /etc/x.

The IPs are configured correctly (in fact, I eventually got them working by NOT following the generic guide at docs.ovh.ca). I can create VMs and connect to them. The VMs are able to communicate with the internet. The problem was staying connected because of copious packet loss, not misconfigured values in the OS...

On the verge of a chargeback now as I've wasted multiple days going nowhere with their support. I have a hard time believing the techs are that oblivious, it seems they are wilfully ignoring where the problem lies.

GIANT_CRAB · Sep 30, 2015

So you Suck

HN-Matt · Sep 30, 2015

very rude @GIANT_CRAB

IndoVirtue · Sep 30, 2015

HN-Matt said:
very rude @GIANT_CRAB

Instead of taking 'you' literally, it might be more like a word play of SYS (So You Start). If anything, he agrees with you. I might be wrong though, need @GIANT_CRAB to answer

wlanboy · Sep 30, 2015

SyS is Bad - Shit bYond compare.

Can'tbelieve their "support" responses...

TheLinuxBug · Sep 30, 2015

I will mention this, if the additional IP you ordered has a different subnet mask and/or gateway you may not have the routing setup correctly on your server. If this was the case you would see large amounts of packet loss. Of course I have never used SYS so I am just guessing here. If all the ips are in the same c-class, subnet and use the same gateway, then your right, this would have to be an issue to resolve from their side. The first thing I would do is remove the additional IP and see if the issue goes away. If it does, instead of telling them there is a problem, ask them for the correct network configuration to use when assigning the IP to the server, it could be that you are not correctly defining the route that data to and from that IP should take.

If you remove the IP and the issue continues, then I would say they have configured something incorrectly at the router and again I would mention that this issue has occurred since they assigned you that IP and ask them if there is possibly a configuration problem on their side.

my 2 cents.

Cheers!

KuJoe · Sep 30, 2015

Why not follow their directions in their original reply to help them? Fighting with them and refusing to help them doesn't help anybody. MTR results go a long way when troubleshooting network issues.

HN-Matt · Oct 1, 2015

@IndoVirtue lol I know / was only playing, but thanks for spelling it out. Beep boop double entendre 0 or 1. First fuzzy logic, then the world.

@TheLinuxBug there was only packet loss with a single failover IP. It was indeed in a different 'c-class'. Although I think you may have misunderstood the problem as adding/removing it had no effect on the other IPs (host node and other FO IP) which were not experiencing any packet loss. Smooth sailing except for a single IP.

@Kujoe you're joking, right? Any remotely competent support would have been able to at least begin troubleshooting this without requesting 'MTR' results, e.g. they could have quickly set up a test server and attempted to reproduce the problem by allocating a similar IP with a slightly different fourth octet. I doubt they bothered to check for themselves at all. Instead they told me that the issue didn't even 'qualify' as packet loss! If a client sends you fifty fucking two different locations experiencing 86 - 100% packet loss and you literally respond with "thats not enough to qualify the issue as packet loss" you're either a complete asshole or beyond oblivious.

Either way, I've had enough. The absurdity of their support responses alone are enough to make me never look back.

HN-Matt · Oct 1, 2015

To add some more perspective, I've bought hundreds of FO IP from OVH within the past year and am more or less satisfied with the quality and service. I've never had connectivity problems with any of them, not a single one, until now via SyS.

KuJoe · Oct 1, 2015

HN-Matt said:
@Kujoe you're joking, right? Any remotely competent support would have been able to at least begin troubleshooting this without requesting 'MTR' results, e.g. they could have quickly set up a test server and attempted to reproduce the problem by allocating a similar IP with a slightly different fourth octet. I doubt they bothered to check for themselves at all. Instead they told me that the issue didn't even 'qualify' as packet loss! If a client sends you fifty fucking two different locations experiencing 86 - 100% packet loss and you literally respond with "thats not enough to qualify the issue as packet loss" you're either a complete asshole or beyond oblivious.

Either way, I've had enough. The absurdity of their support responses alone are enough to make me never look back.

An MTR will show them where the packet loss is. You opened the ticket yet you're not willing to put any effort in resolving it? The ticket could have gone a lot differently if you just followed their request. Anybody who's ever called their ISP for tech support knows that step number one is rebooting the modem/router even though it's not going to fix most issues but we humor the script readers and do it so that we can get on to step two of troubleshooting or perhaps escalation. If their script says "do not escalate without an MTR from both directions" then you're only hurting yourself at this point. Sure, the tech could do this themselves but why should they? If nobody else is having a problem and you're the only one then why should they build a new server in hopes of reproducing a problem that is obviously not widespread? They're probably making less than $20/hour juggling dozens or even hundreds of tickets at a time so of course they'll be more helpful towards clients who don't fight them on something simple as an MTR showing where the packet loss is. Imagine how you'd feel if somebody opened a ticket with you, fought with you for hours, only to receive an MTR output showing the packet loss was occurring on their server and not their network? With tech support you need to pick and choose your battles and this was one battle not worth fighting and as a result you've wasted more time than you needed to (they're getting paid either way so the only loss is your own, then again it's your call if it's a loss or not but I personally see the dollar signs leaving my wallet if I had to make that many replies to a ticket with a data center like you did).

HN-Matt · Oct 1, 2015

"the script readers"

I see what you're saying @Kujoe but if their 'support' (if you can even call it that without cringing) can't respond beyond the cynicism of your speculations, then it's even more reason for me to cancel. If they're only functionaries who can't improvise beyond a script, why would I want to work with them to begin with?

Not all hosts are reduced to highly constrained script-reading contexts like the outsourced tech support for large ISPs (I used to do that exact job for Comcast in my early twenties... hated it).

Really, you can argue about 'MTR' or any other small detail re: 'what I should have done' until you're blue in the face, but in the end there's a minimum definition of 'support' that I'm willing to work with and they failed to meet it.

HN-Matt · Oct 1, 2015

KuJoe said:
With tech support you need to pick and choose your battles and this was one battle not worth fighting and as a result you've wasted more time than you needed to (they're getting paid either way so the only loss is your own, then again it's your call if it's a loss or not but I personally see the dollar signs leaving my wallet if I had to make that many replies to a ticket with a data center like you did).

By the way, this too. You don't 'pick and choose your battles' with any support team that is actually there to help. That's absolute nonsense. If you've reached the point where you're battling with those who you're paying for support, it's only another reason to get your money back and move on if anything.

That's what's so insulting about it. I'm paying them hundreds of dollars and for what? So they can waste my time while proving they're incapable of doing anything beyond the tunnel vision of scripted responses? No thanks.

DomainBop · Oct 2, 2015

HN-Matt said:
KuJoe said:

I'm paying them hundreds of dollars and for what? So they can waste my time while proving they're incapable of doing anything beyond the tunnel vision of scripted responses? No thanks.

Click to expand...

OVH's budget used equipment brands SoYouStart and Kimsufi only include a bare minimal amount of non-managed support for hardware problems and billing problems only. Nothing else besides hardware and billing assistance is included (and their support page says to ask all other questions on their forum). "Scripted responses" help keep the costs down and the bare minimal support levels they provide for those budget brands are the only reason they're able to offer their servers at those prices.

If you want something non-scripted with better support you need to get a full priced server at OVH instead of SYS, and if you want something with great support buy their VIP support package for €49.00 monthly (payable in annual payments only, so €588.00 each year). If you're running a business on OVH it's a good idea to get their VIP support package as an insurance policy in case something goes wrong (and it should go without saying you shouldn't try to run a business on SYS).

Quote said:
They're probably making less than $20/hour juggling dozens or even hundreds of tickets at a time so of course they'll be more helpful towards clients who don't fight them on something simple as an MTR showing where the packet loss is.

Their job posting for Level1/2 techs doesn't include a salary but if anyone needs a job they're hiring 20 more L1/L2 techs...4 week training period: https://www.ovh.com/fr/careers/sc_st_rbx1015-technicien-support-it

(list of all job openings: https://www.ovh.com/fr/careers/offres/?country=fr )

willie · Oct 2, 2015

Mtr in both directions is a standard request.... I had packet loss with a ramnode vps the other day and they asked for that. By the time I sent it the problem had cleared up, but at least it showed the issue was at their end. Matt your expectations are unrealistic. Just send the mtr's next time.

HN-Matt · Oct 2, 2015

@DomainBop I didn't realize SyS = 100% used hardware. Are you sure? As I wrote earlier, I have some full priced servers with OVH for business use and no problems there. Didn't imagine SyS would be so different.@willie obviously it was possible for them to do their own MTR or traceroutes. Super-Ping has a traceroute feature (http://www.super-ping.com/?traceroute=xxx.xxx.xxx.xxx&node=x) so they would have had the opportunity to do 36 different traceroutes from that site alone if they'd bothered to confirm what I sent. Ellipsis Node is even a sponsor so they could have done a traceroute from one of my nodes without having to ask me. Running traceroutes or MTR from multiple directions (why only 'both'?) would have been much more helpful than a single MTR from me. Especially with such insane worldwide packet loss which clearly suggests that any diagnosis shouldn't be isolated to a single location... and yet refusing to budge until that happened?

willie said:
Mtr in both directions is a standard request....

It is? Then why didn't they bother to do it?

Seriously, if a client is citing ridiculous packet loss from 52 different locations, how is it not 'standard' to imagine that support would first and foremost attempt to confirm it on their end? There is no 'sane' reason to isolate responsibility to the client in such circumstances. Refusing to help beyond forcing an MTR from one particular location in the face of worldwide packet loss without doing any tests of your own is not standard, it's stupid. I have no problem typing those three magic letters either, it was their scripted inflexibility to do so themselves that lost me. If that's all SyS's support is, then my mistake for renting from there to begin with.

KuJoe · Oct 2, 2015

HN-Matt said:
willie said:

Mtr in both directions is a standard request....

Click to expand...

It is? Then why didn't they bother to do it?

Seriously, if a client is citing ridiculous packet loss from 52 different locations, how is it not 'standard' to imagine that support would first and foremost attempt to confirm it on their end? There is no 'sane' reason to isolate responsibility to the client in such circumstances. Refusing to help beyond forcing an MTR from one particular location in the face of worldwide packet loss without doing any tests of your own is not standard, it's stupid. I have no problem typing those three magic letters either, it was their scripted inflexibility to do so themselves that lost me. If that's all SyS's support is, then my mistake for renting from there to begin with.

I understand why you think this, it's probably a foreign concept to most, but in reality it is more beneficial to the client and the provider if the client does the legwork before opening a ticket. We've had a lot of ticket where client go "OMG packet loss!" when the rest of the network is running fine and we make them do the traceroutes and MTRs so they can see where the packet loss is on their VPS or their home ISP (one of those "if you teach a man to fish" things). Sure, I could easily run the MTR myself but if I had to do that for every ticket then I'd just close up shop because for a $7/month VPS doesn't cover the cost of hand holding (even at my very reduced rate of $25/hour that I charge our clients if they insist on hand holding). If there's a definite problem with our network then yes, I'll be happy to invest hours of my time to resolve it but if one person is affected out of hundreds then they must show me that the problem is with our network and not their VPS before I can assist them. I even wrote a document for our clients to follow if they experience a network issue that I request they do before I even login to any servers, routers, or switches (link). SoYouStart is budget servers, if the techs there were to hold everybody's hand every ticket they would be operating at a loss since human support is easily the most expensive factor of operating a budget brand.

To clarify the "pick your battles" thing I mentioned above, it has to do with expectations also:

If I call up my home ISP for packet loss I immediately expect the person on the phone to read me a script and make me waste half an hour of our lives to go through the motions even if I tell them exactly what/where the problem is.
If I call up my work ISP for packet loss I don't ping a damn thing if I get an alert, I simply say "circuit is down" or "circuit is experience packet loss" and within 5 minutes I'm off the phone and they're working on it (for $10k+ a month they'll send a tech out to the site and do the traceroutes themselves)
If I open a ticket for a $2/month VPS I already provide them the traceroutes and MTRs in my first message along with telling them where the packet loss is (which hop) so when they make their first response (hopefully within 48 hours) they'll have all of the information I have available to me.
If I open a ticket for a $75/month VPS I have, I'm happy to just open a ticket on my phone with simply "Got an alert, please investigate" while I'm out and about without doing any general troubleshooting myself.

HN-Matt · Oct 2, 2015

KuJoe said:
I understand why you think this, it's probably a foreign concept to most, but in reality it is more beneficial to the client and the provider if the client does the legwork before opening a ticket.

I don't disagree, but 'in reality' it's also more beneficial to both parties if the host ~~does the legwork~~ goes beyond the scriptwork should the client not follow their script to a T, rather than stubbornly refusing to do anything at all until then (i.e. the definition of being unhelpful, inflexible and incapable of spontaneously adapting to different situations).

Quote said:
We've had a lot of ticket where client go "OMG packet loss!" when the rest of the network is running fine...

Sure, but your 'rest of the network' and OVH's are completely different. The latter is much larger and has service in Portugal, Ireland, Lithuania, Finland, United Kingdom, Germany, Poland, Belgium, France, Netherlands, Spain, Czech Republic, Italy and more. I had FO IP in multiple locations. It would be silly for their support to simply assume the rest of the network 'is probably running fine' if IP addresses on the same host node are experiencing extreme packet loss in one part of the world and not another.

KuJoe said:
and we make them do the traceroutes and MTRs so they can see where the packet loss is on their VPS or their home ISP (one of those "if you teach a man to fish" things).

Then what's the problem with asking them to do it after you? MTR isn't stupid, but needlessly forcing it into a script's anachronistic 'order of operations' and being 'unable to help' (i.e. being negligent and/or bullshitting your way through excuses) outside of that sure is!

Quote said:
Sure, I could easily run the MTR myself but if I had to do that for every ticket then I'd just close up shop because for a $7/month VPS doesn't cover the cost of hand holding (even at my very reduced rate of $25/hour that I charge our clients if they insist on hand holding).

Being competent enough to look into your own network's connectivity prior to forcing the client to do it first is not 'hand holding'. You're obviously lying, or at least I hope you are because lol if you get enough packet loss related tickets to end your business should you dare attempt an MTR for each one. You could have done like 1000 MTR tests in the time it's taken you to respond here.

Rather than bending over backwards to defend SyS's Eternal Right to never have to do any of their own MTR 'legwork' (lmao) prior to bizarrely isolating the responsibility to the client and awkwardly refusing to help otherwise, why not suggest they update their dumb scripts?

KuJoe · Oct 2, 2015

Quote said:
I don't disagree, but 'in reality' it's also more beneficial to both parties if the host does the legwork goes beyond the scriptwork should the client not follow their script to a T, rather than stubbornly refusing to do anything at all until then (i.e. the definition of being unhelpful, inflexible and incapable of spontaneously adapting to different situations).

It's not beneficial to anybody as you've clearly seen already. Offering tech support on a budget is what you've experienced with SYS already, the best way to make it work is to do the legwork yourself to avoid these kinds of tickets.

Quote said:
Sure, but your 'rest of the network' and OVH's are completely different. The latter is much larger and has service in Portugal, Ireland, Lithuania, Finland, United Kingdom, Germany, Poland, Belgium, France, Netherlands, Spain, Czech Republic, Italy and more. I had FO IP in multiple locations. It would be silly for their support to simply assume the rest of the network 'is probably running fine' if IP addresses allocated to the same host node are experiencing extreme packet loss in one part of the world and not another.

For every 1 ticket I get they probably get 100 and that's exactly why making the client do the legwork is where it becomes better for all parties. A simple MTR output could have prevented this thread and probably resolved your issue much quicker.

Quote said:
Then what's the problem with asking them to do it after you? It's not the MTR test that's stupid, but needlessly forcing it into a scripted 'order of operations' routine and being 'unable' to help (i.e. being negligent and/or bullshitting your way through excuses) outside of that sure is!

In this instance they probably do not have access to your server so their MTRs would not be apples to apples.

Quote said:
Being competent enough to look into your own network's connectivity prior to forcing the client to do it first is not 'hand holding'. You're obviously lying, or at least I hope you are because lol if you get enough packet loss related tickets to end your business should you dare attempt an MTR for each one. You could have done like 1000 MTR tests in the time it's taken you to respond here.Rather than bending over backwards to defend a support team's Eternal Right to never have to do any of their own MTR 'legwork' (lmao) prior to bizarrely isolating the responsibility to the client and awkwardly refusing to help otherwise, why not suggest they update their dumb scripts?

We have monitoring that tells us when our own network is having issues as I'm sure OVH has the same types of monitoring in place. If the issue was affecting more than a few people I would hope that the "script readers" would have simply told you so but since they didn't it's probably safe to assume the issue was exclusive to your service.

I'm not lying about the hand holding and not all tickets we receive are due to packet loss (A LOT of clients get blocked by firewalls on a daily basis) but if I had to login to a computer every time I wanted to answer a support ticket I would be losing a lot of money and closing up shop would be much more profitable for me. When a client opens a ticket about not being able to connect to their VPS, 99.999999999999% of the time it's because they either blocked themselves with their own firewall, our firewall blocked them for whatever reason, or their ISP blocked their access to their server. A simple traceroute/MTR would tell us exactly where they were blocked and I could get the whole thing resolved from my cell phone (where I answer the majority of my support tickets).

I'm just trying to show you another point of view on this situation so hopefully it makes more sense why they do the things they do.

So you Start - Sentient?

New Member

New Member

New Member

New Member

New Member

New Member

Content Contributer

New Member

Well-Known Member

New Member

New Member

Well-Known Member

New Member

New Member

Dormant VPSB Pathogen

Active Member

New Member

Well-Known Member

New Member

Well-Known Member