search

pierky / arouteserver

A tool to automatically build (and test) feature-rich configurations for BGP route servers.
https://arouteserver.readthedocs.org/
GNU General Public License v3.0
288 stars 46 forks source link

Switch to using 'bgpq4' #53

Closed job closed 4 years ago

job commented 4 years ago

The bgpq4 utility is an equivalent (but faster and better) replacement to bgpq3.

coveralls commented 4 years ago

Coverage Status

Coverage increased (+0.02%) to 72.574% when pulling 72bed1e8113a356d276f3b55b618ef60d1ad9c1b on job:bgpq4 into d31559b2a19a09a4501911bce8a0fb3b12cf7792 on pierky:master.

eimann commented 4 years ago

Can I help with getting this PR merged? We are using bgpq4 since 0.22.2 and it's working like a charm. Unfortunately after every upgrade through pip we have to apply the patches for bgpq4 manually.

pierky commented 4 years ago

Hello, thanks @job for the PR and @eimann for the feedback. I'm working on this; I'll try to come up with a solution to keep backward compatibility, in order to not break the currently existing environments where bgpq3 is used today. Stay tuned ;)

pierky commented 4 years ago

Hi @eimann, I pushed something to the dev branch, a new commit where I document the support of bgpq4.

I've noticed that since version 0.0.5, bgpq4 can deal with a set of CLI arguments which is fully backward compatible with bgpq3, at least for the options used by ARouteServer. A part from a cosmetic change in the error messages produced by my tool when bgpq fails, I couldn't spot any other relevant change needed to have it integrated with ARouteServer. Could you share which patch you need to apply in order to have it working properly? Maybe you are using bgpq4 0.0.4, which doesn't support the -3 argument that is passed by my tool?

From what you can see in the branch, my idea for the time being is to keep support of both bgpq3 and bgpq4: the way to deal with them is a bit of a hack, that is all the internal references and config lines are still named after bgpq3, with notes to make it clear that they can also be used to configure the tool for bgpq4, but this allows to easily keep backward compatibility with the existing ARouteServer deployments withouth touching the code too much.

The rational behind the intent of keeping support for both is that bgpq3 is still very commonly used on many systems, and also it's not a dead project (yeah, maybe not the most active one but still maintained).

I'll consider a better transition strategy in the future, or maybe a refactoring of the way to have the two programs both integrated in ARouteServer.

pierky commented 4 years ago

Support for bgpq4 is now introduced with version 0.24.1. More details in my previous comments.