Hi,
I managed to create a working setup by omitting this flow for bgp routed 
networks 
(https://github.com/ovn-org/ovn/blob/branch-22.03/northd/northd.c#L13234) . It 
is also important to keep snat enabled in the openstack router, otherwise no 
communication between a floating ip and a routed tenant network ip on the same 
network will be possible. But so far I have no idea how to decide in northd 
whether it is a routed network or not. From my point of view, the CMS (neutron) 
should pass this information to OVN. In my proof of concept, I excluded 
specific subnet ranges, but that's not useful for a production setup.

Best regards

Michael

Von: Roberto Bartzen Acosta <roberto.aco...@luizalabs.com>
Gesendet: Mittwoch, 8. März 2023 14:03
An: Lajos Katona <katonal...@gmail.com>
Cc: Plato, Michael <michael.pl...@tu-berlin.de>; ovs-discuss@openvswitch.org
Betreff: Re: [ovs-discuss] Problem with ovn and neutron dynamic routing

Hi Plato,

An alternative would be to segment the networks of the hacks so that the next 
hop is announced as the IP of the segment of each hack (I'm not sure if this 
will work with OVN).
Take a look at this doc [2].

[2] 
https://docs.openstack.org/neutron/latest/admin/config-bgp-floating-ip-over-l2-segmented-network.html#setting-up-the-provider-subnets-for-the-bgp-next-hop-routing

Em qua., 8 de mar. de 2023 às 08:54, Roberto Bartzen Acosta 
<roberto.aco...@luizalabs.com<mailto:roberto.aco...@luizalabs.com>> escreveu:
Hey folks,

Please correct me if I'm wrong, but this problem seems related to the logical 
flow order.

How does it work when there is no n-d-r?
- the FIP traffic is redirected from the external host to the openstack network 
provider (no explicit next-hop) and the path is discovered via ARP and then 
forwarded by the FIP's dnat_and_snat action.

When n-d-r starts to advertise the FIPs via BGP it informs the router's 
external IP as the FIP's next_hop [1].
The order of the logical flows must be interfering with the action performed 
(should do a default router nat action first or do a dnat_and_snat for the FIP?)
I think you have two alternatives to test some possible fix:
1 - Look the OVN backend in Neutron and map (Neutron/OVN) the tables used for 
the two types of traffic (NAT for routers and NAT for FIPs), and maybe change 
the priority of the flow actions (very complex)
2 - Change the n-d-r to not advertise the router's gw port IP in next_hop [1] 
(ovn case), maybe changing it to the FIP address (would need to study how the 
bgp peer expects to receive the next_hop to compose the AS_PATH).

[1] - 
https://opendev.org/openstack/neutron-dynamic-routing/src/commit/e9529f7dc5449714c76afd7fce62f228f8111177/neutron_dynamic_routing/services/bgp/bgp_plugin.py#L261

Best regards,
Roberto

Em qua., 8 de mar. de 2023 às 04:25, Lajos Katona via discuss 
<ovs-discuss@openvswitch.org<mailto:ovs-discuss@openvswitch.org>> escreveu:
Hi,
If you feel that OVN-Neutron-Neutron-Dynamic-Routing has some issue feel free 
to open a bug report in launchpad:
https://bugs.launchpad.net/neutron

If it is a more complex issue we have weekly meetings where you can ask Neutron 
team for advice and help (we use IRC), or just write a mail to Openstack 
Discuss List 
<openstack-disc...@lists.openstack.org<mailto:openstack-disc...@lists.openstack.org>>
 with [Neutron] in the subject.

Best wishes
Lajos Katona


Plato, Michael via discuss 
<ovs-discuss@openvswitch.org<mailto:ovs-discuss@openvswitch.org>> ezt írta 
(időpont: 2023. febr. 23., Cs, 10:26):
Hello,

many thanks for the quick response. As I can see, the ticket is a bit older. 
Are there any ideas for a solution so far or first patches that could be tested?

Best regards

Michael

Von: Luis Tomas Bolivar <ltoma...@redhat.com<mailto:ltoma...@redhat.com>>
Gesendet: Montag, 20. Februar 2023 10:03
An: Plato, Michael 
<michael.pl...@tu-berlin.de<mailto:michael.pl...@tu-berlin.de>>
Cc: ovs-discuss@openvswitch.org<mailto:ovs-discuss@openvswitch.org>
Betreff: Re: [ovs-discuss] Problem with ovn and neutron dynamic routing

We hit this problem a while ago and reported it here: 
https://bugzilla.redhat.com/show_bug.cgi?id=1906455

On Mon, Feb 20, 2023 at 9:56 AM Plato, Michael via discuss 
<ovs-discuss@openvswitch.org<mailto:ovs-discuss@openvswitch.org>> wrote:
Hello,

we have a problem with ovn in connection with neutron dynamic routing (which is 
now supported with ovn). We can announce our internal networks via BGP and the 
VMs in this network can also be reached directly without nat.
But if we attach a public floating ip to the internal self service network ip, 
we have some strange effects. The VM can still be reached via ping with both 
ips. But SSH for example only works via floating ip. I did some network traces 
and found that the return traffic is being natted even though no nat was 
applied on incoming way. From my point of view we need a conntrack marker which 
identifies traffic which was d-natted on incoming way and s-nat only those 
traffic on return way. Is it possible to implement something like this to fully 
support ovn with BGP announced networks which are directly reachable via 
routing?

Thanks for reply and best regards!

Michael
_______________________________________________
discuss mailing list
disc...@openvswitch.org<mailto:disc...@openvswitch.org>
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss


--
LUIS TOMÁS BOLÍVAR
Principal Software Engineer
Red Hat
Madrid, Spain
ltoma...@redhat.com<mailto:ltoma...@redhat.com>

_______________________________________________
discuss mailing list
disc...@openvswitch.org<mailto:disc...@openvswitch.org>
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
_______________________________________________
discuss mailing list
disc...@openvswitch.org<mailto:disc...@openvswitch.org>
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss


‘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’.
_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Reply via email to