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