[RFE] BGP Dynamic Routing for IPv4 AND IPv6 routes not possible with just one dragent (really make use of MP-BGP or support multiple BGP speakers / sessions per dragent)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
neutron |
New
|
Undecided
|
Unassigned |
Bug Description
When setting up Neutron BGP Dynamic Routing to advertise IPv4 floating IPs and also IPv6 tenant networks I ran into some issues.
I then asked on the ML [1] and also found an older thread [2] discussing the advertising of IPv6 routes (e.g. from tenant networks). There Sean mentioned [4] that even with MP-BGP support [3] it's required to have two BGP speakers. While [3] means IPv4 or IPv6 can be used to establish the BGP session itself to then advertise routes for either address family, it's not possible to advertise IPv4 AND IPv6 routes via the same session.
To cut to the chase of this bug ....
It's very common to use distinct (read: NON multi protocol) BGP sessions to exchange routes for IPv4 and IPv6 individually and this poses no issue in itself.
The problem with Neutron is though, that the os_ken dragent driver only supports one BGP speaker [5] per agent. This leads to only one of the BGP speakers involved (one with `ip_version=4` the other with `ip_version=6`) running per individual (control plane, networking) host. So on a single control plane host it seems not even possible to setup and use BGP dynamic routing for IPv4 and IPv6 routes.
I see two options for improvement here:
1) Enabling a BGP speaker to have more than one address family (dragent driver already has MP-BGP support via [3]), so the query fetching the routes [6] simply(TM) does `ip_version in ('4','6')`. There also is a bug open [7] about the filtering currently being broken.
2) Somehow get more than one BGP speaker per dragent working by ...
a) ... extending the driver to host more than one BGP speaker
b) ... extending dragent to have more than one driver instance
[1] https://<email address hidden>
[2] https://<email address hidden>
[3] https:/
[4] https://<email address hidden>
[5] https:/
[6] https:/
[7] https:/
This was approved at the last Neutron Drivers meeting [0].
The consensus was to ask for a spec to be created so we can learn more about the two proposed solutions and make a decision.
[0] https:/ /meetings. opendev. org/meetings/ neutron_ drivers/ 2024/neutron_ drivers. 2024-05- 31-14.00. log.html# l-20