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
I was wondering when will be your turn @Nick_A ...
At least we were partially hit, here only IPv6, there only one node, but others were completely down for a long time...
@apollo15 Pretty sure tim uses what francisco made, but BuyVM have been Improving and adding to it.
I think @KuJoe developed his own.
Most likely yes, but I doubt he developed his own pps and gbps accounting like Fran did
Nope, Tim's using a very old one our old dev created. It's perl based and is quite terrible.
I met up with the dev when I was in San Jose and we both ranted about how poorly it performs and how much CPU it sucks down.
what we use is a complete rewrite in a different set of languages and works much faster. On top of that the readings we mail to our clients are accurate instead of hitting a 30 - 50k 'max'.
Old autonull ate well over a core and only caught about 10% of the traffic coming in, where as the new ponynull eats about a gig of RAM and ~40% of a core spread over all availabel cores and gets 90%+ of the traffic.
Francisco
So he bought it from your dev ?
Anyhow, could your Vyatta nullroute if your whole port gets full / if Vyatta IP gets 90%+ packet loss? I assume you still need some available port to pass over the community nullroute string over to datacenter router and transit, assuming the script runs directly on Vyatta, not based on external collector system? Always wondered that.
Far as I know Tim didn't pay anything and the dev simply gave him it.
Remember there's 2 ways for a port. Even though your inbound can be maxed, you're still able to send out the BGP community.
The code works on any platform, probably even windows if you tweaked it enough.
I moved away from it because there's many flood types it misses that we've been wacked with. It isn't a fault of the developer, these floods weren't common ground back when he did this development.
Our new one being that much more responsive was a side effect of my coding styles
Francisco
Thanks for information Fran, appreciated
EDIT: How about legit high PPS that don't cause any packet loss? It would be probably worth to implement an extra if packet_loss > 30 or 40% to destination IP just to prevent false positives, but you probably have that worked out somehow already. Just saying my crazy ideas, may actually help someone :P
Maybe, but i'm assuming Tim has his rates at a reasonable value so it wouldn't trigger false positives.
It's rare that we get false positives since we set things reasonable high. (read: We aren't hosting any sites that get 50,000 connections a second).
Francisco
Fair enough, but it reminds me of Hetzner autonull which blocks IPs for doing backups. They would definitely need to check for packet loss before nullrouting people for storing backups :P
Luckily I'm in the same boat with erichi. I don't have much experience with VPSs and only own one through hostigation on their Charlotte servers. Currently just using it to host a few web development projects and try out new services and such. So, no I can't comment on the quality of the service, because really I'm not really pushing the box that hard:) BUT I can comment on their customer support, overall uptime for the past 6 months @ charlotte, and the groovy speedy UI. -- and all of which are top notch, couldn't ask for more.
Obviously the amount of attention that this thread has gotten proves to me one thing.. hostigation did something right
Personally, I'm willing to forgive any provider a few times as long as they've made it up to me with an excellent service.
Noob out.
Actually sounds like Hetzner's usual action of selling servers, but then not actually allowing you to do anything with them :P
Maybe it's their business plan, who knows j/k :P
Unfortunately we do and there are some 3 VPSes like that on a single node it gets like 200 k pps at times in total without DDoS. I leaned hard on the owners and that is much down, but still they have spikes. Didnt have much of an effect on the node, though, It starts to choke at about 700 k from what I saw during DDoSes on similar nodes.
Of pure SYN? Not on an OVZ you aren't. Things like conntrack will melt well before that even if tuned a lot.
ACK packets don't count since a single speedtest run can hit 100k pps alone.
Francisco
What kind of hardware are you running that can sustain 700k pps!?
DDoS traffic != normal traffic.
I saw a packet loss on the Node during only 30k PPS of pure SYN - checked with vnstat.
@Maounique how do you know exactly, how did you count 700k :S ?
10G.
Counted at router level. Before was 700 k it was still some traffic, when went over, it died.
Had 3 mil attacks iirc, but, of course, no node can sustain that.
Had outgoing attacks at hundreds of k going.
DDoS is a very ugly business, this is why we do not offer any protection against it, only null and suspend, but that is a protection for the other ppl, not the victim.
I hope there will be one big company in EU to provide traffic scrubbing at affordable prices with bw like OVH and big cpu power.
Yes, but what when you as hoster get attacked and one abuses your system, and makes you nullroute & suspend one IP once a few days until you run our of clients? It happens, some people around here are in the business for it, especially in the UK market.
What router was that btw? Pretty sure Vyatta would die completely at 3M.
@apollo15 Vyatta comercial can handle 8Mpps per core?
at core we use an extreme networks x480 with 4 10G port module for both L2 and L3. It should be able to handle 100M pps on paper.
Nope.
Their fastpath stuff isn't out in any form yet.
They claim it will be able to do that at some point, but considering brocade owns them now I expect that technology to go away.
Francisco
Hope we dont test that too soon...