Hi Michael,
I'm not sure if this is the best way to do this, maybe it would be better
to change the logic of the dnat_and_snat flows created for Floating IP.
Anyway, please check the openflow pipeline created for your router.
$ ovn-sbctl --no-leader-only lflow-list *neutron-router-name*
e.g.
FIP IP - x.x.x.99
Router IP - *x.x.x.16*
VM IP - 192.168.2.179
ingress pipeline
table=4 (lr_in_unsnat ), priority=100 , match=(ip && ip4.dst ==*
x.x.x.16 *&& inport == "lrp-3f47fa82-6290-40f6-b83e-5ed29e559925" &&
flags.loopback == 0 &&
is_chassis_resident("cr-lrp-3f47fa82-6290-40f6-b83e-5ed29e559925")),
action=(ct_snat_in_czone;)
table=4 (lr_in_unsnat ), priority=100 , match=(ip && ip4.dst ==*
x.x.x.16* && inport == "lrp-3f47fa82-6290-40f6-b83e-5ed29e559925" &&
flags.loopback == 1 && flags.use_snat_zone == 1 &&
is_chassis_resident("cr-lrp-3f47fa82-6290-40f6-b83e-5ed29e559925")),
action=(ct_snat;)
table=4 (lr_in_unsnat ), priority=100 , match=(ip && ip4.dst ==
x.x.x.99 && inport == "lrp-3f47fa82-6290-40f6-b83e-5ed29e559925" &&
flags.loopback == 0 &&
is_chassis_resident("cr-lrp-3f47fa82-6290-40f6-b83e-5ed29e559925")),
action=(ct_snat_in_czone;)
table=4 (lr_in_unsnat ), priority=100 , match=(ip && ip4.dst ==
x.x.x.99 && inport == "lrp-3f47fa82-6290-40f6-b83e-5ed29e559925" &&
flags.loopback == 1 && flags.use_snat_zone == 1 &&
is_chassis_resident("cr-lrp-3f47fa82-6290-40f6-b83e-5ed29e559925")),
action=(ct_snat;)
egress pipeline
table=3 (lr_out_snat ), priority=162 , match=(ip && ip4.src ==
192.168.2.179 && outport == "lrp-3f47fa82-6290-40f6-b83e-5ed29e559925" &&
is_chassis_resident("cr-lrp-3f47fa82-6290-40f6-b83e-5ed29e559925") &&
reg9[4] == 1), action=(reg9[4] = 0; ct_snat(x.x.x.99);)
table=3 (lr_out_snat ), priority=161 , match=(ip && ip4.src ==
192.168.2.179 && outport == "lrp-3f47fa82-6290-40f6-b83e-5ed29e559925" &&
is_chassis_resident("cr-lrp-3f47fa82-6290-40f6-b83e-5ed29e559925")),
action=(ct_snat_in_czone(x.x.x.99);)
table=3 (lr_out_snat ), priority=154 , match=(ip && ip4.src ==
192.168.2.0/24 && outport == "lrp-3f47fa82-6290-40f6-b83e-5ed29e559925" &&
is_chassis_resident("cr-lrp-3f47fa82-6290-40f6-b83e-5ed29e559925") &&
reg9[4] == 1), action=(reg9[4] = 0; ct_snat(*x.x.x.16*);)
table=3 (lr_out_snat ), priority=153 , match=(ip && ip4.src ==
192.168.2.0/24 && outport == "lrp-3f47fa82-6290-40f6-b83e-5ed29e559925" &&
is_chassis_resident("cr-lrp-3f47fa82-6290-40f6-b83e-5ed29e559925")),
action=(ct_snat_in_czone(*x.x.x.16*);)
Check that the priority for the snat out rule of the router is different
from that of the FIP.
You can change this value so that the snat rule for the Router IP occurs
first! This sounds very strange but since n-d-r advertise the FIP address
using the router's IP as the next-hop, it can be an alternative for this
specific case.
Please open a bug on launchpad.
Regards,
Roberto
Em ter., 4 de abr. de 2023 às 04:11, Plato, Michael <
[email protected]> escreveu:
> 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 <[email protected]>
> *Gesendet:* Mittwoch, 8. März 2023 14:03
> *An:* Lajos Katona <[email protected]>
> *Cc:* Plato, Michael <[email protected]>;
> [email protected]
> *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 <
> [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’.*
>
--
_‘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
