Re: FRR for BGP route reflectors?

[Saku Ytti via NANOG <nanog () lists nanog org>]

Thanks Raymond, cursory look makes it look quite usable.

There are purpose-built BGP libraries, but they're all more or less
unmaintained, as they're not part of dog-fooding by building daemon
around it, which seems crucial for survival.

e.g.
https://github.com/Nat-Lab/libbgp
https://github.com/jeanmichel-gh/bgp4r
https://github.com/wladwm/zettabgp

(many many other, but none, afaik, anywhere near maturity of any of
the daemons we've discussed)



On Tue, 9 Jun 2026 at 07:54, Raymond Burkholder via NANOG
<nanog () lists nanog org> wrote:
> On 2026-06-04 01:59, Saku Ytti via NANOG wrote:
> > 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.
>
> You may not think of them like Internet APIs, but there is a kind of
> tightly bound library access to FRR:
> https://docs.frrouting.org/projects/dev-guide/en/latest/library.html
>
> FRR does have some hooks for customization.  It also has a Lua scripting
> interface:
> https://docs.frrouting.org/projects/dev-guide/en/latest/scripting.html
>
> There is an ability to add your own callback hooks, command line
> additions, ... and other stuff.
>
> Link State API
> https://docs.frrouting.org/projects/dev-guide/en/latest/link-state.html
>
> Northbound API
> https://docs.frrouting.org/projects/dev-guide/en/latest/northbound/northbound.html
>
> Zebra Neighbor API
> https://docs.frrouting.org/projects/dev-guide/en/latest/zebra-neigh-api.html
>
> Mind you, all this access probably requires you have the FRR source code
> open, but given the complexity of the daemons and networking in general,
> this access is probably as close to API as possible.
>
> > 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.
>
> https://docs.frrouting.org/projects/dev-guide/en/latest/fuzzing.html
>
> > So please, the next person planning to write BGP or whatever project
> > they're thinking of, separate the logic and daemon. Thank you.
> I'm not an FRR developer, just a satisfied user with a programming bent.
>
> Raymond Burkholder
> https://blog.raymond.burkholder.net/
> _______________________________________________
> NANOG mailing list
> https://lists.nanog.org/archives/list/nanog () lists nanog org/message/FHTU5M5OFXXJ4S3SLIFWSNH4AM4BUJJ4/



-- 
  ++ytti
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/7N5YRSSKNDVC6M2OHE2546NKD7KG2E7H/