Thanks a lot for your reply Lajos!

On 29.04.24 9:32 AM, Lajos Katona wrote:

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

DONE via https://bugs.launchpad.net/neutron/+bug/2064120

The Neutron drivers team discuss these topics on Fridays 1400 UTC if there's open agenda (open RFEs :-))

Do you expect / want me to join in? This Friday then? Could you kindly point me (and others interested) to the Etherpad / conferencing info?

If I understand well the technical bottleneck here is os-ken, am I right?

Maybe. Let me rephrase my 1) and 2) options towards fixing this a little ...

1) If you can only run one BGP speaker per dragent (due to os-ken only supporting one BGP session), one option would be to allow this BGP session to be multi-protocol BGP (so carrying IPv4 and IPv6 routes). os-ken already has MP-BGP support, so it's about selecting and exporting IPv4 and IPv6 routes within the same, single session.

2) The second option is to enable dragent or somehow have two BGP speakers scheduled to it.

a) extend os_ken (as you suggested) to support more than one BGP session (two should be enough if we are talking about one for IPv4 and another one for IPv6). There has to be some consideration for HA [1] to now schedule two sessions that are redundant to each other to one agent. But when only accepting one IPv4 and one IPv6 session this should not be an issue.

b) if extending os_ken is not an option, maybe the whole dragent can be built to run multiple instances of a single driver (os_ken) to then accept more than one bgp speaker scheduled to it. Somewhat of the worker pattern with the drivers being the workers.

[1] https://docs.openstack.org/neutron/latest/admin/config-bgp-dynamic-routing.h...

Regards and thanks again!

Christian

Hi, I added this topic to the meeting wiki: https://wiki.openstack.org/wiki/Meetings/NeutronDrivers#Agenda I think you can edit if you would like to add other context there, but I suppose the lp bug/RFE and the mail thread is good starting point. The meeting time is 1400 UTC Friday: https://meetings.opendev.org/#Neutron_drivers_Meeting

Lajos Katona (lajoskatona)

Roberto Bartzen Acosta roberto.acosta@luizalabs.com ezt írta (időpont: 2024. ápr. 29., H, 15:36):

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, Roberto

[1] https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/888787

Em 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 wishes Lajos 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.... [3] https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/608302 [4]

https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.... [5]

https://github.com/openstack/neutron-dynamic-routing/blob/ffaaf5a25d846feadc... [6]

https://github.com/openstack/neutron-dynamic-routing/blob/ffaaf5a25d846feadc...

*‘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’.*