
OpenBGPD – Adding Diversity to the Route Server Landscape - fcambus
https://labs.ripe.net/Members/claudio_jeker/openbgpd-adding-diversity-to-route-server-landscape
======
corndoge
The first and only article comment:

 _What about FRRouting, ExaBGP, GoBGP or Bio-Routing ?_ _Yeah, wasting
resources for stuff nobody needs - thanks RIPE!_ _(what about contributing?)_

Bang on, BIRD is absolutely not the only solution in this space, no idea what
the author's on about

~~~
throwaway2048
theoretically there is a lot of BGP software.

None of gets used as a route server except BIRD, because nothing else can
handle the full IPv4 BGP mesh.

~~~
ZWoz
I used OpenBGPD it first around 2012. In moment I have OpenBGPD instance with
4 x full table, so that "nothing else can handle the full BGP tables" isn't
simply true. Thats not forwarding instance though, I use it as looking glass.

~~~
throwaway2048
Handle the full BGP table while serving as a route server. OpenBGPD devs
themselves admit it was inadequate at that role, mostly because adding filters
was incredibly inefficient, as well as RIB updates being super slow (in a
relative sense).

------
fosco
any thoughts on requiring the creation of both outbound and inbound prefix
lists when peering?

~~~
kbirkeland
Unless you're peering with another stub AS, creating a prefix list for both
sides is almost impossible. The current recommendation[0] is to filter inbound
on customer links using either IRR or ROA. Unfortunately neither of these are
perfect. ROA can be replayed. There are a breadth of IRRs and I'm not quite
sure of the validation levels each has. From my experience, they usually allow
updates via email with either sender verification or password based
authentication.

[0]
[https://www.manrs.org/isps/guide/filtering/](https://www.manrs.org/isps/guide/filtering/)

