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
Jesus, so you basically just take whatever he said?
Yes, you need a faster detection, and some extra capacity to take in shocks for a short time.A DDoS does not kick in suddenly with full force, takes some seconds to pick up, at times even minutes, so there is plenty of time to do the nulling, and if you have a cushion capacity, it will probably not be noticeable, and even if noticeable, nobody really expects 0 packet loss at any given time on a DDoS mitigation network.
I had 157 tickets in their system with 130+ related to nullroutes and this constant back/forth with them. There's so many MTR's/etc showing the packets traveling all of nlayer/GTT's network all the way to Portland and getting dropped at their own edge.
We provided so many MTR's from clients showing it dropping at CN's network. I mean, shit, if it's a UDP flood and you have no problems eating it at your edge, why not just apply ACL's for the most common protocols at the time (DNS AMP & NTP AMP)? It's still slamming away at their port so it isn't like 'theyre protecting their network'. Maybe they're protecting their filtering appliances but still, an edge ACL would handle all their UDP woes.
We had times where nullroutes were in place for well over a day before customers would bring up the IP being dead. We were never ticketed informing us the nullroute was put in place, nothing.
We never once in all the time we were with you had nullroutes come off automatically, we always had to nag you to handle it. Granted, you were always quick to handle tickets at all hours of the day, but it was incredibly annoying.
Listen, I'm bored and my copy of the newest Flash episode is done downloading. I'm going to go enjoy that while you come up with new ways of explaining how I've taken years off your life.
Francisco
Back in the day, the minecraft guys do complaint alot when these attacks affecting their games. So we had to do what we need to do. Please keep in mind that it was 2013, those SYN attack were pretty big.
It's in the flippin' traceroutes man! Read the freaking tickets!
493131 clearly shows the packets routing all the way through nlayer to SEA1 where it then drops. Why oh why oh why would nlayer allow a 40gbit flood to travel their whole west coast deployment?
Francisco
Thanks.
If Buyvm/Frantech only said how our mitigation suck, our support suck, our network suck, we wouldn't even bother to reply. We can't keep every customer happy.
But something like this " they hate the chinese (even though i'm fairly sure the owner is in China)." made up, we just can't tolerate. What world are we living in if we can't even come out and defend ourselves.
That's WHY I repeatedly said since you are not the one doing mitigation, you don' t know what's going on behind the scene. Those IPs were nulled UPSTREAM when they were actually getting attack and causing issues, after that the null route on upstream is removed and only nulled on our borders. It would be crazy that we don't push the null routes upstreams during big attacks, our customers would have kill us.
We didn't though. We didn't say any of those things.
We had no problems when we had proof that someone got smacked in the face with a large flood and got nulled. No problem, it happens, clients can pay up or wait it out.
The problems came when you're telling us the tales of the the Great Wall of DDOS that you...sank at your edge.
Francisco
Then address that issue only. I agree 100% it is not acceptable to single out people based on nationality, race, religion, sex, sexual orientation, disabilities, whatever, but you contradicted yourself here when invoking nationality in a technical issue.
As i said, how BuyVM handles their customers and content is entirely their business, you only need to provide a DDoS mitigation service which involves clear technical facts, such as IP addresses, PPS, bandwidth, timing, ACL, etc. You will never be asked by the police about their content, you have no legitimate interest in looking it up not to mention the nationality of their customers, period.
Upstream. At your edge.
I mean, hell, the freaking HOP has your ASN in the name: | as40065.ae2-415.cr1.sea1.us.nlayer.net - 0 | 4 | 4 | 168 | 169 | 171 | 168 |
Obviously upstream nullroute.
Francisco
Ask your Chinese customers see what they say about SF/private game servers, SF publish sites and DDOS attacks.
Here you go again, no race/nationality bias?
Jesus, did you even read what I typed? By the time you take that traceroute, the BGP communities are already removed, and the null is only on our edge. We even told you "and got some huge attacks last night."
Because obviously you guys don't believe SF/private game servers in Chinese get big attacks. But Chinese guys know. What's wrong with asking you to ask them since you guys don't believe what I said.
I have no doubt various types of content are attracting attacks, you are paid to mitigate them to a point and null past that. How does that make nationality relevant? Any customer looking for DDoS protection can get big attacks, if you cannot cope, look to another field of business, stop looking up content and nationalities, that will not solve the problem, will actually make it worse.
I'm sure @yhuza can comment on 私服/SF and ddos attacks if he's still here and assuming he's Chinese.
I did and my point still stands, why would you have a local nullroute if it isn't being sent upstream? If you went through the effort of removing the communities, why not remove the rest of the nullroute?
At this point we're going around in circles and my (literal) popcorn is done popping so I'm going to go enjoy Flash.
Francisco
OK, I repeatedly said you are not the one doing the mitigation, obviously you don't know what we do. We have auto system that removes null routes. AND we also manually review the attacks if they affected our network, that's where the manual null route on our edge happen. Carriers do have a limit of prefixes that announce to them, that's why we want to keep the prefixes announced to them minimal. Here it's the technical explanation.
Hey, we just want to protect our network and customers, and we know these are high risk customers that causes issues since we deal with them alot. It's not we can't cope, we gave buyvm a choice. We told buyvm to remove them or we have to terminate their service, it was their choice. We are not required to tank these big attacks for them, and we are not required to keep their service running when they are causing issues to other customers.
Hum, so this is poor planning if not plain overselling, you are taking more prefixes than you can handle and hope not all will need mitigation, which is why your approach will fail, I believe that a protected /24 will have at least 1 IP attacked at most times and only exceptionally not. If you do manage to get only customers in that exceptional situation, good for you, but blaming them for not selecting their customers better is counter-productive.
You didn't get my point, my point was they got big attacks that affected our network before our BGP announcement even takes effect. It has nothing to do with where the null routing is placed after the attack is stopped. We just keep it nulled on our edge so the attacker doesn't attack it again, and they didn't.
Make things simple
Attacker pours 40G SYN -> detected and nulled (already caused some issues) -> after some hours we remove the null route upstream and place it on our edge to make sure the attacker doesn't come back and attack again, and this attacker went through multiple IPs.
this is what happened when Buyvm/Frantech did the traceroute in that ticket, by the time they did that traceroute, it was already hours later. By the way, Voxility does handle null routes similarly.
Where were people getting 40gbit of SYN in 2013? Seriously, I had access to the bandwidth graphs at Awknet and he hosted half of efnet on there and I had long chats with Staminus and it was a cold day in hell if any of them saw a 10gbit SYN flood, let alone a 40gbit.
I would love to see that PCAP.
Francisco
If you had doubt then you should have questioned and asked for pcap and graph back then, you even have access to logs, but you never looked at them. see ticket #493131.
We did ask and we were told a PCAP wasn't possible in many instances.
Again, it's just the scales of things you keep bringing up. Christ, you could have a nice high end E3 at the time and you'd still have issues hitting a full 1M pps SYN on an E1k NIC. The NIC/E1K drive is going to fall over well before that but you're telling me someone got 40 boxes, at minimum, rimming pure SYN at some random site?
I mean, the best part of this all is we said screw it, moved our operations to Staminus, and we never, ever, had to terminate another client for this crap. Those same forums host with us and even up until early this year they ate only a few million PPS of SYN. Sure, that would've been over our filtering limit and that's worthy of a nullroute.
I mean, we had arguments in our very last days/weeks with you about some of these clients and we simply asked them to hold on if they could and we'd be away from it. Did they suddenly lose all their haters that quickly?
Francisco
You don't have anything to backup your claims.
But we have our tickets to backup ours. We never asked you to remove someone because they are Chinese, it was because they got big attacks who most of them happened to be Chinese. You are crazy if you think with that we hate Chinese. We have many Chinese customers, if we hate them we would not host them at all.
Anyone who don't believe Chinese SF/私服/private game server could get huge attacks, go ask other Chinese guys about SF/私服/Private game servers. Don't take this as racist.
All this while, you were trying to say this?
ProTip : As the history of this forum goes, disputing with @Maounique OR @Fransisco is an art by itself. And lucky you they have combined forces for you. I hope you are getting paid for all this...
I can't stop laughing right now. Here I though CNServers was a professional outfit... Now I'm getting worried about @Nick_A's Seattle deployments.
Francisco is a really good PR.
I can see there are many buyvm fans out there. Unfortunately, I was one of their unhappy customers: http://lowendtalk.com/discussion/comment/1017519/#Comment_1017519
RamNode is not BuyVM. Put it simply.
BuyVM probably made a huge profit from DDoS protected IPs and paid to CNServers just %10 and expected huge protection for small money.