http://tools.ietf.org/search/rfc6192
has an excellent example recipie for juniper and cisco control-plane protection. it's a good starting off point and it covers the rational behind the various elements in detail. some things like my l2 policer were meant to solve invidualized needs there are probably examples in the wild albiet I can probably also dig one up. On 1/30/14, 10:03 PM, Misak Khachatryan wrote: > Thanks Saku and Joel for detailed explanations, > > Do You know any good resource to start with lo filters? Recommendations > about how much police several types of packets and so on. I don't want > to do much experiments on production network. > > joel jaeggli wrote: >> On 1/30/14, 6:46 AM, Saku Ytti wrote: >>> On (2014-01-30 14:35 +0400), Misak Khachatryan wrote: >>> >>>> Thanks Abhi, i saw this document, but i need real life experience >>>> about hardening thresholds or implementing additional >>>> filter/policers. >>> >>> In my experience there is some build-in unconfigurable policer to >>> limit how >>> many packets can hit control-plane. >>> Under attack, when IGP, BGP, LDP etc are all dead, the UI is happy >>> camper, >>> with control-plane CPU load in MX960 just few percentage, it should >>> be dying, >>> the global policer is just making attackers job easier by essentially >>> downgrading CPU performance. >>> >>> So it probably goes something like this >>> >>> traffic => if-filter => lo-filter => ddos-policer => >>> global-unconfigurable-policer >>> >>> Stock limitation to most DDoS policers are 20kpps, which is more than >>> enough >>> to bring MX960 to its knees >>> >>> If your DDoS policer can see good and bad traffic, low limit will >>> just make >>> attacking easier. It's mostly useful to catch things lo0 cannot >>> reasonably >>> protect like HTTP rate (you'd need <=4Mbps policer to have >>> accceptable pps), >>> BGP rate, etc and to catch non-IP stuff lo0 cannot handle and to fix >>> accidental errors causing flood of 'trusted/good' packets. >>> But in this case, you'd rather keep IGP and BGP rocking than >>> multicast, so I'd >>> police all non-critical to under 4kpps in DoS policer. For for >>> critical I'd >>> try to guarantee only good traffic passes lo0. >> >> A good solid control-plane protection acl with sensible rate limits is a >> good place to start. >> >>> Longer term, JunOS should adapt LPTS from IOS-XR, where each session has >>> unique policer, making sure that one session attacking does not stop >>> non-attacking sessions from working. >>> Shorter term JunOS should add PPS policers in FW filters for proper lo0 >>> filtering and configurable global policer (I'd just remove it >>> personally). >> >> iirc from arp-storm-land I set per interface policers at limits lower >> than those for the global policers (which are poorly or undocumented >> (and vary by release/platform)) but can of course be emperically >> determined. the upshot of that was the interface melting before the >> whole box did. >> >>> >>> >> >> >> >> >> _______________________________________________ >> juniper-nsp mailing list juniper-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/juniper-nsp >> >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
