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

Saku Ytti saku at ytti.fi
Thu Jan 30 09:46:19 EST 2014


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.

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).



-- 
  ++ytti


More information about the juniper-nsp mailing list