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

Saku Ytti saku at ytti.fi
Thu Jan 30 12:43:49 EST 2014


On (2014-01-30 09:18 -0800), joel jaeggli wrote:

> A good solid control-plane protection acl with sensible rate limits is a
> good place to start.

Absolutely. But FW policers are only bps not pps (trio hw is fully pps capable
and microcode etc, just lacks CLI).
You want to give scp, http, bgp more bps than the platform can handle with
small packets. scp and http could be solved with FW policer supporting pps,
but bgp can't really be solved without per-flow logic.

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

In distributed boxes it's dimensioned so that RE can take what every LC CPU
could try to punt it at the same time, so it can never ever be oversubscribed,
but often the limits are for RE many generations back and thus way too
restrictive.
I guess it's good the limits are there, for boxes which won't be configured by
operator, only one FPC will fail at a time, but it also feels they unfairly
punish those operators who actually configure the boxes and then end up having
downtime in situation which RE could have handled given the chance.
In centralized boxes like MX80 and MX104 the limiting makes no sense in any
case. MX80 is dead on 4Mbps (Mbps, not MBps) attack, with RE CPU sitting <10%.

-- 
  ++ytti


More information about the juniper-nsp mailing list