Re: FRR for BGP route reflectors?

[Douglas Fischer via NANOG <nanog () lists nanog org>]

Regarding the multiplicity of daemons for BGP.

I believe it's only necessary to say that there are daemons with different
purposes.
- FRR, for instance, most of the time doesn't allow you to break what the
protocol proposes. To do that, you have to go down several layers, which
isn't simple.
- ExaBGP, for example, is designed so that you can do "anything you want"
with the routes, regardless of whether they respect basic BGP criteria.

And both are necessary.

Em qui., 4 de jun. de 2026 às 05:00, Saku Ytti via NANOG <
nanog () lists nanog org> escreveu:

> On Wed, 3 Jun 2026 at 18:05, André Dias via NANOG <nanog () lists nanog org>
> wrote:
>
> > I use FRR a lot in ISPs that I work for, but in cases of RR I prefer to
> use GoBGP or BIRD. I prefer GoBGP or Bird instead FRR because they are
> easier to automate.
>
> It boggles my mind that someone goes 'I'm going to write this very
> complex daemon' and then they proceed to write monolithic tightly
> coupled CLI+daemon+logic.
>
> So we have a huge collection of BGP implementations, as mentioned just
> here, frr, gobgp, bird, rustybgp, openbgp, exabgp and many many
> others. But we don't really have any BGP library approaching a similar
> maturity level. While to me it seems it should have been an obvious
> win for any project, to start day1 with decoupled library, cli and
> daemon as separate libraries, i see it reducing work day1 due to
> forcing more maintainability in design.
>
> Then instead of using low performance, lacking or non-existing APIs in
> your automation, you could write your own BGP worker using the library
> to have superior flexibility and performance, and exactly the
> behaviour you want. Many things you cannot do at all, because you
> don't have a library, like fuzzing, the daemon won't allow you to do
> wrong/bad things.
>
> So please, the next person planning to write BGP or whatever project
> they're thinking of, separate the logic and daemon. Thank you.
>
>
> --
>   ++ytti
> _______________________________________________
> NANOG mailing list
>
> https://lists.nanog.org/archives/list/nanog () lists nanog org/message/OPAVVROPAXNFN5VTGB5RDLYQ4HPQGGGT/



-- 
Douglas Fernando Fischer
Engº de Controle e Automação
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/Z53M4HBJ4T6GUYVWWLG2LDWJ4YPB5XMI/