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.
Interserver Network Issues
I think I remember seeing Interserver lurking on here.
Anybody else with servers with Interserver seeing horrible connection throughput and outages?
I have a ticket open with Interserver, but the last response was 2 hours ago. Meanwhile the server's been up for maybe 2 minutes of those 2 hours.
Comments
Same problem with contabo St. Louis, range of ip 207.244.xxx.xxx, some nodes of netcup, ovh and others. A global network problem maybe?
It came back up for about an hour, but now we're back to the up and down we had all afternoon.
The damning thing is the lack of communication. Not a peep from anyone with Interserver.
@interservermike
We have seen an increased number of complaints over the last few days, but everything looks normal on our side. No solid leads to go on yet that we can test and reproduce. Maybe one of our upstreams is having problems.
I rebooted the server and it seems to be working now. But it also worked fine for about an hour or so before, so I'm not holding my breath.
Sounds good. We will continue to monitor here as well.
I experienced a similar issue with a VPS and wrote in about it a couple of days ago. The problem was with very poor outbound performance and about 5% packet loss to a nearby (NYC area) destination. I couldn't pin it down to any particular network hop; it was as if something was interfering with this specific traffic.
Interestingly, the issue was completely absent from a different Interserver VPS.
It seems to have disappeared for now.
Starting again now
I think I found the issue.
A website on the server was getting absolutely pounded with hits and it had flooded the TCP stack. I have taken measures to mitigate this.
This is also why I hate CloudFlare. Website was behind CloudFlare, so of course the IPs being reported by the web server weren't the actual IPs connecting to the server. You can block those IPs on the server to your heart's desire, but it ain't going to do anything.
Customer and website owner is obviously oblivious to the incident, so they're not going to log into their CloudFlare account and do anything.
Maybe the paid CloudFlare plans do something to stop stuff automatically, but the free plan does nothing.
CloudFlare in a shared hosting environment is just not something I recommend - because of these reasons.
Now anybody else on the server that is using CloudFlare will not be able to access their website. But such is the price to be paid for using a service that meshes all of it's users into one.
You know you can use forward headers to get the real IP from Cloudflare visitors you know? Using CF-Connecting-IP for example. Then block them on your web server.
If you need assistance in this you can request mitigate be activated for 24 hours with synproxy on port 80 / 443 enabled. Cloudflare complicates this a bit but the protection works under most synfloods even behind cloudflare. If you know the site, and have cloudflare access though, site under attack mode usually will kill it.
You can't block them with iptables.
You can block them at the web server level, but that's still going to take CPU cycles.
If you use mod_remoteip or other measures to reveal the user's real IP address, that's all fine and dandy in the web server logs. But that's not the IP that is actually connecting to the server. The actual IP will be something like 172.68.174.197. If you put the user's real IP, what mod_remoteip shows in the web server logs, in iptables to block... you'll still see that IP hitting the account because you didn't actually block the connecting IP.
Maybe CloudFlare is great if you're the server administrator on the server that your website is hosted on. Then you have a vested interest in maintaining the server and keeping it up. But for shared hosting... most clients use CloudFlare because of ... reasons, or they read it on a blog some where. They set it and forget it. And then the server administrator (me) has to deal with the fallout.