Hello,

I don't like posting complaints about companies i use, but i believe this one is warranted. You've probably noticed me recommend staminus around here, well i have encountered alot of downtime recently...

Right now they are experiencing some downtime, well not entirely but at least 75% packetloss:

traceroute to 65.215.***.*** (65.215.***.***), 30 hops max, 40 byte packets
1 FastEthernet6-0.civ-service1.Canberra.telstra.net (203.50.1.65) 0.511 ms 0.458 ms 0.313 ms
2 GigabitEthernet0-0-0.civ-core2.Canberra.telstra.net (203.50.10.129) 0.428 ms 0.333 ms 0.465 ms
3 GigabitEthernet4-0-0.dkn-core1.Canberra.telstra.net (203.50.6.126) 0.642 ms 0.493 ms 0.621 ms
4 Pos4-0.ken-core4.Sydney.telstra.net (203.50.6.121) 4.04 ms 3.823 ms 3.935 ms
5 Pos2-0.pad-core4.Sydney.telstra.net (203.50.6.22) 4.352 ms 4.082 ms 4.223 ms
6 GigabitEthernet0-1.syd-core01.Sydney.net.reach.com (203.50.13.246) 4.138 ms 4.055 ms 4.051 ms
7 i-9-6.wil-core02.net.reach.com (202.84.249.245) 173.662 ms 173.589 ms 173.582 ms
8 p7-0.lsanca2-cr2.bbnplanet.net (4.25.112.29) 172.33 ms 171.982 ms 172.136 ms
9 POS4-0.BR1.LAX9.ALTER.NET (204.255.169.117) 175.111 ms 174.896 ms 175.08 ms
10 0.so-0-1-0.XL2.LAX9.ALTER.NET (152.63.113.18) 175.113 ms 175.159 ms 175.161 ms
11 0.so-3-0-0.XR2.LAX9.ALTER.NET (152.63.115.165) 174.945 ms 174.831 ms 174.757 ms
12 190.ATM4-0.GW1.LAX9.ALTER.NET (152.63.113.33) 192.455 ms 192.639 ms 192.654 ms
13 Staminus-gw.customer.ALTER.NET (157.130.225.166) 199.559 ms 212.917 ms 197.256 ms
14 core01.irv.staminus.net (65.215.***.*) 181.682 ms * *
15 65.215.***.*** (65.215.***.***) 190.029 ms * *

Also look at this:

Interruptions in this service:
Service http went down at Fri Aug 16 15:30:07 EST 2002
Service http is backup at Fri Aug 16 18:30:09 EST 2002
Service http went down at Fri Aug 16 23:31:17 EST 2002
Service http is backup at Sat Aug 17 08:00:30 EST 2002
Service http went down at Sun Aug 18 23:31:34 EST 2002
Service http is backup at Mon Aug 19 03:30:05 EST 2002
Service http went down at Mon Aug 19 14:00:18 EST 2002
Service http is backup at Mon Aug 19 15:30:05 EST 2002
Service http went down at Tue Aug 20 04:30:06 EST 2002
Service http is backup at Tue Aug 20 05:00:10 EST 2002
Service http went down at Thu Aug 22 19:31:36 EST 2002
Service http is backup at Fri Aug 23 10:00:18 EST 2002
Service http went down at Wed Aug 28 07:30:04 EST 2002
Service http is backup at Wed Aug 28 08:30:06 EST 2002
Service http went down at Wed Aug 28 09:00:06 EST 2002
- still down....... its 11:52 EST now...

Pinging 65.215.***.*** [65.215.***.***] with 32 bytes of data:

Reply from 65.215.***.***: bytes=32 time=78ms TTL=244
Request timed out.
Request timed out.
Reply from 65.215.***.***: bytes=32 time=63ms TTL=244
Request timed out.
Request timed out.


Ping Statistic :
Packet Sent = 6
Packet Received = 2
Lost = 4 <67% loss>

I am not paying for cogent based dedicated server, i am paying a very decent price for a managed server. (decent price means, its not one of those 199 for 500 gb deals).

I need your opinion on what i should do..

Regards,
edude

Contact them, get an answer. If you think it's bull**** or they aren't handling it properly. Switch. Otherwise if they've been good up to this point, give them a bit to fix it. However, if they don't. I'd switch.

Every host has their moments.

