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/northboun...
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/FHTU5M5O...
-- ++ytti