Hello Roland, >> I am thinking about dropping some (mainly ddos) traffic on the outside network borders with ACLs. > > ACLs don't work well as a DDoS reaction mechanism. They're good for protecting your network infrastructure: > > <https://app.box.com/s/osk4po8ietn1zrjjmn8b> > > S/RTBH is much better as a DDoS reaction mechanism:
I already thought about that (after trying out uRPF, before ever reading that term). My fear is that somebody creates blackholes in my network with spoofed source IPs. I think this is a potential damage amplifier and may cause much bigger impact than a flooding itself could ever do. I could black/whitelist something like 8.8.8.8, but I think there is no chance to build a list that will ever be sufficient for blackholing sources. I furthermore think I will run into problems as soon as I block anything from source xy in the complete network, i.e. also for customers that do not want their traffic to be filtered at all. > All the caveats folks have noted about ACLs hold true. But are there any experience reports / measurements in place ? For example how long does an upload of 100 rules via TFTP or SSH + activation of it take on a Sup2T ? Does it behave linear, exponential or will a set of 200 rules only take 10% longer ? Will there be an impact while applying it ? What about changing rules ? Will adding/removing take less or more ressources/time than just replacing the whole set with a new one ? That is the stuff I am interested in. >> Maybe it works if I use an ACL with 100k entries but it takes a minute >> to install. > > In what topological situation do you need 100K entries? Unless you're a > very large wholesale transit network trying to enforce anti-spoofing for > downstreams of your downstreams, do you really need that many entries? That was just a sample number, not an expectation. Maybe I will never need more than 100 entries, but I think it is important to know the limits before hitting them. ;) kind regards Rolf _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