Jason i have tried :( but i cant get through to the number, probably on my side since i am in australia and international calls are horrible from here :( but do you think this amount of downtime is norm? they guarantee a 99.9% uptime.

well how long have you been experienceing packetloss now?
btw. the httpd could go down on your server, which doesn't mean that the network is affected in any shape. it would be just the httpd process.
so eventually you may want to take a look at your server too?!

greets,

hehe i have already checked, httpd is fine..

there main site is down aswell, run a tracert to staminus.net see for yourself...

httpd process is fine..

I have been experiencing packetloss for 2-3 hours now..

also httpd cannot be causing packetloss..

Jason i have tried but i cant get through to the number, probably on my side since i am in australia and international calls are horrible from here but do you think this amount of downtime is norm? they guarantee a 99.9% uptime.

I do not pay $199.00/mo for those 500GB deals, that doesn't even pay for the bandwidth that I use.

I also expect 99.99% uptime, and my providers have yet to fail me. Every bit of downtime that I've had, was because of my fault. (And that's not even much and It was fixed properly) except one time.. the router was dropping Valid SYN packets because it was getting DOS'd really hard. But it was fixed within 8 minutes.

I've never had prolonged packetloss. I wouldn't stand for it. Nor would my customers. If I was paying for Cogent .. I would have too. But I do use Cogent for some audio streaming, and I never have any problems with it like the people do on this board.

I do however, think that your provider is a new host. They will go through some issues and there's not much anybody can do about it.

YOU have to do what's best for your customers or your websites.

if you're running redhat 7.3 or the latest kernel (2.4.19?) and CPanel/WHM, your httpd is gonna yoyo like a bat out of hell, why exactly, im not too sure, but it's a pattern i've noticed recently.

Aside from that, are you sure staminus hasn't got a shellbox on their local network, they do quite a bit of shell stuff, thats the only thing i could think of that would concern me with that one edude, i know how you feel though (having uplink woes myself, a very rude cisco tech on the uplink, hate rude people).

There's a EFnet server on one of the local networks that I'm on, I don't see downtime or packetloss.

traceroute to staminus.net (65.215.220.10), 30 hops max, 40 byte packets
1 FastEthernet6-0.civ-service1.Canberra.telstra.net (203.50.1.65) 0.366 ms 0.42 ms 0.31 ms
2 GigabitEthernet0-0-0.civ-core2.Canberra.telstra.net (203.50.10.129) 0.392 ms 0.302 ms 0.29 ms
3 GigabitEthernet4-0-0.dkn-core1.Canberra.telstra.net (203.50.6.126) 0.59 ms 0.444 ms 0.45 ms
4 Pos4-1.ken-core4.Sydney.telstra.net (203.50.6.69) 3.883 ms 3.838 ms 3.894 ms
5 Pos2-0.pad-core4.Sydney.telstra.net (203.50.6.22) 4.027 ms 3.985 ms 4.055 ms
6 GigabitEthernet0-1.syd-core01.Sydney.net.reach.com (203.50.13.246) 4.041 ms 4.024 ms 3.924 ms
7 i-9-6.wil-core02.net.reach.com (202.84.249.245) 173.754 ms 173.599 ms 173.594 ms
8 p7-0.lsanca2-cr2.bbnplanet.net (4.25.112.29) 171.977 ms 171.953 ms 172.121 ms
9 POS4-0.BR1.LAX9.ALTER.NET (204.255.169.117) 175.099 ms 175.037 ms 174.947 ms
10 0.so-0-1-0.XL1.LAX9.ALTER.NET (152.63.113.10) 174.809 ms 174.786 ms 174.784 ms
11 0.so-3-0-0.XR1.LAX9.ALTER.NET (152.63.115.157) 174.967 ms 174.96 ms 174.945 ms
12 191.ATM6-0.GW1.LAX9.ALTER.NET (152.63.113.25) 175.583 ms 175.092 ms 175.118 ms
13 Staminus-gw.customer.ALTER.NET (157.130.225.166) 212.947 ms 199.223 ms 212.748 ms
14 * * *
15 web1.staminus.net (65.215.220.10) 193.78 ms * 205.605 ms

to staminus.net's site.

Originally posted by jayjay
There's a EFnet server on one of the local networks that I'm on, I don't see downtime or packetloss.

Which efnet server is that?

efnet servers are packet magnets, it must have a lot of preventative measures to prevent there from being downtime/packet loss as most get packeted weekly it seems (though it has died down a lot since efnet got services and made packet kiddies attacks very futile).

What are you talking about, Jason?
edude's in AU. I'm in US with the same results.

08/28/02 12:11:40 Fast traceroute 65.215.220.10
Trace 65.215.220.10 ...
5 144.232.18.229 921ms 292ms 186ms TTL: 0 (sl-bb23-fw-10-1.sprintlink.net ok)
6 144.232.18.242 1102ms 223ms 198ms TTL: 0 (sl-bb20-ana-8-0.sprintlink.net ok)
7 144.232.1.46 952ms 215ms 208ms TTL: 0 (sl-gw23-ana-9-0.sprintlink.net ok)
8 160.81.103.46 966ms 344ms 238ms TTL: 0 (sl-savvis-14-0.sprintlink.net ok)
9 64.240.66.6 816ms 217ms 220ms TTL: 0 (stamin-1.savvis-internet.uslsan2-j20c.savvis.net.66.240.64.in-addr.arpa probable bogus rDNS: No DNS)
10 65.215.220.2 750ms * * TTL: 0 (core01.irv.staminus.net ok)
11 65.215.220.10 791ms * * TTL:249 (web1.staminus.net ok)

You're on EFnet. I've talked with you before you started prioritycolocation.

Which efnet server is that?

irc.servercentral.net

Seiki runs it. /join #irc.servercentral.net

efnet servers are packet magnets, it must have a lot of preventative measures to prevent there from being downtime/packet loss as most get packeted weekly it seems (though it has died down a lot since efnet got services and made packet kiddies attacks very futile).

Yup. It's a new link, so it's got hit alot. But no damage.

What are you talking about, Jason?

What are YOU talking about? :)

