If you look just to the normal situations...
1.2K vs 576K may not represent very much.

But if you look tho ARP Requests Graphs on a significative topology changing on a big IXP, and also look to CPU-per-process graphs, maybe what I'm suggesting could be more explicit.

I'm talking of good boxes freezing because of that.
Of course CoPP exists to avoid that. But the vanilla configurations of CoPP combined with lunatic ARP-Timeout causes many day-by-day problems...

So, in this case, the solution would but a BCP with some "MUST"s defining acceptable rates.

And with that, every that doesn't like to be waked up at dawn will become happy(at least by this reason).

Em qui., 17 de set. de 2020 às 15:07, Saku Ytti <saku@ytti.fi> escreveu:

On Thu, 17 Sep 2020 at 20:51, Douglas Fischer <fischerdouglas@gmail.com> wrote:

> Why should we spend CPU Cycles with 576K ARP Requests a day(2K participants, 5 min ARP-Timeout).
> Instead of 1.2K ARP Requests a day(2K participants, 4 hours ARP-Timeout)?
> I would prefer to use those CPU cycles to process other things like BGP messages, BFD, etc...

I think this communication may not be very communicative.

How many more BGP messages per day can we process if we do 1.2k ARP
requests a day instead of 576k? How many more days of DFZ BGP UPDATE
growth is that?

--
++ytti