Re: FRR for BGP route reflectors?

[Tom Samplonius via NANOG <nanog () lists nanog org>]

Saku,

  I don’t frequently agree with your posts, but I agree with this.  FRR is embedded in a lot of systems, and sometimes 
is somehow buried underneath a second CLI.  These layers of config files frequently cause configuration de-sync issues. 
 So the top level configuration that I see, is different from the configuration that FRR is using.

  I realize it is somewhat different, but it similar to the entire issue of “commit” versus “commit full”.  You can 
commit a configuration, which may not be fully applied to the hardware, or you can “commit full” and really commit that 
change.  Its just because the outer most configuration layer, doesn’t know what is going on the lower layers of 
configuration.

  But as a mid-sized ISP, and with route reflectors having the ability to identify new EVPN instances, and routers 
having the ability to signal to the RR, which EVPN and L3VPN instances they are part of, how much programmability would 
I need?  Other than modifying global policy, perhaps I never need to modify the RR configuration?  I certainly don’t 
need to modify it, to add a new EVPN or new L3VPN?



Tom



> On Jun 4, 2026, at 12:59 AM, Saku Ytti via NANOG <nanog () lists nanog org> wrote:
>
> 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/

_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/KWMVGK4GHLCDYQ5VHT2M7MG5PBJPQPDG/