I have what Patrick would call "a wee bit" of experience with this problem; I led a dev team on a successful anti-DDoS product from 2001-2003. For now, I have two pieces of advice:
Advice #1:
Every major ISP has a tier of network engineer that is equipped to handle the DDoS problem. They're the ones with access to the traffic analysis tools, they're the ones with the scripts to deploy ACLs, they're the ones that can reroute traffic to a regional scrubbing center. If you're dealing with a real ISP, they have an anti-DDoS product (probably one I've very familiar with) deployed.
There aren't many of them and they are never the person answering the phone when you call the ISP. Nobody at your ISP has any incentive to escalate you to that person. Your ISP may deny that the person exists (I've seen that happen at ISPs where I know the right person by name).
Find that person. Be persistent. If I knew who mine was right now I'd send brownies and belgian ale. Weekly. Advance planning and cheap insurance can't hurt.
Advice #2:
Nobody knows what "I'm under DDoS attack" means. It doesn't mean anything. You have to be able to describe the attack precisely in technical terms. That doesn't mean "it's a SYN flood!"; it means, "My link is saturated, I'm getting N million packets per second, an unusually high number of connections sourced from TCP ports 15030 - 19012, it started 9 minutes ago, and doesn't coincide with a spike in requests to my DNS server."
In all likelihood, nothing you have deployed today is going to generate that information for you, so your job today is to get that infrastructure set up. I recommend getting NetFlow turned on and using Argus, which is free; NetFlow also happens to be a language ISP network engineers speak readily. You have other alternatives, like ntop. Just have something that can characterize traffic and ideally tell you (either directly, or via graphs) when things are out of the ordinary.
You will have much better luck getting help from your upstreams if you can write the ACL for them and make it easier to find what places in the network need it.
I can vouch for nTop. Really cool project. I did a bandwidth monitoring deployment for a customer who runs their own layer-3 network atop a carrier ethernet solution, but didn't have any plan in place for monitoring what goes over the wire. We found all kinds of fun stuff once we installed a few nTop nodes. Among the things we found: a Halo server to which employees from several different states were connecting and playing on a daily basis.
Advice #1:
Every major ISP has a tier of network engineer that is equipped to handle the DDoS problem. They're the ones with access to the traffic analysis tools, they're the ones with the scripts to deploy ACLs, they're the ones that can reroute traffic to a regional scrubbing center. If you're dealing with a real ISP, they have an anti-DDoS product (probably one I've very familiar with) deployed.
There aren't many of them and they are never the person answering the phone when you call the ISP. Nobody at your ISP has any incentive to escalate you to that person. Your ISP may deny that the person exists (I've seen that happen at ISPs where I know the right person by name).
Find that person. Be persistent. If I knew who mine was right now I'd send brownies and belgian ale. Weekly. Advance planning and cheap insurance can't hurt.
Advice #2:
Nobody knows what "I'm under DDoS attack" means. It doesn't mean anything. You have to be able to describe the attack precisely in technical terms. That doesn't mean "it's a SYN flood!"; it means, "My link is saturated, I'm getting N million packets per second, an unusually high number of connections sourced from TCP ports 15030 - 19012, it started 9 minutes ago, and doesn't coincide with a spike in requests to my DNS server."
In all likelihood, nothing you have deployed today is going to generate that information for you, so your job today is to get that infrastructure set up. I recommend getting NetFlow turned on and using Argus, which is free; NetFlow also happens to be a language ISP network engineers speak readily. You have other alternatives, like ntop. Just have something that can characterize traffic and ideally tell you (either directly, or via graphs) when things are out of the ordinary.
You will have much better luck getting help from your upstreams if you can write the ACL for them and make it easier to find what places in the network need it.