OpenBGPD – Adding Diversity to the Route Server Landscape | Hacker News Reader

OpenBGPD – Adding Diversity to the Route Server Landscape

labs.ripe.net

128 pointsfcambus10 comments

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

AFAIK half of those, ExaBGP and GoBGP, could be used to build a route server, but aren't out of the box, and it's far from obvious doing that would be less "wasted resources" than the investment in OpenBGPD, and at least for what's actually deployed in IXes BIRD is more or less a monoculture, so apparently the operators think the alternatives aren't so viable.

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.

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.

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).

I have been doing full tables using Quagga in production, in multiple regions, for years.

The thing BIRD does well is being hardened against untrusted users having access (the route server use case). I'm very happy to see a second implementation that has this focus as well.

Quagga easily

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

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/

That would be completely unusable in large IX router meshes with hundreds or thousands of peers, constantly coming and going, all with their own lists of prefixes constantly changing.

Reply on news.ycombinator.com