[j-nsp] MX480 RE-S-2000 IGMP flood

[joel jaeggli]

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.

> 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 308 bytes
Desc: OpenPGP digital signature
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20140130/faf6ade7/attachment.sig>