Re: Best Linux (or BSD) hosted BGP?

[Tom Beecher <beecher () beecher cc>]

> The implication being that while it might work, it would make
> administration of the system onerous and unpredictable, considering we are
> dealing with a ton of FreeBSD installations, and not just a single server.

Adjusting a single tunable is 'onerous'? Ok.

On Tue, May 9, 2023 at 9:00 AM Mark Tinka <mark@tinka.africa> wrote:

> On 5/9/23 14:32, Tom Beecher wrote:
>
>
> Except you didn't exactly "call out limitations". You simply said :
>
> IS-IS in Quagga and FRR are not yet ready for business, is what I would
> > caution.
>
> The reality is that's not true.
>
>
> And just a few weeks prior, I had given an update about this very issue,
> as per attached.
>
> I figured if anyone needed more details (as I'd provided weeks prior),
> they'd reach out, like Bryan did.
>
>
>
> - You have a specific environment ( FRR on FreeBSD ) that has an issue
> with IS-IS.
> - You identified the issue in Apr 2020 as related to the size of the PSNPs
> being larger than the default BPF packet buffer size :
> https://seclists.org/nanog/2020/Apr/238
> - Although a solution was provided (
> https://seclists.org/nanog/2020/Apr/240 ) , you made an affirmative
> choice you didn't want to. ( https://seclists.org/nanog/2020/Apr/241 )
>
> You didn't say "I don't want to adjust net.bpf.bufsize because it would
> have negative impacts in my environment, so I need an option in FRR to
> adjust the PSNP size." You said "I don't want to."
>
>
> Ummh, not sure if you need help reading, but my exact words were:
>
>     "Probably could - but I'd prefer solutions that don't mess with the
> base
>     system, which ensures long term usability of FRR across future
> upgrades."
>
> The implication being that while it might work, it would make
> administration of the system onerous and unpredictable, considering we are
> dealing with a ton of FreeBSD installations, and not just a single server.
>
> You, somehow, read my response is me being petulant; which is entirely
> your right, of course. But I also won't let you make a false inference of
> what my response actually was.
>
>
> You are of course perfectly free to not make that change, and perfectly
> free to gripe that FRR development has not done what you asked. But it's
> pretty disingenuous to say that the software isn't "ready" strictly because
> of issues in your use case. That doesn't really help anyone.
>
>
> I made a statement, I was asked to explain, I did. There was historical
> context, even though I can't expect you to file all member's postings to
> memory.
>
> But if you want to let yourself get into your feelings, I can't help you
> there.
>
> Mark.