Gavin, I think it's very useful information, thank you!
I didn't read about issues related to using the common zone before.
Generally, we use dnat_and_snat rule when allocating FIP to the VMs, but I
didn't have time to try it with the LB scheme in common zone
Regards,
Ildar, network engineer
On Thu, Jul 25, 2024 at 5:47 PM Gavin McKee <gavmcke...@googlemail.com>
wrote:
> Ildar/Numan,
>
> If you are using HWOL on a smart NIC (CX6 and CX7 ) I had run into an
> issue with dnat_and_snat offloading in one direction only (OVN central
> 23.09.0 and OVN controller 23.09.0)
>
> I worked with the Nvidia team on this problem and the summary was as
> follows:
>
> Initially there was an offloading problem with SNAT/DNAT because they
> were using separate CT zones and one of them is not committed but CT
> action was performed for every packet.
> The problem was then fixed by using a common zone by the patch in
> 2021. (4deac4509abb northd: Use ct_(snat/dnat)_in_czone action for
> distributed routers.)
> Later in 2023 the default behavior was reverted back by a new patch
> with the config use_common_zone, (b8c40e7593a9 northd: Make the use of
> common zone in NAT configurable)
>
> I think the trade of here is the LB and dnat_and_snat can't coexist on
> a DLR which is using common_zone.
>
> I just wanted to call this out in case its useful for you here.
>
> Gav
>
>
> On Thu, 25 Jul 2024 at 07:36, Ildar Isangulov via discuss
> <ovs-discuss@openvswitch.org> wrote:
> >
> > Numan, thanks for clarification, I didn't know that both approaches use
> OVS conntrack the same way
> >
> > Now I think we'll do that.
> >
> > On Wed, Jul 24, 2024 at 6:28 PM Numan Siddique <num...@ovn.org> wrote:
> >>
> >> On Wed, Jul 24, 2024 at 11:15 AM Ildar Isangulov via discuss
> >> <ovs-discuss@openvswitch.org> wrote:
> >> >
> >> > Hi, Justin! Sorry, didn't notice your reply
> >> >
> >> > I will review this
> >> >
> >> > Regards,
> >> > Ildar, network engineer
> >> >
> >> > On Wed, Jul 24, 2024 at 6:07 PM Ildar Isangulov <
> ildarvildanovich...@gmail.com> wrote:
> >> >>
> >> >> Hi Numan, thanks for your reply, here more details as you requested
> >> >>
> >> >> This is a structure of NAT table in the OVN NB Database in my
> production environment
> >> >>
> >> >> # ovn-nbctl --no-l list nat <some rule>
> >> >> _uuid :
> >> >> allowed_ext_ips :
> >> >> exempted_ext_ips : []
> >> >> external_ids :
> >> >> external_ip :
> >> >> external_mac : []
> >> >> external_port_range : ""
> >> >> gateway_port : []
> >> >> logical_ip :
> >> >> logical_port : []
> >> >> options : {}
> >> >> type :
> >> >>
> >> >> OVN version
> >> >>
> >> >> # ovn-nbctl -V
> >> >> ovn-nbctl 24.03.2
> >> >> Open vSwitch Library 3.3.0
> >> >> DB Schema 7.3.0
> >> >>
> >> >> So, my use case is to be able to create DNAT rules like this
> (example):
> >> >>
> >> >> A user connects via public IP and some port, let's say 22222, and
> the gateway does DNAT translation and modifies headers:
> >> >> public IP -> private IP of VM
> >> >> external port (22222) -> ssh tcp port (22)
> >> >>
> >> >> But OVN can do only 1:1 DNAT translations, in other words port 22222
> to port 22222, and this way we can expose only one VM using one public IP
> address
> >> >>
> >> >> Solution, as shown in a guide I shared demonstrates how to solve
> this using load balancers, but I want to try a more lightweight solution
> for comparison.
> >> >>
> >>
> >> OK. Thanks for the details.
> >>
> >> OVN DNAT (i.e NAT of type "dnat" or "dnat_and_snat") maps one public
> >> IP to one internal VM IP. Seems to me using OVN load balancers is
> >> the right way
> >> for your use case.
> >> i.e PUBLIC IP : 22222 = [VM1 : 22, VM2 : 22, VM3 : 22, ...]
> >>
> >> As I said previously, there is no real difference in the
> >> implementation of OVN NAT and OVN Load balancers. We use OVS
> >> conntrack internally and it should
> >> not have any impact in terms of performance. Both are of the same
> weight.
> >>
> >> Thanks
> >> Numan
> >>
> >>
> >> >> Regards,
> >> >> Ildar, network engineer
> >> >>
> >> >> On Wed, Jul 24, 2024 at 5:33 PM Numan Siddique <num...@ovn.org>
> wrote:
> >> >>>
> >> >>> On Wed, Jul 24, 2024 at 9:41 AM Justin Lamp via discuss
> >> >>> <ovs-discuss@openvswitch.org> wrote:
> >> >>> >
> >> >>> > Hey,
> >> >>> >
> >> >>> > we would be in favor of that as well. It was actually possible to
> do
> >> >>> > such a thing in the past, but only due to a bug, and we
> unfortunately
> >> >>> > rely on that as many customers need to have ports from the routers
> >> >>> > public ip forwarded to their VPN appliance.
> >> >>> >
> >> >>> > https://github.com/ovn-org/ovn/issues/233
> >> >>> >
> >> >>> > Thanks and best regards,
> >> >>> > Justin Lamp
> >> >>> >
> >> >>> > Am 24.07.24 um 13:18 schrieb Ildar Isangulov via discuss:
> >> >>> > > Hi everyone!
> >> >>> > >
> >> >>> > > I would like to ask the community about the implementation of
> DNAT in
> >> >>> > > OVN. A few months ago, I read this topic
> >> >>> > > (
> https://www.flaviof.com/blog2/post/main/openstack-port-forwarding/).
> >> >>> > > Author shows how to configure DNAT translations using
> implementation
> >> >>> > > with Load-balancer.
> >> >>> > >
> >> >>> > > My question is: is it the only one way to do DNAT in OVN? Maybe
> there
> >> >>> > > is some way to configure it using either native nat rules on
> >> >>> > > logical-router or OVS logical-flows?
> >> >>>
> >> >>> Hi,
> >> >>>
> >> >>> I'm a little confused here. OVN does support DNAT in the logical
> router.
> >> >>> Please see the NAT table in the OVN NB Database.
> >> >>>
> >> >>> Also note that OVN implements NAT and load balancer features using
> OVS
> >> >>> conntrack.
> >> >>> So its essentially the same underneath.
> >> >>>
> >> >>> Can you please explain your use case in more detail?
> >> >>>
> >> >>> Thanks
> >> >>> Numan
> >> >>>
> >> >>> > >
> >> >>> > > Regards,
> >> >>> > > Ildar, network engineer
> >> >>> > >
> >> >>> > > _______________________________________________
> >> >>> > > discuss mailing list
> >> >>> > > disc...@openvswitch.org
> >> >>> > > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> > --
> >> >>> > Justin Lamp
> >> >>> > Systems Engineer
> >> >>> >
> >> >>> > NETWAYS Managed Services GmbH | Deutschherrnstr. 15-19 | D-90429
> Nuernberg
> >> >>> > Tel: +49 911 92885-0 | Fax: +49 911 92885-77
> >> >>> > CEO: Julian Hein, Bernd Erk, Sebastian Saemann | AG Nuernberg
> HRB25207
> >> >>> > https://www.netways.de | justin.l...@netways.de
> >> >>> >
> >> >>> > ** Meet us at it-sa - https://www.netways.de/it-sa-2024/ **
> >> >>> > ** OSMC 2024 - November | Nuremberg - https://osmc.de **
> >> >>> > ** stackconf 2025 - Stay Tuned for 2025 - https://stackconf.eu **
> >> >>> > ** NETWAYS Web Services - https://nws.netways.de **
> >> >>> > ** NETWAYS Trainings - https://netways.de/trainings **
> >> >>> > _______________________________________________
> >> >>> > discuss mailing list
> >> >>> > disc...@openvswitch.org
> >> >>> > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
> >> >
> >> > _______________________________________________
> >> > discuss mailing list
> >> > disc...@openvswitch.org
> >> > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
> >
> > _______________________________________________
> > discuss mailing list
> > disc...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
