<div dir="ltr">I'm confused here, are you intentionally running larger MTU interfaces than the packet filter can handle with default config, and not wanting to change the tunable to fix the config for buffer size for the packet filter, or am I misreading?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 10, 2023 at 11:51 PM Mark Tinka <mark@tinka.africa> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 5/10/23 15:55, Tom Beecher wrote:<br>
<br>
>  That could just as easily happen today. Every OS release has all <br>
> kinds of changes to defaults, and frequently don't get caught until <br>
> they break something. Even if today's FreeBSD defaults worked for this <br>
> scenario, the next release could change to a value that doesn't.<br>
<br>
We implement a lot of user-defined changes to FreeBSD defaults via <br>
"/etc/sysctl.conf", as an example, whose unexpected change would not <br>
necessarily break anything as they would reduce scaled performance. We <br>
can live with that, because we can afford a reduction in performance <br>
until the fault is found, not an outright outage.<br>
<br>
The problem with doing this with something like a routing protocol - and <br>
in this specific case with FRR on FreeBSD for IS-IS - is that it would <br>
not be a reduction in performance if an unexpected change were to find <br>
its way into future revisions of FreeBSD... it would, in all likelihood, <br>
be a complete outage. That is a steeper price to pay, for us anyway.<br>
<br>
It's just about weighing the risks for one's particular operating <br>
environment, and for us, that risk is too high for a routing protocol.<br>
<br>
Mark.<br>
</blockquote></div>