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
Bump & Dump .Co
Are they getting ddosed? We've been a target as-well if they have.
If they are & they're using OVH, traceroute would show the traffic being redirected for scrubbing. The traceroute path looks pretty normal for OVH.
goodhosting.co down here
No issues at OVH BHS here.
That appears to be correct.
What a traceroute would look like if a server is under DDoS attack http://forum.ovh.co.uk/showthread.php?6884-Anti-DDoS-exemples-of-traceroutes
Well, you know according to @GoodHosting they are in different
dcrackIt would also look like that when VAC is turned on permanently
It would also look like that when VAC is turned on permanently
Also: No issues with OVH in the BHS Datacenter (using ovh myself)
Oh yeah, I forgot about that, thanks for mentioning it.
I can ping my server with them, and i do not see any interruptions
must be Canada Day.
No website DNS entry,
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> www.goodhosting.co
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 36037
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.goodhosting.co. IN A
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> goodhosting.co
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 30487
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;goodhosting.co. IN A
;; Query time: 5027 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Aug 2 15:24:11 2014
Again with the DNS Issues, Where is he...
Probably gone for the week again
no, this time it's the entire subnet. probably their single leased server ("we have multiple nodes" lol) kernel panicked or something
http://www.timeanddate.com/holidays/canada/
Maybe he's out celebrating early.
Or maybe it's 3AM on a Saturday and OVH decides to "mitigate" an entire account from only a single IP address infringing on the network. They apparently don't know what "nullrouting" is, or how to implement it. Instead they would rather reboot all the machines into rescue-FTP and refuse to hand over credentials, whilst demanding we remove the infringing client with no means to do so.
Currently on line with some techs about this and dealing with the issue slowly.
Oh boy, What was this "Client" doing, If you don't mind telling us all?
I've got about 40 emails saying he was DDoSing between the hours of 1AM and 3AM, right up until they mitigated the account. Varying rates are reported between 79Kbps to 483Mbps at the peak. I can understand nullrouting an IP when something like this happens, but the entire account?
Lots and lots of:
OVH themselves could block the IP address from transmitting (reaching) outside of that Top of Rack Switch, thus completely mitigating the attack from its source. They can just stop the IP address from leaving the network, or block all traffic originating from/to it, etcetera.
That is what they have done in every situation for me. They have never blocked the entire node for 1 random IP behaving badly, in my experience.
My understanding is this is all automated and no OVH staff intervention is required for this to occur.
You have a fair point, I have no means myself of knowing if they could have blocked it earlier or not, but I don't think my 500Mbps (at peak) attack could have been "jeopardizing the network", especially under 200kpps as I've been told the attack was.
Here I would have thought, until they opened a new subject-less ticket to me:
Then proceeded to take the account offline.
Not just that, but they disabled IPMI to all machines as well:
this thread was started at 2:13 PM EDT. let's be generous and say that OP was delayed an hour and 15 minutes or so in making the post (highly unlikely).
last I checked, Canada's time zones do not include UTC-10. has the company now moved to Hawaii?
edit: oh, and also, bridging the network connection and/or giving full speed to everyone -- not a brilliant idea.
The issue has been settled.
You're hosting with OVH. My sympathy for you is nonexistent.
So you've decided to just keep the site down then?
Because it doesn't work. Neither does ns1.goodhosting.co nor ns2.goodhosting.co.
As you'd understand DNS takes some time to kick back in. The nameservers are resolving on my end (Google DNS, albeit I had to flush the local cache as well as Google's copy via their tool.)
https://developers.google.com/speed/public-dns/cache