<div dir="ltr"><div class="gmail_default" style="font-family:"courier new",monospace;font-size:small">About this comparison between CAM-Table Timeout, and ARP-Table Timeout.<br>I tend to partially agree with you...<br><br>Ethernet is a so widely used protocol to sever scenarios.</div><div class="gmail_default" style="font-family:"courier new",monospace;font-size:small">We need to consider the different needs of the type of communications.<br><br><br>For example:<br>I'm not a big fan of Mikrotik/RouterOS.<br>But I know they are there, and liking or not, I need to accept that I will need to deal with then(as a peer or even as an operator).</div><div class="gmail_default" style="font-family:"courier new",monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:"courier new",monospace;font-size:small">One of most common uses of Mikrotik is for HotSpot/Captive Portal.<br>And for that, an ARP Timeout of 30 seconds is very OK!<br>Is a good way to check if the EndUser is still reachable on the network, and based on that do the billing.<br><br>But 30 Seconds for an IXP? It does not make any sense!</div><div class="gmail_default" style="font-family:"courier new",monospace;font-size:small">Those packets are stealing CPU cycles of the Control Plane of any router in the LAN.  <br><br>Another example:<br>You suggested equalizing ARP-Timeout and MAC-Timeout<br>For a campus LAN? With frequent 

topology

changes, add/removes of hosts every time...<br>That is perfect!<br><br><br>But talking about an IXP LAN:<br>In an ideal scenario, how often should happen topology changes on an IXP?<br>How often new hosts get ins/outs of hosts in the and IXP LAN?<br><br>Why should we spend CPU Cycles with 576K ARP Requests a day(2K participants, 5 min ARP-Timeout).<br>Instead of 1.2K ARP Requests a day(2K participants, 4 hours ARP-Timeout)?<br>I would prefer to use those CPU cycles to process other things like BGP messages, BFD, etc...<br></div><div class="gmail_default" style="font-family:"courier new",monospace;font-size:small"><br><br></div><div class="gmail_default" style="font-family:"courier new",monospace;font-size:small"><br><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em qui., 17 de set. de 2020 às 02:54, Saku Ytti <<a href="mailto:saku@ytti.fi">saku@ytti.fi</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, 16 Sep 2020 at 23:15, Chriztoffer Hansen<br>
<<a href="mailto:chriztoffer.hansen@de-cix.net" target="_blank">chriztoffer.hansen@de-cix.net</a>> wrote:<br>
> On 16/09/2020 04:01, Ryan Hamel wrote:<br>
<br>
> > CoPP is always important, and it's not just Mikrotik's with default low<br>
> > ARP timeouts.<br>
> ><br>
> > Linux - 1 minute<br>
> > Brocade - 10 minutes<br>
> > Cumulus  - 18 minutes<br>
> > BSD distros - 20 minutes<br>
> > Extreme - 20 minutes<br>
> Juniper - 20 minutes<br>
> > HP - 25 minutes<br>
IOS - 4 hours<br>
<br>
Why are these considered (by Ryan) low values? Does low have a<br>
negative connotation here?<br>
<br>
ARP timeout should be lower than MAC timeout, and MAC timeout usually<br>
is 300 seconds. Anything above 300seconds is probably poor BCP for<br>
default value, as defaults should interoperate in a somewhat sane<br>
manner.<br>
Of course operators are free to configure very high ARP timeout, as<br>
long as they also remember to equally configure higher MAC timeout.<br>
<br>
-- <br>
  ++ytti<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><font size="2"><span style="font-family:"courier new",monospace">Douglas Fernando Fischer</span><br style="font-family:"courier new",monospace"><span style="font-family:"courier new",monospace">Engº de Controle e Automação</span></font><div style="padding:0px;margin-left:0px;margin-top:0px;overflow:hidden;color:black;text-align:left;line-height:130%;font-family:"courier new",monospace"></div></div>