I never said Staminus wasn't having problems.

from voxel:

traceroute to staminus.net (65.215.220.10), 30 hops max, 38 byte packets
1 207.99.115.1.voxel.net (207.99.115.1) 0.627 ms 0.351 ms 0.428 ms
2 a9-0-1070.msfc1.nyc.nac.net (209.123.11.57) 1.966 ms 2.659 ms 3.124 ms
3 nycmny2lce1-atm.wcg.net (64.200.86.149) 1.919 ms 1.654 ms 1.997 ms
4 nycmny2wcx3-oc48.wcg.net (64.200.87.109) 1.912 ms 2.097 ms 2.891 ms
5 chcgil1wcx3-oc48.wcg.net (64.200.240.37) 25.296 ms 25.160 ms 25.216 ms
6 chcgil1wcx2-oc48.wcg.net (64.200.103.77) 25.019 ms 24.768 ms 25.226 ms
7 at-0-2-271.uschcg-j20c.savvis.net (64.243.47.17) 25.992 ms 27.477 ms 27.153 ms
8 at-0-2-0.902.ussfnc2-j20c-1.savvis.net (64.242.22.138) 86.119 ms 85.341 ms 84.150 ms
9 216.88.159.186 (216.88.159.186) 110.249 ms 92.822 ms 128.625 ms
10 * * *
11 * web1.staminus.net (65.215.220.10) 110.751 ms *

Originally posted by jayjay
You're on EFnet. I've talked with you before you started prioritycolocation.



irc.servercentral.net

Seiki runs it. /join #irc.servercentral.net



Yup. It's a new link, so it's got hit alot. But no damage.

Yep,

Used to be more fond of efnet then i am now i have to admit, i at one time had a botnet of 50 bots, for a popular channel over around 20 different shell providers (all legitimate bots mind you), one day a packet kiddie came along and downed the entire thing, and another 40 that were also oped, pretty depressing, must better with services now (as now i only have like 10 bots, would hate to see what might happen there)

Still heaps of packetloss, i guess everyone is on holidays. :(

That's too bad edude because you were praising them highly before. Rightfully so, because the results were good. I trust you'll get it sorted.

Gary

Yes, they were good, but this happened once before, i still had them in high regard, after he personally guaranteed me it wouldn't happen again few days later it happens again.

Originally posted by Editor
That's too bad edude because you were praising them highly before. Rightfully so, because the results were good. I trust you'll get it sorted.

Gary

edude: they specify a reason it happened the first time?

Yes,

he said they were DOS'ed but the firewall held the DOS attack out, but after the DOS attack there was a bug in the firewall :confused:

Pinging staminus.net [65.215.***.**] with 32 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.


Ping Statistic :
Packet Sent = 6
Packet Received = 0
Lost = 6 <100% loss>

YAY!

Results seem to be getting heaps better :D

Most places don't get DoS'ed unless they have irc connections going on. We got hit the other day, nasty little thing, found the box, disabled it, and shipped it back to the customer (was a colocation client), only way to reduce DoS attacks IMHO is to reduce the appealing targets.

ow come on, don't make irc look like a place full of packet kiddiots.
that just ain't true unless your in the wrong channels, doing wrong things, :rolleyes: you pretty won't recognize anything of these attacks.

Issue has been resolved..

network is fine now.

There was configuration issue in one of the routers. Connection table max was set too low and auto configuration script had it misconfigured. As a result, packet loss incurred. The auto notification scripts only notify in case of outage, and not packet loss, thus not reporting the problem. The problem was fixed this morning and the auto configuration scripts were repaired to prevent the issue from happening again.

Credit is being issued as 1/3 next month's payment for jeopardizing our availability guarantee.

A few things:
We do not allow high volume irc-related servers. Our network has an automated DOS suppression system in case of an attack.