Hi Christian,I believe we have two separate things related to your comments.The first is that we certainly have an issue with on-ken because this new BGP driver doesn't support MP-BGP in an easy way like the previous os-ryu. This behaviour triggers some issues when we have multiple IP versions on the same network because the n-d-r tries to advertise IPv6 using IPv4 peers / IPv4 using IPv6 peers. I've opened this change to avoid this issue [1].
The second thing, and the fundamental question here is: the n-d-r stuff (bgp agent, peers, etc) relate all the configurations by address-scope, and for that reason, we have only one IP version per n-d-r agent. In other words, an n-d-r agent works with only one IP version on its peer, and because of this the MP-BGP can help you in very specific cases (but still advertising IPv4 addresses using a IPv6 bgp peer, for example).So, if you want to use multiple peer sessions in the same n-d-r agent, maybe you need to follow Lajos' suggestion and open an RFE to implement this support for multiple address-scopes in n-d-r. Otherwise, a fix in os-ken can solve the mixed IP version problem using only one peer IP version to advertise both IP protocols (MP-BGP). Just keep in mind that the BGP capabilities to work with MP-BGP isn't implemented in n-d-r but in an external lib (os-ken) that can evolve and change the behaviour in the future (although what occurred from os-ryu to os-ken was an unaddressed regression in my point of view). Using separate agents for IPv4 and IPv6 solves the problem and is a very common configuration option. However, if you are interested in using multiple IP versions in your control panel (IPv4 + IPv6 in the external/internal networks in the same OpenStack project) it requires the fix for n-d-r doesn't mix the network IP versions and only advertise the IP version of its peer (IPv4 agent/peer advertising IPv4 addresses / IPv6 agent/peer advertising IPv6 addresses).
Thank you for bringing this discussion!Regards,RobertoEm seg., 29 de abr. de 2024 às 00:41, Lajos Katona <katonalala@gmail.com> escreveu:Hi Christian,I suggest to open a launchpad bug for this, perhaps even mark it as an RFE (Request for Enhancement, kind of lightweight blueprint for Neutron).The Neutron drivers team discuss these topics on Fridays 1400 UTC if there's open agenda (open RFEs :-))If I understand well the technical bottleneck here is os-ken, am I right?Best wishesLajos Katona (lajoskatona)Christian Rohmann <christian.rohmann@inovex.de> ezt írta (időpont: 2024. ápr. 25., Cs, 13:22):Hello OpenStack-Discuss,
when setting up Neutron Dynamic Routing [1] to advertise IPV4 floating
IPs and also IPv6 tenant networks I ran into some questions / issues.
I was just about to ask about them here on the ML, when I found the
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 threat ....
It's not uncommon to simply use individual (non Multi-Protocol) BGP
sessions to exchange routes for IPv4 and IPv6 individually and to me
this poses no issue to me.
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 (IPv4 or IPv6)
running per individual (control plane, networking) host.
Or am I not seeing something or am misreading the capabilities of the
components involved?
If not, 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 returns them both.
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
Would love to hear how others have set up their dynamic routing and what
your ideas are!
Regards
Christian
[1] https://github.com/openstack/neutron-dynamic-routing
[2]
https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/CM3MOEIAMJ7YSVL5FRDCL5DIT5PYGT2R/#CM3MOEIAMJ7YSVL5FRDCL5DIT5PYGT2R
[3] https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/608302
[4]
https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/MQPEXJFQNQLI2KNJYP3O5CGF5COJR7Y7/
[5]
https://github.com/openstack/neutron-dynamic-routing/blob/ffaaf5a25d846feadc589b83281c783b10ae7684/neutron_dynamic_routing/services/bgp/agent/driver/os_ken/driver.py#L77
[6]
https://github.com/openstack/neutron-dynamic-routing/blob/ffaaf5a25d846feadc589b83281c783b10ae7684/neutron_dynamic_routing/db/bgp_db.py#L859
‘Esta mensagem é direcionada apenas para os endereços constantes no cabeçalho inicial. Se você não está listado nos endereços constantes no cabeçalho, pedimos-lhe que desconsidere completamente o conteúdo dessa mensagem e cuja cópia, encaminhamento e/ou execução das ações citadas estão imediatamente anuladas e proibidas’.‘Apesar do Magazine Luiza tomar todas as precauções razoáveis para assegurar que nenhum vírus esteja presente nesse e-mail, a empresa não poderá aceitar a responsabilidade por quaisquer perdas ou danos causados por esse e-mail ou por seus anexos’.