Best Linux (or BSD) hosted BGP?

Tue May 9 12:32:08 UTC 2023

>
> I think we all appreciate how open source projects work. Calling out
> their limitations is as old as mailing lists. I don't code. I test a
> lot, and continue to test IS-IS in FRR on FreeBSD every year or so. I'll
> keep testing and giving feedback at least once or twice a year. If it's
> still broken, I'll call it out.
>

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.

- 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."

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.

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

>
>
> On 5/9/23 00:03, Jeff Tantsura wrote:
>
> > Saying that IS-IS in FRR is broken is incorrect, that it is in many ways
> weird - no offense to folks who coded it :)  (especially if you have worked
> with commercial code bases), that it doesn’t scale/naive, missing features
> - for sure.
> > FRR runs today some of the biggest DCs in the world and is reasonably
> stable within the feature set used (RFC7938), there’s interest in further
> IS-IS development - you could see some minor bug fixes/features coming from
> a particular company, if you are interested - join them and work together.
>
> When one can't get a base adjacency going, use of further features is
> rather pointless.
>
> But again, it seems those running it on Linux have better luck than
> those on FreeBSD, so that is something to remember. We are a FreeBSD
> house. Our alternative is to use OSPF in Quagga and redistribute it into
> IS-IS. That works well. Would we like to use IS-IS natively? Sure. But
> the alternative has been working well for nearly 10 years.
>
>
> > FRR is an Open Source project, whining about missing features is not
> helpful, coding (or at least testing) and contributing is.
>
> I think we all appreciate how open source projects work. Calling out
> their limitations is as old as mailing lists. I don't code. I test a
> lot, and continue to test IS-IS in FRR on FreeBSD every year or so. I'll
> keep testing and giving feedback at least once or twice a year. If it's
> still broken, I'll call it out.
>
> Mark.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230509/190ecccf/attachment.html>