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

Misak Khachatryan m.khachatryan at gnc.am
Sat Feb 1 02:16:12 EST 2014


Does anybody know how lo0.0 filter affects to other loopbacks and 
routing instances. To be more clear, i have lo0.0 as loopback for MPLS 
and internal MBGP, and routing instance with lo0.1 where internet lives. 
Also i have lo0.2 for NGN BGP MVPN for PIM.

Should I write filters specific for each lo and routing instance unit or 
lo0.0 is catch all for everything?

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 at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>

-- 
Best regards,
Misak Khachatryan,
Head of Network Administration
and Monitoring Department,
GNC-Alfa CJSC.


More information about the juniper-nsp mailing list