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 < [email protected]> 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 < > [email protected]> 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 <[email protected]> with >> [Neutron] in the subject. >> >> Best wishes >> Lajos Katona >> >> >> Plato, Michael via discuss <[email protected]> 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 <[email protected]> >>> *Gesendet:* Montag, 20. Februar 2023 10:03 >>> *An:* Plato, Michael <[email protected]> >>> *Cc:* [email protected] >>> *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 < >>> [email protected]> 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 >>> [email protected] >>> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss >>> >>> >>> >>> -- >>> >>> LUIS TOMÁS BOLÍVAR >>> Principal Software Engineer >>> Red Hat >>> Madrid, Spain >>> [email protected] >>> >>> _______________________________________________ >>> discuss mailing list >>> [email protected] >>> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss >>> >> _______________________________________________ >> discuss mailing list >> [email protected] >> 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 [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
