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

[Misak Khachatryan]

Thank You very much,

I've also googled these, look very useful:

http://www.juniper.net/us/en/community/junos/training-certification/day-one/fundamentals-series/securing-routing-engine/

http://cyruslab.net/2012/12/16/juniper-networks-default-configuration-hardening/

http://forums.juniper.net/t5/Management/Juniper-Device-Hardening-amp-Best-Practices/td-p/125185


joel jaeggli wrote:
> 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 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.