pierky
commented
3 years ago Has it been considered to support other BGP implementations as a route-server?
E.g.
Hello @netravnen,
yes, it's been considered, and in the past I've spent a bit of time to lay the groundwork for making it possible and easier.
The way the whole tool is built is very modular, each BGP speaker represents a sort of "plug-in".
Also, the integration testing suite is based on an abstract interface that allows the "unit test" cases to interact with the route-server without having to care about the underlying implementation of the BGP speaker it's running on. In https://github.com/pierky/arouteserver/pull/51#issuecomment-599137299 an attempt was started to add a Junos-based BGP speaker, and I've provided some guidelines on how to move forward with it (which are complemented by the docs available at https://arouteserver.readthedocs.io/en/latest/LIVETESTS.html).
Additionally, to allow an "incremental" release plan where some features may be shipped since the beginning and some other postponed, I've structured the documentation in a way that makes it easier to see which of them are available for a specific BGP speaker: see https://arouteserver.readthedocs.io/en/latest/SUPPORTED_SPEAKERS.html. This allows any additional "module" to start with a sub-set of features instead of having all of them implemented.
Now, for the specific request about FRR, I have to say that I haven't considering to implement it on my own in the short term, but of course contributions would be well accepted! If you like the idea of working on it, we can briefly meet (or share some emails) and discuss the best way forward. Probably the first step would be to agree on a set of mandatory features that we want to have implemented before shipping it, and which test cases they must pass.
Has it been considered to support other BGP implementations as a route-server?
E.g.