BFD for routes learned trough Route-servers in IXPs

Thu Sep 17 18:20:45 UTC 2020

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 at ytti.fi> escreveu:

> On Thu, 17 Sep 2020 at 20:51, Douglas Fischer <fischerdouglas at 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
>

-- 
Douglas Fernando Fischer
Engº de Controle e Automação
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200917/9c44df98/attachment.html>