Re: [ovs-dev] [PATCH ovn v4 3/9] northd: Add Sampling_App table.

[Numan Siddique]

On Wed, Jul 31, 2024 at 4:20 PM Numan Siddique  wrote:
>
> On Wed, Jul 31, 2024 at 11:48 AM Ilya Maximets  wrote:
> >
> > On 7/31/24 17:05, Dumitru Ceara wrote:
> > > On 7/31/24 16:40, Ilya Maximets wrote:
> > >> On 7/31/24 16:17, Dumitru Ceara wrote:
> > >>> On 7/31/24 16:07, Ilya Maximets wrote:
> > >>>> On 7/31/24 16:04, Ilya Maximets wrote:
> > >>>>> On 7/31/24 11:05, Dumitru Ceara wrote:
> > >>>>>> This will represent a unified place to store IPFIX observation 
> > >>>>>> domain ID
> > >>>>>> configurations for sampling applications (currently only drop 
> > >>>>>> sampling
> > >>>>>> is supported as application but following commits will add more).
> > >>>>>>
> > >>>>>> Acked-by: Mark Michelson 
> > >>>>>> Signed-off-by: Dumitru Ceara 
> > >>>>>> ---
> > >>>>>> V4:
> > >>>>>> - Addressed Ales' comments:
> > >>>>>>   - fix up indentation
> > >>>>>>   - bump NB schema version
> > >>>>>> - Added Mark's ack.
> > >>>>>> ---
> > >>>>>>  northd/automake.mk   |   2 +
> > >>>>>>  northd/en-lflow.c|   5 ++
> > >>>>>>  northd/en-sampling-app.c | 120 
> > >>>>>> +++
> > >>>>>>  northd/en-sampling-app.h |  51 +
> > >>>>>>  northd/inc-proc-northd.c |  10 +++-
> > >>>>>>  northd/northd.h  |   1 +
> > >>>>>>  ovn-nb.ovsschema |  23 +++-
> > >>>>>>  ovn-nb.xml   |  17 ++
> > >>>>>>  tests/ovn-northd.at  |  17 ++
> > >>>>>>  9 files changed, 242 insertions(+), 4 deletions(-)
> > >>>>>>  create mode 100644 northd/en-sampling-app.c
> > >>>>>>  create mode 100644 northd/en-sampling-app.h
> > >>>>>
> > >>>>> 
> > >>>>>
> > >>>>>> diff --git a/ovn-nb.xml b/ovn-nb.xml
> > >>>>>> index 6376320d31..b96b0b34ed 100644
> > >>>>>> --- a/ovn-nb.xml
> > >>>>>> +++ b/ovn-nb.xml
> > >>>>>> @@ -5093,4 +5093,21 @@ or
> > >>>>>>
> > >>>>>>  
> > >>>>>>
> > >>>>>> +  
> > >>>>>> +
> > >>>>>
> > >>>>> Maybe this should be 'type' instead of a 'name'?
> > >>>>> 'name' makes me think that I can create multiple of them
> > >>>>> with different parameters, but that's not the case.
> > >>>>>
> > >>>
> > >>> I guess it depends a bit how you look at it.  It's just a 1:1 mapping
> > >>> between an "OVN application" (ACL, default drops) and an integer ID.
> > >>> I'm not sure why you get the impression that you can create multiple of
> > >>> them, there's an explicit index on 'name' that doesn't allow that.
> > >>
> > >> Index is rather indirect way of saying that there should be only one 
> > >> instance
> > >> of each application.
> > >>
> > >> The word 'name' says to me that I can choose an arbitrary one, but there 
> > >> is a
> > >> predefined list here.  So, it is actually a type and not a name.
> > >>
> > >
> > > Hmm, OK, I guess I can live with 'type'.
> > >
> > >>>
> > >>> I could change it to 'type' but for me 'name' made more sense.
> > >>
> > >> Another way to represent the same thing is to have a table with a single 
> > >> row
> > >> with a map from enum to an integer.  But also, why is it a separate 
> > >> table at all?
> > >> Why not a column in the NB_Global table?
> > >>
> > >> Something like:
> > >>
> > >>  "NB_Global": {
> > >>   ...
> > >>
> > >>   "sample_domain_ids": {
> > >> "type": {"key": {"type": "string",
> > >>  "enum": ["

Re: [ovs-dev] [PATCH ovn v4 1/9] northd: Fix up logical flow documentation for QoS.

[Numan Siddique]

> > @@ -1065,7 +1038,7 @@
> >
> >  
> >
> > -Ingress Table 14: Load balancing affinity learn
> > +Ingress Table 13: Load balancing affinity learn
> >
> >  
> >Load balancing affinity learn table contains the following
> > @@ -1096,7 +1069,7 @@
> >
> >  
> >
> > -Ingress Table 15: Pre-Hairpin
> > +Ingress Table 14: Pre-Hairpin
> >  
> >
> >  If the logical switch has load balancer(s) configured, then a
> > @@ -1114,7 +1087,7 @@
> >
> >  
> >
> > -Ingress Table 16: Nat-Hairpin
> > +Ingress Table 15: Nat-Hairpin
> >  
> >
> >   If the logical switch has load balancer(s) configured, then a
> > @@ -1149,7 +1122,7 @@
> >
> >  
> >
> > -Ingress Table 17: Hairpin
> > +Ingress Table 16: Hairpin
> >  
> >
> >  
> > @@ -1187,7 +1160,7 @@
> >
> >  
> >
> > -Ingress table 18: from-lport ACL evaluation after
> > LB
> > +Ingress table 17: from-lport ACL evaluation after
> > LB
> >
> >  
> >Logical flows in this table closely reproduce those in the
> > @@ -1272,7 +1245,7 @@
> >
> >  
> >
> > -Ingress Table 19: from-lport ACL action after LB
> > +Ingress Table 18: from-lport ACL action after LB
> >
> >  
> >Logical flows in this table decide how to proceed based on the
> > values of
> > @@ -1312,7 +1285,7 @@
> >
> >  
> >
> > -Ingress Table 20: Stateful
> > +Ingress Table 19: Stateful
> >
> >  
> >
> > @@ -1335,7 +1308,7 @@
> >
> >  
> >
> > -Ingress Table 21: ARP/ND responder
> > +Ingress Table 20: ARP/ND responder
> >
> >  
> >This table implements ARP/ND responder in a logical switch for known
> > @@ -1670,7 +1643,7 @@ output;
> >
> >  
> >
> > -Ingress Table 22: DHCP option processing
> > +Ingress Table 21: DHCP option processing
> >
> >  
> >This table adds the DHCPv4 options to a DHCPv4 packet from the
> > @@ -1731,7 +1704,7 @@ next;
> >
> >  
> >
> > -Ingress Table 23: DHCP responses
> > +Ingress Table 22: DHCP responses
> >
> >  
> >This table implements DHCP responder for the DHCP replies generated
> > by
> > @@ -1812,7 +1785,7 @@ output;
> >
> >  
> >
> > -Ingress Table 24 DNS Lookup
> > +Ingress Table 23 DNS Lookup
> >
> >  
> >This table looks up and resolves the DNS names to the corresponding
> > @@ -1841,7 +1814,7 @@ reg0[4] = dns_lookup(); next;
> >
> >  
> >
> > -Ingress Table 25 DNS Responses
> > +Ingress Table 24 DNS Responses
> >
> >  
> >This table implements DNS responder for the DNS replies generated by
> > @@ -1876,7 +1849,7 @@ output;
> >
> >  
> >
> > -Ingress table 26 External ports
> > +Ingress table 25 External ports
> >
> >  
> >Traffic from the external logical ports enter the
> > ingress
> > @@ -1919,7 +1892,7 @@ output;
> >
> >  
> >
> > -Ingress Table 27 Destination Lookup
> > +Ingress Table 26 Destination Lookup
> >
> >  
> >This table implements switching behavior.  It contains these logical
> > @@ -2117,7 +2090,7 @@ output;
> >
> >  
> >
> > -Ingress Table 28 Destination unknown
> > +Ingress Table 27 Destination unknown
> >
> >  
> >This table handles the packets whose destination was not found or
> > @@ -2330,28 +2303,21 @@ output;
> >This is similar to ingress table ACL action.
> >  
> >
> > -Egress Table 6: to-lport QoS Marking
> > -
> > -
> > -  This is similar to ingress table QoS marking except
> > -  they apply to to-lport QoS rules.
> > -
> > -
> > -Egress Table 7: to-lport QoS Meter
> > +Egress Table 6: to-lport QoS
> >
> >  
> > -  This is similar to ingress table QoS meter except
> > +  This is similar to ingress table QoS except
> >they apply to to-lport QoS rules.
> >  
> >
> > -Egress Table 8: Stateful
> > +Egress Table 7: Stateful
> >
> >  
> >This is similar to ingress table Stateful except that
> >there are no rules added for load balancing new connections.
> >  
> >
> > -Egress Table 9: Egress Port Security - check
> > +Egress Table 8: Egress Port Security - check
> >
> >  
> >This is similar to the port security logic in table
> > @@ -2380,7 +2346,7 @@ output;
> >
> >  
> >
> > -Egress Table 10: Egress Port Security - Apply
> > +Egress Table 9: Egress Port Security - Apply
> >
> >  
> >This is similar to the ingress port security logic in ingress table
> > --
> > 2.45.2
> >
> >
> Acked-by: Ales Musil 

Acked-by: Numan Siddique 

Not related to this patch:
I think ovn-northd.8.xml has been out of sync with the logical flow
description  for a while.
I'm not sure how to fix that.  I wonder if users and developers refer
to this documentation
to understand the OVN pipeline or not.

Numan


> --
>
> Ales Musil
>
> Senior Software Engineer - OVN Core
>
> Red Hat EMEA <https://www.redhat.com>
>
> amu...@redhat.com
> <https://red.ht/sig>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn v4 3/9] northd: Add Sampling_App table.

[Numan Siddique]

On Wed, Jul 31, 2024 at 11:48 AM Ilya Maximets  wrote:
>
> On 7/31/24 17:05, Dumitru Ceara wrote:
> > On 7/31/24 16:40, Ilya Maximets wrote:
> >> On 7/31/24 16:17, Dumitru Ceara wrote:
> >>> On 7/31/24 16:07, Ilya Maximets wrote:
>  On 7/31/24 16:04, Ilya Maximets wrote:
> > On 7/31/24 11:05, Dumitru Ceara wrote:
> >> This will represent a unified place to store IPFIX observation domain 
> >> ID
> >> configurations for sampling applications (currently only drop sampling
> >> is supported as application but following commits will add more).
> >>
> >> Acked-by: Mark Michelson 
> >> Signed-off-by: Dumitru Ceara 
> >> ---
> >> V4:
> >> - Addressed Ales' comments:
> >>   - fix up indentation
> >>   - bump NB schema version
> >> - Added Mark's ack.
> >> ---
> >>  northd/automake.mk   |   2 +
> >>  northd/en-lflow.c|   5 ++
> >>  northd/en-sampling-app.c | 120 +++
> >>  northd/en-sampling-app.h |  51 +
> >>  northd/inc-proc-northd.c |  10 +++-
> >>  northd/northd.h  |   1 +
> >>  ovn-nb.ovsschema |  23 +++-
> >>  ovn-nb.xml   |  17 ++
> >>  tests/ovn-northd.at  |  17 ++
> >>  9 files changed, 242 insertions(+), 4 deletions(-)
> >>  create mode 100644 northd/en-sampling-app.c
> >>  create mode 100644 northd/en-sampling-app.h
> >
> > 
> >
> >> diff --git a/ovn-nb.xml b/ovn-nb.xml
> >> index 6376320d31..b96b0b34ed 100644
> >> --- a/ovn-nb.xml
> >> +++ b/ovn-nb.xml
> >> @@ -5093,4 +5093,21 @@ or
> >>
> >>  
> >>
> >> +  
> >> +
> >
> > Maybe this should be 'type' instead of a 'name'?
> > 'name' makes me think that I can create multiple of them
> > with different parameters, but that's not the case.
> >
> >>>
> >>> I guess it depends a bit how you look at it.  It's just a 1:1 mapping
> >>> between an "OVN application" (ACL, default drops) and an integer ID.
> >>> I'm not sure why you get the impression that you can create multiple of
> >>> them, there's an explicit index on 'name' that doesn't allow that.
> >>
> >> Index is rather indirect way of saying that there should be only one 
> >> instance
> >> of each application.
> >>
> >> The word 'name' says to me that I can choose an arbitrary one, but there 
> >> is a
> >> predefined list here.  So, it is actually a type and not a name.
> >>
> >
> > Hmm, OK, I guess I can live with 'type'.
> >
> >>>
> >>> I could change it to 'type' but for me 'name' made more sense.
> >>
> >> Another way to represent the same thing is to have a table with a single 
> >> row
> >> with a map from enum to an integer.  But also, why is it a separate table 
> >> at all?
> >> Why not a column in the NB_Global table?
> >>
> >> Something like:
> >>
> >>  "NB_Global": {
> >>   ...
> >>
> >>   "sample_domain_ids": {
> >> "type": {"key": {"type": "string",
> >>  "enum": ["set", ["drop", "acl-new", "acl-est"]]},
> >>  "value": {"type": "integer",
> >>"minInteger": 1,
> >>"maxInteger": 255}}}
> >>
> >> ?
> >>
> >
> > We could.
> >
> >> This way we don't need a table, don't need an index or strange column 
> >> names,
> >
> > I think this is a matter of personal preference.  To me it doesn't seem
> > "strange", it makes sense.  But I wrote this code so I'm of course biased.
> >
> >> likely don't need a separate I-P node.  We're just turning 
> >> debug_drop_domain_id
> >> into a new column with a set.
> >>
> >
> > But we'd still need most of the logic that's currently in
> > en-sampling-app.c.  That would have to move to en-global-config.c
> > because the "en_lflow" incremental processing node depends on
> > "en_global_config" whose data is built based on the "en_nb_nb_global"
> > database node.
>
> Sure, I just meant that we'd not need a separate node.  We'll need
> the logic for the new column.
>
> >
> > So, with that in mind, in my opinion it seems cleaner if we have a
> > sampling_app table to define this kind of mapping instead of stuffing
> > more random feature-specific configuration fields in NB_Global.  But I'm
> > open to discussion.
>
> NB_Global carries all sorts of global configuration including specific
> configuration for various features.  Observation IDs for different
> sampling types is a global configuration, it doesn't depend on anything
> else.  It would make some sense to have a separate table if there were
> more configuration options for each type, not only ID, but I'm not sure
> what else we would need there.  Even then it would probably make more
> sense as a map in nb-global from type to a reference to a configuration
> table.
>
> >
> > Maybe others could share their opinion on this too.  I'll wait a bit
> > with sending v5 until we clear this up.
>
> Sure.

My 2 cents.

1. I'd prefer 

Re: [ovs-dev] [PATCH ovn v2] controller: Add lsp option disable_garp_rarp.

[Numan Siddique]

On Thu, Jul 25, 2024 at 7:29 AM Shibir Basak  wrote:
>
> If the lsp option 'disable_garp_rarp' is set to true,
> GARP and RARP announcements are not sent by ovn when a
> VIF port is created on a bridged logical switch.
>
> Usecase
> 
> This option is useful during VM migration to let the
> hypervisor/VM send the RARP/GARP once VM is ready to
> process the packets post migration. This helps to reduce
> downtime during VM migration.
>
> Signed-off-by: Shibir Basak 
> Acked-by: Naveen Yerramneni 

Thanks.  Applied to main.

Numan

> ---
> v2: Rebase on top of latest main
> Updated NEWS
> ---
>  NEWS |  3 ++
>  controller/pinctrl.c |  4 +--
>  ovn-nb.xml   |  7 +
>  tests/ovn.at | 68 
>  4 files changed, 80 insertions(+), 2 deletions(-)
>
> diff --git a/NEWS b/NEWS
> index 72933b5b9..435e6f773 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -42,6 +42,9 @@ Post v24.03.0
>  true, the traffic destined to a logical port of a provider logical switch
>  (having a localnet port) will be tunnelled instead of sending it via the
>  localnet port.
> +  - A new LSP option "disable_garp_rarp" has been added to prevent OVN from
> +sending GARP or RARP announcements when a VIF is created on a bridged
> +logical switch.
>
>  OVN v24.03.0 - 01 Mar 2024
>  --
> diff --git a/controller/pinctrl.c b/controller/pinctrl.c
> index 6a4299b82..7cbb0cf81 100644
> --- a/controller/pinctrl.c
> +++ b/controller/pinctrl.c
> @@ -6612,7 +6612,7 @@ send_garp_rarp_prepare(struct ovsdb_idl_txn 
> *ovnsb_idl_txn,
>  SSET_FOR_EACH (iface_id, _vifs) {
>  const struct sbrec_port_binding *pb = lport_lookup_by_name(
>  sbrec_port_binding_by_name, iface_id);
> -if (pb) {
> +if (pb && !smap_get_bool(>options, "disable_garp_rarp", false)) {
>  send_garp_rarp_update(ovnsb_idl_txn,
>sbrec_mac_binding_by_lport_ip,
>local_datapaths, pb, _addresses,
> @@ -6625,7 +6625,7 @@ send_garp_rarp_prepare(struct ovsdb_idl_txn 
> *ovnsb_idl_txn,
>  SSET_FOR_EACH (gw_port, _l3gw_ports) {
>  const struct sbrec_port_binding *pb
>  = lport_lookup_by_name(sbrec_port_binding_by_name, gw_port);
> -if (pb) {
> +if (pb && !smap_get_bool(>options, "disable_garp_rarp", false)) {
>  send_garp_rarp_update(ovnsb_idl_txn, 
> sbrec_mac_binding_by_lport_ip,
>local_datapaths, pb, _addresses,
>garp_max_timeout, garp_continuous);
> diff --git a/ovn-nb.xml b/ovn-nb.xml
> index 0f9a1005a..fd6d42afd 100644
> --- a/ovn-nb.xml
> +++ b/ovn-nb.xml
> @@ -1306,6 +1306,13 @@
>The default value is false.
>  
>
> + +type='{"type": "boolean"}'>
> +  If set to true, GARP and RARP announcements are not
> +  sent when a VIF port is created on a bridged logical switch.
> +  The default value is false.
> +
> +
>type='{"type": "string", "enum": ["set", ["mc_unknown"]]}'>
>If set to mc_unknown, packets going to this VIF get cloned to all
> diff --git a/tests/ovn.at b/tests/ovn.at
> index 2ced7c0b2..207ecf769 100644
> --- a/tests/ovn.at
> +++ b/tests/ovn.at
> @@ -25008,6 +25008,74 @@ OVN_CLEANUP([hv1])
>  AT_CLEANUP
>  ])
>
> +OVN_FOR_EACH_NORTHD([
> +AT_SETUP([Disabling RARP/GARP announcements])
> +ovn_start
> +
> +# In this test case we create 1 switch and bring up 4 VIFs on it.
> +# Two VIFs will be assigned MAC addresses only (i.e. without ips)
> +# and two VIFs will be assigned IP addresses along with MAC addresses.
> +# VIFs with IPs are supposed to send GARPs and VIFs with only MAC
> +# addresses are supposed to send RARP. However, we test the lsp
> +# option disable_garp_rarp, which when set to true for an lsp does
> +# not send the GARP/RARP announcements.
> +
> +ovn-nbctl ls-add ls1
> +ovn-nbctl lsp-add ls1 ln1 "" 101
> +ovn-nbctl lsp-set-addresses ln1 unknown
> +ovn-nbctl lsp-set-type ln1 localnet
> +ovn-nbctl lsp-set-options ln1 network_name=phys
> +
> +ovn-nbctl lsp-add ls1 lp11
> +ovn-nbctl lsp-set-addresses lp11 "f0:00:00:00:00:11"
> +
> +ovn-nbctl lsp-add ls1 lp12
> +ovn-nbctl lsp-set-addresses lp12 "f0:00:00:00:00:12"
> +ovn-nbctl set logical_switch_port lp12 options:disable_garp_rarp=true
> +
> +ovn-nbctl lsp-add ls1 lp13
> +ovn-nbctl lsp-set-addresses lp13 "f0:00:00:00:00:13 192.168.1.3"
> +
> +ovn-nbctl lsp-add ls1 lp14
> +ovn-nbctl lsp-set-addresses lp14 "f0:00:00:00:00:14 192.168.1.4"
> +ovn-nbctl set logical_switch_port lp14 options:disable_garp_rarp=true
> +
> +net_add n1
> +
> +sim_add hv1
> +as hv1
> +ovs-vsctl add-br br-phys
> +ovs-vsctl set open . external-ids:ovn-bridge-mappings=phys:br-phys
> +ovn_attach n1 br-phys 192.168.0.1
> +
> +AT_CHECK([ovs-vsctl add-port br-phys snoopvif -- set Interface 

Re: [ovs-dev] [PATCH ovn] northd: Allow Load balancer to be attached to router with multiple GW ports

[Numan Siddique]

On Wed, Jul 17, 2024 at 5:04 AM Priyankar Jain
 wrote:
>
> This commit removes the restriction of support LB for router with only
> <= 1 Distributed gateway ports.
> Added datapath and logical flows validation cases.
>
> Signed-off-by: Priyankar Jain 

Hi Priyankar,

Thanks for the patch.

Can you please tell me the use case ?

Lets say a logical router lr1 has sw1 (10.0.0.0/24) , sw2
(20.0.0.0/24) and sw3 (30.0.0.0/24) and the corresponding
gw ports are bound to chassis ch1, ch2 and ch3 respectively.

Let's say we attach load balancers - lb1 (10.0.0.40:80 ->
20.0.0.40:80), lb2 (20.0.0.50:80 -> 30.0.0.50:80) and
lb3 (30.0.0.60:80 -> 10.0.0.60:80) to lr1.

If I understand correctly, routing for sw1 (10.0.0.0/24) is handled on
the chassis ch1 and so on for other switches.

This patch generates the below logical flows in the router pipeline
for load balancer lb1, lb2 and lb3

  table=8 (lr_in_dnat ), priority=110  , match=(ct.new &&
!ct.rel && ip4 && ip4.dst == 10.0.0.40 && tcp && tcp.dst == 80 &&
is_chassis_resident("cr-lr0-sw1")),
action=(ct_lb_mark(backends=20.0.0.40:80);)
  table=8 (lr_in_dnat ), priority=110  , match=(ct.new &&
!ct.rel && ip4 && ip4.dst == 10.0.0.40 && tcp && tcp.dst == 80 &&
is_chassis_resident("cr-lr0-sw2")),
action=(ct_lb_mark(backends=20.0.0.40:80);)
  table=8 (lr_in_dnat ), priority=110  , match=(ct.new &&
!ct.rel && ip4 && ip4.dst == 10.0.0.40 && tcp && tcp.dst == 80 &&
is_chassis_resident("cr-lr0-sw3")),
action=(ct_lb_mark(backends=20.0.0.40:80);)
  table=8 (lr_in_dnat ), priority=110  , match=(ct.new &&
!ct.rel && ip4 && ip4.dst == 20.0.0.50 && tcp && tcp.dst == 80 &&
is_chassis_resident("cr-lr0-sw1")),
action=(ct_lb_mark(backends=30.0.0.50:80);)
  table=8 (lr_in_dnat ), priority=110  , match=(ct.new &&
!ct.rel && ip4 && ip4.dst == 20.0.0.50 && tcp && tcp.dst == 80 &&
is_chassis_resident("cr-lr0-sw2")),
action=(ct_lb_mark(backends=30.0.0.50:80);)
  table=8 (lr_in_dnat ), priority=110  , match=(ct.new &&
!ct.rel && ip4 && ip4.dst == 20.0.0.50 && tcp && tcp.dst == 80 &&
is_chassis_resident("cr-lr0-sw3")),
action=(ct_lb_mark(backends=30.0.0.50:80);)
  table=8 (lr_in_dnat ), priority=110  , match=(ct.new &&
!ct.rel && ip4 && ip4.dst == 30.0.0.60 && tcp && tcp.dst == 80 &&
is_chassis_resident("cr-lr0-sw1")),
action=(ct_lb_mark(backends=10.0.0.60:80);)
  table=8 (lr_in_dnat ), priority=110  , match=(ct.new &&
!ct.rel && ip4 && ip4.dst == 30.0.0.60 && tcp && tcp.dst == 80 &&
is_chassis_resident("cr-lr0-sw2")),
action=(ct_lb_mark(backends=10.0.0.60:80);)
  table=8 (lr_in_dnat ), priority=110  , match=(ct.new &&
!ct.rel && ip4 && ip4.dst == 30.0.0.60 && tcp && tcp.dst == 80 &&
is_chassis_resident("cr-lr0-sw3")),
action=(ct_lb_mark(backends=10.0.0.60:80);)

If a logical port of sw2 (20.0.0.4) sends any packet to 10.0.0.0/24,
then ideally  the routing will be handled in ch1 since lr1-sw1 is
bound on ch1.

Now with the above logical flows,  load balancing could happen in the
source chassis itself. Is that ok ?

Shouldn't this patch generate the flows like this for lb1, lb2 and lb3 ?

  table=8 (lr_in_dnat ), priority=110  , match=(ct.new &&
!ct.rel && ip4 && ip4.dst == 10.0.0.40 && tcp && tcp.dst == 80 &&
is_chassis_resident("cr-lr0-sw1")),
action=(ct_lb_mark(backends=20.0.0.40:80);)
  table=8 (lr_in_dnat ), priority=110  , match=(ct.new &&
!ct.rel && ip4 && ip4.dst == 20.0.0.50 && tcp && tcp.dst == 80 &&
is_chassis_resident("cr-lr0-sw2")),
action=(ct_lb_mark(backends=30.0.0.50:80);)
  table=8 (lr_in_dnat ), priority=110  , match=(ct.new &&
!ct.rel && ip4 && ip4.dst == 30.0.0.60 && tcp && tcp.dst == 80 &&
is_chassis_resident("cr-lr0-sw3")),
action=(ct_lb_mark(backends=10.0.0.60:80);)

So that the LB NAT happens on the chassis where the distributed
gateway port for the LB vip subnet resides ?

Thanks
Numan





> ---
>  northd/en-lr-stateful.c |  12 ---
>  northd/northd.c |  12 +--
>  tests/ovn-northd.at |  86 +
>  tests/ovn.at| 167 
>  4 files changed, 260 insertions(+), 17 deletions(-)
>
> diff --git a/northd/en-lr-stateful.c b/northd/en-lr-stateful.c
> index baf1bd2f8..f09691af6 100644
> --- a/northd/en-lr-stateful.c
> +++ b/northd/en-lr-stateful.c
> @@ -516,18 +516,6 @@ lr_stateful_record_create(struct lr_stateful_table 
> *table,
>
>  table->array[od->index] = lr_stateful_rec;
>
> -/* Load balancers are not supported (yet) if a logical router has 
> multiple
> - * distributed gateway port.  Log a warning. */
> -if (lr_stateful_rec->has_lb_vip && lr_has_multiple_gw_ports(od)) {
> -static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 1);
> -VLOG_WARN_RL(, "Load-balancers are configured on logical "
> - "router %s, which has %"PRIuSIZE" distributed "
> - "gateway ports. Load-balancer is not supported "
> - "yet when 

Re: [ovs-dev] [PATCH ovn v2 3/7] binding: Cleanup related_lports for deleted ports.

[Numan Siddique]

On Tue, Jul 23, 2024 at 11:55 AM Xavier Simonart  wrote:
>
> When a port is deleted, remove it from the related ports.
> Some ports, such a l3gw ports for non local datapaths, can be related
> while not belonging to a local datapath. Remove such ports from
> related_lports when they are deleted.
>
> Some tests, such as "delete mac bindings" or
> "router port add then remove - distributed router gateway port" were already
> testing such scenarios, but were were checking whether related_lports were
> correct.
> This will be automatically tested when related_lports will be checked
> at the end of the tests, in a following patch.
>
> Signed-off-by: Xavier Simonart 
> ---
>  controller/binding.c | 10 +-
>  1 file changed, 1 insertion(+), 9 deletions(-)
>
> diff --git a/controller/binding.c b/controller/binding.c
> index 97f4545a4..1bb5cca52 100644
> --- a/controller/binding.c
> +++ b/controller/binding.c
> @@ -2734,6 +2734,7 @@ handle_deleted_lport(const struct sbrec_port_binding 
> *pb,
>   struct binding_ctx_in *b_ctx_in,
>   struct binding_ctx_out *b_ctx_out)
>  {
> +remove_related_lport(pb, b_ctx_out);

Thanks for the patch.  The function remove_pb_from_local_datapath() also calls
remove_related_lport().  So I applied this patch with the below changes


-
diff --git a/controller/binding.c b/controller/binding.c
index 1bb4cf8649..a7bbd24435 100644
--- a/controller/binding.c
+++ b/controller/binding.c
@@ -2732,7 +2732,6 @@ handle_deleted_lport(const struct sbrec_port_binding *pb,
  struct binding_ctx_in *b_ctx_in,
  struct binding_ctx_out *b_ctx_out)
 {
-remove_related_lport(pb, b_ctx_out);
 /* If the binding is local, remove it. */
 struct local_datapath *ld =
 get_local_datapath(b_ctx_out->local_datapaths,
@@ -2750,6 +2749,12 @@ handle_deleted_lport(const struct sbrec_port_binding *pb,
 return;
 }

+/* Some ports, such a l3gw ports for non local datapaths, can be related
+ * while not belonging to a local datapath. Remove such ports from
+ * related_lports when they are deleted.
+ */
+remove_related_lport(pb, b_ctx_out);
+
 /* If the binding is not local, if 'pb' is a L3 gateway port, we should
  * remove its peer, if that one is local.
  */

-

Numan

>  /* If the binding is local, remove it. */
>  struct local_datapath *ld =
>  get_local_datapath(b_ctx_out->local_datapaths,
> @@ -2751,15 +2752,6 @@ handle_deleted_lport(const struct sbrec_port_binding 
> *pb,
>  return;
>  }
>
> -/*
> - * Remove localport that was part of local datapath that is not
> - * considered to be local anymore.
> - */
> -if (!ld && !strcmp(pb->type, "localport") &&
> -sset_find(_ctx_out->related_lports->lport_names, 
> pb->logical_port)) {
> -remove_related_lport(pb, b_ctx_out);
> -}
> -
>  /* If the binding is not local, if 'pb' is a L3 gateway port, we should
>   * remove its peer, if that one is local.
>   */
> --
> 2.31.1
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn v2 2/7] tests: Add macros for checking related ports.

[Numan Siddique]

On Tue, Jul 23, 2024 at 11:55 AM Xavier Simonart  wrote:
>
> Two macros have been added:
> - CHECK_RELATED_PORTS_AFTER_RECOMPUTE
>   Checks the related_lports using IP and recompute.
> - CHECK_AFTER_RECOMPUTE
>   Checks related_lports and flows using IP and recompute.
>   Using CHECK_RELATED_PORTS_AFTER_RECOMPUTE followed by
>   CHECK_FLOWS_PORTS_AFTER_RECOMPUTE would not detect any lflow related issues.
>
> CHECK_RELATED_PORTS_AFTER_RECOMPUTE will be used in following patch
> to check related_ports at the end of the tests.
>
> Signed-off-by: Xavier Simonart 

Thanks.  I applied this patch to main with the below changes

--
diff --git a/tests/ovn-macros.at b/tests/ovn-macros.at
index 02de7208dc..d57eadfc57 100644
--- a/tests/ovn-macros.at
+++ b/tests/ovn-macros.at
@@ -27,7 +27,7 @@ m4_define([DUMP_FLOWS], [
   sort > $output_file
 ])

-# DUMP_RELATED_PORTS(sbix, output_file)
+# DUMP_RELATED_PORTS(sbox, output_file)
 # Dump related ports
 m4_define([DUMP_RELATED_PORTS], [
 sbox=$1
@@ -69,7 +69,7 @@ m4_define([CHECK_RELATED_PORTS_AFTER_RECOMPUTE], [
 sbox=$2
 related_ports=$3
 AT_CAPTURE_FILE([related-ports-diff])
-# Make sure I+P has finalized his job before getting flows and
comparing them after recompte.
+# Make sure I+P has finalized the job before getting flows and
comparing them after recompte.
 # Some tests have northd and ovn-nb ovsdb stopped, so avoid
ovn-nbctl for those.
 if [[ -e ovn-nb/ovn-nb.sock ]] && [[ -e northd/ovn-northd.pid ]]; then
 # Do wait twice to handle some potential race conditions
@@ -79,15 +79,15 @@ m4_define([CHECK_RELATED_PORTS_AFTER_RECOMPUTE], [

 as $sbox
 if test "$hv" != "vtep"; then
-  DUMP_RELATED_PORTS([$sbox], [related-ports-$hv-1])
+  DUMP_RELATED_PORTS([$sbox], [related-ports-$hv-before])
   check ovn-appctl -t ovn-controller recompute
   # The recompute might cause some sb changes. Let controller catch up.
   if [[ -e ovn-nb/ovn-nb.sock ]] && [[ -e northd/ovn-northd.pid ]]; then
   check ovn-nbctl --wait=hv sync
   fi
-  DUMP_RELATED_PORTS([$sbox], [related-ports-$hv-2])
+  DUMP_RELATED_PORTS([$sbox], [related-ports-$hv-after])
   # Compare and store differences before and after recompute
-  comm -3 related-ports-$hv-1 related-ports-$hv-2 > related-ports-diff-$hv
+  comm -3 related-ports-$hv-before related-ports-$hv-after >
related-ports-diff-$hv
   # Ignore some differences.
   echo "$related_ports" | comm -2 -3 related-ports-diff-$hv - >
related-ports-diff
   AT_CHECK([wc -l < related-ports-diff], [0], [0
-

Numan



> ---
>  tests/ovn-macros.at | 80 -
>  1 file changed, 79 insertions(+), 1 deletion(-)
>
> diff --git a/tests/ovn-macros.at b/tests/ovn-macros.at
> index 47ada5c70..02de7208d 100644
> --- a/tests/ovn-macros.at
> +++ b/tests/ovn-macros.at
> @@ -27,6 +27,15 @@ m4_define([DUMP_FLOWS], [
>sort > $output_file
>  ])
>
> +# DUMP_RELATED_PORTS(sbix, output_file)
> +# Dump related ports
> +m4_define([DUMP_RELATED_PORTS], [
> +sbox=$1
> +output_file=$2
> +as $sbox
> +ovn-appctl debug/dump-related-ports | sort > $output_file
> +])
> +
>  m4_define([CHECK_FLOWS_AFTER_RECOMPUTE], [
>  hv=$1
>  sbox=$2
> @@ -50,7 +59,76 @@ m4_define([CHECK_FLOWS_AFTER_RECOMPUTE], [
>fi
>DUMP_FLOWS([$sbox], [flows-$hv-2])
>diff flows-$hv-1 flows-$hv-2 > flow-diff
> -  AT_CHECK([test $(diff flows-$hv-1 flows-$hv-2 | wc -l) == 0])
> +  AT_CHECK([wc -l < flow-diff], [0], [0
> +])
> +fi
> +])
> +
> +m4_define([CHECK_RELATED_PORTS_AFTER_RECOMPUTE], [
> +hv=$1
> +sbox=$2
> +related_ports=$3
> +AT_CAPTURE_FILE([related-ports-diff])
> +# Make sure I+P has finalized his job before getting flows and comparing 
> them after recompte.
> +# Some tests have northd and ovn-nb ovsdb stopped, so avoid ovn-nbctl 
> for those.
> +if [[ -e ovn-nb/ovn-nb.sock ]] && [[ -e northd/ovn-northd.pid ]]; then
> +# Do wait twice to handle some potential race conditions
> +check ovn-nbctl --wait=hv sync
> +check ovn-nbctl --wait=hv sync
> +fi
> +
> +as $sbox
> +if test "$hv" != "vtep"; then
> +  DUMP_RELATED_PORTS([$sbox], [related-ports-$hv-1])
> +  check ovn-appctl -t ovn-controller recompute
> +  # The recompute might cause some sb changes. Let controller catch up.
> +  if [[ -e ovn-nb/ovn-nb.sock ]] && [[ -e northd/ovn-northd.pid ]]; then
> +  check ovn-nbctl --wait=hv sync
> +  fi
> +  DUMP_RELATED_PORTS([$sbox], [related-ports-$hv-2])
> +  # Compare and store differences before and after recompute
> +  comm -3 related-ports-$hv-1 related-ports-$hv-2 > 
> related-ports-diff-$hv
> +  # Ignore some differences.
> +  echo "$related_ports" | comm -2 -3 related-ports-diff-$hv - > 
> related-ports-diff
> +  AT_CHECK([wc -l < 

Re: [ovs-dev] [PATCH ovn v2 1/7] controller: Add debug/dump-related-ports unixctl.

[Numan Siddique]

On Tue, Jul 23, 2024 at 11:55 AM Xavier Simonart  wrote:
>
> Signed-off-by: Xavier Simonart 


> ---
>  controller/binding.c| 12 
>  controller/binding.h|  3 +++
>  controller/ovn-controller.c | 15 +++
>  3 files changed, 30 insertions(+)
>
> diff --git a/controller/binding.c b/controller/binding.c
> index b7e7f4874..97f4545a4 100644
> --- a/controller/binding.c
> +++ b/controller/binding.c
> @@ -1037,6 +1037,18 @@ local_binding_set_down(struct shash *local_bindings, 
> const char *pb_name,
>  }
>  }
>
> +void
> +binding_dump_related_lports(struct related_lports *related_lports,
> +struct ds *out_data)
> +{
> +const char *name;
> +if (sset_count(_lports->lport_names)) {
> +SSET_FOR_EACH (name, _lports->lport_names) {
> +ds_put_format(out_data, "%s\n", name);
> +}
> +}
> +}

Thanks.

I applied this patch with the below changes

diff --git a/controller/binding.c b/controller/binding.c
index 97f4545a40..5d1650fe1e 100644
--- a/controller/binding.c
+++ b/controller/binding.c
@@ -1042,10 +1042,8 @@ binding_dump_related_lports(struct
related_lports *related_lports,
 struct ds *out_data)
 {
 const char *name;
-if (sset_count(_lports->lport_names)) {
-SSET_FOR_EACH (name, _lports->lport_names) {
-ds_put_format(out_data, "%s\n", name);
-}
+SSET_FOR_EACH (name, _lports->lport_names) {
+ds_put_format(out_data, "%s\n", name);
 }
 }



Numan

> +
>  void
>  binding_dump_local_bindings(struct local_binding_data *lbinding_data,
>  struct ds *out_data)
> diff --git a/controller/binding.h b/controller/binding.h
> index 75e7a2679..f44f95833 100644
> --- a/controller/binding.h
> +++ b/controller/binding.h
> @@ -202,6 +202,9 @@ void binding_tracked_dp_destroy(struct hmap 
> *tracked_datapaths);
>
>  void binding_dump_local_bindings(struct local_binding_data *, struct ds *);
>
> +void binding_dump_related_lports(struct related_lports *related_lports,
> + struct ds *);
> +
>  bool is_additional_chassis(const struct sbrec_port_binding *pb,
> const struct sbrec_chassis *chassis_rec);
>
> diff --git a/controller/ovn-controller.c b/controller/ovn-controller.c
> index d6d001b1a..a4714739e 100644
> --- a/controller/ovn-controller.c
> +++ b/controller/ovn-controller.c
> @@ -99,6 +99,7 @@ static unixctl_cb_func debug_pause_execution;
>  static unixctl_cb_func debug_resume_execution;
>  static unixctl_cb_func debug_status_execution;
>  static unixctl_cb_func debug_dump_local_bindings;
> +static unixctl_cb_func debug_dump_related_lports;
>  static unixctl_cb_func debug_dump_local_template_vars;
>  static unixctl_cb_func debug_dump_lflow_conj_ids;
>  static unixctl_cb_func lflow_cache_flush_cmd;
> @@ -5310,6 +5311,10 @@ main(int argc, char *argv[])
>   debug_dump_local_bindings,
>   _data->lbinding_data);
>
> +unixctl_command_register("debug/dump-related-ports", "", 0, 0,
> + debug_dump_related_lports,
> + _data->related_lports);
> +
>  unixctl_command_register("debug/dump-lflow-conj-ids", "", 0, 0,
>   debug_dump_lflow_conj_ids,
>   _output_data->conj_ids);
> @@ -6220,6 +6225,16 @@ debug_dump_local_bindings(struct unixctl_conn *conn, 
> int argc OVS_UNUSED,
>  ds_destroy(_data);
>  }
>
> +static void
> +debug_dump_related_lports(struct unixctl_conn *conn, int argc OVS_UNUSED,
> +  const char *argv[] OVS_UNUSED, void 
> *related_lports)
> +{
> +struct ds data = DS_EMPTY_INITIALIZER;
> +binding_dump_related_lports(related_lports, );
> +unixctl_command_reply(conn, ds_cstr());
> +ds_destroy();
> +}
> +
>  static void
>  debug_dump_lflow_conj_ids(struct unixctl_conn *conn, int argc OVS_UNUSED,
>const char *argv[] OVS_UNUSED, void *conj_ids)
> --
> 2.31.1
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn v2 0/7] pmtud and related ports.

[Numan Siddique]

On Tue, Jul 23, 2024 at 11:55 AM Xavier Simonart  wrote:
>
> Xavier Simonart (7):
>   controller: Add debug/dump-related-ports unixctl.
>   tests: Add macros for checking related ports.
>   binding: Cleanup related_lports for deleted ports.
>   binding: Cleanup related_lports for container ports.
>   binding: Cleanup related ports on port type change.
>   tests: Compare IP and recompute related ports.
>   northd: Fix pmtud related issues.
>
>  controller/binding.c| 33 +
>  controller/binding.h|  3 ++
>  controller/ovn-controller.c | 15 ++
>  northd/northd.c | 13 ++
>  tests/multinode.at  | 33 +
>  tests/ovn-controller.at | 20 +---
>  tests/ovn-macros.at | 92 ++---
>  tests/ovn-northd.at | 10 
>  tests/ovn.at| 27 ---
>  9 files changed, 209 insertions(+), 37 deletions(-)

Hi Xavier,

Thanks for the patch series.  I applied this patch series with some
changes in p1, p2 and p3.

Please see the individual patches for the changes.

Numan

>
> --
> 2.31.1
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn v2] northd: Add ECMP symmetric replies for egress.

[Numan Siddique]

On Fri, Jul 26, 2024 at 11:16 AM Mark Michelson  wrote:
>
> Hi Numan,
>
> The only issue I have with this patch is that I think it should have a
> change in ovn-nb.xml to mention that the ecmp_symmetric_reply option
> also now applies for egress-originated traffic.
>
> Other than that,
>
> Acked-by: Mark Michelson 

Thanks for the reviews.

I applied this patch to the main with the below changes in ovn-nb.xml.


diff --git a/ovn-nb.xml b/ovn-nb.xml
index 6a2b964ace..a4362a4ef1 100644
--- a/ovn-nb.xml
+++ b/ovn-nb.xml
@@ -3686,12 +3686,29 @@ or
   

   
-If true, then new traffic that arrives over this route will have
-its reply traffic bypass ECMP route selection and will be sent out
-this route instead. Note that this option overrides any rules set
-in the  table. This option
-only works on gateway routers (routers that have
- set).
+
+  If true, then
+
+
+  
+New ingress-originated traffic that arrives over this route will
+have its reply traffic bypass ECMP route selection and will be
+sent out this route instead.
+  
+
+  
+For the egress-originated traffic, the ingress reply traffic route
+gets saved.  And the subsequent traffic will bypass ECMP route
+selection and instead be sent out the same route.
+  
+
+
+
+  Note that this option overrides any rules set in the
+   table.  This option only works
+  on gateway routers (routers that have
+   set).
+
   

   



Numan

>
> On 7/18/24 17:29, num...@ovn.org wrote:
> > From: Numan Siddique 
> >
> > When there are ECMP symmetric static routes configured, OVN selects
> > one of the next hop for the traffic originated from within the
> > cluster.  For the subsequent packets to the same destination,
> > OVN may select a different next hop (which is fine).  But there can
> > be certain usecases, where the next hop entity can be stateful and
> > selecting the same next hop is desirable.
> >
> > This patch address this usecase in the following way
> >
> > 1.  For the first packet originating from the OVN logical port
> > VIF, OVN selects a next hop 'A' and forwards the traffic to
> > it.
> >
> > 2.  When the reply traffic is received (either from next hop 'A'
> > or any other next hop), it commits the connection in the
> > DNAT zone of the logical router and saves the state in
> > ct_label.ecmp_reply_eth and ct_label.ecmp_reply_port.
> > Note that we already support this for the traffic
> > originating from an ECMP route [1].  We are now extending
> > the same for the traffic originating from the cluster towards
> > the ECMP route.
> >
> >  3. For the subsequent packets from the cluster, we select the
> > next hop eth address and the port from the saved conntrack
> > state.  This is straightforward as we anyway send the packet
> > to the DNAT zone of the logical router.
> >
> > Example: If a logical router lr0 is configured with the below
> > EMCP static routes
> >
> > ovn-nbctl lr-route-list lr0
> > IPv4 Routes
> > Route Table :
> >  0.0.0.0/0172.20.0.1 dst-ip ecmp
> >  0.0.0.0/0172.20.0.2 dst-ip ecmp 
> > ecmp-symmetric-reply
> >
> > Before this patch, we were adding the below logical flows in the router
> > pipeline for the ECMP route handling:
> >
> > -
> > table=10(lr_in_ecmp_stateful), priority=100  , match=(inport == 
> > "lr0-public" && ip4.src == 0.0.0.0/0 && !ct.rpl && (ct.new || ct.est)), 
> > action=(ct_commit { ct_label.ecmp_reply_eth = eth.src;  
> > ct_mark.ecmp_reply_port = 3;}; next;)
> > table=14(lr_in_ip_routing   ), priority=10300, match=(ct.rpl && 
> > ct_mark.ecmp_reply_port == 3 && reg7 == 0 && ip4.dst == 0.0.0.0/0), 
> > action=(ip.ttl--; flags.loopback = 1; eth.src = 00:11:22:00:ff:01; reg1 = 
> > 172.20.0.100; outport = "lr0-public"; next;)
> > table=16(lr_in_policy   ), priority=65535, match=(ct.rpl && 
> > ct_mark.ecmp_reply_port == 3), action=(next;)
> > table=20(lr_in_arp_resolve  ), priority=200  , match=(ct.rpl && 
> > ct_mark.ecmp_reply_port == 3), action=(push(xxreg1); xxreg1 = ct_label; 
> > eth.dst = xxreg1[32..79]; pop(xxreg1); next;)
> > -
> &g

Re: [ovs-dev] [PATCH ovn] containers: Cap sphinx at 7 to unblock CI.

[Numan Siddique]

On Mon, Jul 29, 2024 at 6:44 PM Ilya Maximets  wrote:
>
> Just released sphinx 8.0 requires Pygments >= 2.17, but it fails to
> build with it in practice.  This breaks our CI completely:
>
>   Traceback (most recent call last):
> File "/usr/local/bin/sphinx-build", line 5, in 
>   from sphinx.cmd.build import main
> File "sphinx/cmd/build.py", line 21, in 
>   from sphinx.application import Sphinx
> File "sphinx/application.py", line 29, in 
>   from sphinx.highlighting import lexer_classes
> File "sphinx/highlighting.py", line 86, in 
>   class PygmentsBridge:
>   ...<131 lines>...
>   return formatter.get_style_defs() + _LATEX_ADD_STYLES
> File "sphinx/highlighting.py", line 89, in PygmentsBridge
>   html_formatter = HtmlFormatter[str]
>~^
>   TypeError: type 'HtmlFormatter' is not subscriptable
>
> Cap the version for now to unblock CI.
>
> Can be reverted once https://github.com/sphinx-doc/sphinx/issues/12711
> is fixed.
>
> Signed-off-by: Ilya Maximets 

Thanks Ilya for fixing the CI.  Applied to main.  Do we need to back port this ?
I think so.

Numan

> ---
>  utilities/containers/py-requirements.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/utilities/containers/py-requirements.txt 
> b/utilities/containers/py-requirements.txt
> index 2a310c687..8a3e977aa 100644
> --- a/utilities/containers/py-requirements.txt
> +++ b/utilities/containers/py-requirements.txt
> @@ -1,7 +1,7 @@
>  flake8>=6.1.0
>  meson>=1.4,<1.5
>  scapy
> -sphinx
> +sphinx<8.0 # https://github.com/sphinx-doc/sphinx/issues/12711
>  setuptools
>  pyelftools
>  pyOpenSSL
> --
> 2.45.2
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn branch-24.03] debian: Fix upper case package name in changlog.

[Numan Siddique]

On Mon, Jul 29, 2024 at 2:58 PM Han Zhou  wrote:
>
> + @Dmitry Yusupov
>
> Reported-by: Dmitry Yusupov 
>
> On Mon, Jul 29, 2024 at 11:42 AM Han Zhou  wrote:
> >
> > In 24.03 branch 'OVN' was used as the package name which breaks debian
> > build:
> >
> > dpkg-gencontrol: error: source package name 'OVN' is illegal: character 'O' 
> > not allowed
> >
> > Signed-off-by: Han Zhou 

Acked-by: Numan Siddique 

Numan

> > ---
> >  debian/changelog | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/debian/changelog b/debian/changelog
> > index 207ea3957524..6b58383f4d85 100644
> > --- a/debian/changelog
> > +++ b/debian/changelog
> > @@ -1,16 +1,16 @@
> > -OVN (24.03.3-1) unstable; urgency=low
> > +ovn (24.03.3-1) unstable; urgency=low
> > [ OVN team ]
> > * New upstream version
> >
> >   -- OVN team   Thu, 09 May 2024 15:10:30 -0400
> >
> > -OVN (24.03.2-1) unstable; urgency=low
> > +ovn (24.03.2-1) unstable; urgency=low
> > [ OVN team ]
> > * New upstream version
> >
> >   -- OVN team   Thu, 09 May 2024 15:10:30 -0400
> >
> > -OVN (24.03.1-1) unstable; urgency=low
> > +ovn (24.03.1-1) unstable; urgency=low
> > [ OVN team ]
> > * New upstream version
> >
> > --
> > 2.38.1
> >
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn v7 2/2] controller, northd: Add support for CT zone limits.

[Numan Siddique]

On Mon, Jul 29, 2024 at 2:41 AM Ales Musil  wrote:
>
> Add support for limiting the CT zone usage per Ls, LR or LSP.
> When the limit is configured on logical switch it will also implicitly
> set limits for all ports in that logical switch. The port configuration
> can be overwritten individually and has priority over the whole logical
> switch configuration.
>
> The value 0 means unlimited, when the value is not specified it is
> derived from OvS default CT limit specified for given OvS datapath.
>
> Reported-at: https://bugzilla.redhat.com/2189924
> Signed-off-by: Ales Musil 
> ---
> v7: Rebase on top of latest main.
> v6: Rebase on top of latest main.
> Addressed comments from Mark:
> - Fix spelling error in the documenation.
> Addressed comments from Numan:
> - Avoid looping over all interface and loop over local ones only.
> - Do not loop over interfaces when the DP limit didn't change.
> v5: Rebase on top of latest main.
> Avoid OvS CT zone lookup in every loop of pending commit.
> v4: Rebase on top of latest main.
> Change naming of the ct_zone_limit_sync to avoid potential confusion as 
> suggested by Lorenzo.
> v3: Rebase on top of latest main.
> ---

Thanks for the patch series.  I did some very small changes and applied to main.


diff --git a/ovn-nb.xml b/ovn-nb.xml
index 7087c0cf22..6a2b964ace 100644
--- a/ovn-nb.xml
+++ b/ovn-nb.xml
@@ -749,7 +749,8 @@
   

   
+  type='{"type": "integer", "minInteger": 0,
+ "maxInteger": 4294967295}'>
 CT zone limit value for given
 . This value will be propagated to all
  when configured, but can be
@@ -1160,7 +1161,8 @@
 

 
+type='{"type": "integer", "minInteger": 0,
+   "maxInteger": 4294967295}'>
   CT zone limit value for given
   . This value has priority over
   limit specified on  when configured.
@@ -2834,9 +2836,10 @@ or
   

   
+  type='{"type": "integer", "minInteger": 0,
+ "maxInteger": 4294967295}'>
 CT zone limit value for given
-. The value 0 means unlimited, when the
+. The value 0 means unlimited. When the
 option is not present the limit is not set and the zone limit is
 derived from OvS default datapath limit.
-

Numan

>  NEWS|   3 +
>  controller/ct-zone.c| 181 
>  controller/ct-zone.h|  15 ++-
>  controller/ovn-controller.c |  19 ++--
>  lib/ovn-util.c  |  17 
>  lib/ovn-util.h  |   3 +
>  northd/northd.c |   8 ++
>  ovn-nb.xml  |  29 ++
>  tests/ovn-controller.at |  99 
>  9 files changed, 346 insertions(+), 28 deletions(-)
>
> diff --git a/NEWS b/NEWS
> index 15c4c788a..87e326f21 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -44,6 +44,9 @@ Post v24.03.0
>  localnet port.
>- Added support to define boundaries (min and max values) for selected ct
>  zones.
> +  - Add support for CT zone limit that can be specified per LR
> +(options:ct-zone-limit), LS (other_config:ct-zone-limit) or LSP
> +(options:ct-zone-limit).
>
>  OVN v24.03.0 - 01 Mar 2024
>  --
> diff --git a/controller/ct-zone.c b/controller/ct-zone.c
> index f19883831..0a5d3d410 100644
> --- a/controller/ct-zone.c
> +++ b/controller/ct-zone.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>
> +#include "binding.h"
>  #include "chassis.h"
>  #include "ct-zone.h"
>  #include "local_data.h"
> @@ -37,6 +38,16 @@ static bool ct_zone_assign_unused(struct ct_zone_ctx *ctx,
>  static bool ct_zone_remove(struct ct_zone_ctx *ctx, const char *name);
>  static void ct_zone_add(struct ct_zone_ctx *ctx, const char *name,
>  uint16_t zone, bool set_pending);
> +static void
> +ct_zone_limits_update_per_dp(struct ct_zone_ctx *ctx,
> + const struct local_datapath *local_dp,
> + const struct shash *local_lports,
> + const char *name);
> +static bool ct_zone_limit_update(struct ct_zone_ctx *ctx, const char *name,
> + int64_t limit);
> +static int64_t ct_zone_get_dp_limit(const struct sbrec_datapath_binding *dp);
> +static int64_t ct_zone_get_pb_limit(const struct sbrec_port_binding *pb);
> +static int64_t ct_zone_limit_normalize(int64_t limit);
>
>  void
>  ct_zone_ctx_init(struct ct_zone_ctx *ctx)
> @@ -265,11 +276,24 @@ ct_zones_update(const struct sset *local_lports,
>
>  void
>  ct_zones_commit(const struct ovsrec_bridge *br_int,
> -struct shash *pending_ct_zones)
> +const struct ovsrec_datapath *ovs_dp,
> +struct ovsdb_idl_txn *ovs_idl_txn,
> +struct ct_zone_ctx *ctx)
>  {
> +if (shash_is_empty(>pending)) {
> +return;
> +}
> +
> + 

Re: [ovs-dev] [PATCH ovn v7 1/2] controller: Prepare structure around CT zone limiting.

[Numan Siddique]

On Mon, Jul 29, 2024 at 2:41 AM Ales Musil  wrote:
>
> In order to be able to store CT limits for specified zone, store the
> zone inside separate struct instead of simap. This allows to add
> the addition of limit without changing the whole infrastructure again.
>
> This is a preparation step for the CT zone limits.
>
> Acked-by: Mark Michelson 
> Signed-off-by: Ales Musil 
> ---
> v7: Rebase on top of latest main.
> v6: Rebase on top of latest main.
> Add ack from Mark.
> v5: Rebase on top of latest main.
> Address comments from Dumitru:
>   Remove the CT_ZONE_STATE_NEW enum variant.
>   Add wrappers for ct_zone_ctx_init/destroy().
> v4: Rebase on top of latest main.
> Address comments from Lorenzo.
> v3: Rebase on top of latest main.
> v2: Fix NULL ptr deref.
> ---
>  controller/ct-zone.c| 195 ++--
>  controller/ct-zone.h|  13 ++-
>  controller/ofctrl.c |   2 +-
>  controller/ovn-controller.c |  17 ++--
>  controller/physical.c   |  17 ++--
>  controller/physical.h   |   2 +-
>  6 files changed, 147 insertions(+), 99 deletions(-)
>
> diff --git a/controller/ct-zone.c b/controller/ct-zone.c
> index c80562e4b..f19883831 100644
> --- a/controller/ct-zone.c
> +++ b/controller/ct-zone.c
> @@ -28,13 +28,29 @@ ct_zone_restore(const struct sbrec_datapath_binding_table 
> *dp_table,
>  struct ct_zone_ctx *ctx, const char *name, int zone);
>  static void ct_zone_add_pending(struct shash *pending_ct_zones,
>  enum ct_zone_pending_state state,
> -int zone, bool add, const char *name);
> +struct ct_zone *zone, bool add,
> +const char *name);
>  static int ct_zone_get_snat(const struct sbrec_datapath_binding *dp);
>  static bool ct_zone_assign_unused(struct ct_zone_ctx *ctx,
>const char *zone_name,
>int *scan_start, int scan_stop);
> -static bool ct_zone_remove(struct ct_zone_ctx *ctx,
> -   struct simap_node *ct_zone);
> +static bool ct_zone_remove(struct ct_zone_ctx *ctx, const char *name);
> +static void ct_zone_add(struct ct_zone_ctx *ctx, const char *name,
> +uint16_t zone, bool set_pending);
> +
> +void
> +ct_zone_ctx_init(struct ct_zone_ctx *ctx)
> +{
> +shash_init(>pending);
> +shash_init(>current);
> +}
> +
> +void
> +ct_zone_ctx_destroy(struct ct_zone_ctx *ctx)
> +{
> +shash_destroy_free_data(>current);
> +shash_destroy_free_data(>pending);
> +}
>
>  void
>  ct_zones_restore(struct ct_zone_ctx *ctx,
> @@ -50,7 +66,8 @@ ct_zones_restore(struct ct_zone_ctx *ctx,
>  struct ct_zone_pending_entry *ctpe = pending_node->data;
>
>  if (ctpe->add) {
> -ct_zone_restore(dp_table, ctx, pending_node->name, ctpe->zone);
> +ct_zone_restore(dp_table, ctx, pending_node->name,
> +ctpe->ct_zone.zone);
>  }
>  }
>
> @@ -144,7 +161,6 @@ ct_zones_update(const struct sset *local_lports,
>  const struct hmap *local_datapaths, struct ct_zone_ctx *ctx)
>  {
>  int min_ct_zone, max_ct_zone;
> -struct simap_node *ct_zone;
>  const char *user;
>  struct sset all_users = SSET_INITIALIZER(_users);
>  struct simap req_snat_zones = SIMAP_INITIALIZER(_snat_zones);
> @@ -186,13 +202,15 @@ ct_zones_update(const struct sset *local_lports,
>  ct_zones_parse_range(ovs_table, _ct_zone, _ct_zone);
>
>  /* Delete zones that do not exist in above sset. */
> -SIMAP_FOR_EACH_SAFE (ct_zone, >current) {
> -if (!sset_contains(_users, ct_zone->name) ||
> -ct_zone->data < min_ct_zone || ct_zone->data > max_ct_zone) {
> -ct_zone_remove(ctx, ct_zone);
> -} else if (!simap_find(_snat_zones, ct_zone->name)) {
> -bitmap_set1(unreq_snat_zones_map, ct_zone->data);
> -simap_put(_snat_zones, ct_zone->name, ct_zone->data);
> +struct shash_node *node;
> +SHASH_FOR_EACH_SAFE (node, >current) {
> +struct ct_zone *ct_zone = node->data;
> +if (!sset_contains(_users, node->name) ||
> +ct_zone->zone < min_ct_zone || ct_zone->zone > max_ct_zone) {
> +ct_zone_remove(ctx, node->name);
> +} else if (!simap_find(_snat_zones, node->name)) {
> +bitmap_set1(unreq_snat_zones_map, ct_zone->zone);
> +simap_put(_snat_zones, node->name, ct_zone->zone);
>  }
>  }
>
> @@ -207,7 +225,7 @@ ct_zones_update(const struct sset *local_lports,
>  struct simap_node *unreq_node;
>  SIMAP_FOR_EACH_SAFE (unreq_node, _snat_zones) {
>  if (unreq_node->data == snat_req_node->data) {
> -simap_find_and_delete(>current, unreq_node->name);
> +ct_zone_remove(ctx, unreq_node->name);
>  

Re: [ovs-dev] [PATCH ovn] ci: Bump the Cirrus CI Ubuntu image.

[Numan Siddique]

On Mon, Jul 29, 2024 at 1:52 AM Ales Musil  wrote:
>
> The Ubuntu 23.10 became EOL on July 11, 2024. Use the LTS
> 24.04 instead.
>
> Signed-off-by: Ales Musil 

Thanks.  Applied to main.

Numan

> ---
>  .cirrus.yml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/.cirrus.yml b/.cirrus.yml
> index 9b35d4cfb..14a54a0fe 100644
> --- a/.cirrus.yml
> +++ b/.cirrus.yml
> @@ -1,6 +1,6 @@
>  compute_engine_instance:
>image_project: ubuntu-os-cloud
> -  image: family/ubuntu-2310-arm64
> +  image: family/ubuntu-2404-lts-arm64
>architecture: arm64
>platform: linux
>memory: 4G
> --
> 2.45.2
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn v6 2/2] Controller, northd: Add support for CT zone limits.

[Numan Siddique]

On Fri, Jul 26, 2024 at 1:20 PM Ales Musil  wrote:
>
> On Fri, Jul 26, 2024 at 5:51 PM Numan Siddique  wrote:
>
> > On Thu, Jul 25, 2024 at 6:22 AM Ales Musil  wrote:
> > >
> > > Add support for limiting the CT zone usage per Ls, LR or LSP.
> > > When the limit is configured on logical switch it will also implicitly
> > > set limits for all ports in that logical switch. The port configuration
> > > can be overwritten individually and has priority over the whole logical
> > > switch configuration.
> > >
> > > The value 0 means unlimited, when the value is not specified it is
> > > derived from OvS default CT limit specified for given OvS datapath.
> > >
> > > Reported-at: https://bugzilla.redhat.com/2189924
> > > Signed-off-by: Ales Musil 
> >
> > Thanks for addressing the comments in v6.  The patch LGTM.
> >
> > Before applying/giving the Ack, I want to make sure that the system
> > test failure for this patch in the CI is a flake.
> > Can you please take a look ?
> >
> > https://github.com/ovsrobot/ovn/actions/runs/10092667039/job/27906915451#step:10:9299
> >
> > Thanks
> > Numan
> >
>
>
> It is a flake, for some reason the openbfdd fails to start from time to
> time.
>

Thanks for confirming.  I was a bit late in applying this patch series and
now it needs rebasing due to this commit -
https://github.com/ovn-org/ovn/commit/f2363f49f6a46e784b1d8dad33eee733aa09380c

I tried resolving the conflicts, but it was non trivial.  Can you
please rebase and submit ?

Numan

>
> > > ---
> > > v6: Rebase on top of latest main.
> > > Addressed comments from Mark:
> > > - Fix spelling error in the documenation.
> > > Addressed comments from Numan:
> > > - Avoid looping over all interface and loop over local ones only.
> > > - Do not loop over interfaces when the DP limit didn't change.
> > > v5: Rebase on top of latest main.
> > > Avoid OvS CT zone lookup in every loop of pending commit.
> > > v4: Rebase on top of latest main.
> > > Change naming of the ct_zone_limit_sync to avoid potential confusion
> > as suggested by Lorenzo.
> > > v3: Rebase on top of latest main.
> > > ---
> > >  NEWS|   3 +
> > >  controller/ct-zone.c| 180 
> > >  controller/ct-zone.h|  15 ++-
> > >  controller/ovn-controller.c |  21 +++--
> > >  lib/ovn-util.c  |  17 
> > >  lib/ovn-util.h  |   3 +
> > >  northd/northd.c |   8 ++
> > >  ovn-nb.xml  |  29 ++
> > >  tests/ovn-controller.at |  99 
> > >  9 files changed, 346 insertions(+), 29 deletions(-)
> > >
> > > diff --git a/NEWS b/NEWS
> > > index 72933b5b9..4c711d1ef 100644
> > > --- a/NEWS
> > > +++ b/NEWS
> > > @@ -42,6 +42,9 @@ Post v24.03.0
> > >  true, the traffic destined to a logical port of a provider logical
> > switch
> > >  (having a localnet port) will be tunnelled instead of sending it
> > via the
> > >  localnet port.
> > > +  - Add support for CT zone limit that can be specified per LR
> > > +(options:ct-zone-limit), LS (other_config:ct-zone-limit) or LSP
> > > +(options:ct-zone-limit).
> > >
> > >  OVN v24.03.0 - 01 Mar 2024
> > >  --
> > > diff --git a/controller/ct-zone.c b/controller/ct-zone.c
> > > index ab0eec9d0..1aab7ccef 100644
> > > --- a/controller/ct-zone.c
> > > +++ b/controller/ct-zone.c
> > > @@ -15,6 +15,7 @@
> > >
> > >  #include 
> > >
> > > +#include "binding.h"
> > >  #include "ct-zone.h"
> > >  #include "local_data.h"
> > >  #include "openvswitch/vlog.h"
> > > @@ -34,6 +35,16 @@ static bool ct_zone_assign_unused(struct ct_zone_ctx
> > *ctx,
> > >  static bool ct_zone_remove(struct ct_zone_ctx *ctx, const char *name);
> > >  static void ct_zone_add(struct ct_zone_ctx *ctx, const char *name,
> > >  uint16_t zone, bool set_pending);
> > > +static void
> > > +ct_zone_limits_update_per_dp(struct ct_zone_ctx *ctx,
> > > + const struct local_datapath *local_dp,
> > > + const struct shash *local_lports,
> > > + const char *name);
> &g

Re: [ovs-dev] [PATCH ovn v6 2/2] Controller, northd: Add support for CT zone limits.

[Numan Siddique]

On Thu, Jul 25, 2024 at 6:22 AM Ales Musil  wrote:
>
> Add support for limiting the CT zone usage per Ls, LR or LSP.
> When the limit is configured on logical switch it will also implicitly
> set limits for all ports in that logical switch. The port configuration
> can be overwritten individually and has priority over the whole logical
> switch configuration.
>
> The value 0 means unlimited, when the value is not specified it is
> derived from OvS default CT limit specified for given OvS datapath.
>
> Reported-at: https://bugzilla.redhat.com/2189924
> Signed-off-by: Ales Musil 

Thanks for addressing the comments in v6.  The patch LGTM.

Before applying/giving the Ack, I want to make sure that the system
test failure for this patch in the CI is a flake.
Can you please take a look ?
https://github.com/ovsrobot/ovn/actions/runs/10092667039/job/27906915451#step:10:9299

Thanks
Numan

> ---
> v6: Rebase on top of latest main.
> Addressed comments from Mark:
> - Fix spelling error in the documenation.
> Addressed comments from Numan:
> - Avoid looping over all interface and loop over local ones only.
> - Do not loop over interfaces when the DP limit didn't change.
> v5: Rebase on top of latest main.
> Avoid OvS CT zone lookup in every loop of pending commit.
> v4: Rebase on top of latest main.
> Change naming of the ct_zone_limit_sync to avoid potential confusion as 
> suggested by Lorenzo.
> v3: Rebase on top of latest main.
> ---
>  NEWS|   3 +
>  controller/ct-zone.c| 180 
>  controller/ct-zone.h|  15 ++-
>  controller/ovn-controller.c |  21 +++--
>  lib/ovn-util.c  |  17 
>  lib/ovn-util.h  |   3 +
>  northd/northd.c |   8 ++
>  ovn-nb.xml  |  29 ++
>  tests/ovn-controller.at |  99 
>  9 files changed, 346 insertions(+), 29 deletions(-)
>
> diff --git a/NEWS b/NEWS
> index 72933b5b9..4c711d1ef 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -42,6 +42,9 @@ Post v24.03.0
>  true, the traffic destined to a logical port of a provider logical switch
>  (having a localnet port) will be tunnelled instead of sending it via the
>  localnet port.
> +  - Add support for CT zone limit that can be specified per LR
> +(options:ct-zone-limit), LS (other_config:ct-zone-limit) or LSP
> +(options:ct-zone-limit).
>
>  OVN v24.03.0 - 01 Mar 2024
>  --
> diff --git a/controller/ct-zone.c b/controller/ct-zone.c
> index ab0eec9d0..1aab7ccef 100644
> --- a/controller/ct-zone.c
> +++ b/controller/ct-zone.c
> @@ -15,6 +15,7 @@
>
>  #include 
>
> +#include "binding.h"
>  #include "ct-zone.h"
>  #include "local_data.h"
>  #include "openvswitch/vlog.h"
> @@ -34,6 +35,16 @@ static bool ct_zone_assign_unused(struct ct_zone_ctx *ctx,
>  static bool ct_zone_remove(struct ct_zone_ctx *ctx, const char *name);
>  static void ct_zone_add(struct ct_zone_ctx *ctx, const char *name,
>  uint16_t zone, bool set_pending);
> +static void
> +ct_zone_limits_update_per_dp(struct ct_zone_ctx *ctx,
> + const struct local_datapath *local_dp,
> + const struct shash *local_lports,
> + const char *name);
> +static bool ct_zone_limit_update(struct ct_zone_ctx *ctx, const char *name,
> + int64_t limit);
> +static int64_t ct_zone_get_dp_limit(const struct sbrec_datapath_binding *dp);
> +static int64_t ct_zone_get_pb_limit(const struct sbrec_port_binding *pb);
> +static int64_t ct_zone_limit_normalize(int64_t limit);
>
>  void
>  ct_zone_ctx_init(struct ct_zone_ctx *ctx)
> @@ -210,11 +221,24 @@ ct_zones_update(const struct sset *local_lports,
>
>  void
>  ct_zones_commit(const struct ovsrec_bridge *br_int,
> -struct shash *pending_ct_zones)
> +const struct ovsrec_datapath *ovs_dp,
> +struct ovsdb_idl_txn *ovs_idl_txn,
> +struct ct_zone_ctx *ctx)
>  {
> +if (shash_is_empty(>pending)) {
> +return;
> +}
> +
> +struct ovsrec_ct_zone **all_zones =
> +xzalloc(sizeof *all_zones * (MAX_CT_ZONES + 1));
> +for (size_t i = 0; i < ovs_dp->n_ct_zones; i++) {
> +all_zones[ovs_dp->key_ct_zones[i]] = ovs_dp->value_ct_zones[i];
> +}
> +
>  struct shash_node *iter;
> -SHASH_FOR_EACH (iter, pending_ct_zones) {
> +SHASH_FOR_EACH (iter, >pending) {
>  struct ct_zone_pending_entry *ctzpe = iter->data;
> +struct ct_zone *ct_zone = >ct_zone;
>
>  /* The transaction is open, so any pending entries in the
>   * CT_ZONE_DB_QUEUED must be sent and any in CT_ZONE_DB_QUEUED
> @@ -226,7 +250,7 @@ ct_zones_commit(const struct ovsrec_bridge *br_int,
>
>  char *user_str = xasprintf("ct-zone-%s", iter->name);
>  if (ctzpe->add) {
> -char *zone_str = 

Re: [ovs-dev] [PATCH ovn v6 1/2] controller: Prepare structure around CT zone limiting.

[Numan Siddique]

On Thu, Jul 25, 2024 at 6:22 AM Ales Musil  wrote:
>
> In order to be able to store CT limits for specified zone, store the
> zone inside separate struct instead of simap. This allows to add
> the addition of limit without changing the whole infrastructure again.
>
> This is a preparation step for the CT zone limits.
>
> Acked-by: Mark Michelson 
> Signed-off-by: Ales Musil 

Acked-by: Numan Siddique 

Numan

> ---
> v6: Rebase on top of latest main.
> Add ack from Mark.
> v5: Rebase on top of latest main.
> Address comments from Dumitru:
>   Remove the CT_ZONE_STATE_NEW enum variant.
>   Add wrappers for ct_zone_ctx_init/destroy().
> v4: Rebase on top of latest main.
> Address comments from Lorenzo.
> v3: Rebase on top of latest main.
> v2: Fix NULL ptr deref.
> ---
>  controller/ct-zone.c| 183 ++--
>  controller/ct-zone.h|  13 ++-
>  controller/ofctrl.c |   2 +-
>  controller/ovn-controller.c |  17 ++--
>  controller/physical.c   |  17 ++--
>  controller/physical.h   |   2 +-
>  6 files changed, 140 insertions(+), 94 deletions(-)
>
> diff --git a/controller/ct-zone.c b/controller/ct-zone.c
> index e4f66a52a..ab0eec9d0 100644
> --- a/controller/ct-zone.c
> +++ b/controller/ct-zone.c
> @@ -26,12 +26,28 @@ ct_zone_restore(const struct sbrec_datapath_binding_table 
> *dp_table,
>  struct ct_zone_ctx *ctx, const char *name, int zone);
>  static void ct_zone_add_pending(struct shash *pending_ct_zones,
>  enum ct_zone_pending_state state,
> -int zone, bool add, const char *name);
> +struct ct_zone *zone, bool add,
> +const char *name);
>  static int ct_zone_get_snat(const struct sbrec_datapath_binding *dp);
>  static bool ct_zone_assign_unused(struct ct_zone_ctx *ctx,
>const char *zone_name, int *scan_start);
> -static bool ct_zone_remove(struct ct_zone_ctx *ctx,
> -   struct simap_node *ct_zone);
> +static bool ct_zone_remove(struct ct_zone_ctx *ctx, const char *name);
> +static void ct_zone_add(struct ct_zone_ctx *ctx, const char *name,
> +uint16_t zone, bool set_pending);
> +
> +void
> +ct_zone_ctx_init(struct ct_zone_ctx *ctx)
> +{
> +shash_init(>pending);
> +shash_init(>current);
> +}
> +
> +void
> +ct_zone_ctx_destroy(struct ct_zone_ctx *ctx)
> +{
> +shash_destroy_free_data(>current);
> +shash_destroy_free_data(>pending);
> +}
>
>  void
>  ct_zones_restore(struct ct_zone_ctx *ctx,
> @@ -47,7 +63,8 @@ ct_zones_restore(struct ct_zone_ctx *ctx,
>  struct ct_zone_pending_entry *ctpe = pending_node->data;
>
>  if (ctpe->add) {
> -ct_zone_restore(dp_table, ctx, pending_node->name, ctpe->zone);
> +ct_zone_restore(dp_table, ctx, pending_node->name,
> +ctpe->ct_zone.zone);
>  }
>  }
>
> @@ -91,7 +108,6 @@ void
>  ct_zones_update(const struct sset *local_lports,
>  const struct hmap *local_datapaths, struct ct_zone_ctx *ctx)
>  {
> -struct simap_node *ct_zone;
>  int scan_start = 1;
>  const char *user;
>  struct sset all_users = SSET_INITIALIZER(_users);
> @@ -132,12 +148,14 @@ ct_zones_update(const struct sset *local_lports,
>  }
>
>  /* Delete zones that do not exist in above sset. */
> -SIMAP_FOR_EACH_SAFE (ct_zone, >current) {
> -if (!sset_contains(_users, ct_zone->name)) {
> -ct_zone_remove(ctx, ct_zone);
> -} else if (!simap_find(_snat_zones, ct_zone->name)) {
> -bitmap_set1(unreq_snat_zones_map, ct_zone->data);
> -simap_put(_snat_zones, ct_zone->name, ct_zone->data);
> +struct shash_node *node;
> +SHASH_FOR_EACH_SAFE (node, >current) {
> +struct ct_zone *ct_zone = node->data;
> +if (!sset_contains(_users, node->name)) {
> +ct_zone_remove(ctx, node->name);
> +} else if (!simap_find(_snat_zones, node->name)) {
> +bitmap_set1(unreq_snat_zones_map, ct_zone->zone);
> +simap_put(_snat_zones, node->name, ct_zone->zone);
>  }
>  }
>
> @@ -152,7 +170,7 @@ ct_zones_update(const struct sset *local_lports,
>  struct simap_node *unreq_node;
>  SIMAP_FOR_EACH_SAFE (unreq_node, _snat_zones) {
>  if (unreq_node->data == snat_req_node->data) {
> -simap_find_and_delet

Re: [ovs-dev] [PATCH ovn v3 7/7] controller: Introduce route-exchange module.

[Numan Siddique]

On Thu, Jul 25, 2024 at 10:05 AM Frode Nordahl  wrote:
>
> Introduce route-exchange module that depending on Logical Router
> Port options maintains a VRF in the system for redistribution of
> host routes to NAT addresses and LB VIPs attached to local gateway
> router datapaths.
>
> The route-exchange module requires input from both runtime_data
> and lb_data engine nodes.  Consequently it needs its own I-P
> engine node.
>
> TODO:
> * E2E test together with the bgp-mirror patch.
> * E2E docs and NEWS items.
>
> Signed-off-by: Frode Nordahl 

Hi Frode,

Thanks for the patch series and adding this feature.  Not a full review.

I've a few comments related to I-P handling. Please see below.

Can you please include a cover letter for this patch series.
Your RFC patch series had a lot of details, maybe you can include
those details in the cover letter ?



> ---
>  controller/automake.mk   |   9 +-
>  controller/ovn-controller.c  | 193 
>  controller/route-exchange-stub.c |  44 
>  controller/route-exchange.c  | 274 ++
>  controller/route-exchange.h  |  45 
>  tests/system-ovn.at  | 382 +++
>  6 files changed, 945 insertions(+), 2 deletions(-)
>  create mode 100644 controller/route-exchange-stub.c
>  create mode 100644 controller/route-exchange.c
>  create mode 100644 controller/route-exchange.h
>
> diff --git a/controller/automake.mk b/controller/automake.mk
> index 006e884dc..3e91e97e6 100644
> --- a/controller/automake.mk
> +++ b/controller/automake.mk
> @@ -49,13 +49,18 @@ controller_ovn_controller_SOURCES = \
> controller/statctrl.h \
> controller/statctrl.c \
> controller/ct-zone.h \
> -   controller/ct-zone.c
> +   controller/ct-zone.c \
> +   controller/route-exchange.h
>
>  if HAVE_NETLINK
>  controller_ovn_controller_SOURCES += \
> controller/route-exchange-netlink.h \
> controller/route-exchange-netlink-private.h \
> -   controller/route-exchange-netlink.c
> +   controller/route-exchange-netlink.c \
> +   controller/route-exchange.c
> +else
> +controller_ovn_controller_SOURCES += \
> +   controller/route-exchange-stub.c
>  endif
>
>  controller_ovn_controller_LDADD = lib/libovn.la 
> $(OVS_LIBDIR)/libopenvswitch.la
> diff --git a/controller/ovn-controller.c b/controller/ovn-controller.c
> index 805d29c81..7bc90da31 100644
> --- a/controller/ovn-controller.c
> +++ b/controller/ovn-controller.c
> @@ -87,6 +87,7 @@
>  #include "statctrl.h"
>  #include "lib/dns-resolve.h"
>  #include "ct-zone.h"
> +#include "route-exchange.h"
>
>  VLOG_DEFINE_THIS_MODULE(main);
>
> @@ -4576,6 +4577,14 @@ controller_output_mac_cache_handler(struct engine_node 
> *node,
>  return true;
>  }
>
> +static bool
> +controller_output_route_exchange_handler(struct engine_node *node,
> + void *data OVS_UNUSED)
> +{
> +engine_set_node_state(node, EN_UPDATED);
> +return true;
> +}
> +
>  /* Handles sbrec_chassis changes.
>   * If a new chassis is added or removed return false, so that
>   * flows are recomputed.  For any updates, there is no need for
> @@ -4599,6 +4608,174 @@ pflow_lflow_output_sb_chassis_handler(struct 
> engine_node *node,
>  return true;
>  }
>
> +struct ed_type_route_exchange {
> +/* Contains struct tracked_datapath entries for local datapaths subject 
> to
> + * route exchange. */
> +struct hmap tracked_re_datapaths;
> +};
> +
> +static void
> +en_route_exchange_run(struct engine_node *node, void *data)
> +{
> +struct ed_type_route_exchange *re_data = data;
> +const struct ovsrec_open_vswitch_table *ovs_table =
> +EN_OVSDB_GET(engine_get_input("OVS_open_vswitch", node));
> +const char *chassis_id = get_ovs_chassis_id(ovs_table);
> +ovs_assert(chassis_id);
> +
> +struct ovsdb_idl_index *sbrec_chassis_by_name =
> +engine_ovsdb_node_get_index(
> +engine_get_input("SB_chassis", node),
> +"name");
> +const struct sbrec_chassis *chassis
> += chassis_lookup_by_name(sbrec_chassis_by_name, chassis_id);
> +ovs_assert(chassis);
> +
> +struct ovsdb_idl_index *sbrec_port_binding_by_name =
> +engine_ovsdb_node_get_index(
> +engine_get_input("SB_port_binding", node),
> +"name");
> +struct ed_type_runtime_data *rt_data =
> +engine_get_input_data("runtime_data", node);
> +
> +const struct sbrec_load_balancer_table *lb_table =
> +EN_OVSDB_GET(engine_get_input("SB_load_balancer", node));
> +struct ed_type_lb_data *lb_data =
> +engine_get_input_data("lb_data", node);
> +
> +struct route_exchange_ctx_in r_ctx_in = {
> +.sbrec_port_binding_by_name = sbrec_port_binding_by_name,
> +.lb_table = lb_table,
> +.chassis_rec = chassis,
> +.active_tunnels = _data->active_tunnels,
> +.local_datapaths = 

Re: [ovs-dev] [PATCH ovn v1] Add support for centralize routing for distributed gw ports.

[Numan Siddique]

On Tue, Jul 9, 2024 at 7:25 PM  wrote:
>
> From: Numan Siddique 
>
> Consider a deployment with the below logical resources:
>
> 1. A bridged logical switch 'public' with a port - P1 and a localnet
>port ln-public.
> 2. A logical router 'R'
> 3. Logical switch 'public' connected to R via logical switch/router port
>peers (public-R and R-public).
> 4. R-public is distributed gateway port with its network as 172.16.0.0/24
> 5. NATs (dnat_and_snat) configured in 'R'.
> 6. And a few overlay logical switches S1, S2 to R.
>
> Any traffic from logical port - P1 of public logical switch destined to
> S1 or S2's logical ports goes out of the source chassis
> (where P1 resides) via the localnet port and reaches the gateway chassis
> which handles the routing.
>
> There are couple of traffic flow scenarios which doesn't work if the
> logical switch 'public' doesn't have a localnet port.
>
> 1. Traffic from port - P1 destined to logical switches S1 or S2 gets
>dropped in the source chassis.  The packet enters the router R's
>pipeline, but it gets dropped in the 'lr_in_admission' stage since
>the logical flow to allow traffic destined to the distributed gateway
>port MAC is installed only on the gateway chassis.
>
> 2. NAT doesn't work as expected.
>
> In order to suppose this use case (of a logical switch not having a
> localnet port, but has a distributed gateway port and NATs), this patch
> supports the option 'centralize_routing', which can be configured on
> the distributed gateway port (R-public in the example above).
> If this option is set, then routing is centralized on the gateway
> chassis for the traffic destined to the R-public's networks
> (172.16.0.0/24 for the above example).  Traffic from P1 will be
> tunnelled to the gateway chassis.
>
> ovn-northd creates a chassisresident port (cr-public-R) for the
> logical switch port - public-R, along with cr-R-public inorder to
> centralize the traffic.
>
> This feature gets enabled for the distributed gateway port R-public if
>   - The above option is set to true in the R-public's options column.
>   - The logical switch 'public' doesn't have any localnet ports.
>   - And R-public is the only distributed gateway port of R.
>
> Distributed NAT (i.e if external_mac and router_port is set) is
> not supported and instead the router port mac is used for such traffic
> and centralized on the gateway chassis.
>
> Reported-at: https://issues.redhat.com/browse/FDP-364
> Signed-off-by: Numan Siddique 
> ---
>  NEWS  |   2 +
>  controller/physical.c |   4 +
>  northd/northd.c   | 257 +++
>  northd/northd.h   |   1 +
>  ovn-nb.xml|  34 +++
>  tests/multinode-macros.at |   2 +-
>  tests/multinode.at| 177 +
>  tests/ovn-northd.at   | 516 +-
>  tests/ovn.at  |   8 +-
>  9 files changed, 951 insertions(+), 50 deletions(-)
>
> diff --git a/NEWS b/NEWS
> index 3e392ff08b..472445a188 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -38,6 +38,8 @@ Post v24.03.0
>  ability to disable "VXLAN mode" to extend available tunnel IDs space for
>  datapaths from 4095 to 16711680.  For more details see man ovn-nb(5) for
>  mentioned option.
> +  - Added Overlay provider network support to a logical switch if
> +the config "overlay_provider_network" is set to true.

Please ignore this modification to NEWS.  It's wrong.  I'll fix it in
the next version.

Numan

>
>  OVN v24.03.0 - 01 Mar 2024
>  --
> diff --git a/controller/physical.c b/controller/physical.c
> index 22756810fd..e3a316989a 100644
> --- a/controller/physical.c
> +++ b/controller/physical.c
> @@ -1608,6 +1608,10 @@ consider_port_binding(struct ovsdb_idl_index 
> *sbrec_port_binding_by_name,
>  ct_zones);
>  put_zones_ofpacts(_ids, ofpacts_p);
>
> +/* Clear the MFF_INPORT.  Its possible that the same packet may
> + * go out from the same tunnel inport. */
> +put_load(ofp_to_u16(OFPP_NONE), MFF_IN_PORT, 0, 16, ofpacts_p);
> +
>  /* Resubmit to table 41. */
>  put_resubmit(OFTABLE_CHECK_LOOPBACK, ofpacts_p);
>  }
> diff --git a/northd/northd.c b/northd/northd.c
> index 6898daa00d..9b52d5a3c0 100644
> --- a/northd/northd.c
> +++ b/northd/northd.c
> @@ -2099,6 +2099,55 @@ parse_lsp_addrs(struct ovn_port *op)
>  }
>  }
>
> +static struct ovn_port *
> +create_cr_port(struct ovn_port *op, struct hmap *ports,
> +   struct ovs_list *both_dbs, struct ovs_list *nb_o

Re: [ovs-dev] [PATCH ovn v5 2/2] Controller, northd: Add support for CT zone limits.

[Numan Siddique]

On Wed, Jul 24, 2024 at 2:37 PM Mark Michelson  wrote:
>
> Thanks Ales.
>
> Acked-by: Mark Michelson 
>
> I have some nits regarding the documentation below. I think these can be
> corrected when committing.
>
> On 7/12/24 10:30, Ales Musil wrote:
> > Add support for limiting the CT zone usage per Ls, LR or LSP.
> > When the limit is configured on logical switch it will also implicitly
> > set limits for all ports in that logical switch. The port configuration
> > can be overwritten individually and has priority over the whole logical
> > switch configuration.
> >
> > The value 0 means unlimited, when the value is not specified it is
> > derived from OvS default CT limit specified for given OvS datapath.
> >
> > Reported-at: https://bugzilla.redhat.com/2189924
> > Signed-off-by: Ales Musil 

Hi Ales,

I've a few comments.  Please see below.


> > ---
> > v5: Rebase on top of latest main.
> >  Avoid OvS CT zone lookup in every loop of pending commit.
> > v4: Rebase on top of latest main.
> >  Change naming of the ct_zone_limit_sync to avoid potential confusion 
> > as suggested by Lorenzo.
> > v3: Rebase on top of latest main.
> > ---
> >   NEWS|   3 +
> >   controller/ct-zone.c| 176 
> >   controller/ct-zone.h|  14 ++-
> >   controller/ovn-controller.c |  27 +-
> >   lib/ovn-util.c  |  17 
> >   lib/ovn-util.h  |   3 +
> >   northd/northd.c |   8 ++
> >   ovn-nb.xml  |  29 ++
> >   tests/ovn-controller.at |  99 
> >   9 files changed, 350 insertions(+), 26 deletions(-)
> >
> > diff --git a/NEWS b/NEWS
> > index 3e392ff08..8e725684e 100644
> > --- a/NEWS
> > +++ b/NEWS
> > @@ -38,6 +38,9 @@ Post v24.03.0
> >   ability to disable "VXLAN mode" to extend available tunnel IDs space 
> > for
> >   datapaths from 4095 to 16711680.  For more details see man ovn-nb(5) 
> > for
> >   mentioned option.
> > +  - Add support for CT zone limit that can be specified per LR
> > +(options:ct-zone-limit), LS (other_config:ct-zone-limit) or LSP
> > +(options:ct-zone-limit).
> >
> >   OVN v24.03.0 - 01 Mar 2024
> >   --
> > diff --git a/controller/ct-zone.c b/controller/ct-zone.c
> > index ab0eec9d0..edee893c8 100644
> > --- a/controller/ct-zone.c
> > +++ b/controller/ct-zone.c
> > @@ -34,6 +34,16 @@ static bool ct_zone_assign_unused(struct ct_zone_ctx 
> > *ctx,
> >   static bool ct_zone_remove(struct ct_zone_ctx *ctx, const char *name);
> >   static void ct_zone_add(struct ct_zone_ctx *ctx, const char *name,
> >   uint16_t zone, bool set_pending);
> > +static void
> > +ct_zone_limits_update_per_dp(struct ct_zone_ctx *ctx,
> > + const struct sbrec_datapath_binding *dp,
> > + const char *name,
> > + struct ovsdb_idl_index *pb_by_dp);
> > +static void ct_zone_limit_update(struct ct_zone_ctx *ctx, const char *name,
> > + int64_t limit);
> > +static int64_t ct_zone_get_dp_limit(const struct sbrec_datapath_binding 
> > *dp);
> > +static int64_t ct_zone_get_pb_limit(const struct sbrec_port_binding *pb);
> > +static int64_t ct_zone_limit_normalize(int64_t limit);
> >
> >   void
> >   ct_zone_ctx_init(struct ct_zone_ctx *ctx)
> > @@ -210,11 +220,24 @@ ct_zones_update(const struct sset *local_lports,
> >
> >   void
> >   ct_zones_commit(const struct ovsrec_bridge *br_int,
> > -struct shash *pending_ct_zones)
> > +const struct ovsrec_datapath *ovs_dp,
> > +struct ovsdb_idl_txn *ovs_idl_txn,
> > +struct ct_zone_ctx *ctx)
> >   {
> > +if (shash_is_empty(>pending)) {
> > +return;
> > +}
> > +
> > +struct ovsrec_ct_zone **all_zones =
> > +xzalloc(sizeof *all_zones * (MAX_CT_ZONES + 1));
> > +for (size_t i = 0; i < ovs_dp->n_ct_zones; i++) {
> > +all_zones[ovs_dp->key_ct_zones[i]] = ovs_dp->value_ct_zones[i];
> > +}
> > +
> >   struct shash_node *iter;
> > -SHASH_FOR_EACH (iter, pending_ct_zones) {
> > +SHASH_FOR_EACH (iter, >pending) {
> >   struct ct_zone_pending_entry *ctzpe = iter->data;
> > +struct ct_zone *ct_zone = >ct_zone;
> >
> >   /* The transaction is open, so any pending entries in the
> >* CT_ZONE_DB_QUEUED must be sent and any in CT_ZONE_DB_QUEUED
> > @@ -226,7 +249,7 @@ ct_zones_commit(const struct ovsrec_bridge *br_int,
> >
> >   char *user_str = xasprintf("ct-zone-%s", iter->name);
> >   if (ctzpe->add) {
> > -char *zone_str = xasprintf("%"PRIu16, ctzpe->ct_zone.zone);
> > +char *zone_str = xasprintf("%"PRIu16, ct_zone->zone);
> >   struct smap_node *node =
> >   smap_get_node(_int->external_ids, user_str);
> >   if (!node || 

Re: [ovs-dev] [PATCH ovn v2] provider networks: Provide the option to tunnel traffic.

[Numan Siddique]

On Wed, Jul 24, 2024 at 12:35 PM Mark Michelson  wrote:
>
> Thanks for the update Numan.
>
> Acked-by: Mark Michelson 

Thank you.  I had missed adding a NEWS entry.  I added that and
applied this patch to
the main branch.

Numan

>
> On 7/24/24 12:01, num...@ovn.org wrote:
> > From: Numan Siddique 
> >
> > This patch adds a global config option - 'always_tunnel' and
> > when set to true, any traffic destined to a VIF logical port of a
> > provider logical switch (having localnet port(s)), is tunnelled to
> > the destination chassis, instead of sending it out via the localnet
> > port.  This feature is useful for the following reasons:
> >
> > 1.  CMS can add both provider logical switches and overlay logical
> >  swithes to a logical router.  With this option set, E-W routing between
> >  these logical switches will be tunnelled all the time.  The router port
> >  mac addresses are not leaked from multiple chassis to the upstream
> >  switches anymore.
> >
> > 2.  NATting will work as expected either in the gateway chassis or on
> >  the source VIF chassis (if external_mac and logical_port set).
> >
> > 3.  With this option set, there is no need to centralize routing
> >  for provider logical switches ('reside-on-redirect-chassis').
> >
> > 4.  With the commits [1] now merged, MTU issues arising due to tunnel
> >  overhead will be handled gracefully.
> >
> > [1] - 3faadc76ad71 ("northd: Fix pmtud for non routed traffic.")
> >221476a01f26 ("ovn: Add tunnel PMTUD support.")
> >
> > Reported-at: https://issues.redhat.com/browse/FDP-209
> > Signed-off-by: Numan Siddique 
> > ---
> >
> > v1 -> v2
> > ---
> > * Changed the config option from 'provider_network_overlay' to
> >   'always_tunnel' as suggested by Mark.
> > * Rebased.
> >
> >
> >   controller/ovn-controller.c |  27 +++
> >   controller/physical.c   |  10 +-
> >   controller/physical.h   |   1 +
> >   northd/en-global-config.c   |   5 +
> >   ovn-nb.xml  |  16 ++
> >   tests/multinode-macros.at   |  19 ++
> >   tests/multinode.at  | 358 
> >   tests/ovn.at| 157 
> >   8 files changed, 592 insertions(+), 1 deletion(-)
> >
> > diff --git a/controller/ovn-controller.c b/controller/ovn-controller.c
> > index b3a265230c..4e30302ea6 100644
> > --- a/controller/ovn-controller.c
> > +++ b/controller/ovn-controller.c
> > @@ -3349,6 +3349,11 @@ non_vif_data_ovs_iface_handler(struct engine_node 
> > *node, void *data OVS_UNUSED)
> >
> >   struct ed_type_northd_options {
> >   bool explicit_arp_ns_output;
> > +bool always_tunnel; /* Indicates if the traffic to the
> > + * logical port of a bridged logical
> > + * switch (i.e with localnet port) should
> > + * be tunnelled or sent via the localnet
> > + * port.  Default value is 'false'. */
> >   };
> >
> >
> > @@ -3380,6 +3385,12 @@ en_northd_options_run(struct engine_node *node, void 
> > *data)
> >   false)
> >   : false;
> >
> > +n_opts->always_tunnel =
> > +sb_global
> > +? smap_get_bool(_global->options, "always_tunnel",
> > +false)
> > +: false;
> > +
> >   engine_set_node_state(node, EN_UPDATED);
> >   }
> >
> > @@ -3403,6 +3414,17 @@ en_northd_options_sb_sb_global_handler(struct 
> > engine_node *node, void *data)
> >   engine_set_node_state(node, EN_UPDATED);
> >   }
> >
> > +bool always_tunnel =
> > +sb_global
> > +? smap_get_bool(_global->options, "always_tunnel",
> > +false)
> > +: false;
> > +
> > +if (always_tunnel != n_opts->always_tunnel) {
> > +n_opts->always_tunnel = always_tunnel;
> > +engine_set_node_state(node, EN_UPDATED);
> > +}
> > +
> >   return true;
> >   }
> >
> > @@ -4315,6 +4337,9 @@ static void init_physical_ctx(struct engine_node 
> > *node,
> >   engine_get_input_data("ct_zones", node);
> >   struct simap *ct_zones = _zones_data->ctx.current;
> >
> > +struct ed_type_northd_options *n_opts =
&

Re: [ovs-dev] [Patch ovn v6] Text respresntations for drop sampling.

[Numan Siddique]

On Wed, Jul 24, 2024 at 1:34 AM Ales Musil  wrote:
>
> On Tue, Jul 23, 2024 at 6:42 PM Numan Siddique  wrote:
>
> > On Tue, Jul 16, 2024 at 9:45 AM Jacob Tanenbaum 
> > wrote:
> > >
> > > Created a new column in the southbound database to hardcode a human
> > readable
> > > description for flows. This first use is describing why the flow is
> > dropping packets.
> > > The new column is called flow_desc and will create southbound database
> > entries like this
> > >
> > > _uuid   : 20f1897b-477e-47ae-a32c-c546d83ec097
> > > actions :
> > "sample(probability=65535,collector_set=123,obs_domain=1,obs_point=$cookie);
> > /* drop */"
> > > controller_meter: []
> > > external_ids: {source="northd.c:8721",
> > stage-name=ls_in_l2_unknown}
> > > flow_desc   : "No L2 destination"
> > > logical_datapath: []
> > > logical_dp_group: ee3c3db5-98a2-4f34-8a84-409deae140a7
> > > match   : "outport == \"none\""
> > > pipeline: ingress
> > > priority: 50
> > > table_id: 27
> > > tags: {}
> > > hash: 0
> > >
> > > future work includes entering more flow_desc for more flows and adding
> > > flow_desc to the actions as a comment.
> > >
> > > Signed-off-by: Jacob Tanenbaum 
> > > Suggested-by: Dumitru Ceara 
> > > Reported-at: https://issues.redhat.com/browse/FDP-307
> > >
> >
> > Hi Jacob,
> >
> > Thanks for the patch.
> >
> > I've a question.  Do you have a specific reason to add a string wrapper ?
> > Looks to me, you can use "const char *flow_desc" in the "struct
> > ovn_lflow".  Is it because in the future, to add
> > dynamic strings ?
> >
>
>
> It was suggested by Adrian that we should be able to accept both dynamic
> and static
> strings. The version 4 AFAIR was using just const char *.

I see.  @Ales - Would you mind taking a look at v6 and provide your
Ack if it LGTY ?

Thanks
Numan

>
>
> > I'd suggest just use "const char *" for now and use "struct ds" in the
> > future patches if we need to add memory allocated
> > strings ?  What do you think ?
> >
> > Otherwise the patch LGTM.
> >
> > Thanks
> > Numan
> >
> > > ---
> > >
> > > v1: initial version
> > > v2: correct commit message
> > > make the flow_desc a char*
> > > correct a typo in the ovn-sb.xml
> > > correct the test
> > > v3: rebase issue with NEWS file
> > > v4: remove options:debug_drop_domain_id="1" from testing as we
> > > do not depend on it
> > > v5: introduce string wrapper
> > > increment ovs-sb.ovsschema version
> > > correct the testing
> > > added descriptions to more dropped packets
> > > v6: v5 was not the correct branch, this is...
> > > added descriptions to more dropped packets
> > > changed the names of the macros to be more descriptive
> > > ---
> > >  NEWS|  2 ++
> > >  lib/ovn-util.h  | 26 +++
> > >  northd/lflow-mgr.c  | 25 +++
> > >  northd/lflow-mgr.h  | 27 +++-
> > >  northd/northd.c | 50 -
> > >  ovn-sb.ovsschema|  8 +---
> > >  ovn-sb.xml  |  5 +
> > >  tests/ovn-northd.at | 15 ++
> > >  8 files changed, 119 insertions(+), 39 deletions(-)
> > >
> > > diff --git a/NEWS b/NEWS
> > > index 3e392ff08..0039b04be 100644
> > > --- a/NEWS
> > > +++ b/NEWS
> > > @@ -38,6 +38,8 @@ Post v24.03.0
> > >  ability to disable "VXLAN mode" to extend available tunnel IDs
> > space for
> > >  datapaths from 4095 to 16711680.  For more details see man
> > ovn-nb(5) for
> > >  mentioned option.
> > > +  - Added a new column in the southbound database "flow_desc" to provide
> > > +human readable context to flows.
> > >
> > >  OVN v24.03.0 - 01 Mar 2024
> > >  --
> > > diff --git a/lib/ovn-util.h b/lib/ovn-util.h
> > > index f75b821b6..2da5cd086 100644
> > > --- a/lib/ovn-util.h
> > > +++ b/lib/ovn-util.h
> > > @@ -466,6 +466,32 @@ void 

Re: [ovs-dev] [PATCH ovn v1] provider networks: Provide the option to tunnel traffic.

[Numan Siddique]

On Tue, Jul 23, 2024 at 4:08 PM Numan Siddique  wrote:
>
> On Tue, Jul 23, 2024 at 2:16 PM Mark Michelson  wrote:
> >
> > Hi Numan,
> >
> > The code change itself is pretty simple, and the new tests are fantastic.
> >
> > Before giving this an ack, I have a couple of questions:
> >
> > 1) Is the name "provider_network_overlay" something that is going to be
> > inherently understood? The documentation makes it clear what it does,
> > but the name seems odd to me, as someone who is not an OpenStack admin.
> > Something as simple as "always_tunnel" would give a clearer indication
> > of what the option does, IMO.
>
> Thanks for the reviews.  I struggled to come up with a good name.
> "always_tunnel"
> sounds good to me.  I'll submit v2.
> >
> > 2) Can you see a situation where this behavior would be desired on one
> > logical switch but not another? I ask because it seems possible to
> > enable the option per logical switch instead of globally.
>
> I thought about it.  Let's say S1 and S2 logical switches (both with
> localnet ports) are connected to a
> logical router and S1 has this option set.  In this case, traffic from
> S1 to S2 will be sent out of the
> localnet port of S2 and the reply traffic from S2 to S1 will be
> tunnelled.   This is undesirable.
> But we can argue that it's the responsibility of CMS to configure
> properly to ensure proper symmetry.
>  Also SB datapath table doesn't have "options" or "other_config" column
> where we can store per datapath option.  NB Logical_Switch has
> "other_config" column.
> I'd prefer global option for now.What do you think ?
>

Submitted v2 changing the config option to 'always_tunnel' -
https://patchwork.ozlabs.org/project/ovn/patch/20240724160130.551695-1-num...@ovn.org/

Request to take a look.

Numan

> Thanks
> Numan
>
>
> >
> > Thanks,
> > Mark Michelson
> >
> > On 5/31/24 12:15, num...@ovn.org wrote:
> > > From: Numan Siddique 
> > >
> > > This patch adds a global config option - 'provider_network_overlay' and
> > > when set to true, any traffic destined to a VIF logical port of a
> > > provider logical switch (having localnet port(s)), is tunnelled to
> > > the destination chassis, instead of sending it out via the localnet
> > > port.  This feature is useful for the following reasons:
> > >
> > > 1.  CMS can add both provider logical switches and overlay logical
> > >  swithes to a logical router.  With this option set, E-W routing 
> > > between
> > >  these logical switches will be tunnelled all the time.  The router 
> > > port
> > >  mac addresses are not leaked from multiple chassis to the upstream
> > >  switches anymore.
> > >
> > > 2.  NATting will work as expected either in the gateway chassis or on
> > >  the source VIF chassis (if external_mac and logical_port set).
> > >
> > > 3.  With this option set, there is no need to centralize routing
> > >  for provider logical switches ('reside-on-redirect-chassis').
> > >
> > > 4.  With the commits [1] now merged, MTU issues arising due to tunnel
> > >  overhead will be handled gracefully.
> > >
> > > [1] - 3faadc76ad71 ("northd: Fix pmtud for non routed traffic.")
> > >221476a01f26 ("ovn: Add tunnel PMTUD support.")
> > >
> > > Reported-at: https://issues.redhat.com/browse/FDP-209
> > > Signed-off-by: Numan Siddique 
> > > ---
> > >   controller/ovn-controller.c |  27 +++
> > >   controller/physical.c   |  10 +-
> > >   controller/physical.h   |   1 +
> > >   northd/en-global-config.c   |   5 +
> > >   ovn-nb.xml  |  16 ++
> > >   tests/multinode-macros.at   |  19 ++
> > >   tests/multinode.at  | 358 
> > >   tests/ovn.at| 156 
> > >   8 files changed, 591 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/controller/ovn-controller.c b/controller/ovn-controller.c
> > > index 6b38f113dc..a1954d7870 100644
> > > --- a/controller/ovn-controller.c
> > > +++ b/controller/ovn-controller.c
> > > @@ -3719,6 +3719,11 @@ non_vif_data_ovs_iface_handler(struct engine_node 
> > > *node, void *data OVS_UNUSED)
> > >   struct ed_type_northd_options {
> > >   bool lb_hairpin_use_ct_mark;
> > >   bool explicit_arp_ns_output;
> > >

Re: [ovs-dev] [PATCH ovn v3 5/8] northd: Commit from-lport ACL label (and state) when LBs are used.

[Numan Siddique]

On Tue, Jul 23, 2024 at 3:05 PM Mark Michelson  wrote:
>
> Hi Dumitru,
>
> The only complaint I have about this patch is that the comments above
> build_lb_affinity_ls_flows() need to be updated since they show that
> REGBIT_CONNTRACK_COMMIT gets reset to 0 as part of their actions. That
> is pretty trivial and can be fixed when committing.
>

+!
> Acked-by: Mark Michelson 


Oops.  I gave an Ack to v2 of this patch, although I had reviewed v3.

Acked-by: Numan Siddique 

Numan

>
> On 7/12/24 11:14, Dumitru Ceara wrote:
> > Quoting the ACL label section in the ovn.nb.5 man page:
> >
> >Associates an identifier with the ACL.
> >The same value will be written to corresponding connection
> >tracker entry. The value should be a valid 32-bit unsigned integer.
> >This value can help in debugging from connection tracker side.
> >For example, through this "label" we can backtrack to the ACL rule
> >which is causing a "leaked" connection. Connection tracker entries are
> >created only for allowed connections so the label is valid only
> >for allow and allow-related actions.
> >
> > The above states that the ACL label must always be stored in the
> > connection tracker entry label for allow-related ACLs (regardless of the
> > direction of the ACL).  However, since 74d82e296f80 ("northd: Support
> > the option to apply from-lport ACLs after load balancer."), the
> > connection is not re-committed in the ls_in_stateful stage (because it
> > already was committed as part of the load balancer DNAT).
> >
> > Moreover, by not re-committing the connection after LB we also risk not
> > re-setting any potential ct_mark.blocked value the connection might
> > have.
> >
> > This patch addresses the issue by always committing packets matched by
> > allow-related (or stateful in general) ACLs even if they were also
> > committed as part of the load balancing stage.
> >
> > There's potentially a slight overhead when doing this (an additional
> > commit call into conntrack but _no_ recirculation).  This is however
> > acceptable as it is required for a correct packet processing pipeline
> > implementation.  Even without this fix, packets creating new
> > connections that hit "--apply-after-lb" ACLs trigger a re-commit (for
> > storing the label and ct_mark.blocked).
> >
> > A new test is added to ensure we don't break this functionality in the
> > future.
> >
> > CC: Numan Siddique 
> > Fixes: 74d82e296f80 ("northd: Support the option to apply from-lport ACLs 
> > after load balancer.")
> > Signed-off-by: Dumitru Ceara 
> > ---
> >   northd/northd.c |   8 +---
> >   tests/ovn-northd.at | 110 +++-
> >   tests/ovn.at|   4 +-
> >   3 files changed, 82 insertions(+), 40 deletions(-)
> >
> > diff --git a/northd/northd.c b/northd/northd.c
> > index fcf8f277ac..901b9e9cd1 100644
> > --- a/northd/northd.c
> > +++ b/northd/northd.c
> > @@ -7494,8 +7494,7 @@ build_lb_affinity_ls_flows(struct lflow_table *lflows,
> >   ipv6 ? REG_LB_L2_AFF_BACKEND_IP6 : REG_LB_AFF_BACKEND_IP4;
> >
> >   /* Prepare common part of affinity LB and affinity learn action. */
> > -ds_put_format(_action, REGBIT_CONNTRACK_COMMIT" = 0; %s = %s; ",
> > -  reg_vip, lb_vip->vip_str);
> > +ds_put_format(_action, "%s = %s; ", reg_vip, lb_vip->vip_str);
> >   ds_put_cstr(_action_learn, "commit_lb_aff(vip = \"");
> >
> >   if (lb_vip->port_str) {
> > @@ -7635,11 +7634,6 @@ build_lb_rules(struct lflow_table *lflows, struct 
> > ovn_lb_datapaths *lb_dps,
> >   ds_clear(action);
> >   ds_clear(match);
> >
> > -/* Make sure that we clear the REGBIT_CONNTRACK_COMMIT flag.  
> > Otherwise
> > - * the load balanced packet will be committed again in
> > - * S_SWITCH_IN_STATEFUL. */
> > -ds_put_format(action, REGBIT_CONNTRACK_COMMIT" = 0; ");
> > -
> >   /* New connections in Ingress table. */
> >   const char *meter = NULL;
> >   bool reject = build_lb_vip_actions(lb, lb_vip, lb_vip_nb, action,
> > diff --git a/tests/ovn-northd.at b/tests/ovn-northd.at
> > index 6802fac380..5acb13c519 100644
> > --- a/tests/ovn-northd.at
> > +++ b/tests/ovn-northd.at
> > @@ -1413,7 +1413,7 @@ check ovn-nbctl --wait=sb ls-lb-add sw0 lb1
> >   AT_CAPTURE_FILE([sbflows])
> >   OVS_WAIT_FOR_OUT

Re: [ovs-dev] [PATCH ovn v1] provider networks: Provide the option to tunnel traffic.

[Numan Siddique]

On Tue, Jul 23, 2024 at 2:16 PM Mark Michelson  wrote:
>
> Hi Numan,
>
> The code change itself is pretty simple, and the new tests are fantastic.
>
> Before giving this an ack, I have a couple of questions:
>
> 1) Is the name "provider_network_overlay" something that is going to be
> inherently understood? The documentation makes it clear what it does,
> but the name seems odd to me, as someone who is not an OpenStack admin.
> Something as simple as "always_tunnel" would give a clearer indication
> of what the option does, IMO.

Thanks for the reviews.  I struggled to come up with a good name.
"always_tunnel"
sounds good to me.  I'll submit v2.
>
> 2) Can you see a situation where this behavior would be desired on one
> logical switch but not another? I ask because it seems possible to
> enable the option per logical switch instead of globally.

I thought about it.  Let's say S1 and S2 logical switches (both with
localnet ports) are connected to a
logical router and S1 has this option set.  In this case, traffic from
S1 to S2 will be sent out of the
localnet port of S2 and the reply traffic from S2 to S1 will be
tunnelled.   This is undesirable.
But we can argue that it's the responsibility of CMS to configure
properly to ensure proper symmetry.
 Also SB datapath table doesn't have "options" or "other_config" column
where we can store per datapath option.  NB Logical_Switch has
"other_config" column.
I'd prefer global option for now.What do you think ?

Thanks
Numan


>
> Thanks,
> Mark Michelson
>
> On 5/31/24 12:15, num...@ovn.org wrote:
> > From: Numan Siddique 
> >
> > This patch adds a global config option - 'provider_network_overlay' and
> > when set to true, any traffic destined to a VIF logical port of a
> > provider logical switch (having localnet port(s)), is tunnelled to
> > the destination chassis, instead of sending it out via the localnet
> > port.  This feature is useful for the following reasons:
> >
> > 1.  CMS can add both provider logical switches and overlay logical
> >  swithes to a logical router.  With this option set, E-W routing between
> >  these logical switches will be tunnelled all the time.  The router port
> >  mac addresses are not leaked from multiple chassis to the upstream
> >  switches anymore.
> >
> > 2.  NATting will work as expected either in the gateway chassis or on
> >  the source VIF chassis (if external_mac and logical_port set).
> >
> > 3.  With this option set, there is no need to centralize routing
> >  for provider logical switches ('reside-on-redirect-chassis').
> >
> > 4.  With the commits [1] now merged, MTU issues arising due to tunnel
> >  overhead will be handled gracefully.
> >
> > [1] - 3faadc76ad71 ("northd: Fix pmtud for non routed traffic.")
> >221476a01f26 ("ovn: Add tunnel PMTUD support.")
> >
> > Reported-at: https://issues.redhat.com/browse/FDP-209
> > Signed-off-by: Numan Siddique 
> > ---
> >   controller/ovn-controller.c |  27 +++
> >   controller/physical.c   |  10 +-
> >   controller/physical.h   |   1 +
> >   northd/en-global-config.c   |   5 +
> >   ovn-nb.xml  |  16 ++
> >   tests/multinode-macros.at   |  19 ++
> >   tests/multinode.at  | 358 
> >   tests/ovn.at| 156 
> >   8 files changed, 591 insertions(+), 1 deletion(-)
> >
> > diff --git a/controller/ovn-controller.c b/controller/ovn-controller.c
> > index 6b38f113dc..a1954d7870 100644
> > --- a/controller/ovn-controller.c
> > +++ b/controller/ovn-controller.c
> > @@ -3719,6 +3719,11 @@ non_vif_data_ovs_iface_handler(struct engine_node 
> > *node, void *data OVS_UNUSED)
> >   struct ed_type_northd_options {
> >   bool lb_hairpin_use_ct_mark;
> >   bool explicit_arp_ns_output;
> > +bool provider_network_overlay; /* Indicates if the traffic to the
> > +* logical port of a bridged logical
> > +* switch (i.e with localnet port) 
> > should
> > +* be tunnelled or sent via the localnet
> > +* port.  Default value is 'false'. */
> >   };
> >
> >
> > @@ -3756,6 +3761,12 @@ en_northd_options_run(struct engine_node *node, void 
> > *data)
> >   false)
> >   : false;
> >
> > +n_opts->provider_network_overlay =
> > +

Re: [ovs-dev] [PATCH ovn] tests: Add system tests for MAC_Binding.

[Numan Siddique]

On Mon, Jul 15, 2024 at 3:08 PM Naveen Yerramneni
 wrote:
>
> 1. Test to validate traffic that needs ARP resolution
> when SB is disconnected.
> 2. Test to validate MAC binding buffer limit when SB
> is disconnected.
>
> Signed-off-by: Naveen Yerramneni 

Thanks Naveen for adding the system tests.  Looks like the added
system test is failing in the CI -
https://github.com/ovsrobot/ovn/actions/runs/9945348439/job/27473539138

Can you please fix it?

Thanks
Numan

> ---
>  tests/system-ovn.at | 223 
>  1 file changed, 223 insertions(+)
>
> diff --git a/tests/system-ovn.at b/tests/system-ovn.at
> index c24ede7c5..5f8778a97 100644
> --- a/tests/system-ovn.at
> +++ b/tests/system-ovn.at
> @@ -13027,3 +13027,226 @@ OVS_TRAFFIC_VSWITCHD_STOP(["/failed to query port 
> patch-.*/d
>  /connection dropped.*/d"])
>  AT_CLEANUP
>  ])
> +
> +OVN_FOR_EACH_NORTHD([
> +AT_SETUP([SB Disconnect - MAC_Binding])
> +ovn_start
> +OVS_TRAFFIC_VSWITCHD_START()
> +
> +ADD_BR([br-int])
> +ADD_BR([br-ext])
> +
> +SB_PATH="unix:$ovs_base/ovn-sb/ovn-sb.sock"
> +ovs-ofctl add-flow br-ext action=normal
> +# Set external-ids in br-int needed for ovn-controller
> +ovs-vsctl \
> +-- set Open_vSwitch . external-ids:system-id=hv1 \
> +-- set Open_vSwitch . external-ids:ovn-remote=$SB_PATH \
> +-- set Open_vSwitch . external-ids:ovn-encap-type=geneve \
> +-- set Open_vSwitch . external-ids:ovn-encap-ip=169.0.0.1 \
> +-- set bridge br-int fail-mode=secure 
> other-config:disable-in-band=true
> +
> +# Start ovn-controller
> +start_daemon ovn-controller
> +
> +ADD_NAMESPACES(sw01)
> +ADD_VETH(sw01, sw01, br-int, "192.168.1.10/24", "f0:00:00:01:02:03", \
> +"192.168.1.1")
> +ADD_NAMESPACES(server)
> +ADD_VETH(s1, server, br-ext, "172.16.1.1/24", "f0:00:00:01:02:05", \
> + "172.16.1.254")
> +NS_CHECK_EXEC([server], [ip addr add 172.16.1.2 dev s1])
> +check ovn-nbctl lr-add R1
> +
> +check ovn-nbctl ls-add sw0
> +check ovn-nbctl ls-add sw-ext
> +
> +check ovn-nbctl lrp-add R1 rp-sw0 00:00:01:01:02:03 192.168.1.1/24
> +check ovn-nbctl lrp-add R1 rp-ext 00:00:02:01:02:03 172.16.1.254/16
> +
> +check ovn-nbctl lrp-set-gateway-chassis rp-ext hv1
> +
> +check ovn-nbctl lsp-add sw0 sw0-rp -- set Logical_Switch_Port sw0-rp \
> +type=router options:router-port=rp-sw0 \
> +-- lsp-set-addresses sw0-rp router
> +
> +check ovn-nbctl set Logical_Switch sw0 other_config:dhcp_relay_port=sw0-rp
> +
> +check ovn-nbctl lsp-add sw-ext ext-rp -- set Logical_Switch_Port ext-rp \
> +type=router options:router-port=rp-ext \
> +-- lsp-set-addresses ext-rp router
> +check ovn-nbctl lsp-add sw-ext lnet \
> +-- lsp-set-addresses lnet unknown \
> +-- lsp-set-type lnet localnet \
> +-- lsp-set-options lnet network_name=phynet
> +
> +check ovn-nbctl lsp-add sw0 sw01 \
> +-- lsp-set-addresses sw01 "f0:00:00:01:02:03 192.168.1.10"
> +
> +AT_CHECK([ovs-vsctl set Open_vSwitch . 
> external-ids:ovn-bridge-mappings=phynet:br-ext])
> +AT_CHECK([ovs-vsctl set Open_vSwitch . 
> external-ids:ovn-remote-probe-interval=100])
> +
> +OVN_POPULATE_ARP
> +
> +check ovn-nbctl --wait=hv sync
> +
> +AS_BOX([Verify ARP resolution is working when SB is in connected state])
> +
> +AT_CHECK([ovn-appctl connection-status], [0], [dnl
> +connected
> +])
> +
> +NS_CHECK_EXEC([server], [tcpdump -l -nvv -i s1  icmp > pkt.pcap 
> 2>tcpdump_err &])
> +OVS_WAIT_UNTIL([grep "listening" tcpdump_err])
> +on_exit 'kill $(pidof tcpdump)'
> +
> +NS_CHECK_EXEC([sw01], [ping -q -c 2 -i 0.2 -w 2 172.16.1.1 | FORMAT_PING],
> +[0], [dnl
> +2 packets transmitted, 2 received, 0% packet loss, time 0ms
> +])
> +
> +OVS_WAIT_UNTIL([
> +total_pkts=$(cat pkt.pcap | wc -l)
> +test ${total_pkts} -ge 2
> +])
> +
> +AS_BOX([Disconnect SB and test ping that generates new ARP])
> +
> +AT_CHECK([ovs-vsctl set Open_vSwitch . 
> external-ids:ovn-remote=tcp:127.0.0.1:1234])
> +
> +sleep 1
> +AT_CHECK([ovn-appctl connection-status], [0], [dnl
> +not connected
> +])
> +
> +NS_CHECK_EXEC([sw01], [ping -q -c 2 -i 0.5 -w 1 172.16.1.2 | FORMAT_PING | 
> sed 's/.* packets/n packets/'],
> +[0], [dnl
> +n packets transmitted, 0 received, 100% packet loss, time 0ms
> +])
> +
> +ovn-sbctl list fdb
> +AS_BOX([Test traffic for which ARP entry existed in MAC_Binding table])
> +NS_CHECK_EXEC([sw01], [ping -q -c 2 -i 0.2 -w 2 172.16.1.1 | FORMAT_PING],
> +[0], [dnl
> +2 packets transmitted, 2 received, 0% packet loss, time 0ms
> +])
> +
> +AT_CHECK([ovs-vsctl set Open_vSwitch . external-ids:ovn-remote=$SB_PATH])
> +OVS_APP_EXIT_AND_WAIT([ovn-controller])
> +
> +as ovn-sb
> +OVS_APP_EXIT_AND_WAIT([ovsdb-server])
> +
> +as ovn-nb
> +OVS_APP_EXIT_AND_WAIT([ovsdb-server])
> +
> +as northd
> +OVS_APP_EXIT_AND_WAIT([ovn-northd])
> +
> +as
> +OVS_TRAFFIC_VSWITCHD_STOP(["/.*error receiving.*/d
> +/failed to query port patch-.*/d
> +/.*terminating with signal 15.*/d"])
> +AT_CLEANUP
> +])
> +
> 

Re: [ovs-dev] [PATCH ovn] ovn-northd.at: Fix flaky VXLAN mode disabling test.

[Numan Siddique]

On Fri, Jul 19, 2024 at 6:01 AM Ilya Maximets  wrote:
>
> On 7/19/24 07:04, Ales Musil wrote:
> >
> >
> > On Thu, Jul 18, 2024 at 9:40 PM Ilya Maximets  > > wrote:
> >
> > This tests constructs a very large operation that frequently takes more
> > than a second on busy CI systems.  As a result ovn-nbctl emits a warning
> > for a long poll interval and fails the test.
> >
> > Fix that by splitting a single large command into a series of smaller
> > ones - 100 switches at a time.  This makes the test a bit slower, but
> > much more reliable.
> >
> > Fixes: 7e99500e60bf ("northd: Add support for disabling vxlan mode.")
> > Signed-off-by: Ilya Maximets  > >
> > ---
> >
> >
> > Hi Ilya,
> >
> > thank you for addressing this, however there is one patch already pending
> > addressing the same issue 
> > https://patchwork.ozlabs.org/project/ovn/patch/20240715091707.83910-1-amu...@redhat.com/
> >  .
>
> Ah, thanks for the pointer!  I did look through patchwork before
> sending, but somehow missed this one.
>
> OTOH, I'm not a big fan of hiding the executed commands from the
> testsuite log, which will happen if we replace check with eval.
> Also, constructing command lines that long is generally not a good
> idea since the maximum command line length is system-dependent
> and can be as low as 4096 characters.
>
> Best regards, Ilya Maximets.

Thanks Ilya and Ales for the patches to address this issue.

@Ales - I went ahead and applied this patch for the reasons stated by Ilya.

Thanks
Numan

>
> >
> >
> >  tests/ovn-northd.at  | 8 ++--
> >  1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/tests/ovn-northd.at  
> > b/tests/ovn-northd.at 
> > index a389d1988..d7551f69a 100644
> > --- a/tests/ovn-northd.at 
> > +++ b/tests/ovn-northd.at 
> > @@ -2882,12 +2882,16 @@ ovn-sbctl \
> >  --id=@e create encap chassis_name=hv1 ip="192.168.0.1" 
> > type="vxlan" \
> >  -- --id=@c create chassis name=hv1 encaps=@e
> >
> > -cmd="ovn-nbctl --wait=sb"
> > +cmd=""
> >  for i in {1..4097..1}; do
> >  cmd="${cmd} -- ls-add lsw-${i}"
> > +if test $(($i % 100)) -eq 0; then
> > +check ovn-nbctl $cmd
> > +cmd=""
> > +fi
> >  done
> >
> > -check $cmd
> > +check ovn-nbctl --wait=sb $cmd
> >
> >  check_row_count nb:Logical_Switch 4097
> >  wait_row_count sb:Datapath_Binding 4095
> > --
> > 2.45.2
> >
> >
> > Thanks,
> > Ales
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [Patch ovn v6] Text respresntations for drop sampling.

[Numan Siddique]

On Tue, Jul 23, 2024 at 12:41 PM Numan Siddique  wrote:
>
> On Tue, Jul 16, 2024 at 9:45 AM Jacob Tanenbaum  wrote:
> >
> > Created a new column in the southbound database to hardcode a human readable
> > description for flows. This first use is describing why the flow is 
> > dropping packets.
> > The new column is called flow_desc and will create southbound database 
> > entries like this
> >
> > _uuid   : 20f1897b-477e-47ae-a32c-c546d83ec097
> > actions : 
> > "sample(probability=65535,collector_set=123,obs_domain=1,obs_point=$cookie);
> >  /* drop */"
> > controller_meter: []
> > external_ids: {source="northd.c:8721", stage-name=ls_in_l2_unknown}
> > flow_desc   : "No L2 destination"
> > logical_datapath: []
> > logical_dp_group: ee3c3db5-98a2-4f34-8a84-409deae140a7
> > match   : "outport == \"none\""
> > pipeline: ingress
> > priority: 50
> > table_id: 27
> > tags: {}
> > hash: 0
> >
> > future work includes entering more flow_desc for more flows and adding
> > flow_desc to the actions as a comment.
> >
> > Signed-off-by: Jacob Tanenbaum 
> > Suggested-by: Dumitru Ceara 
> > Reported-at: https://issues.redhat.com/browse/FDP-307
> >
>
> Hi Jacob,
>
> Thanks for the patch.
>
> I've a question.  Do you have a specific reason to add a string wrapper ?
> Looks to me, you can use "const char *flow_desc" in the "struct
> ovn_lflow".  Is it because in the future, to add
> dynamic strings ?
>
> I'd suggest just use "const char *" for now and use "struct ds" in the
> future patches if we need to add memory allocated
> strings ?  What do you think ?
>
> Otherwise the patch LGTM.

Also there are a few typos.

In the commit message - s/respresntations/representations

And a few below.


>
> Thanks
> Numan
>
> > ---
> >
> > v1: initial version
> > v2: correct commit message
> > make the flow_desc a char*
> > correct a typo in the ovn-sb.xml
> > correct the test
> > v3: rebase issue with NEWS file
> > v4: remove options:debug_drop_domain_id="1" from testing as we
> > do not depend on it
> > v5: introduce string wrapper
> > increment ovs-sb.ovsschema version
> > correct the testing
> > added descriptions to more dropped packets
> > v6: v5 was not the correct branch, this is...
> > added descriptions to more dropped packets
> > changed the names of the macros to be more descriptive
> > ---
> >  NEWS|  2 ++
> >  lib/ovn-util.h  | 26 +++
> >  northd/lflow-mgr.c  | 25 +++
> >  northd/lflow-mgr.h  | 27 +++-
> >  northd/northd.c | 50 -
> >  ovn-sb.ovsschema|  8 +---
> >  ovn-sb.xml  |  5 +
> >  tests/ovn-northd.at | 15 ++
> >  8 files changed, 119 insertions(+), 39 deletions(-)
> >
> > diff --git a/NEWS b/NEWS
> > index 3e392ff08..0039b04be 100644
> > --- a/NEWS
> > +++ b/NEWS
> > @@ -38,6 +38,8 @@ Post v24.03.0
> >  ability to disable "VXLAN mode" to extend available tunnel IDs space 
> > for
> >  datapaths from 4095 to 16711680.  For more details see man ovn-nb(5) 
> > for
> >  mentioned option.
> > +  - Added a new column in the southbound database "flow_desc" to provide
> > +human readable context to flows.
> >
> >  OVN v24.03.0 - 01 Mar 2024
> >  --
> > diff --git a/lib/ovn-util.h b/lib/ovn-util.h
> > index f75b821b6..2da5cd086 100644
> > --- a/lib/ovn-util.h
> > +++ b/lib/ovn-util.h
> > @@ -466,6 +466,32 @@ void sorted_array_apply_diff(const struct sorted_array 
> > *a1,
> >  bool add),
> >   const void *arg);
> >
> > +/* A wrapper that holds strings */
> > +struct string_wrapper
> > +{
> > +char *str;
> > +bool owns_string;
> > +};
> > +
> > +#define EMPTY_STRING_WRAPPER (struct string_wrapper){NULL, false}
> > +
> > +static inline struct string_wrapper
> > +string_wrapper_create(char *str, bool take_ownership)
> > +{
> > +return (struct string_wrapper) {
> > +.str = str,
> > +.owns_

Re: [ovs-dev] [Patch ovn v6] Text respresntations for drop sampling.

[Numan Siddique]

On Tue, Jul 16, 2024 at 9:45 AM Jacob Tanenbaum  wrote:
>
> Created a new column in the southbound database to hardcode a human readable
> description for flows. This first use is describing why the flow is dropping 
> packets.
> The new column is called flow_desc and will create southbound database 
> entries like this
>
> _uuid   : 20f1897b-477e-47ae-a32c-c546d83ec097
> actions : 
> "sample(probability=65535,collector_set=123,obs_domain=1,obs_point=$cookie); 
> /* drop */"
> controller_meter: []
> external_ids: {source="northd.c:8721", stage-name=ls_in_l2_unknown}
> flow_desc   : "No L2 destination"
> logical_datapath: []
> logical_dp_group: ee3c3db5-98a2-4f34-8a84-409deae140a7
> match   : "outport == \"none\""
> pipeline: ingress
> priority: 50
> table_id: 27
> tags: {}
> hash: 0
>
> future work includes entering more flow_desc for more flows and adding
> flow_desc to the actions as a comment.
>
> Signed-off-by: Jacob Tanenbaum 
> Suggested-by: Dumitru Ceara 
> Reported-at: https://issues.redhat.com/browse/FDP-307
>

Hi Jacob,

Thanks for the patch.

I've a question.  Do you have a specific reason to add a string wrapper ?
Looks to me, you can use "const char *flow_desc" in the "struct
ovn_lflow".  Is it because in the future, to add
dynamic strings ?

I'd suggest just use "const char *" for now and use "struct ds" in the
future patches if we need to add memory allocated
strings ?  What do you think ?

Otherwise the patch LGTM.

Thanks
Numan

> ---
>
> v1: initial version
> v2: correct commit message
> make the flow_desc a char*
> correct a typo in the ovn-sb.xml
> correct the test
> v3: rebase issue with NEWS file
> v4: remove options:debug_drop_domain_id="1" from testing as we
> do not depend on it
> v5: introduce string wrapper
> increment ovs-sb.ovsschema version
> correct the testing
> added descriptions to more dropped packets
> v6: v5 was not the correct branch, this is...
> added descriptions to more dropped packets
> changed the names of the macros to be more descriptive
> ---
>  NEWS|  2 ++
>  lib/ovn-util.h  | 26 +++
>  northd/lflow-mgr.c  | 25 +++
>  northd/lflow-mgr.h  | 27 +++-
>  northd/northd.c | 50 -
>  ovn-sb.ovsschema|  8 +---
>  ovn-sb.xml  |  5 +
>  tests/ovn-northd.at | 15 ++
>  8 files changed, 119 insertions(+), 39 deletions(-)
>
> diff --git a/NEWS b/NEWS
> index 3e392ff08..0039b04be 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -38,6 +38,8 @@ Post v24.03.0
>  ability to disable "VXLAN mode" to extend available tunnel IDs space for
>  datapaths from 4095 to 16711680.  For more details see man ovn-nb(5) for
>  mentioned option.
> +  - Added a new column in the southbound database "flow_desc" to provide
> +human readable context to flows.
>
>  OVN v24.03.0 - 01 Mar 2024
>  --
> diff --git a/lib/ovn-util.h b/lib/ovn-util.h
> index f75b821b6..2da5cd086 100644
> --- a/lib/ovn-util.h
> +++ b/lib/ovn-util.h
> @@ -466,6 +466,32 @@ void sorted_array_apply_diff(const struct sorted_array 
> *a1,
>  bool add),
>   const void *arg);
>
> +/* A wrapper that holds strings */
> +struct string_wrapper
> +{
> +char *str;
> +bool owns_string;
> +};
> +
> +#define EMPTY_STRING_WRAPPER (struct string_wrapper){NULL, false}
> +
> +static inline struct string_wrapper
> +string_wrapper_create(char *str, bool take_ownership)
> +{
> +return (struct string_wrapper) {
> +.str = str,
> +.owns_string = take_ownership,
> +};
> +}
> +
> +static inline void
> +string_wrapper_destroy(struct string_wrapper *s)
> +{
> +if (s->owns_string) {
> +free(s->str);
> +}
> +}
> +
>  /* Utilities around properly handling exit command. */
>  struct ovn_exit_args {
>  struct unixctl_conn **conns;
> diff --git a/northd/lflow-mgr.c b/northd/lflow-mgr.c
> index b2c60b5de..c81d9afcd 100644
> --- a/northd/lflow-mgr.c
> +++ b/northd/lflow-mgr.c
> @@ -25,6 +25,7 @@
>  #include "debug.h"
>  #include "lflow-mgr.h"
>  #include "lib/ovn-parallel-hmap.h"
> +#include "lib/ovn-util.h"
>
>  VLOG_DEFINE_THIS_MODULE(lflow_mgr);
>
> @@ -36,7 +37,7 @@ static void ovn_lflow_init(struct ovn_lflow *, struct 
> ovn_datapath *od,
> uint16_t priority, char *match,
> char *actions, char *io_port,
> char *ctrl_meter, char *stage_hint,
> -   const char *where);
> +   const char *where, struct string_wrapper 
> flow_desc);
>  static struct ovn_lflow *ovn_lflow_find(const struct hmap *lflows,
>  enum 

Re: [ovs-dev] [PATCH ovn v2 5/8] northd: Commit from-lport ACL label (and state) when LBs are used.

[Numan Siddique]

On Thu, Jul 11, 2024 at 12:22 PM Dumitru Ceara  wrote:
>
> Quoting the ACL label section in the ovn.nb.5 man page:
>
>   Associates an identifier with the ACL.
>   The same value will be written to corresponding connection
>   tracker entry. The value should be a valid 32-bit unsigned integer.
>   This value can help in debugging from connection tracker side.
>   For example, through this "label" we can backtrack to the ACL rule
>   which is causing a "leaked" connection. Connection tracker entries are
>   created only for allowed connections so the label is valid only
>   for allow and allow-related actions.
>
> The above states that the ACL label must always be stored in the
> connection tracker entry label for allow-related ACLs (regardless of the
> direction of the ACL).  However, since 74d82e296f80 ("northd: Support
> the option to apply from-lport ACLs after load balancer."), the
> connection is not re-committed in the ls_in_stateful stage (because it
> already was committed as part of the load balancer DNAT).
>
> Moreover, by not re-committing the connection after LB we also risk not
> re-setting any potential ct_mark.blocked value the connection might
> have.
>
> This patch addresses the issue by always committing packets matched by
> allow-related (or stateful in general) ACLs even if they were also
> committed as part of the load balancing stage.
>
> There's potentially a slight overhead when doing this (an additional
> commit call into conntrack but _no_ recirculation).  This is however
> acceptable as it is required for a correct packet processing pipeline
> implementation.  Even without this fix, packets creating new
> connections tha hit "--apply-after-lb" ACLs trigger a re-commit (for
> storing the label and ct_mark.blocked).
>
> A new test is added to ensure we don't break this functionality in the
> future.
>
> CC: Numan Siddique 
> Fixes: 74d82e296f80 ("northd: Support the option to apply from-lport ACLs 
> after load balancer.")
> Signed-off-by: Dumitru Ceara 

Acked-by: Numan Siddique 

Numan

> ---
>  northd/northd.c |   8 +---
>  tests/ovn-northd.at | 110 +++-
>  tests/ovn.at|   4 +-
>  3 files changed, 82 insertions(+), 40 deletions(-)
>
> diff --git a/northd/northd.c b/northd/northd.c
> index fcf8f277ac..901b9e9cd1 100644
> --- a/northd/northd.c
> +++ b/northd/northd.c
> @@ -7494,8 +7494,7 @@ build_lb_affinity_ls_flows(struct lflow_table *lflows,
>  ipv6 ? REG_LB_L2_AFF_BACKEND_IP6 : REG_LB_AFF_BACKEND_IP4;
>
>  /* Prepare common part of affinity LB and affinity learn action. */
> -ds_put_format(_action, REGBIT_CONNTRACK_COMMIT" = 0; %s = %s; ",
> -  reg_vip, lb_vip->vip_str);
> +ds_put_format(_action, "%s = %s; ", reg_vip, lb_vip->vip_str);
>  ds_put_cstr(_action_learn, "commit_lb_aff(vip = \"");
>
>  if (lb_vip->port_str) {
> @@ -7635,11 +7634,6 @@ build_lb_rules(struct lflow_table *lflows, struct 
> ovn_lb_datapaths *lb_dps,
>  ds_clear(action);
>  ds_clear(match);
>
> -/* Make sure that we clear the REGBIT_CONNTRACK_COMMIT flag.  
> Otherwise
> - * the load balanced packet will be committed again in
> - * S_SWITCH_IN_STATEFUL. */
> -ds_put_format(action, REGBIT_CONNTRACK_COMMIT" = 0; ");
> -
>  /* New connections in Ingress table. */
>  const char *meter = NULL;
>  bool reject = build_lb_vip_actions(lb, lb_vip, lb_vip_nb, action,
> diff --git a/tests/ovn-northd.at b/tests/ovn-northd.at
> index 6802fac380..5acb13c519 100644
> --- a/tests/ovn-northd.at
> +++ b/tests/ovn-northd.at
> @@ -1413,7 +1413,7 @@ check ovn-nbctl --wait=sb ls-lb-add sw0 lb1
>  AT_CAPTURE_FILE([sbflows])
>  OVS_WAIT_FOR_OUTPUT(
>[ovn-sbctl dump-flows sw0 | tee sbflows | grep 'priority=120.*backends' | 
> ovn_strip_lflows], 0, [dnl
> -  table=??(ls_in_lb   ), priority=120  , match=(ct.new && ip4.dst == 
> 10.0.0.10 && tcp.dst == 80), action=(reg0[[1]] = 0; 
> ct_lb_mark(backends=10.0.0.3:80,20.0.0.3:80);)
> +  table=??(ls_in_lb   ), priority=120  , match=(ct.new && ip4.dst == 
> 10.0.0.10 && tcp.dst == 80), 
> action=(ct_lb_mark(backends=10.0.0.3:80,20.0.0.3:80);)
>  ])
>
>  # disabled LSPs should not be a backend of Load Balancer
> @@ -1422,7 +1422,7 @@ check ovn-nbctl lsp-set-enabled sw0-p1 disabled
>  AT_CAPTURE_FILE([sbflows])
>  OVS_WAIT_FOR_OUTPUT(
>[ovn-sbctl dump-flows sw0 | tee sbflows | grep 'priority=120.*backends' | 
> ovn_strip_lflows], 0, [dnl
> -  table=??(ls_in_lb   ), p

Re: [ovs-dev] [PATCH ovn v3 2/8] northd: Assume all chassis support the "ct-no-masked-label" feature.

[Numan Siddique]

On Mon, Jul 15, 2024 at 4:56 AM Ales Musil  wrote:
>
> On Fri, Jul 12, 2024 at 5:14 PM Dumitru Ceara  wrote:
>
> > This feature is supported in the last two LTS releases and the correct
> > upgrade procedure mandates that we don't jump across LTS releases.  It's
> > safe to remove the check in northd.
> >
> > Also remove logical field definitions for ct_label.s that cannot
> > appear anymore in the southbound database.
> >
> > Signed-off-by: Dumitru Ceara 
> > ---
> >
>
> Hi Dumitru,
>
> I think this patch should also address the duality of encode_ct_lb() WDYT?
> Other than that it looks good.
>

Thanks for the patch series.
I agree with Ales that we need to address the duality of
encode_ct_lb().  But I think it can be a separate patch.

So I went ahead and applied the first 4 patches of this series.

Regarding the ct_lb and ct_lb_mark actions,  I see we can take 2 approaches

1.  Just delete the action "ct_lb"  or
2,  Make "ct_lb" to also use ct_mark and in the few releases remove
"ct_lb_mark" as "ct_lb" seems a better name.

My preference is (2) if we don't forsee any upgrade issues.

If we want to take approach (1),  I'd suggest include a new patch to
do this in v3 of your series.

Thanks
Numan

> Changes in v2:
> > - fixed "Load balancer CT related backwards compatibility" test.
> > ---
> >  controller/lflow.c  |  39 ++-
> >  controller/lflow.h  |   1 -
> >  controller/ovn-controller.c |  22 
> >  lib/logical-fields.c|  22 
> >  northd/en-global-config.c   |  23 
> >  northd/en-global-config.h   |   1 -
> >  northd/inc-proc-northd.c|   2 -
> >  northd/northd.c | 190 +++
> >  ovn-sb.xml  |  19 
> >  tests/ovn-controller.at |   8 +-
> >  tests/ovn-northd.at | 215 
> >  tests/ovn.at|   9 +-
> >  12 files changed, 95 insertions(+), 456 deletions(-)
> >
> > diff --git a/controller/lflow.c b/controller/lflow.c
> > index b4c379044f..9f6564787f 100644
> > --- a/controller/lflow.c
> > +++ b/controller/lflow.c
> > @@ -100,7 +100,6 @@ consider_logical_flow(const struct sbrec_logical_flow
> > *lflow,
> >  static void
> >  consider_lb_hairpin_flows(const struct ovn_controller_lb *lb,
> >const struct hmap *local_datapaths,
> > -  bool use_ct_mark,
> >struct ovn_desired_flow_table *flow_table);
> >
> >  static void add_port_sec_flows(const struct shash *binding_lports,
> > @@ -1631,7 +1630,6 @@ static void
> >  add_lb_vip_hairpin_flows(const struct ovn_controller_lb *lb,
> >   struct ovn_lb_vip *lb_vip,
> >   struct ovn_lb_backend *lb_backend,
> > - bool use_ct_mark,
> >   struct ovn_desired_flow_table *flow_table)
> >  {
> >  uint64_t stub[1024 / 8];
> > @@ -1722,29 +1720,13 @@ add_lb_vip_hairpin_flows(const struct
> > ovn_controller_lb *lb,
> >   * - packets must have ip.src == ip.dst at this point.
> >   * - the destination protocol and port must be of a valid backend that
> >   *   has the same IP as ip.dst.
> > - *
> > - * During upgrades logical flows might still use the old way of
> > storing
> > - * ct.natted in ct_label.  For backwards compatibility, only use
> > ct_mark
> > - * if ovn-northd notified ovn-controller to do that.
> >   */
> > -if (use_ct_mark) {
> > -uint32_t lb_ct_mark = OVN_CT_NATTED;
> > -match_set_ct_mark_masked(_match, lb_ct_mark, lb_ct_mark);
> > +uint32_t lb_ct_mark = OVN_CT_NATTED;
> > +match_set_ct_mark_masked(_match, lb_ct_mark, lb_ct_mark);
> >
> > -ofctrl_add_flow(flow_table, OFTABLE_CHK_LB_HAIRPIN, 100,
> > -lb->slb->header_.uuid.parts[0], _match,
> > -, >slb->header_.uuid);
> > -} else {
> > -match_set_ct_mark_masked(_match, 0, 0);
> > -ovs_u128 lb_ct_label = {
> > -.u64.lo = OVN_CT_NATTED,
> > -};
> > -match_set_ct_label_masked(_match, lb_ct_label,
> > lb_ct_label);
> > -
> > -ofctrl_add_flow(flow_table, OFTABLE_CHK_LB_HAIRPIN, 100,
> > -lb->slb->header_.uuid.parts[0], _match,
> > -, >slb->header_.uuid);
> > -}
> > +ofctrl_add_flow(flow_table, OFTABLE_CHK_LB_HAIRPIN, 100,
> > +lb->slb->header_.uuid.parts[0], _match,
> > +, >slb->header_.uuid);
> >
> >  ofpbuf_uninit();
> >  }
> > @@ -1967,7 +1949,6 @@ add_lb_ct_snat_hairpin_flows(const struct
> > ovn_controller_lb *lb,
> >  static void
> >  consider_lb_hairpin_flows(const struct ovn_controller_lb *lb,
> >const struct hmap *local_datapaths,
> > -  bool use_ct_mark,
> >struct ovn_desired_flow_table *flow_table)
> >  {
> >  for (size_t i = 

Re: [ovs-dev] [PATCH ovn] northd: Fix issues for Forwarding_Group

[Numan Siddique]

On Fri, Jul 12, 2024 at 6:34 AM 1130911995--- via dev
 wrote:
>
> From 805422a85cf839bdff5330cd173f3ae55861efe9 Mon Sep 17 00:00:00 2001
> From: zhangqiang45 
> Date: Mon, 8 Jul 2024 14:25:04 +0800
> Subject: [PATCH ovn] northd:Fix issues for Forwarding_Group The use of
>  variables from the outer loop in the inner loop causes the outer loop to
>  terminate prematurely. eg. LVS are three fwgs,
>  fwg1(p1,p2,p3,p4),fwg2(p11,p22), fwg3(p31,p32),only fwg1 in logical_flows.
> Submitted-at: https://github.com/ovn-org/ovn/pull/250
>
> Signed-off-by: zhangqiang45 

Thanks.  I applied this patch to the main.  I'll backport to other branches.

Numan



> ---
>  northd/northd.c | 7 +--
>  tests/ovn.at| 7 +++
>  2 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/northd/northd.c b/northd/northd.c
> index 6898daa00..be1a1e288 100644
> --- a/northd/northd.c
> +++ b/northd/northd.c
> @@ -7929,6 +7929,9 @@ build_fwd_group_lflows(struct ovn_datapath *od, struct 
> lflow_table *lflows,
>  continue;
>  }
>
> +ds_clear();
> +ds_clear();
> +
>  /* ARP responder for the forwarding group's virtual IP */
>  ds_put_format(, "arp.tpa == %s && arp.op == 1",
>fwd_group->vip);
> @@ -7959,9 +7962,9 @@ build_fwd_group_lflows(struct ovn_datapath *od, struct 
> lflow_table *lflows,
>  ds_put_cstr(_ports, "liveness=\"true\",");
>  }
>  ds_put_cstr(_ports, "childports=");
> -for (i = 0; i < (fwd_group->n_child_port - 1); ++i) {
> +for (size_t j = 0; j < (fwd_group->n_child_port - 1); ++j) {
>  ds_put_format(_ports, "\"%s\",",
> - fwd_group->child_port[i]);
> + fwd_group->child_port[j]);
>  }
>  ds_put_format(_ports, "\"%s\"",
>fwd_group->child_port[fwd_group->n_child_port - 1]);
> diff --git a/tests/ovn.at b/tests/ovn.at
> index 185ba4a21..b1fd8c69b 100644
> --- a/tests/ovn.at
> +++ b/tests/ovn.at
> @@ -27054,7 +27054,14 @@ check ovs-vsctl add-port br-int vif3 -- set 
> Interface vif3 external-ids:iface-id
>  # Add a forwarding group on ls2 with lsp21 and lsp22 as child ports
>  # virtual IP - 172.16.1.11, virtual MAC - 00:11:de:ad:be:ef
>  check ovn-nbctl --wait=hv fwd-group-add fwd_grp1 ls2 172.16.1.11 
> 00:11:de:ad:be:ef lsp21 lsp22
> +check ovn-nbctl --wait=hv fwd-group-add fwd_grp2 ls2 172.16.2.11 
> 00:22:de:ad:be:ef lsp21 lsp22
>
> +# Check logical flow
> +AT_CAPTURE_FILE([sbflows])
> +ovn-sbctl dump-flows > sbflows
> +AT_CHECK([grep ls_in_l2_lkup sbflows | grep fwd_group | wc -l], [0], [2
> +])
> +check ovn-nbctl --wait=hv fwd-group-del fwd_grp2
>  # Check logical flow
>  AT_CAPTURE_FILE([sbflows])
>  ovn-sbctl dump-flows > sbflows
> --
> 2.43.5
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v7 ovn] northd: Add bfd, static_routes and route_policies nodes to I-P engine.

[Numan Siddique]

On Mon, Jul 22, 2024 at 2:04 AM Han Zhou  wrote:
>
> On Sat, Jul 20, 2024 at 8:22 AM Lorenzo Bianconi
>  wrote:
> >
> > > On Fri, Jul 19, 2024 at 9:20 AM Lorenzo Bianconi
> > >  wrote:
> > > >
> > > > [...]
> > > > >
> > > > > Hi Han,
> > > > >
> > > > > I had suggested Lorenzo to add a new node to do the sync for the
> > > > > reasons Lorenzo mentioned.
> > > > > I'm fine with your suggestion or any other optimization or re-ordering
> > > > > as long as we can
> > > > > avoid looping every static route and route policy for each bfd entry
> > > > > to check if it is being
> > > > > used actively before putting its state to admin_down.
> > > >
> > >
> > > Thanks Lore and Numan for the details. Now I understand the context.
> > >
> > > > Hi Han and Numan,
> > > >
> > > > I do not think we can move en_bfd node after en_route_policies or
> > > > en_static_routes ones since the en_bfd computation results are used by
> > > > en_route_policies and en_static_routes.
> > >
> > > I didn't see how en_bfd computation results are used by
> > > en_route_policies and en_static_routes. In your patch,
> > > en_route_policies and en_static_routes don't have en_bfd as input. Is
> > > there any hidden dependency I didn't see?
> >
> > Hi Han,
> >
> > I guess en_route_policies and en_static_routes nodes depend on the result 
> > from
> > en_bfd one since we check nb_bt->status value in check_bfd_state() and
> > parsed_route_lookup() to see if route_policy/static_route is usable or not.
> > Please take a look to [0] and [1].
>
> I see. These are indeed hidden dependencies. Originally all these
> logic belong to a single node en_lflow, so it wasn't a problem, but
> now since they are split into different nodes, the dependencies need
> to be properly tracked.
>
> In the current patch the en_bfd not only generates output data in the
> bfd_connections hmap, but also updates NB-DB's bfd status, and
> en_route_policies and en_static_routes nodes depend on the NB-DB bfd
> status. The I-P engine doesn't detect OVSDB changes within an
> iteration, which makes the situation very tricky.
>
> > Moreover please consider build_bfd_table() can modify nb_bt->status 
> > according
> > to the sb_bt->status value since ovn-controller could update it (e.g. if the
> > bfd link goes down). Please take a look to [2].
> > Thinking again about it, I guess we need to keep en_bfd node as input of
> > en_route_policies/en_static_routes.
>
> Yes we can add en_bfd as the input of both en_route_policies and
> en_static_routes, even though there is no direct use of en_bfd's data
> from these nodes, just because the dependency is through the NB-DB IDL
> which is not reflected by the I-P engine. This is a workaround and we
> need to carefully add comments to describe the reason for this special
> case.
>
> Alternatively, I think a better approach is that in en_bfd's data
> (bfd_connections) we keep track of the desired state of each entry but
> don't directly update the NB-DB. In en_route_policies and
> en_static_routes nodes we don't check NB-DB status but check the
> states stored in bfd_connections, and they shouldn't make any change
> to the NB-DB state either (I see there are NB-DB updates from
> parsed_routes_add but I wonder if the state change can be moved to the
> en_bfd node). Finally in the en_bfd_nb_sync it can take care of all
> the NB-DB bfd state updates as needed, according to the data of
> en_bfd, en_route_policies and en_static_routes. And these NB-DB update
> notifications will later trigger another I-P run anyway, thus the
> en_bfd node run will be triggered and the states in bfd_connections
> would eventually reflect the NB-DB bfd states. This avoids the hidden
> dependency, and makes NB bfd status sync in one place, which is more
> clear, but I understand it requires more changes. Please give it some
> thoughts.
>

While reviewing the patch,  I totally missed the fact that en_bfd,
en_route_policies
and en_static_routes nodes are also updating the NB BFD status,  I thought that
the en_bfd_nb_sync engine node is the one which does the status update.

I agree with Han.  Only the engine en_bfd_nb_sync should update the NB BFD.

Thanks
Numan

> Thanks,
> Han
>
> > What do you think? Am I missing something?
> >
> > Regards,
> > Lorenzo
> >
> > [0] https://github.com/ovn-org/ovn/blob/main/northd/northd.c#L10012
> > [1] https://github.com/ovn-org/ovn/blob/main/northd/northd.c#L10382
> > [2] https://github.com/ovn-org/ovn/blob/main/northd/northd.c#L9897
> >
> > >
> > > If the dependency is correct, I think the en_bfd_nb_sync is
> > > unnecessary because you can add en_route_policies and en_static_routes
> > > as inputs for en_bfd, and move just the same logic of en_bfd_nb_sync
> > > to en_bfd. This shouldn't require looping every static route and route
> > > policy for each bfd entry. What do you think?
> > >
> > > Thanks,
> > > Han
> > >
> > > > Let's consider the following example:
> > > > we have an ecmp route configured with two different 

Re: [ovs-dev] [PATCH ovn] ci: Use compressed format for podman save.

[Numan Siddique]

On Thu, Jul 11, 2024 at 5:32 AM Ales Musil  wrote:
>
> The default format "docker-archive" is just pure tar without any
> compression. Use "oci-archive" instead which compresses the layers
> and saves some space in the cache which translates to time save
> during the upload/download.
>
> Signed-off-by: Ales Musil 

Thanks for the improvements.  Applied to main.

Numan

> ---
>  .cirrus.yml| 2 +-
>  .github/workflows/ovn-fake-multinode-tests.yml | 2 +-
>  .github/workflows/test.yml | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/.cirrus.yml b/.cirrus.yml
> index 0a16d7b5f..9b35d4cfb 100644
> --- a/.cirrus.yml
> +++ b/.cirrus.yml
> @@ -15,7 +15,7 @@ build_image_task:
>build_container_script:
>  - cd utilities/containers
>  - make ubuntu
> -- podman save -o /tmp/image.tar ovn-org/ovn-tests:ubuntu
> +- podman save -o /tmp/image.tar --format oci-archive 
> ovn-org/ovn-tests:ubuntu
>
>upload_image_script:
>  - curl -s -X POST -T /tmp/image.tar 
> http://$CIRRUS_HTTP_CACHE_HOST/${CIRRUS_CHANGE_IN_REPO}
> diff --git a/.github/workflows/ovn-fake-multinode-tests.yml 
> b/.github/workflows/ovn-fake-multinode-tests.yml
> index 5c9030a49..b83bfce36 100644
> --- a/.github/workflows/ovn-fake-multinode-tests.yml
> +++ b/.github/workflows/ovn-fake-multinode-tests.yml
> @@ -60,7 +60,7 @@ jobs:
>  sudo -E ./ovn_cluster.sh build
>  mkdir -p /tmp/_output
>  sudo podman tag ovn/ovn-multi-node:latest ovn/ovn-multi-node:${{ 
> matrix.cfg.branch }}
> -sudo podman save ovn/ovn-multi-node:${{ matrix.cfg.branch }} > 
> /tmp/_output/ovn_${{ matrix.cfg.branch }}_image.tar
> +sudo podman save --format oci-archive ovn/ovn-multi-node:${{ 
> matrix.cfg.branch }} > /tmp/_output/ovn_${{ matrix.cfg.branch }}_image.tar
>working-directory: ovn-fake-multinode
>
>  - uses: actions/upload-artifact@v4
> diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml
> index befa0bfac..0342c3dcf 100644
> --- a/.github/workflows/test.yml
> +++ b/.github/workflows/test.yml
> @@ -56,7 +56,7 @@ jobs:
>  run: podman pull ghcr.io/ovn-org/ovn-tests:${{ env.IMAGE_DISTRO }}
>
>- name: Export image
> -run: podman save -o /tmp/image.tar ovn-org/ovn-tests:${{ 
> env.IMAGE_DISTRO }}
> +run: podman save -o /tmp/image.tar --format oci-archive 
> ovn-org/ovn-tests:${{ env.IMAGE_DISTRO }}
>
>- name: Cache image
>  id: image_cache
> --
> 2.45.2
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn] controller: Add lsp option disable_garp_rarp.

[Numan Siddique]

On Wed, Jul 17, 2024 at 3:07 AM Shibir Basak  wrote:
>
> Hi Ales,
>
> Configuring “unknown” addresses will remove the port security even if IP/MAC 
> is configured on the port or when OVN is acting as DHCP server for the subnet.
> We would like to avoid it.

Hi Shibir,

I do agree with Ales to avoid a config option if possible.  If I
understand correctly,  during the migration, the logical port on the
AZ2 will be created
with the same MAC + IP and with the option:disable_garp_rarp=true set
right ?  And when the CMS detects that the VM is successfully
migrated,
it will clear this option or set it to false right ?  Please correct
me If I'm wrong.

If so,  can't the CMS first create the logical port with no addresses
at all and once migrated set the addresses to the desired MAC + IP ?
Please let me know why this approach doesn't work in your case ?

I'm fine with this patch if you can justify why the approach I
suggested won't work.  In that case please update the new version with
the NEWS item entry for this option.

Thanks
Numan

>
> Thanks,
> Shibir
>
> From: Ales Musil 
> Date: Tuesday, 16 July 2024 at 3:48 PM
> To: Shibir Basak 
> Cc: d...@openvswitch.org 
> Subject: Re: [ovs-dev] [PATCH ovn] controller: Add lsp option 
> disable_garp_rarp.
> Yes, that's why I'm trying to find out if that would work for you. If I 
> remember correctly libvirt/qemu is supposed to send gARP on its own when the 
> migration finishes. On Tue, Jul 16, 2024 at 12: 13 PM Shibir Basak  basak@ nutanix. com>
> ZjQcmQRYFpfptBannerStart
> CAUTION: External Email
>
> ZjQcmQRYFpfptBannerEnd
> Yes, that's why I'm trying to find out if that would work for you. If I 
> remember correctly libvirt/qemu is supposed to send gARP on its own when the 
> migration finishes.
>
> On Tue, Jul 16, 2024 at 12:13 PM Shibir Basak 
> mailto:shibir.ba...@nutanix.com>> wrote:
> Yes, I think OVN doesn’t send rarp and garp unless the VIF has MAC and IP 
> addresses configured respectively.
>
> Are you suggesting to configure the IP/MAC once we feel the VM is ready to 
> avoid the problem?
>
> Thanks,
> Shibir
>
> From: Ales Musil mailto:amu...@redhat.com>>
> Date: Tuesday, 16 July 2024 at 1:10 PM
> To: Shibir Basak mailto:shibir.ba...@nutanix.com>>
> Cc: d...@openvswitch.org 
> mailto:d...@openvswitch.org>>
> Subject: Re: [ovs-dev] [PATCH ovn] controller: Add lsp option 
> disable_garp_rarp.
> I fully understand the problem, however when I update your test into the 
> snippet below it starts to fail because we don't send any garp/rarp for ports 
> with unknown address, does that make sense? diff --git a/tests/ovn. at [ovn. 
> at] b/tests/ovn. at
> ZjQcmQRYFpfptBannerStart
> CAUTION: External Email
>
> ZjQcmQRYFpfptBannerEnd
> I fully understand the problem, however when I update your test into the 
> snippet below it starts to fail because we don't send any garp/rarp for ports 
> with unknown address, does that make sense?
>
> diff --git a/tests/ovn.at 
> [ovn.at]
>  b/tests/ovn.at 
> [ovn.at]
> index 185ba4a21..618d7bd72 100644
> --- a/tests/ovn.at 
> [ovn.at]
> +++ b/tests/ovn.at 
> [ovn.at]
> @@ -38426,3 +38426,58 @@ OVN_CLEANUP([hv1],[hv2])
>
>  AT_CLEANUP
>  ])
> +
> +OVN_FOR_EACH_NORTHD([
> +AT_SETUP([Disabling RARP/GARP announcements])
> +ovn_start
> +
> +# In this test case we create 1 switch and bring up 4 VIFs on it.
> +# Two VIFs will be assigned MAC addresses only (i.e. without ips)
> +# and two VIFs will be assigned IP addresses along with MAC addresses.
> +# VIFs with IPs are supposed to send GARPs and VIFs with only MAC
> +# addresses are supposed to send RARP. However, we test the lsp
> +# option disable_garp_rarp, which when set to true for an lsp does
> +# not send the GARP/RARP announcements.
> +
> +ovn-nbctl ls-add ls1
> +ovn-nbctl lsp-add ls1 ln1 "" 101
> +ovn-nbctl lsp-set-addresses ln1 unknown
> +ovn-nbctl lsp-set-type ln1 localnet
> +ovn-nbctl lsp-set-options ln1 network_name=phys
> +
> +ovn-nbctl lsp-add ls1 lp11
> +ovn-nbctl lsp-set-addresses 

Re: [ovs-dev] [PATCH ovn] tests: Fix ssl-ciphers RO sb test with old openssl.

[Numan Siddique]

On Wed, Jul 10, 2024 at 2:57 AM Ales Musil  wrote:
>
> On Sat, Jul 6, 2024 at 4:21 PM Vladislav Odintsov  wrote:
>
> > The test "read-only sb db:pssl access with ssl-ciphers and ssl-protocols"
> > fails when running with openssl which doesn't support some of passed
> > values.
> > For instance, on openssl 1.0.2 there is no support for 'SECLEVEL' and
> > test fails due to extra string in stderr, which is asserted as a part of
> > test:
> >
> >   ./ovn.at:37851: ovn-sbctl --db=ssl:127.0.0.1:$TCP_PORT \
> > --private-key=$PKIDIR/testpki-test-privkey.pem \
> >   --certificate=$PKIDIR/testpki-test-cert.pem \
> >   --ca-cert=$PKIDIR/testpki-cacert.pem \
> >   --ssl-ciphers='HIGH:!aNULL:!MD5:@SECLEVEL=1' \
> >   --ssl-protocols='TLSv1,TLSv1.1,TLSv1.2' \
> > chassis-add ch vxlan 1.2.4.8
> >   --- - 2024-07-05 13:48:11.697647047 +0300
> >   +++
> > /builddir/build/BUILD/ovn-24.03.90/tests/testsuite.dir/at-groups/520/stderr
> > 2024-07-05 13:48:11.694353357 +0300
> >   @@ -1,2 +1,3 @@
> >   +2024-07-05T10:48:11Z|1|stream_ssl|ERR|SSL_CTX_set_cipher_list:
> > error:140E6118:SSL routines:SSL_CIPHER_PROCESS_RULESTR:invalid command
> >ovn-sbctl: transaction error: {"details":"insert operation not allowed
> > when database server is in read only mode","error":"not allowed"}
> >
> > This patch fixes the test adding grep of expected transaction error.
> >
> > CC: Aliasgar Ginwala 
> > Fixes: 620203f9f0d9 ("Fix segfault due to ssl-ciphers.")
> > Signed-off-by: Vladislav Odintsov 
> > ---
> >  tests/ovn.at | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/tests/ovn.at b/tests/ovn.at
> > index 87a64499f..2341f52d5 100644
> > --- a/tests/ovn.at
> > +++ b/tests/ovn.at
> > @@ -37854,9 +37854,9 @@ AT_CHECK([ovn-sbctl --db=ssl:127.0.0.1:$TCP_PORT \
> >  --ca-cert=$PKIDIR/testpki-cacert.pem \
> >  --ssl-ciphers='HIGH:!aNULL:!MD5:@SECLEVEL=1' \
> >  --ssl-protocols='TLSv1,TLSv1.1,TLSv1.2' \
> > -chassis-add ch vxlan 1.2.4.8], [1], [ignore],
> > -[ovn-sbctl: transaction error: {"details":"insert operation not allowed
> > when database server is in read only mode","error":"not allowed"}
> > -])
> > +chassis-add ch vxlan 1.2.4.8 2>&1 | grep 'transaction
> > error]', [0], [dnl
> > +ovn-sbctl: transaction error: {"details":"insert operation not allowed
> > when database server is in read only mode","error":"not allowed"}
> > +], [ignore])
> >
> >  OVS_APP_EXIT_AND_WAIT([ovsdb-server])
> >  AT_CLEANUP
> > --
> > 2.45.2
> >
> > ___
> > dev mailing list
> > d...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> >
> >
> Looks good to me, thanks.
>
> Acked-by: Ales Musil 

Thanks.  Applied to main.

Numan

>
> --
>
> Ales Musil
>
> Senior Software Engineer - OVN Core
>
> Red Hat EMEA 
>
> amu...@redhat.com
> 
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] Fwd: ovn-controller generates some non-expected openflows to forward packets to tunnel ports in table 37 when a localnet port existed on the datapath

[Numan Siddique]

On Thu, Jul 18, 2024 at 10:17 PM Jun Gu  wrote:
>
> Hi, Numan, Thanks for your reply. Unfortunately, We have restarted the
> ovn-controller and the issue is fixed now. Currently, I am analyzing
> codes to confirm if some situations will cause the issue. Do you have
> any suggestions for me?
>

Fact that the restart fixed the issue suggests that it was most likely
an I-P issue
It would be great if you can consider upgrading OVN to the latest
version or latest LTS version.

I'd suggest delete the localnet port and re-add it and see if those
unexpected flows are present or not.
Next time the issue is seen, please run the ovn-appctl command to see
if it fixes the issue.

Numan

> Thanks
> Jun
>
> On 7/19/24 00:52, Numan Siddique wrote:
> > On Wed, Jul 17, 2024 at 6:07 AM Jun Gu  wrote:
> >>
> >> Hi team
> >> The version is below:
> >>   OVN version: branch-21.09
> >>   OVS version: branch-2.16.2
> >> we encounter a issue that ovn-controller generates some non-expected
> >> openflows to forward packets to tunnel ports in table 37 when a localnet
> >> port existed on the datapath. The related information is below:
> >> - Related datapath and ports.
> >> ```
> >> switch d9954742-5f9a-440d-8f4a-e9cba08ff5b3
> >> (neutron-102c1351-65a6-4640-8310-c3cd446a5b69) (aka JSNX_APP_VLAN121)
> >>   port b4decafe-1948-4214-b021-393953bf94c3 (aka
> >> sc-arm-lnbp-clbatch-13_JSNX_APP_VLAN121_d36c91ab)
> >>   addresses: ["fa:16:3e:32:ca:7e 32.12.121.150"]
> >>   port 87e5ac12-80b8-4477-af59-dfb0fc0a43ff (aka
> >> sc-arm-lnbp-pfservice-6_JSNX_APP_VLAN121_109c4c56)
> >>   addresses: ["fa:16:3e:e7:58:37 32.12.121.103"]
> >>   port ad722de8-20ca-4f52-97bf-df29f9512d6e
> >>   type: localport
> >>   addresses: ["fa:16:3e:3d:96:cd 32.12.121.10"]
> >> ...
> >>   port 067b57c8-2e50-4a86-a255-31e799a24ac5 (aka
> >> sc-arm-lnbp-taebatch-5_JSNX_APP_VLAN121_a029cd93)
> >>   addresses: ["fa:16:3e:e5:0e:10 32.12.121.151"]
> >>   port d2479952-a2e2-4c94-b5d9-5086f5a177ee (aka
> >> sc-arm-lnbp-mars-3_JSNX_APP_VLAN121_319305dc)
> >>   addresses: ["fa:16:3e:7c:4e:35 32.12.121.194"]
> >>   port 64ddd42f-6a70-4060-8782-bd5cad7c4983 (aka
> >> sc-arm-lnbp-clbatch-8_JSNX_APP_VLAN121_7a4ca62f)
> >>   addresses: ["fa:16:3e:9c:56:aa 32.12.121.213"]
> >>   port provnet-6612e9ff-5364-4788-9b27-0a8c6053bec3
> >>   type: localnet
> >>   tag: 121
> >>   addresses: ["unknown"]
> >>   port f004de9d-5e52-43c7-9094-364a07ac420f (aka
> >> sc-arm-lnbp-influxdb-3_JSNX_APP_VLAN121_7527d6dc)
> >>   addresses: ["fa:16:3e:96:6b:45 32.12.121.231"]
> >> ```
> >> - Related openflows.
> >> ```
> >>cookie=0xd9b58719, duration=3803793.502s, table=37, n_packets=0,
> >> n_bytes=0, idle_age=65535, priority=100,reg15=0x37,metadata=0xd
> >> actions=set_field:0xd/0xff->tun_id,set_field:0x37->tun_metadata0,move:NXM_NX_REG14[0..14]->NXM_NX_TUN_METADATA0[16..30],output:13
> >>cookie=0x997eb173, duration=3803793.502s, table=37, n_packets=0,
> >> n_bytes=0, idle_age=65535, priority=100,reg15=0x8005,metadata=0xd
> >> actions=set_field:0x2->reg15,resubmit(,39),set_field:0x8005->reg15,set_field:0xd/0xff->tun_id,set_field:0x8005->tun_metadata0,move:NXM_NX_REG14[0..14]->NXM_NX_TUN_METADATA0[16..30],output:300,output:14,output:138,output:137,output:299,output:140,output:304,output:303,output:142,output:1,output:302,output:139,output:301,output:13,output:11,output:10,resubmit(,38)
> >>cookie=0xce52adfe, duration=3803793.502s, table=37, n_packets=2475804,
> >> n_bytes=162274574, idle_age=0, priority=100,reg15=0x8000,metadata=0xd
> >> actions=set_field:0x2->reg15,resubmit(,39),set_field:0x8000->reg15,set_field:0xd/0xff->tun_id,set_field:0x8000->tun_metadata0,move:NXM_NX_REG14[0..14]->NXM_NX_TUN_METADATA0[16..30],output:300,output:14,output:138,output:137,output:299,output:140,output:304,output:303,output:142,output:1,output:302,output:139,output:301,output:13,output:11,output:10,resubmit(,38)
> >>cookie=0xb9dee9ea, duration=3803793.502s, table=37, n_packets=0,
> >> n_bytes=0, idle_age=65535, priority=100,reg15=0x8003,metadata=0xd
> >> actions=set_field:0xd/0xff->tun_id,set_field:0x8003->tun_metadata0,move:NXM_NX_REG14[0..14]->NXM_NX_TUN_METADATA0[16..30],output:300,output:14,output:13

Re: [ovs-dev] [PATCH v7 ovn] northd: Add bfd, static_routes and route_policies nodes to I-P engine.

[Numan Siddique]

On Fri, Jul 19, 2024 at 6:45 AM Lorenzo Bianconi
 wrote:
>
> > On Thu, Jul 18, 2024 at 8:34 AM Lorenzo Bianconi
> >  wrote:
> > >
> > > Introduce bfd, static_routes and route_policies nodes to northd I-P
> > > engine to track bfd connections and northd static_route/policy_route
> > > changes.
> > >
> > > Acked-by: Numan Siddique 
> > > Reported-at: https://issues.redhat.com/browse/FDP-600
> > > Signed-off-by: Lorenzo Bianconi 
> > > ---
> > > Changes since v6:
> > > - remove unnecessary node inputs
> > > - fix comment
> >
> > Thanks Lore for the v7. Please find below some more comments.
>
> Hi Han,
>
> thx for the review.
>
> >
>
> [...]
>
> > >
> > > +bool
> > > +route_policies_northd_change_handler(struct engine_node *node,
> > > + void *data OVS_UNUSED)
> > > +{
> > > +struct northd_data *northd_data = engine_get_input_data("northd", 
> > > node);
> > > +if (!northd_has_tracked_data(_data->trk_data)) {
> > > +return false;
> > > +}
> > > +
> > > +/* This node uses the below data from the en_northd engine node.
> > > + * See (lr_stateful_get_input_data())
> > > + *   1. northd_data->lr_datapaths
> >
> > This node also depends on lr_ports.
>
> ack, I will fix it in v8
>
> >
> > > + *  This data gets updated when a logical router is created or 
> > > deleted.
> > > + *  northd engine node presently falls back to full recompute 
> > > when
> > > + *  this happens and so does this node.
> > > + *  Note: When we add I-P to the created/deleted logical 
> > > routers, we
> > > + *  need to revisit this handler.
> > > + *
> > > + *  This node also accesses the route policies of the logical 
> > > router.
> > > + *  When these route policies get updated, en_northd engine 
> > > recomputes
> > > + *  and so does this node.
> > > + *  Note: When we add I-P to handle route policies changes, we 
> > > need
> > > + *  to revisit this handler.
> > > + */
> > > +return true;
> > > +}
> > > +
> > > +void
> > > +en_route_policies_run(struct engine_node *node, void *data)
> > > +{
> > > +struct northd_data *northd_data = engine_get_input_data("northd", 
> > > node);
> > > +struct route_policies_data *route_policies_data = data;
> > > +
> > > +route_policies_destroy(data);
> > > +route_policies_init(data);
> > > +
> > > +struct ovn_datapath *od;
> > > +HMAP_FOR_EACH (od, key_node, _data->lr_datapaths.datapaths) {
> > > +build_route_policies(od, _data->lr_ports,
> > > + _policies_data->route_policies,
> > > + 
> > > _policies_data->bfd_active_connections);
> > > +}
> > > +
> > > +engine_set_node_state(node, EN_UPDATED);
> > > +}
> > > +
> > > +bool
> > > +static_routes_northd_change_handler(struct engine_node *node,
> > > +void *data OVS_UNUSED)
> > > +{
> > > +struct northd_data *northd_data = engine_get_input_data("northd", 
> > > node);
> > > +if (!northd_has_tracked_data(_data->trk_data)) {
> > > +return false;
> > > +}
> > > +
> > > +/* This node uses the below data from the en_northd engine node.
> > > + * See (lr_stateful_get_input_data())
> > > + *   1. northd_data->lr_datapaths
> >
> > Same as above. The node also depends on lr_ports.
>
> ack, I will fix it in v8
>
> >
> > > + *  This data gets updated when a logical router is created or 
> > > deleted.
> > > + *  northd engine node presently falls back to full recompute 
> > > when
> > > + *  this happens and so does this node.
> > > + *  Note: When we add I-P to the created/deleted logical 
> > > routers, we
> > > + *  need to revisit this handler.
> > > + *
> > > + *  This node also accesses the static routes of the logical 
> > > router.
> > > + *  When t

Re: [ovs-dev] Fwd: ovn-controller generates some non-expected openflows to forward packets to tunnel ports in table 37 when a localnet port existed on the datapath

[Numan Siddique]

On Wed, Jul 17, 2024 at 6:07 AM Jun Gu  wrote:
>
> Hi team
>The version is below:
>  OVN version: branch-21.09
>  OVS version: branch-2.16.2
>we encounter a issue that ovn-controller generates some non-expected
> openflows to forward packets to tunnel ports in table 37 when a localnet
> port existed on the datapath. The related information is below:
>- Related datapath and ports.
> ```
> switch d9954742-5f9a-440d-8f4a-e9cba08ff5b3
> (neutron-102c1351-65a6-4640-8310-c3cd446a5b69) (aka JSNX_APP_VLAN121)
>  port b4decafe-1948-4214-b021-393953bf94c3 (aka
> sc-arm-lnbp-clbatch-13_JSNX_APP_VLAN121_d36c91ab)
>  addresses: ["fa:16:3e:32:ca:7e 32.12.121.150"]
>  port 87e5ac12-80b8-4477-af59-dfb0fc0a43ff (aka
> sc-arm-lnbp-pfservice-6_JSNX_APP_VLAN121_109c4c56)
>  addresses: ["fa:16:3e:e7:58:37 32.12.121.103"]
>  port ad722de8-20ca-4f52-97bf-df29f9512d6e
>  type: localport
>  addresses: ["fa:16:3e:3d:96:cd 32.12.121.10"]
> ...
>  port 067b57c8-2e50-4a86-a255-31e799a24ac5 (aka
> sc-arm-lnbp-taebatch-5_JSNX_APP_VLAN121_a029cd93)
>  addresses: ["fa:16:3e:e5:0e:10 32.12.121.151"]
>  port d2479952-a2e2-4c94-b5d9-5086f5a177ee (aka
> sc-arm-lnbp-mars-3_JSNX_APP_VLAN121_319305dc)
>  addresses: ["fa:16:3e:7c:4e:35 32.12.121.194"]
>  port 64ddd42f-6a70-4060-8782-bd5cad7c4983 (aka
> sc-arm-lnbp-clbatch-8_JSNX_APP_VLAN121_7a4ca62f)
>  addresses: ["fa:16:3e:9c:56:aa 32.12.121.213"]
>  port provnet-6612e9ff-5364-4788-9b27-0a8c6053bec3
>  type: localnet
>  tag: 121
>  addresses: ["unknown"]
>  port f004de9d-5e52-43c7-9094-364a07ac420f (aka
> sc-arm-lnbp-influxdb-3_JSNX_APP_VLAN121_7527d6dc)
>  addresses: ["fa:16:3e:96:6b:45 32.12.121.231"]
> ```
>- Related openflows.
> ```
>   cookie=0xd9b58719, duration=3803793.502s, table=37, n_packets=0,
> n_bytes=0, idle_age=65535, priority=100,reg15=0x37,metadata=0xd
> actions=set_field:0xd/0xff->tun_id,set_field:0x37->tun_metadata0,move:NXM_NX_REG14[0..14]->NXM_NX_TUN_METADATA0[16..30],output:13
>   cookie=0x997eb173, duration=3803793.502s, table=37, n_packets=0,
> n_bytes=0, idle_age=65535, priority=100,reg15=0x8005,metadata=0xd
> actions=set_field:0x2->reg15,resubmit(,39),set_field:0x8005->reg15,set_field:0xd/0xff->tun_id,set_field:0x8005->tun_metadata0,move:NXM_NX_REG14[0..14]->NXM_NX_TUN_METADATA0[16..30],output:300,output:14,output:138,output:137,output:299,output:140,output:304,output:303,output:142,output:1,output:302,output:139,output:301,output:13,output:11,output:10,resubmit(,38)
>   cookie=0xce52adfe, duration=3803793.502s, table=37, n_packets=2475804,
> n_bytes=162274574, idle_age=0, priority=100,reg15=0x8000,metadata=0xd
> actions=set_field:0x2->reg15,resubmit(,39),set_field:0x8000->reg15,set_field:0xd/0xff->tun_id,set_field:0x8000->tun_metadata0,move:NXM_NX_REG14[0..14]->NXM_NX_TUN_METADATA0[16..30],output:300,output:14,output:138,output:137,output:299,output:140,output:304,output:303,output:142,output:1,output:302,output:139,output:301,output:13,output:11,output:10,resubmit(,38)
>   cookie=0xb9dee9ea, duration=3803793.502s, table=37, n_packets=0,
> n_bytes=0, idle_age=65535, priority=100,reg15=0x8003,metadata=0xd
> actions=set_field:0xd/0xff->tun_id,set_field:0x8003->tun_metadata0,move:NXM_NX_REG14[0..14]->NXM_NX_TUN_METADATA0[16..30],output:300,output:14,output:138,output:137,output:299,output:140,output:304,output:303,output:142,output:1,output:302,output:139,output:301,output:13,output:11,output:10,resubmit(,38)
> ```
>The datapath tunnel_key is 0xd, its localnet port tunnel_key is 0x1
> and its localport port tunnel_key is 0x2. From openflows related 0xd
> datapath, the localnet port has not been acquired to generate the table
> 37 non-expected openflows. And other tables can identify the localnet
> port, so other tables which generate openflows are correct. For example,
> a openflow from table 38
> ```
>   cookie=0xce52adfe, duration=3803727.055s, table=38, n_packets=2475787,
> n_bytes=162273290, idle_age=0, priority=100,reg15=0x8000,metadata=0xd
> actions=set_field:0x1->reg15,resubmit(,39),set_field:0x70->reg13,set_field:0x3->reg15,resubmit(,39),set_field:0x72->reg13,set_field:0x26->reg13,set_field:0x29->reg15,resubmit(,39),set_field:0x39->reg13,set_field:0x33->reg15,resubmit(,39),set_field:0x8000->reg15
> ```
>Based on the above information, we analyze the related ovn-controller
> codes. Only one condition that the localnet port is not queried by
> get_localnet_port function, the issue will occur.
>However, a deeper analysis of the code did not yield more useful
> information.

Seems to me this could be a bug in the ovn-controller's incremental
processing (I-P) and should be fixed in recent versions.

Can you please run the command - "ovn-appctl -t ovn-controller
recompute" or "ovn-appctl -t ovn-controller inc-engine/recompute"
and see if the non-expected openflows are deleted ?  This would
confirm 

Re: [ovs-dev] [PATCH ovn v1] northd: Add ECMP symmetric replies for egress.

[Numan Siddique]

On Wed, Jul 17, 2024 at 2:59 PM Ilya Maximets  wrote:
>
> On 7/16/24 23:16, num...@ovn.org wrote:
> > From: Numan Siddique 
> >
> > When there are ECMP symmetric static routes configured, OVN selects
> > one of the next hop for the traffic originated from within the
> > cluster.  For the subsequent packets to the same destination,
> > OVN may select a different next hop (which is fine).  But there can
> > be certain usecases, where the next hop entity can be stateful and
> > selecting the same next hop is desirable.
> >
> > This patch address this usecase in the following way
> >
> >1.  For the first packet originating from the OVN logical port
> >VIF, OVN selects a next hop 'A' and forwards the traffic to
> >it.
> >
> >2.  When the reply traffic is received (either from next hop 'A'
> >or any other next hop), it commits the connection in the
> >DNAT zone of the logical router and saves the state in
> >ct_label.ecmp_reply_eth and ct_label.ecmp_reply_port.
> >Note that we already support this for the traffic
> >originating from an ECMP route [1].  We are now extending
> >the same for the traffic originating from the cluster towards
> >the ECMP route.
> >
> > 3. For the subsequent packets from the cluster, we select the
> >next hop eth address and the port from the saved conntrack
> >state.  This is straightforward as we anyway send the packet
> >to the DNAT zone of the logical router.
>
> Hi, Numan.  Thanks for the change!
>
> It seems like you missed the update for system tests.  A few ECMP
> system tests are failing in CI.

Thanks for the review and pointing this out.  I'll fix it in v2.

>
> Also, not sure how big of a problem that is, but we may still spray
> out uni-directional traffic.  For example, any UDP tunnels may still
> be re-shuffled.  Do we need a solution for those?

I think that's ok.  If OVN doesn't see the reply, then its fine for
the traffic from pod to external
is load balanced between the ecmp routes.  Once the reply is seen,
this patch would save
the state in conntrack and going forward, the same route will be used
to forward the traffic
for that connection.

Numan

>
> Best regards, Ilya Maximets.
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v2 ovn] nbctl: Added local link ipv6 to nbctl show.

[Numan Siddique]

On Fri, Jul 5, 2024 at 12:41 PM Mj Ponsonby  wrote:
>
> From: MJ Ponsonby 
>
>
> This commit modifies a test to deal with the changed,
> response from the command
> This commit also modifies the function of ovn-nbctl show,
> to also return the ipv6 link local address as mentioned
>
> This information would be useful to have with the wider useage of
> advertising IPv4 Prefixes over IPv6 next hops [0]
>
> 0: https://datatracker.ietf.org/doc/html/rfc5549
>
> Reported-at: https://launchpad.net/bugs/2069804
> Signed-off-by: MJ Ponsonby 

Thanks.  Applied to main.

Numan

> ---
>  tests/ovn-nbctl.at|  1 +
>  utilities/ovn-nbctl.c | 10 ++
>  2 files changed, 11 insertions(+)
>
> diff --git a/tests/ovn-nbctl.at b/tests/ovn-nbctl.at
> index 19c83a4a5..de014e1f9 100644
> --- a/tests/ovn-nbctl.at
> +++ b/tests/ovn-nbctl.at
> @@ -1670,6 +1670,7 @@ AT_CHECK([ovn-nbctl show lr0 | uuidfilt], [0], [dnl
>  router <0> (lr0)
>  port lrp0
>  mac: "00:00:00:01:02:03"
> +ipv6-lla: "fe80::200:ff:fe01:203"
>  networks: [["192.168.1.1/24"]]
>  ])
>
> diff --git a/utilities/ovn-nbctl.c b/utilities/ovn-nbctl.c
> index 32ca4f750..04c123022 100644
> --- a/utilities/ovn-nbctl.c
> +++ b/utilities/ovn-nbctl.c
> @@ -780,6 +780,16 @@ print_lr(const struct nbrec_logical_router *lr, struct 
> ds *s)
>  if (lrp->mac) {
>  ds_put_cstr(s, "mac: ");
>  ds_put_format(s, "\"%s\"\n", lrp->mac);
> +
> +/* Have the mac address in an array. */
> +struct eth_addr ea;
> +eth_addr_from_string(lrp->mac, );
> +struct in6_addr lla;
> +in6_generate_lla(ea, );
> +
> +ds_put_cstr(s, "ipv6-lla: \"");
> +ipv6_format_addr(, s);
> +ds_put_cstr(s, "\"\n");
>  }
>  if (lrp->n_networks) {
>  ds_put_cstr(s, "networks: [");
> --
> 2.43.0
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v5 ovn] northd: Add bfd, static_routes and route_policies I-P nodes.

[Numan Siddique]

On Fri, Jul 5, 2024 at 1:31 PM Lorenzo Bianconi
 wrote:
>
> Introduce bfd, static_routes, route_policies and bfd_nb_sync nodes to northd 
> I-P
> engine to track bfd connections and northd static_route/policy_route
> changes.
>
> Reported-at: https://issues.redhat.com/browse/FDP-600
> Signed-off-by: Lorenzo Bianconi 

Hi Lorenzo,

Thanks for addressing the comments.  Please see below a small comment.
With that addressed :

Acked-by: Numan Siddique 

Numan

> ---
> Changes since v4:
> - introduce bfd_nb_sync node and ger rid of bfd_consumer routine
> Changes since v3:
> - fix bfd_northd_change_handler logic
> - fix route_policies_northd_change_handler logic
> - fix static_routes_northd_change_handler logic
> - add unit-tests
> - cosmetics
> Changes since v2:
> - add incremental processing routines
> - split bfd_consumer node in static_routes and route_policies nodes
> Changes since v1:
> - add incremental processing logic for bfd_consumer node to avoid a full
>   recompute
> ---
>  northd/en-lflow.c|  25 +-
>  northd/en-northd.c   | 215 ++
>  northd/en-northd.h   |  23 ++
>  northd/inc-proc-northd.c |  37 ++-
>  northd/northd.c  | 587 +++
>  northd/northd.h  |  63 -
>  tests/ovn-northd.at  |  56 
>  7 files changed, 810 insertions(+), 196 deletions(-)
>
> diff --git a/northd/en-lflow.c b/northd/en-lflow.c
> index c4b927fb8..3dba5034b 100644
> --- a/northd/en-lflow.c
> +++ b/northd/en-lflow.c
> @@ -41,6 +41,11 @@ lflow_get_input_data(struct engine_node *node,
>   struct lflow_input *lflow_input)
>  {
>  struct northd_data *northd_data = engine_get_input_data("northd", node);
> +struct bfd_data *bfd_data = engine_get_input_data("bfd", node);
> +struct static_routes_data *static_routes_data =
> +engine_get_input_data("static_routes", node);
> +struct route_policies_data *route_policies_data =
> +engine_get_input_data("route_policies", node);
>  struct port_group_data *pg_data =
>  engine_get_input_data("port_group", node);
>  struct sync_meters_data *sync_meters_data =
> @@ -50,10 +55,6 @@ lflow_get_input_data(struct engine_node *node,
>  struct ed_type_ls_stateful *ls_stateful_data =
>  engine_get_input_data("ls_stateful", node);
>
> -lflow_input->nbrec_bfd_table =
> -EN_OVSDB_GET(engine_get_input("NB_bfd", node));
> -lflow_input->sbrec_bfd_table =
> -EN_OVSDB_GET(engine_get_input("SB_bfd", node));
>  lflow_input->sbrec_logical_flow_table =
>  EN_OVSDB_GET(engine_get_input("SB_logical_flow", node));
>  lflow_input->sbrec_multicast_group_table =
> @@ -78,7 +79,10 @@ lflow_get_input_data(struct engine_node *node,
>  lflow_input->meter_groups = _meters_data->meter_groups;
>  lflow_input->lb_datapaths_map = _data->lb_datapaths_map;
>  lflow_input->svc_monitor_map = _data->svc_monitor_map;
> -lflow_input->bfd_connections = NULL;
> +lflow_input->bfd_connections = _data->bfd_connections;
> +lflow_input->parsed_routes = _routes_data->parsed_routes;
> +lflow_input->route_tables = _routes_data->route_tables;
> +lflow_input->route_policies = _policies_data->route_policies;
>
>  struct ed_type_global_config *global_config =
>  engine_get_input_data("global_config", node);
> @@ -95,25 +99,14 @@ void en_lflow_run(struct engine_node *node, void *data)
>  struct lflow_input lflow_input;
>  lflow_get_input_data(node, _input);
>
> -struct hmap bfd_connections = HMAP_INITIALIZER(_connections);
> -lflow_input.bfd_connections = _connections;
> -
>  stopwatch_start(BUILD_LFLOWS_STOPWATCH_NAME, time_msec());
>
>  struct lflow_data *lflow_data = data;
>  lflow_table_clear(lflow_data->lflow_table);
>  lflow_reset_northd_refs(_input);
>
> -build_bfd_table(eng_ctx->ovnsb_idl_txn,
> -lflow_input.nbrec_bfd_table,
> -lflow_input.sbrec_bfd_table,
> -lflow_input.lr_ports,
> -_connections);
>  build_lflows(eng_ctx->ovnsb_idl_txn, _input,
>   lflow_data->lflow_table);
> -bfd_cleanup_connections(lflow_input.nbrec_bfd_table,
> -_connections);
> -hmap_destroy(_connections);
>  stopwatch_stop(BUILD_LFLOWS_STOPWATCH_NAME, time_msec());
>
>  engine_set_node_state(node, EN_UPDATED);
> diff --git a/northd/en-northd.c b/northd/en-northd.c
> index 4479b4af

Re: [ovs-dev] [PATCH ovn v4 1/1] Add support for overlay provider networks.

[Numan Siddique]

On Mon, Jul 8, 2024 at 5:32 PM Numan Siddique  wrote:
>
> On Mon, Jul 8, 2024 at 2:54 AM Han Zhou  wrote:
> >
> > On Thu, Jun 6, 2024 at 3:38 PM  wrote:
> > >
> > > From: Numan Siddique 
> > >
> > > It is expected that a provider network logical switch has a localnet 
> > > logical
> > > switch port in order to bridge the overlay traffic to the underlay 
> > > traffic.
> > > There can be some usecases where a overlay logical switch (without
> > > a localnet port) can act as a provider network and presently NAT doesn't
> > > work as expected.  This patch adds this support.  A new config option
> > > "overlay_provider_network" is added to support this feature.
> > > This feature gets enabled for a logical switch 'P' if:
> > >   - The above option is set to true in the Logical_Switch.other_config
> > > column.
> > >   - The logical switch 'P' doesn't have any localnet ports.
> > >   - The logical router port of a router 'R' connecting to 'P'
> > > is a gateway router port.
> > >   - And the logical router 'R' has only one gateway router port.
> > >
> > > If all the above conditions are met, ovn-northd creates a chassisredirect
> > > port for the logical switch port (of type router) connecting to the
> > > router 'R'.  For example, if the logical port is named as "P-R" and its
> > > peer router port is "R-P", then chassisredirect port cr-P-R is created
> > > along with cr-R-P.  Gateway chassis binding the cr-R-P also binds cr-P-R.
> > > This ensures that the routing is centralized on this gateway chassis for
> > > the traffic coming from switch "P" towards the router or vice versa.
> > > This centralization is required in order to support NAT (both SNAT and
> > > DNAT).  Distributed NAT (i.e if external_mac and router_port is set) is
> > > not supported and instead the router port mac is used for such traffic.
> > >
> > > Reported-at: https://issues.redhat.com/browse/FDP-364
> > > Signed-off-by: Numan Siddique 
> > > ---
> > >  NEWS  |   2 +
> > >  controller/physical.c |   4 +
> > >  northd/northd.c   | 239 ++
> > >  northd/northd.h   |   1 +
> > >  ovn-nb.xml|  27 ++
> > >  tests/multinode-macros.at |   2 +-
> > >  tests/multinode.at| 177 +
> > >  tests/ovn-northd.at   | 520 +-
> > >  tests/ovn.at  |   8 +-
> > >  9 files changed, 928 insertions(+), 52 deletions(-)
> > >
> > > diff --git a/NEWS b/NEWS
> > > index 3bdc551728..51e6eeabc9 100644
> > > --- a/NEWS
> > > +++ b/NEWS
> > > @@ -31,6 +31,8 @@ Post v24.03.0
> > >  has been renamed to "options:ic-route-denylist" in order to comply 
> > > with
> > >  inclusive language guidelines. The previous name is still recognized 
> > > to
> > >  aid with backwards compatibility.
> > > +  - Added Overlay provider network support to a logical switch if
> > > +the config "overlay_provider_network" is set to true.
> > >
> > >  OVN v24.03.0 - 01 Mar 2024
> > >  --
> > > diff --git a/controller/physical.c b/controller/physical.c
> > > index 25da789f0b..69a617f341 100644
> > > --- a/controller/physical.c
> > > +++ b/controller/physical.c
> > > @@ -1607,6 +1607,10 @@ consider_port_binding(struct ovsdb_idl_index 
> > > *sbrec_port_binding_by_name,
> > >  ct_zones);
> > >  put_zones_ofpacts(_ids, ofpacts_p);
> > >
> > > +/* Clear the MFF_INPORT.  Its possible that the same packet 
> > > may
> > > + * go out from the same tunnel inport. */
> > > +put_load(ofp_to_u16(OFPP_NONE), MFF_IN_PORT, 0, 16, 
> > > ofpacts_p);
> > > +
> > >  /* Resubmit to table 41. */
> > >  put_resubmit(OFTABLE_CHECK_LOOPBACK, ofpacts_p);
> > >  }
> > > diff --git a/northd/northd.c b/northd/northd.c
> > > index 9f81afccbb..2af9295a50 100644
> > > --- a/northd/northd.c
> > > +++ b/northd/northd.c
> > > @@ -2098,6 +2098,53 @@ parse_lsp_addrs(struct ovn_port *op)
> > >  }
> > >  }
> > >
> > > +static struct ovn_port *
> > >

Re: [ovs-dev] [PATCH ovn v2] Maintainers: Fix the typo in the email id.

[Numan Siddique]

On Mon, Jul 8, 2024 at 5:49 PM Dumitru Ceara  wrote:
>
> On 7/8/24 23:22, num...@ovn.org wrote:
> > From: Numan Siddique 
> >
> > Also added my ovn.org email id to the list.
> >
> > Signed-off-by: Numan Siddique 
> > ---
>
> Looks good to me, thanks!
>
> Acked-by: Dumitru Ceara 

Thanks.  Applied to main.

Numan

>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn v4 1/1] Add support for overlay provider networks.

[Numan Siddique]

On Mon, Jul 8, 2024 at 2:54 AM Han Zhou  wrote:
>
> On Thu, Jun 6, 2024 at 3:38 PM  wrote:
> >
> > From: Numan Siddique 
> >
> > It is expected that a provider network logical switch has a localnet logical
> > switch port in order to bridge the overlay traffic to the underlay traffic.
> > There can be some usecases where a overlay logical switch (without
> > a localnet port) can act as a provider network and presently NAT doesn't
> > work as expected.  This patch adds this support.  A new config option
> > "overlay_provider_network" is added to support this feature.
> > This feature gets enabled for a logical switch 'P' if:
> >   - The above option is set to true in the Logical_Switch.other_config
> > column.
> >   - The logical switch 'P' doesn't have any localnet ports.
> >   - The logical router port of a router 'R' connecting to 'P'
> > is a gateway router port.
> >   - And the logical router 'R' has only one gateway router port.
> >
> > If all the above conditions are met, ovn-northd creates a chassisredirect
> > port for the logical switch port (of type router) connecting to the
> > router 'R'.  For example, if the logical port is named as "P-R" and its
> > peer router port is "R-P", then chassisredirect port cr-P-R is created
> > along with cr-R-P.  Gateway chassis binding the cr-R-P also binds cr-P-R.
> > This ensures that the routing is centralized on this gateway chassis for
> > the traffic coming from switch "P" towards the router or vice versa.
> > This centralization is required in order to support NAT (both SNAT and
> > DNAT).  Distributed NAT (i.e if external_mac and router_port is set) is
> > not supported and instead the router port mac is used for such traffic.
> >
> > Reported-at: https://issues.redhat.com/browse/FDP-364
> > Signed-off-by: Numan Siddique 
> > ---
> >  NEWS  |   2 +
> >  controller/physical.c |   4 +
> >  northd/northd.c   | 239 ++
> >  northd/northd.h   |   1 +
> >  ovn-nb.xml|  27 ++
> >  tests/multinode-macros.at |   2 +-
> >  tests/multinode.at| 177 +
> >  tests/ovn-northd.at   | 520 +-
> >  tests/ovn.at  |   8 +-
> >  9 files changed, 928 insertions(+), 52 deletions(-)
> >
> > diff --git a/NEWS b/NEWS
> > index 3bdc551728..51e6eeabc9 100644
> > --- a/NEWS
> > +++ b/NEWS
> > @@ -31,6 +31,8 @@ Post v24.03.0
> >  has been renamed to "options:ic-route-denylist" in order to comply with
> >  inclusive language guidelines. The previous name is still recognized to
> >  aid with backwards compatibility.
> > +  - Added Overlay provider network support to a logical switch if
> > +the config "overlay_provider_network" is set to true.
> >
> >  OVN v24.03.0 - 01 Mar 2024
> >  --
> > diff --git a/controller/physical.c b/controller/physical.c
> > index 25da789f0b..69a617f341 100644
> > --- a/controller/physical.c
> > +++ b/controller/physical.c
> > @@ -1607,6 +1607,10 @@ consider_port_binding(struct ovsdb_idl_index 
> > *sbrec_port_binding_by_name,
> >  ct_zones);
> >  put_zones_ofpacts(_ids, ofpacts_p);
> >
> > +/* Clear the MFF_INPORT.  Its possible that the same packet may
> > + * go out from the same tunnel inport. */
> > +put_load(ofp_to_u16(OFPP_NONE), MFF_IN_PORT, 0, 16, ofpacts_p);
> > +
> >  /* Resubmit to table 41. */
> >  put_resubmit(OFTABLE_CHECK_LOOPBACK, ofpacts_p);
> >  }
> > diff --git a/northd/northd.c b/northd/northd.c
> > index 9f81afccbb..2af9295a50 100644
> > --- a/northd/northd.c
> > +++ b/northd/northd.c
> > @@ -2098,6 +2098,53 @@ parse_lsp_addrs(struct ovn_port *op)
> >  }
> >  }
> >
> > +static struct ovn_port *
> > +create_cr_port(struct ovn_port *op, struct hmap *ports,
> > +   struct ovs_list *both_dbs, struct ovs_list *nb_only)
> > +{
> > +char *redirect_name = ovn_chassis_redirect_name(
> > +op->nbsp ? op->nbsp->name : op->nbrp->name);
> > +
> > +struct ovn_port *crp = ovn_port_find(ports, redirect_name);
> > +if (crp && crp->sb && crp->sb->datapath == op->od->sb) {
> > +ovn_port_set_nb(crp, NULL, op->nbrp);
> > +ovs_list_remove(>list);

Re: [ovs-dev] [PATCH ovn] Maintainers: Fix the typo in the email id.

[Numan Siddique]

On Mon, Jul 8, 2024 at 5:05 PM Dumitru Ceara  wrote:
>
> On 7/8/24 22:38, num...@ovn.org wrote:
> > From: Numan Siddique 
> >
> > Also added my ovn.org email id to the list.
> >
> > Signed-off-by: Numan Siddique 
> > ---
>
> Hi Numan,
>
> >  MAINTAINERS.rst | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/MAINTAINERS.rst b/MAINTAINERS.rst
> > index f72c8b5eda..0d70048078 100644
> > --- a/MAINTAINERS.rst
> > +++ b/MAINTAINERS.rst
> > @@ -54,7 +54,8 @@ This is the current list of active OVN committers:
> > * - Mark Michelson
> >   - mmich...@redhat.com
> > * - Numan Siddique
> > - - nusd...@redhat.com
> > + - nusid...@redhat.com
> > + - num...@ovn.org
>
> Unfortunately, this breaks the format of the maintainers file because
> the table only has two columns and this adds 3 values for this row:
>
> https://github.com/ovsrobot/ovn/blob/series_414329/MAINTAINERS.rst
>
> Maybe you can change it to list both emails, separated by comma?  I

Thanks for pointing out this error.
Separated by comma seems fine to me. Let me test it out before submitting v2.

Thanks
Numan

> don't really know much .rst so maybe there are other options too.
>
> Regards,
> Dumitru
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn v5 2/2] pinctrl: Handle arp/nd for other address families.

[Numan Siddique]

On Fri, Jun 28, 2024 at 5:54 PM Numan Siddique  wrote:
>
> On Wed, Jun 12, 2024 at 2:50 AM Felix Huettner via dev
>  wrote:
> >
> > Previously we could only generate ARP requests from IPv4 packets
> > and NS requests from IPv6 packets. This was the case because we rely on
> > information in the packet to generate the ARP/NS requests.
> >
> > However in case of ARP/NS requests originating from the Logical_Router
> > pipeline for nexthop lookups we overwrite the affected fields
> > afterwards. This overwrite is done by the userdata openflow actions.
> > Because of this we actually do not rely on any information of the IPv4/6
> > packets in these cases.
> >
> > Unfortunately we can not easily determine if we are actually later
> > overwriting the affected fields. The approach now is to use the fields
> > from the IP header if we have a matching IP version and default to some
> > values otherwise. In case we overwrite this data afterwards we are
> > generally good. If we do not overwrite this data because of some bug we
> > will send out invalid ARP/NS requests. They will hopefully be dropped by
> > the rest of the network.
> >
> > The alternative would have been to introduce new arp/nd_ns actions where
> > we guarantee this overwrite. This would not suffer from the above
> > limitations, but would require a coordination on upgrades between all
> > ovn-controllers and northd.
> >
> > Signed-off-by: Felix Huettner 
>
> Hi Felix,
>
> Thanks for the patch series and sorry for the delay in reviews.
>
> Looks like this patch series requires another rebase.
>
> I tested this patch series using the ovn-fake-mutlinode - [1] .
>
> After starting it,  I added the below static route
>
> ovn-nbctl lr-route-add lr1 172.15.0.0/24 3001::b
>
> And in the 'ovn-chassis-1' container I ran this command
>
> [root@ovn-chassis-1 ~]# ip netns exec sw01p1 ping 172.15.0.50
>
> Since we don't know the next hop,  the below logical flow is hit
> (which is as expected)
>
>   table=24(lr_in_arp_request  ), priority=200  , match=(eth.dst ==
> 00:00:00:00:00:00 && reg9[9] == 0 && xxreg0 == 3001::4), action=(nd_ns
> { eth.dst = 33:33:ff:00:00:04; ip6.dst = ff02::1:ff00:4; nd.target =
> 3001::b; output; }; output;)
>
> And If I look into the ovn-controller logs (after enabling vconn:dbg)
> I see that ovn-controller receives the icmp ping packet and it
> generates IPv6 NS packet which is also as expected
>
> 
> 2024-06-28T21:39:06.303Z|00020|vconn(ovn_pinctrl0)|DBG|unix:/var/run/openvswitch/br-int.mgmt:
> received: NXT_PACKET_IN2 (OF1.5) (xid=0x0): cookie=0x77e2d8b
> total_len=98 
> reg0=0x3001,reg1=0xac10016e,reg3=0xb,reg4=0x3001,reg7=0xa,reg9=0x4,reg10=0x1,reg11=0x1,reg12=0x3,reg14=0x1,reg15=0x3,metadata=0x3,in_port=5
> (via action) data_len=98 (unbuffered)
>  
> userdata=00.00.00.09.00.00.00.00.00.1c.00.18.00.80.00.00.00.00.00.00.00.01.de.10.80.00.3e.10.00.00.00.00.ff.ff.00.10.00.00.23.20.00.0e.ff.f8.25.00.00.00
>  continuation.bridge=b72b4e65-0756-4215-bfbf-c3db3652e8ee
>  continuation.actions=unroll_xlate(table=0, cookie=0),resubmit(,37)
>  continuation.odp_port=5
> icmp,vlan_tci=0x,dl_src=30:51:00:00:00:03,dl_dst=00:00:00:00:00:00,nw_src=11.0.0.3,nw_dst=172.15.0.50,nw_tos=0,nw_ecn=0,nw_ttl=63,nw_frag=no,icmp_type=8,icmp_code=0
> icmp_csum:cf9b
> 2024-06-28T21:39:06.304Z|00021|vconn(ovn_pinctrl0)|DBG|unix:/var/run/openvswitch/br-int.mgmt:
> sent (Success): OFPT_PACKET_OUT (OF1.5) (xid=0x413):
> in_port=CONTROLLER
> actions=set_field:0x3001->reg0,set_field:0xac10016e->reg1,set_field:0xb->reg3,set_field:0x3001->reg4,set_field:0xa->reg7,set_field:0x4->reg9,set_field:0x1->reg10,set_field:0x1->reg11,set_field:0x3->reg12,set_field:0x1->reg14,set_field:0x3->reg15,set_field:0x3->metadata,move:NXM_NX_XXREG0[]->NXM_NX_ND_TARGET[],resubmit(,37)
> data_len=86
> icmp6,vlan_tci=0x,dl_src=30:51:00:00:00:03,dl_dst=33:33:ff:ff:ff:ff,ipv6_src=fe80::3251:ff:fe00:3,ipv6_dst=ff02::1::,ipv6_label=0x0,nw_tos=0,nw_ecn=0,nw_ttl=255,nw_frag=no,icmp_type=135,icmp_code=0,nd_target=:::::::,nd_sll=30:51:00:00:00:03,nd_tll=00:00:00:00:00:00
> icmp6_csum:1877
> --
>
> But strangely when this packet leaves the physical interface 'eth2' on
> ovn-chassis-1,  the nd_target is wrongly populated
>
> tcpdump on the physical interface (connected to br-ex)
> ---
> 17:37:40.289881 30:51:00:00:00:03 > 33:33:ff:ff:ff:ff, ethertype IPv6
> (0x86dd), length 86: (hlim 255, next-header ICMPv6 (58) payload
> length: 32) fe80::3251:ff:fe00:3 > ff02::1::: [icmp6 sum ok]
> ICMP6, neighbor solicitation, length 32,

Re: [ovs-dev] [PATCH ovn v4 1/4] controller: Move CT zone handling into separate module.

[Numan Siddique]

On Wed, Jun 26, 2024 at 1:56 AM Ales Musil  wrote:
>
> Move the CT zone handling specific bits into its own module. This
> allows for easier changes done within the module and separates the
> logic that is unrelated from ovn-controller.
>
> Signed-off-by: Ales Musil 
> Acked-by: Lorenzo Bianconi 

Thanks.  I applied the first 2 patches of this series to the main branch

Numan

> ---
> v4: Rebase on top of latest main.
> Added ack from Lorenzo.
> v3: Rebase on top of latest main.
> ---
>  controller/automake.mk  |   4 +-
>  controller/ct-zone.c| 378 ++
>  controller/ct-zone.h|  74 +++
>  controller/ofctrl.c |   3 +-
>  controller/ovn-controller.c | 393 +++-
>  controller/ovn-controller.h |  21 +-
>  controller/pinctrl.c|   2 +-
>  tests/ovn.at|   4 +-
>  8 files changed, 486 insertions(+), 393 deletions(-)
>  create mode 100644 controller/ct-zone.c
>  create mode 100644 controller/ct-zone.h
>
> diff --git a/controller/automake.mk b/controller/automake.mk
> index 1b1b3aeb1..ed93cfb3c 100644
> --- a/controller/automake.mk
> +++ b/controller/automake.mk
> @@ -47,7 +47,9 @@ controller_ovn_controller_SOURCES = \
> controller/mac-cache.h \
> controller/mac-cache.c \
> controller/statctrl.h \
> -   controller/statctrl.c
> +   controller/statctrl.c \
> +   controller/ct-zone.h \
> +   controller/ct-zone.c
>
>  controller_ovn_controller_LDADD = lib/libovn.la 
> $(OVS_LIBDIR)/libopenvswitch.la
>  man_MANS += controller/ovn-controller.8
> diff --git a/controller/ct-zone.c b/controller/ct-zone.c
> new file mode 100644
> index 0..3e37fedb6
> --- /dev/null
> +++ b/controller/ct-zone.c
> @@ -0,0 +1,378 @@
> +/* Copyright (c) 2024, Red Hat, Inc.
> + *
> + * Licensed under the Apache License, Version 2.0 (the "License");
> + * you may not use this file except in compliance with the License.
> + * You may obtain a copy of the License at:
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> + * See the License for the specific language governing permissions and
> + * limitations under the License.
> + */
> +
> +#include 
> +
> +#include "ct-zone.h"
> +#include "local_data.h"
> +#include "openvswitch/vlog.h"
> +
> +VLOG_DEFINE_THIS_MODULE(ct_zone);
> +
> +static void
> +ct_zone_restore(const struct sbrec_datapath_binding_table *dp_table,
> +struct ct_zone_ctx *ctx, const char *name, int zone);
> +static void ct_zone_add_pending(struct shash *pending_ct_zones,
> +enum ct_zone_pending_state state,
> +int zone, bool add, const char *name);
> +
> +void
> +ct_zones_restore(struct ct_zone_ctx *ctx,
> + const struct ovsrec_open_vswitch_table *ovs_table,
> + const struct sbrec_datapath_binding_table *dp_table,
> + const struct ovsrec_bridge *br_int)
> +{
> +memset(ctx->bitmap, 0, sizeof ctx->bitmap);
> +bitmap_set1(ctx->bitmap, 0); /* Zone 0 is reserved. */
> +
> +struct shash_node *pending_node;
> +SHASH_FOR_EACH (pending_node, >pending) {
> +struct ct_zone_pending_entry *ctpe = pending_node->data;
> +
> +if (ctpe->add) {
> +ct_zone_restore(dp_table, ctx, pending_node->name, ctpe->zone);
> +}
> +}
> +
> +const struct ovsrec_open_vswitch *cfg;
> +cfg = ovsrec_open_vswitch_table_first(ovs_table);
> +if (!cfg) {
> +return;
> +}
> +
> +if (!br_int) {
> +/* If the integration bridge hasn't been defined, assume that
> + * any existing ct-zone definitions aren't valid. */
> +return;
> +}
> +
> +struct smap_node *node;
> +SMAP_FOR_EACH (node, _int->external_ids) {
> +if (strncmp(node->key, "ct-zone-", 8)) {
> +continue;
> +}
> +
> +const char *user = node->key + 8;
> +if (!user[0]) {
> +continue;
> +}
> +
> +if (shash_find(>pending, user)) {
> +continue;
> +}
> +
> +unsigned int zone;
> +if (!str_to_uint(node->value, 10, )) {
> +continue;
> +}
> +
> +ct_zone_restore(dp_table, ctx, user, zone);
> +}
> +}
> +
> +bool
> +ct_zone_assign_unused(struct ct_zone_ctx *ctx, const char *zone_name,
> +  int *scan_start)
> +{
> +/* We assume that there are 64K zones and that we own them all. */
> +int zone = bitmap_scan(ctx->bitmap, 0, *scan_start, MAX_CT_ZONES + 1);
> +if (zone == MAX_CT_ZONES + 1) {
> +static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 1);
> +VLOG_WARN_RL(, "exhausted all ct zones");
> +

Re: [ovs-dev] [PATCH ovn 0/4] Fix issues reported by coverity

[Numan Siddique]

On Wed, Jun 26, 2024 at 9:30 AM Ales Musil  wrote:
>
> Coverity discovered a couple of isse that and dead code. The series
> aims to fix some of them.
>
> Ales Musil (4):
>   treewide: Remove dead code.
>   northd: Fix potential overflow
>   ovn-nbctl: Avoid uninitialized value for mirror index.
>   treewide: Prevent potential NULL ptr deref.

Thanks for the fixes.  I applied the series to the main branch.

Numan

>
>  controller/binding.c| 2 +-
>  controller/lflow.c  | 5 +
>  controller/lflow.h  | 3 +--
>  controller/ovn-controller.c | 3 +--
>  controller/pinctrl.c| 8 +---
>  lib/inc-proc-eng.c  | 8 ++--
>  lib/lex.c   | 1 -
>  northd/aging.c  | 3 ++-
>  northd/northd.c | 2 +-
>  northd/test-ipam.c  | 4 
>  tests/ovn-nbctl.at  | 9 +
>  utilities/ovn-ic-nbctl.c| 2 +-
>  utilities/ovn-nbctl.c   | 8 +---
>  13 files changed, 25 insertions(+), 33 deletions(-)
>
> --
> 2.45.1
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn] northd: Detect if SB LB was removed and re-sync that row.

[Numan Siddique]

On Wed, Jul 3, 2024 at 8:20 AM Ales Musil  wrote:
>
> When someone removes SB LB it won't be detected until the next
> recompute of the "sync_to_sb_lb" node. This will cause traffic
> disruptions in case of hairpin as the flows directly depend on
> the SB LB entries. Add check to trigger recompute when we detect
> that the row is missing in SB, but still present in NB.
>
> Reported-at: https://issues.redhat.com/browse/FDP-682
> Signed-off-by: Ales Musil 

Thanks for the patch.

I'm not sure if we need to fix this.  Ideally a user is not supposed
to destroy records in SB DB.
And if the user does it so, then I'd assume the user should trigger a recompute.

You'd see the same behavior if you delete a logical flow manually from
SB DB.  ovn-northd doesn't fix this
causing traffic disruptions until ovn-northd reconciles the SB DB.

I'm not against this fix.  This patch is straightforward and we
already check for duplicate entries in SB LB
in the sync_to_sb_lb_sb_load_balancer().

 But maybe we should discuss if we want to take a similar approach for
other tables as well or not.

Thanks
Numan

> ---
>  northd/en-sync-sb.c | 38 +-
>  tests/ovn-macros.at |  2 +-
>  tests/ovn-northd.at | 38 ++
>  3 files changed, 72 insertions(+), 6 deletions(-)
>
> diff --git a/northd/en-sync-sb.c b/northd/en-sync-sb.c
> index 9bd8a1fc6..12dbd139e 100644
> --- a/northd/en-sync-sb.c
> +++ b/northd/en-sync-sb.c
> @@ -20,6 +20,7 @@
>
>  /* OVS includes. */
>  #include "lib/svec.h"
> +#include "lib/uuidset.h"
>  #include "openvswitch/util.h"
>
>  /* OVN includes. */
> @@ -232,6 +233,7 @@ struct sb_lb_table {
>  struct hmap entries; /* Stores struct sb_lb_record. */
>  struct hmap ls_dp_groups;
>  struct hmap lr_dp_groups;
> +struct uuidset sb_entries;
>  };
>
>  struct ed_type_sync_to_sb_lb_data {
> @@ -347,16 +349,29 @@ sync_to_sb_lb_northd_handler(struct engine_node *node, 
> void *data_)
>  }
>
>  bool
> -sync_to_sb_lb_sb_load_balancer(struct engine_node *node, void *data 
> OVS_UNUSED)
> +sync_to_sb_lb_sb_load_balancer(struct engine_node *node, void *data_)
>  {
>  const struct sbrec_load_balancer_table *sb_load_balancer_table =
>  EN_OVSDB_GET(engine_get_input("SB_load_balancer", node));
> +struct ed_type_sync_to_sb_lb_data *data = data_;
>
> -/* The only reason to handle SB.Load_Balancer updates is to detect
> +/* The reasons to handle SB.Load_Balancer updates is to detect
>   * spurious records being created in clustered databases due to
> - * lack of indexing on the SB.Load_Balancer table.  All other changes
> - * are valid and performed by northd, the only write-client for
> - * this table. */
> + * lack of indexing on the SB.Load_Balancer table.  The other reason 
> might
> + * be when someone removes the SB row while the NB row is still valid.
> + * All other changes are valid and performed by northd. */
> +
> +const struct sbrec_load_balancer *sb_lb;
> +SBREC_LOAD_BALANCER_TABLE_FOR_EACH_TRACKED (sb_lb,
> +sb_load_balancer_table) {
> +if (sbrec_load_balancer_is_deleted(sb_lb) &&
> +uuidset_find(>sb_lbs.sb_entries, _lb->header_.uuid)) {
> +VLOG_WARN("A SB LB for \"%s\" is deleted but the NB LB entry "
> +  "still exists.", sb_lb->name);
> +return false;
> +}
> +}
> +
>  if (check_sb_lb_duplicates(sb_load_balancer_table)) {
>  return false;
>  }
> @@ -626,6 +641,7 @@ sb_lb_table_init(struct sb_lb_table *sb_lbs)
>  hmap_init(_lbs->entries);
>  ovn_dp_groups_init(_lbs->ls_dp_groups);
>  ovn_dp_groups_init(_lbs->lr_dp_groups);
> +uuidset_init(_lbs->sb_entries);
>  }
>
>  static void
> @@ -638,6 +654,7 @@ sb_lb_table_clear(struct sb_lb_table *sb_lbs)
>
>  ovn_dp_groups_clear(_lbs->ls_dp_groups);
>  ovn_dp_groups_clear(_lbs->lr_dp_groups);
> +uuidset_clear(_lbs->sb_entries);
>  }
>
>  static void
> @@ -647,6 +664,7 @@ sb_lb_table_destroy(struct sb_lb_table *sb_lbs)
>  hmap_destroy(_lbs->entries);
>  ovn_dp_groups_destroy(_lbs->ls_dp_groups);
>  ovn_dp_groups_destroy(_lbs->lr_dp_groups);
> +uuidset_destroy(_lbs->sb_entries);
>  }
>
>  static struct sb_lb_record *
> @@ -693,6 +711,8 @@ sb_lb_table_build_and_sync(
>  const char *nb_lb_uuid = smap_get(_lb->external_ids, "lb_id");
>  struct uuid lb_uuid;
>  if (!nb_lb_uuid || !uuid_from_string(_uuid, nb_lb_uuid)) {
> +uuidset_find_and_delete(_lbs->sb_entries,
> +_lb->header_.uuid);
>  sbrec_load_balancer_delete(sbrec_lb);
>  continue;
>  }
> @@ -711,6 +731,8 @@ sb_lb_table_build_and_sync(
>  hmap_insert(_lbs->entries, _lb->key_node,
>  uuid_hash(_lb->lb_dps->lb->nlb->header_.uuid));
>  } else {
> +

Re: [ovs-dev] [PATCH ovn] ovn-ctl: Fix incorrect use of `==` operator.

[Numan Siddique]

On Wed, Jul 3, 2024 at 1:30 AM Frode Nordahl  wrote:
>
> The ovn-ctl script uses a POSIX shell in its shebang line,
> however commit 12412b13c9e2 added two occurrences of the `==`
> operator which is bash specific.
>
> Symptoms of the issue are failure to start up and the follwing
> messages logged:
>
> ovn-ctl: 287: test: X: unexpected operator
> ovn-ctl: 307: test: X: unexpected operator
>
> Fixes: 12412b13c9e2 ("ovn-ctl: Support for --config-file ovsdb-server 
> option.")
> Reported-at: https://launchpad.net/bugs/2071767
> Signed-off-by: Frode Nordahl 

Thanks for fixing this.  Applied to main.

Numan

> ---
>  utilities/ovn-ctl | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/utilities/ovn-ctl b/utilities/ovn-ctl
> index a4f410e4f..d7ca9e758 100755
> --- a/utilities/ovn-ctl
> +++ b/utilities/ovn-ctl
> @@ -284,7 +284,7 @@ $cluster_remote_port
>  set ovsdb-server
>  set "$@" $log --log-file=$logfile
>  set "$@" --pidfile=$db_pid_file
> -if test X"$config_file" == X; then
> +if test X"$config_file" = X; then
>  set "$@" --remote=punix:$sock
>  else
>  set "$@" --config-file=$config_file
> @@ -304,7 +304,7 @@ $cluster_remote_port
>  set exec "$@"
>  fi
>
> -if test X"$use_remote_in_db" != Xno && test X"$config_file" == X; then
> +if test X"$use_remote_in_db" != Xno && test X"$config_file" = X; then
>  set "$@" --remote=db:$schema_name,$table_name,connections
>  fi
>
> --
> 2.45.2
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn] Documentation: Update language about soft freeze requirements.

[Numan Siddique]

On Tue, Jul 2, 2024 at 1:51 PM Ilya Maximets  wrote:
>
> On 7/2/24 19:38, Mark Michelson wrote:
> > The documentation stated that for soft freeze, the development team
> > would only consider merging new feature patches that had been "discussed
> > and reviewed" during the soft freeze period. In reality, the OVN team
> > has been willing to merge any new feature as long as it has been posted
> > for review prior to the soft freeze date. The emails sent out by the OVN
> > team prior to soft freeze have also stated that patches that were posted
> > for review were under consideration for merging.
> >
> > To clear up confusion, the wording in the documentation has been updated
> > as well now to indicate that patches simply need to be "posted" rather
> > than being "discussed and reviewed" prior to the soft freeze date.
> >
> > Signed-off-by: Mark Michelson 

Acked-by: Numan Siddique 

Numan

> > ---
> >  Documentation/internals/release-process.rst | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/Documentation/internals/release-process.rst 
> > b/Documentation/internals/release-process.rst
> > index 988257975..2e9fa4f18 100644
> > --- a/Documentation/internals/release-process.rst
> > +++ b/Documentation/internals/release-process.rst
> > @@ -45,9 +45,9 @@ Scheduling`_ for the timing of each stage:
> >  1. "Soft freeze" of the main branch.
> >
> > During the freeze, we ask committers to refrain from applying patches 
> > that
> > -   add new features unless those patches were already being publicly 
> > discussed
> > -   and reviewed before the freeze began.  Bug fixes are welcome at any 
> > time.
> > -   Please propose and discuss exceptions on ovs-dev.
> > +   add new features unless those patches were already publicly posted 
> > before
>
> 'publicly posted' sounds a little strange...  Maybe 'posted for review' or
> 'posted for a public review'?
>
> > +   the freeze began.  Bug fixes are welcome at any time. Please propose
>
> Two spaces vs one space.  We should be consistent at least within the same
> paragraph.
>
> > +   and discuss exceptions on ovs-dev.
> >
> >  2. Fork a release branch from main, named for the expected release number,
> > e.g. "branch-25.09" for the branch that will yield OVN 25.09.x.
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn v5 2/2] pinctrl: Handle arp/nd for other address families.

[Numan Siddique]

On Wed, Jun 12, 2024 at 2:50 AM Felix Huettner via dev
 wrote:
>
> Previously we could only generate ARP requests from IPv4 packets
> and NS requests from IPv6 packets. This was the case because we rely on
> information in the packet to generate the ARP/NS requests.
>
> However in case of ARP/NS requests originating from the Logical_Router
> pipeline for nexthop lookups we overwrite the affected fields
> afterwards. This overwrite is done by the userdata openflow actions.
> Because of this we actually do not rely on any information of the IPv4/6
> packets in these cases.
>
> Unfortunately we can not easily determine if we are actually later
> overwriting the affected fields. The approach now is to use the fields
> from the IP header if we have a matching IP version and default to some
> values otherwise. In case we overwrite this data afterwards we are
> generally good. If we do not overwrite this data because of some bug we
> will send out invalid ARP/NS requests. They will hopefully be dropped by
> the rest of the network.
>
> The alternative would have been to introduce new arp/nd_ns actions where
> we guarantee this overwrite. This would not suffer from the above
> limitations, but would require a coordination on upgrades between all
> ovn-controllers and northd.
>
> Signed-off-by: Felix Huettner 

Hi Felix,

Thanks for the patch series and sorry for the delay in reviews.

Looks like this patch series requires another rebase.

I tested this patch series using the ovn-fake-mutlinode - [1] .

After starting it,  I added the below static route

ovn-nbctl lr-route-add lr1 172.15.0.0/24 3001::b

And in the 'ovn-chassis-1' container I ran this command

[root@ovn-chassis-1 ~]# ip netns exec sw01p1 ping 172.15.0.50

Since we don't know the next hop,  the below logical flow is hit
(which is as expected)

  table=24(lr_in_arp_request  ), priority=200  , match=(eth.dst ==
00:00:00:00:00:00 && reg9[9] == 0 && xxreg0 == 3001::4), action=(nd_ns
{ eth.dst = 33:33:ff:00:00:04; ip6.dst = ff02::1:ff00:4; nd.target =
3001::b; output; }; output;)

And If I look into the ovn-controller logs (after enabling vconn:dbg)
I see that ovn-controller receives the icmp ping packet and it
generates IPv6 NS packet which is also as expected


2024-06-28T21:39:06.303Z|00020|vconn(ovn_pinctrl0)|DBG|unix:/var/run/openvswitch/br-int.mgmt:
received: NXT_PACKET_IN2 (OF1.5) (xid=0x0): cookie=0x77e2d8b
total_len=98 
reg0=0x3001,reg1=0xac10016e,reg3=0xb,reg4=0x3001,reg7=0xa,reg9=0x4,reg10=0x1,reg11=0x1,reg12=0x3,reg14=0x1,reg15=0x3,metadata=0x3,in_port=5
(via action) data_len=98 (unbuffered)
 
userdata=00.00.00.09.00.00.00.00.00.1c.00.18.00.80.00.00.00.00.00.00.00.01.de.10.80.00.3e.10.00.00.00.00.ff.ff.00.10.00.00.23.20.00.0e.ff.f8.25.00.00.00
 continuation.bridge=b72b4e65-0756-4215-bfbf-c3db3652e8ee
 continuation.actions=unroll_xlate(table=0, cookie=0),resubmit(,37)
 continuation.odp_port=5
icmp,vlan_tci=0x,dl_src=30:51:00:00:00:03,dl_dst=00:00:00:00:00:00,nw_src=11.0.0.3,nw_dst=172.15.0.50,nw_tos=0,nw_ecn=0,nw_ttl=63,nw_frag=no,icmp_type=8,icmp_code=0
icmp_csum:cf9b
2024-06-28T21:39:06.304Z|00021|vconn(ovn_pinctrl0)|DBG|unix:/var/run/openvswitch/br-int.mgmt:
sent (Success): OFPT_PACKET_OUT (OF1.5) (xid=0x413):
in_port=CONTROLLER
actions=set_field:0x3001->reg0,set_field:0xac10016e->reg1,set_field:0xb->reg3,set_field:0x3001->reg4,set_field:0xa->reg7,set_field:0x4->reg9,set_field:0x1->reg10,set_field:0x1->reg11,set_field:0x3->reg12,set_field:0x1->reg14,set_field:0x3->reg15,set_field:0x3->metadata,move:NXM_NX_XXREG0[]->NXM_NX_ND_TARGET[],resubmit(,37)
data_len=86
icmp6,vlan_tci=0x,dl_src=30:51:00:00:00:03,dl_dst=33:33:ff:ff:ff:ff,ipv6_src=fe80::3251:ff:fe00:3,ipv6_dst=ff02::1::,ipv6_label=0x0,nw_tos=0,nw_ecn=0,nw_ttl=255,nw_frag=no,icmp_type=135,icmp_code=0,nd_target=:::::::,nd_sll=30:51:00:00:00:03,nd_tll=00:00:00:00:00:00
icmp6_csum:1877
--

But strangely when this packet leaves the physical interface 'eth2' on
ovn-chassis-1,  the nd_target is wrongly populated

tcpdump on the physical interface (connected to br-ex)
---
17:37:40.289881 30:51:00:00:00:03 > 33:33:ff:ff:ff:ff, ethertype IPv6
(0x86dd), length 86: (hlim 255, next-header ICMPv6 (58) payload
length: 32) fe80::3251:ff:fe00:3 > ff02::1::: [icmp6 sum ok]
ICMP6, neighbor solicitation, length 32, who has 3001:0:ac10:16e::b
  source link-address option (1), length 8 (1): 30:51:00:00:00:03

---

You can see that the nd_target is '3001:0:ac10:16e::b  and not
'3001::b', which is strange.  The inner action of "nd_ns" clearly sets
nd.target = 3001::b.

Can you please verify in your end if that is the case ?  You can
perhaps use ovn-fake-multinode if you can't  reproduce in your setup.

Thanks
Numan




> ---
> v4->v5: rebase
> v4: newly added
>
>  controller/pinctrl.c |  52 +++--
>  lib/actions.c|   4 +-
>  northd/northd.c  |   9 +-
>  tests/ovn-northd.at  |   8 +-
>  tests/ovn.at | 268 

Re: [ovs-dev] [PATCH v3 ovn] northd: Add bfd, static_routes and route_policies I-P nodes.

[Numan Siddique]

On Wed, Jun 5, 2024 at 10:55 AM Lorenzo Bianconi
 wrote:
>
> Introduce bfd, static_routes and route_policies nodes to northd I-P
> engine to track bfd connections and northd static_route/policy_route
> changes.
>
> Reported-at: https://issues.redhat.com/browse/FDP-600
> Signed-off-by: Lorenzo Bianconi 
> ---
> Changes since v2:
> - add incremental processing routines
> - split bfd_consumer node in static_routes and route_policies nodes
> Changes since v1:
> - add incremental processing logic for bfd_consumer node to avoid a full
>   recompute

Hi Lorenzo,

Thanks for the v3.  Please see below for some comments.

This patch is missing the test cases for the I-P handling.  Please see
the existing test cases [1]
in ovn-northd.at and please add test cases accordingly, making sure
that ovn-northd generates
the logical flows  as expected when a change occurs and then after recompute.
Please also check the engine stats.

[1] - https://github.com/ovn-org/ovn/blob/main/tests/ovn-northd.at#L11076

Thanks
Numan

> ---
>  northd/en-lflow.c|  25 +-
>  northd/en-northd.c   | 192 
>  northd/en-northd.h   |  15 +
>  northd/inc-proc-northd.c |  31 +-
>  northd/northd.c  | 648 +++
>  northd/northd.h  |  62 +++-
>  6 files changed, 757 insertions(+), 216 deletions(-)
>
> diff --git a/northd/en-lflow.c b/northd/en-lflow.c
> index c4b927fb8..3dba5034b 100644
> --- a/northd/en-lflow.c
> +++ b/northd/en-lflow.c
> @@ -41,6 +41,11 @@ lflow_get_input_data(struct engine_node *node,
>   struct lflow_input *lflow_input)
>  {
>  struct northd_data *northd_data = engine_get_input_data("northd", node);
> +struct bfd_data *bfd_data = engine_get_input_data("bfd", node);
> +struct static_routes_data *static_routes_data =
> +engine_get_input_data("static_routes", node);
> +struct route_policies_data *route_policies_data =
> +engine_get_input_data("route_policies", node);
>  struct port_group_data *pg_data =
>  engine_get_input_data("port_group", node);
>  struct sync_meters_data *sync_meters_data =
> @@ -50,10 +55,6 @@ lflow_get_input_data(struct engine_node *node,
>  struct ed_type_ls_stateful *ls_stateful_data =
>  engine_get_input_data("ls_stateful", node);
>
> -lflow_input->nbrec_bfd_table =
> -EN_OVSDB_GET(engine_get_input("NB_bfd", node));
> -lflow_input->sbrec_bfd_table =
> -EN_OVSDB_GET(engine_get_input("SB_bfd", node));
>  lflow_input->sbrec_logical_flow_table =
>  EN_OVSDB_GET(engine_get_input("SB_logical_flow", node));
>  lflow_input->sbrec_multicast_group_table =
> @@ -78,7 +79,10 @@ lflow_get_input_data(struct engine_node *node,
>  lflow_input->meter_groups = _meters_data->meter_groups;
>  lflow_input->lb_datapaths_map = _data->lb_datapaths_map;
>  lflow_input->svc_monitor_map = _data->svc_monitor_map;
> -lflow_input->bfd_connections = NULL;
> +lflow_input->bfd_connections = _data->bfd_connections;
> +lflow_input->parsed_routes = _routes_data->parsed_routes;
> +lflow_input->route_tables = _routes_data->route_tables;
> +lflow_input->route_policies = _policies_data->route_policies;
>
>  struct ed_type_global_config *global_config =
>  engine_get_input_data("global_config", node);
> @@ -95,25 +99,14 @@ void en_lflow_run(struct engine_node *node, void *data)
>  struct lflow_input lflow_input;
>  lflow_get_input_data(node, _input);
>
> -struct hmap bfd_connections = HMAP_INITIALIZER(_connections);
> -lflow_input.bfd_connections = _connections;
> -
>  stopwatch_start(BUILD_LFLOWS_STOPWATCH_NAME, time_msec());
>
>  struct lflow_data *lflow_data = data;
>  lflow_table_clear(lflow_data->lflow_table);
>  lflow_reset_northd_refs(_input);
>
> -build_bfd_table(eng_ctx->ovnsb_idl_txn,
> -lflow_input.nbrec_bfd_table,
> -lflow_input.sbrec_bfd_table,
> -lflow_input.lr_ports,
> -_connections);
>  build_lflows(eng_ctx->ovnsb_idl_txn, _input,
>   lflow_data->lflow_table);
> -bfd_cleanup_connections(lflow_input.nbrec_bfd_table,
> -_connections);
> -hmap_destroy(_connections);
>  stopwatch_stop(BUILD_LFLOWS_STOPWATCH_NAME, time_msec());
>
>  engine_set_node_state(node, EN_UPDATED);
> diff --git a/northd/en-northd.c b/northd/en-northd.c
> index 4479b4aff..a4de71ba1 100644
> --- a/northd/en-northd.c
> +++ b/northd/en-northd.c
> @@ -236,6 +236,150 @@ northd_global_config_handler(struct engine_node *node, 
> void *data OVS_UNUSED)
>  return true;
>  }
>
> +bool
> +route_policies_change_handler(struct engine_node *node, void *data)
> +{
> +struct northd_data *northd_data = engine_get_input_data("northd", node);
> +struct route_policies_data *route_policies_data = data;
> +enum engine_node_state state = EN_UNCHANGED;
> +
> 

Re: [ovs-dev] [PATCH v2 ovn] Do not reply on unicast arps for IPv4 targets.

[Numan Siddique]

On Fri, May 24, 2024 at 4:00 AM Vasyl Saienko  wrote:
>
> Reply only if target ethernet address is broadcast, if
> address is specified explicitly do noting to let target
> reply by itself. This technique allows to monitor target
> aliveness with arping.
>
> Closes  #239
>
> Signed-off-by: Vasyl Saienko 

Sorry for the late reviews.

Acked-by: Numan Siddique 

Numan

> ---
>  northd/northd.c | 11 +--
>  northd/ovn-northd.8.xml |  7 ---
>  tests/ovn-northd.at |  4 ++--
>  3 files changed, 15 insertions(+), 7 deletions(-)
>
> diff --git a/northd/northd.c b/northd/northd.c
> index 37f443e70..e80e1885d 100644
> --- a/northd/northd.c
> +++ b/northd/northd.c
> @@ -8832,8 +8832,15 @@ build_lswitch_arp_nd_responder_known_ips(struct 
> ovn_port *op,
>  for (size_t i = 0; i < op->n_lsp_addrs; i++) {
>  for (size_t j = 0; j < op->lsp_addrs[i].n_ipv4_addrs; j++) {
>  ds_clear(match);
> -ds_put_format(match, "arp.tpa == %s && arp.op == 1",
> -op->lsp_addrs[i].ipv4_addrs[j].addr_s);
> +/* NOTE(vsaienko): Do not reply on unicast ARPs, forward
> + * them to the target to have ability to monitor target
> + * aliveness via ARPs.
> +*/
> +ds_put_format(match,
> +"arp.tpa == %s && "
> +"arp.op == 1 && "
> +"eth.dst == ff:ff:ff:ff:ff:ff",
> +op->lsp_addrs[i].ipv4_addrs[j].addr_s);
>  ds_clear(actions);
>  ds_put_format(actions,
>  "eth.dst = eth.src; "
> diff --git a/northd/ovn-northd.8.xml b/northd/ovn-northd.8.xml
> index b14a30285..ffdd67895 100644
> --- a/northd/ovn-northd.8.xml
> +++ b/northd/ovn-northd.8.xml
> @@ -1435,9 +1435,10 @@
>
>
>  
> -  Priority-50 flows that match ARP requests to each known IP address
> -  A of every logical switch port, and respond with ARP
> -  replies directly with corresponding Ethernet address E:
> +  Priority-50 flows that match only broadcast ARP requests to each
> +  known IPv4 address A of every logical switch port, and
> +  respond with ARP replies directly with corresponding Ethernet
> +  address E:
>  
>
>  
> diff --git a/tests/ovn-northd.at b/tests/ovn-northd.at
> index be006fb32..4162196f4 100644
> --- a/tests/ovn-northd.at
> +++ b/tests/ovn-northd.at
> @@ -9283,9 +9283,9 @@ AT_CAPTURE_FILE([S1flows])
>
>  AT_CHECK([grep -e "ls_in_arp_rsp" S1flows | ovn_strip_lflows], [0], [dnl
>table=??(ls_in_arp_rsp  ), priority=0, match=(1), action=(next;)
> -  table=??(ls_in_arp_rsp  ), priority=100  , match=(arp.tpa == 
> 192.168.0.10 && arp.op == 1 && inport == "S1-vm1"), action=(next;)
> +  table=??(ls_in_arp_rsp  ), priority=100  , match=(arp.tpa == 
> 192.168.0.10 && arp.op == 1 && eth.dst == ff:ff:ff:ff:ff:ff && inport == 
> "S1-vm1"), action=(next;)
>table=??(ls_in_arp_rsp  ), priority=100  , match=(nd_ns && ip6.dst == 
> {fd00::10, ff02::1:ff00:10} && nd.target == fd00::10 && inport == "S1-vm1"), 
> action=(next;)
> -  table=??(ls_in_arp_rsp  ), priority=50   , match=(arp.tpa == 
> 192.168.0.10 && arp.op == 1), action=(eth.dst = eth.src; eth.src = 
> 50:54:00:00:00:10; arp.op = 2; /* ARP reply */ arp.tha = arp.sha; arp.sha = 
> 50:54:00:00:00:10; arp.tpa = arp.spa; arp.spa = 192.168.0.10; outport = 
> inport; flags.loopback = 1; output;)
> +  table=??(ls_in_arp_rsp  ), priority=50   , match=(arp.tpa == 
> 192.168.0.10 && arp.op == 1 && eth.dst == ff:ff:ff:ff:ff:ff), action=(eth.dst 
> = eth.src; eth.src = 50:54:00:00:00:10; arp.op = 2; /* ARP reply */ arp.tha = 
> arp.sha; arp.sha = 50:54:00:00:00:10; arp.tpa = arp.spa; arp.spa = 
> 192.168.0.10; outport = inport; flags.loopback = 1; output;)
>table=??(ls_in_arp_rsp  ), priority=50   , match=(nd_ns && ip6.dst == 
> {fd00::10, ff02::1:ff00:10} && nd.target == fd00::10), action=(nd_na { 
> eth.src = 50:54:00:00:00:10; ip6.src = fd00::10; nd.target = fd00::10; nd.tll 
> = 50:54:00:00:00:10; outport = inport; flags.loopback = 1; output; };)
>  ])
>
> --
> 2.43.0
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn branch-23.09] northd: Remove unused ovn_datapath_is_transit_switch().

[Numan Siddique]

On Tue, Jun 18, 2024 at 3:01 PM Dumitru Ceara  wrote:
>
> Fixes: 5f0809be5657 ("Revert "northd: Don't skip transit switch LSP when 
> creating mcast groups."")
> Signed-off-by: Dumitru Ceara 

Acked-by: Numan Siddique 

I think it's better to update the commit message that it is for
branch-23.09 only. wdyt ?

Numan

> ---
>  northd/northd.c | 6 --
>  1 file changed, 6 deletions(-)
>
> diff --git a/northd/northd.c b/northd/northd.c
> index 60f692aff3..2873a9bc48 100644
> --- a/northd/northd.c
> +++ b/northd/northd.c
> @@ -806,12 +806,6 @@ ovn_datapath_is_stale(const struct ovn_datapath *od)
>  return !od->nbr && !od->nbs;
>  }
>
> -static inline bool
> -ovn_datapath_is_transit_switch(const struct ovn_datapath *od)
> -{
> -return od->tunnel_key >= OVN_MIN_DP_KEY_GLOBAL;
> -}
> -
>  static struct ovn_datapath *
>  ovn_datapath_from_sbrec(const struct hmap *ls_datapaths,
>  const struct hmap *lr_datapaths,
> --
> 2.44.0
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn 0/4] Fix inter-AZ IP-multicast traffic in ovn-kubernetes-like deployments.

[Numan Siddique]

On Tue, Jun 18, 2024 at 9:34 AM Dumitru Ceara  wrote:
>
> Out of the patches in the series, the one that introduced the issue is
> PATCH 3/4.  However we need to also revert two other patches that depend
> on it.  PATCH 4/4 is a test to avoid future regressions.
>
> Dumitru Ceara (4):
>   Revert "IC: Tansit switch don't flood mcast traffic to router ports if
> matches igmp group."
>   Revert "ovn-ic: Avoid igmp/mld traffic flooding."
>   Revert "northd: Don't skip transit switch LSP when creating mcast
> groups."
>   tests: ic: Add IP multicast test that simulates the ovn-k8s use case.

Thanks for adding the test patch.  It would be great at some point we
add mutlinode tests (mutlinode.at) for various multicast traffic
scenarios.

For the entire series:

Acked-by: Numan Siddique 

Numan



>
>  controller/pinctrl.c |   2 -
>  include/ovn/logical-fields.h |   3 -
>  lib/logical-fields.c |   4 -
>  northd/northd.c  |  36 ++---
>  northd/northd.h  |   6 -
>  northd/ovn-northd.8.xml  |  14 +-
>  tests/ovn-ic.at  | 252 +--
>  7 files changed, 261 insertions(+), 56 deletions(-)
>
> --
> 2.44.0
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn v2] controller: Store src_mac, src_ip in svc_monitor struct.

[Numan Siddique]

On Wed, May 22, 2024 at 8:34 AM Vladislav Odintsov  wrote:
>
> Again adding forgotten tag:
>
> Reported-at: 
> https://mail.openvswitch.org/pipermail/ovs-dev/2024-April/413198.html
>
> regards,

Thanks for fixing this.  I applied this patch to main and will
backport to other branches once the CI passes
for those branches in my github repo.

Numan

>
> Vladislav Odintsov
>
> On 22.05.2024, 15:19, "Vladislav Odintsov"  wrote:
>
> These structure members are read in pinctrl_handler() in a separare 
> thread.
> This is unsafe: when IDL is re-connected or some IDL objects are freed
> after svc_monitors list with svc_monitor structures, which point to
> sbrec_service_monitor is initialized, sb_svc_mon structure property can
> point to wrong address, which then leads to segmentation fault in
> svc_monitor_send_tcp_health_check__() and
> svc_monitor_send_udp_health_check() on accessing svc_mon->sb_svc_mon.
>
> Imagine situation:
>
> Main ovn-controller thread:
> 1. Connects to SB and fills IDL with DB contents.
> 2. run pinctrl_run() with pinctrl mutex and sync_svc_monitors() as a part
>of it.
> 3. Release mutex.
>
> ...
> 4. Loss of OVNSB connection for any reason (network outage/inactivity 
> probe
>timeout/etc), start new main-loop iteration, re-initialize IDL in
>ovsdb_idl_run() (which probably will destroy previous IDL objects).
> ...
>
> pinctrl thread:
> 5. Awake from poll_block().
> ... run new iteration in its main loop ...
> 6. Acquire mutex lock.
> 7. Run svc_monitors_run(), run svc_monitor_send_tcp_health_check__() or
>svc_monitor_send_udp_health_check(), which try to access IDL objects
>with outdated pointers.
>
> 8. Segmentation fault:
>
> Stack trace of thread 212406:
>__GI_strlen (libc.so.6)
>inet_pton (libc.so.6)
>ip_parse (ovn-controller)
>svc_monitor_send_tcp_health_check__.part.37 (ovn-controller)
>svc_monitor_send_health_check (ovn-controller)
>pinctrl_handler (ovn-controller)
>ovsthread_wrapper (ovn-controller)
>start_thread (libpthread.so.0)
>    __clone (libc.so.6)
>
> This patch removes unsafe access to IDL objects from pinctrl thread.
> New svc_monitor structure members are used to store needed data.
>
> CC: Numan Siddique 
> Acked-by: Ales Musil 
> Fixes: 8be01f4a5329 ("Send service monitor health checks")
> Signed-off-by: Vladislav Odintsov 
>
> ---
> v1 -> v2:
>   - Addressed Ales's comment: replaced ip_parse() & ipv6_parse() with
> ip46_parse().
> ---
>  controller/pinctrl.c | 37 -
>  1 file changed, 16 insertions(+), 21 deletions(-)
>
> diff --git a/controller/pinctrl.c b/controller/pinctrl.c
> index 6a2c3dc68..0178ac6cc 100644
> --- a/controller/pinctrl.c
> +++ b/controller/pinctrl.c
> @@ -7307,6 +7307,9 @@ struct svc_monitor {
>  long long int timestamp;
>  bool is_ip6;
>
> +struct eth_addr src_mac;
> +struct in6_addr src_ip;
> +
>  long long int wait_time;
>  long long int next_send_time;
>
> @@ -7501,6 +7504,9 @@ sync_svc_monitors(struct ovsdb_idl_txn 
> *ovnsb_idl_txn,
>  svc_mon->n_success = 0;
>  svc_mon->n_failures = 0;
>
> +eth_addr_from_string(sb_svc_mon->src_mac, _mon->src_mac);
> +ip46_parse(sb_svc_mon->src_ip, _mon->src_ip);
> +
>  hmap_insert(_monitors_map, _mon->hmap_node, hash);
>  ovs_list_push_back(_monitors, _mon->list_node);
>  changed = true;
> @@ -8259,19 +8265,14 @@ svc_monitor_send_tcp_health_check__(struct rconn 
> *swconn,
>  struct dp_packet packet;
>  dp_packet_use_stub(, packet_stub, sizeof packet_stub);
>
> -struct eth_addr eth_src;
> -eth_addr_from_string(svc_mon->sb_svc_mon->src_mac, _src);
>  if (svc_mon->is_ip6) {
> -struct in6_addr ip6_src;
> -ipv6_parse(svc_mon->sb_svc_mon->src_ip, _src);
> -pinctrl_compose_ipv6(, eth_src, svc_mon->ea,
> - _src, _mon->ip, IPPROTO_TCP,
> +pinctrl_compose_ipv6(, svc_mon->src_mac, svc_mon->ea,
> + _mon->src_ip, _mon->ip, IPPROTO_TCP,
>   63, TCP_HEADER_LEN);
>  } else {
> -ovs_

Re: [ovs-dev] [PATCH ovn 5/5] controller: Handle postponed ports release.

[Numan Siddique]

On Thu, May 30, 2024 at 11:31 AM Numan Siddique  wrote:
>
> On Tue, Apr 23, 2024 at 7:54 AM Xavier Simonart  wrote:
> >
> > Reported-at: 
> > https://mail.openvswitch.org/pipermail/ovs-dev/2023-May/405107.html
> > Suggested-by: Priyankar Jain 
> >
> > Signed-off-by: Xavier Simonart 
> > ---
> >  controller/binding.c | 12 +-
> >  tests/ovn.at | 57 
> >  2 files changed, 68 insertions(+), 1 deletion(-)
> >
> > diff --git a/controller/binding.c b/controller/binding.c
> > index 0bef5dc42..c37066cbe 100644
> > --- a/controller/binding.c
> > +++ b/controller/binding.c
> > @@ -1317,6 +1317,14 @@ lport_maybe_postpone(const char *port_name, long 
> > long int now,
> >  return true;
> >  }
> >
> > +static bool
> > +is_postponed_port(const char *port_name)
> > +{
> > +struct claimed_port *cp =
> > +(struct claimed_port *) sset_find(&_postponed_ports, port_name);
> > +return !!cp;
> > +}
>
> This is wrong.  '_postponed_ports' is an sset and not shash and
> sset_find returns 'struct sset_node'.
>
> You can use sset_contains i.,e
> ----
> static bool
> is_postponed_port(const char *port_name)
> {
> return sset_contains(&_postponed_ports, port_name);
> }
> 
>
>
> With the above addressed:
>
> Acked-by: Numan Siddique 

I applied this patch series to main with the above changes.

Numan

>
> Numan
>
>
> > +
> >  /* Returns false if lport is not claimed due to 'sb_readonly'.
> >   * Returns true otherwise.
> >   */
> > @@ -1491,7 +1499,8 @@ is_binding_lport_this_chassis(struct binding_lport 
> > *b_lport,
> >  {
> >  return (b_lport && b_lport->pb && chassis &&
> >  (b_lport->pb->chassis == chassis
> > - || is_additional_chassis(b_lport->pb, chassis)));
> > + || is_additional_chassis(b_lport->pb, chassis)
> > + || is_postponed_port(b_lport->pb->logical_port)));
> >  }
> >
> >  /* Returns 'true' if the 'lbinding' has binding lports of type 
> > LP_CONTAINER,
> > @@ -1593,6 +1602,7 @@ consider_vif_lport_(const struct sbrec_port_binding 
> > *pb,
> >  }
> >
> >  if (!lbinding_set || !can_bind) {
> > +remove_related_lport(pb, b_ctx_out);
> >  return release_lport(pb, b_ctx_in->chassis_rec,
> >   !b_ctx_in->ovnsb_idl_txn,
> >   b_ctx_out->tracked_dp_bindings,
> > diff --git a/tests/ovn.at b/tests/ovn.at
> > index 74c5bccc0..b0aba2207 100644
> > --- a/tests/ovn.at
> > +++ b/tests/ovn.at
> > @@ -37838,3 +37838,60 @@ OVN_CLEANUP([hv1])
> >
> >  AT_CLEANUP
> >  ])
> > +
> > +OVN_FOR_EACH_NORTHD([
> > +AT_SETUP([Deleting vif while controller fight for port claim])
> > +ovn_start
> > +
> > +ovn-nbctl ls-add ls0
> > +ovn-nbctl lsp-add ls0 lsp0
> > +ovn-nbctl lsp-add ls0 lsp1
> > +
> > +net_add n1
> > +for i in 1 2; do
> > +sim_add hv$i
> > +as hv$i
> > +ovs-vsctl add-br br-phys
> > +ovn_attach n1 br-phys 192.168.0.$i
> > +done
> > +
> > +check ovn-nbctl --wait=hv sync
> > +hv1_uuid=$(ovn-sbctl --bare --columns _uuid list chassis hv1)
> > +hv2_uuid=$(ovn-sbctl --bare --columns _uuid list chassis hv2)
> > +
> > +as hv1 ovs-vsctl -- add-port br-int vif1 -- set Interface vif1 
> > external-ids:iface-id=lsp1
> > +as hv1 ovs-vsctl -- add-port br-int vif -- set Interface vif 
> > external-ids:iface-id=lsp0
> > +wait_for_ports_up
> > +
> > +# Delete vif => store flows w/ only vif1, and no vif
> > +as hv1 ovs-vsctl -- del-port br-int vif
> > +check ovn-nbctl --wait=hv sync
> > +DUMP_FLOWS([hv1], [oflows1])
> > +sleep_controller hv1
> > +as hv2 ovs-vsctl -- add-port br-int vif -- set Interface vif 
> > external-ids:iface-id=lsp0
> > +as hv1 ovs-vsctl -- add-port br-int vif -- set Interface vif 
> > external-ids:iface-id=lsp0
> > +
> > +OVS_WAIT_UNTIL([
> > +chassis=$(ovn-sbctl --bare --columns chassis list port_binding lsp0)
> > +test "$chassis" = $hv2_uuid
> > +])
> > +
> > +sleep_sb
> > +wake_up_controller hv1
> > +sleep_controller hv2
> > +
> > +as hv1 ovs-vsctl -- del-port br-int vif
> > +wake_up_sb
> > +wake_up_controller hv2
> > +
> > +as hv2 ovs-vsctl -- del-port br-int vif
> > +check ovn-nbctl --wait=hv sync
> > +
> > +DUMP_FLOWS([hv1], [oflows2])
> > +
> > +check diff oflows1 oflows2
> > +OVN_CLEANUP([hv1],[hv2])
> > +
> > +AT_CLEANUP
> > +])
> > +
> > --
> > 2.31.1
> >
> > ___
> > dev mailing list
> > d...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> >
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn 0/8] Flaky tests fixes and tests cleanup.

[Numan Siddique]

On Mon, Jun 10, 2024 at 3:04 AM Ales Musil  wrote:
>
> On Tue, Jun 4, 2024 at 3:11 PM Xavier Simonart  wrote:
>
> > Xavier Simonart (8):
> >   tests: Cleanup on_exit commands.
> >   tests: Fixed "lflow cache operations".
> >   tests: Fixed flaky "Logical router IP for NAT".
> >   tests: Fixed flaky "NB_Global and SB_Global I+P".
> >   tests: Fixed multiple flaky tests.
> >   tests: Wait for controller exit before restart.
> >   tests: Fixed flaky "ovn-ic -- AZ register".
> >   tests: Fix flaky "ovn-controller - restart ...".
> >
> >  tests/ofproto-macros.at |  2 +-
> >  tests/ovn-controller.at | 51 ++-
> >  tests/ovn-ic.at |  2 ++
> >  tests/ovn-macros.at |  9 +
> >  tests/ovn-northd.at |  5 +--
> >  tests/ovn.at| 70 -
> >  tests/system-kmod-macros.at |  4 +--
> >  7 files changed, 74 insertions(+), 69 deletions(-)
> >
> > --
> > 2.31.1
> >
> > ___
> > dev mailing list
> > d...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> >
> >
> Looks good to me, thanks.
>
> Acked-by: Ales Musil 

Thanks for fixing the flakes.  I applied all the patches in this
series to main except the patch 6.
Mark has some comments in that patch.

Numan

>
> --
>
> Ales Musil
>
> Senior Software Engineer - OVN Core
>
> Red Hat EMEA 
>
> amu...@redhat.com
> 
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn 6/8] tests: Wait for controller exit before restart.

[Numan Siddique]

On Thu, Jun 6, 2024 at 4:59 PM Mark Michelson  wrote:
>
> Hi Xavier,
>
> This is the only patch in the series for which I have a recommendation.
> The rest all look good to me.
>
> On 6/4/24 09:10, Xavier Simonart wrote:
> > In some rare cases, and despite "recent" changes to wait for cleanup
> > before replying to exit, ovn-controller was still running when trying
> > to restart it.
> >
> > Signed-off-by: Xavier Simonart 
> > ---
> >   tests/ovn-macros.at |  9 +
> >   tests/ovn.at| 17 ++---
> >   2 files changed, 15 insertions(+), 11 deletions(-)
> >
> > diff --git a/tests/ovn-macros.at b/tests/ovn-macros.at
> > index 47ada5c70..71a46db8b 100644
> > --- a/tests/ovn-macros.at
> > +++ b/tests/ovn-macros.at
> > @@ -1107,6 +1107,15 @@ 
> > m4_define([OVN_CHECK_SCAPY_EDNS_CLIENT_SUBNET_SUPPORT],
> >   AT_SKIP_IF([! echo "from scapy.layers.dns import EDNS0ClientSubnet" | 
> > python 2>&1 > /dev/null])
> >   ])
> >
> > +m4_define([OVN_CONTROLLER_EXIT_RESTART],
>
> I think this should just be called "OVN_CONTROLLER_RESTART". The goal is
> to restart ovn-controller, so I think the simpler name makes sense. It's
> true that we are using an "exit" command for ovn-appctl, but that is
> more of an implementation detail than anything else.

Thanks for fixing the flakes.  I applied all the patches in this
series to main except this one.

Numan

>
> > +  [TMPPID=$(cat $1/ovn-controller.pid)
> > +   AT_CHECK([as $1 ovn-appctl -t ovn-controller exit --restart])
> > +   # Make sure ovn-controller stopped so that a future restart will not 
> > fail.
> > +   # Checking debug/status is running is not enough as there might be a 
> > small race condition.
> > +   echo "Waiting for pid $TMPPID"
> > +   OVS_WAIT_WHILE([kill -0 $TMPPID 2>/dev/null])
> > +])
> > +
> >   m4_define([OFTABLE_PHY_TO_LOG], [0])
> >   m4_define([OFTABLE_LOG_INGRESS_PIPELINE], [8])
> >   m4_define([OFTABLE_OUTPUT_LARGE_PKT_DETECT], [37])
> > diff --git a/tests/ovn.at b/tests/ovn.at
> > index 2dd0dfd2e..8fa26c192 100644
> > --- a/tests/ovn.at
> > +++ b/tests/ovn.at
> > @@ -20615,7 +20615,7 @@ echo $expected | ovstest test-ovn expr-to-packets > 
> > expected
> >   OVN_CHECK_PACKETS([hv2/vif1-tx.pcap], [expected])
> >
> >   # Stop ovn-controller on hv2 with --restart flag
> > -as hv2 ovs-appctl -t ovn-controller exit --restart
> > +OVN_CONTROLLER_EXIT_RESTART([hv2])
> >
> >   # Now send the packet again. This time, it should still arrive
> >   OVS_WAIT_UNTIL([as hv1 ovs-appctl -t ovn-controller inject-pkt "$packet"])
> > @@ -29316,7 +29316,7 @@ check test "$hvt2" -gt 0
> >   # Kill ovn-controller on chassis hv3, so that it won't update nb_cfg.
> >   # Then wait for 9 out of 10
> >   sleep 1
> > -check as hv3 ovn-appctl -t ovn-controller exit --restart
> > +OVN_CONTROLLER_EXIT_RESTART([hv3])
> >   wait_for_ports_up
> >   ovn-nbctl --wait=sb sync
> >   wait_row_count Chassis_Private 9 name!=hv3 nb_cfg=2
> > @@ -36252,7 +36252,7 @@ check_tunnel_port hv1 br-int 
> > hv2@192.168.0.2%192.168.0.1
> >   check_tunnel_port hv2 br-int hv1@192.168.0.1%192.168.0.2
> >
> >   # Stop ovn-controller on hv1
> > -check as hv1 ovn-appctl -t ovn-controller exit --restart
> > +OVN_CONTROLLER_EXIT_RESTART([hv1])
> >
> >   # The tunnel should remain intact
> >   check_tunnel_port hv1 br-int hv2@192.168.0.2%192.168.0.1
> > @@ -36281,7 +36281,7 @@ check_tunnel_port hv2 br-int1 
> > hv1@192.168.0.1%192.168.0.2
> >   check grep -q "Clearing old tunnel port \"ovn-hv1-0\" 
> > (hv1@192.168.0.1%192.168.0.2) from bridge \"br-int\"" hv2/ovn-controller.log
> >
> >   # Stop ovn-controller on hv1
> > -check as hv1 ovn-appctl -t ovn-controller exit --restart
> > +OVN_CONTROLLER_EXIT_RESTART([hv1])
> >
> >   # The tunnel should remain intact
> >   check_tunnel_port hv1 br-int1 hv2@192.168.0.2%192.168.0.1
> > @@ -36371,10 +36371,7 @@ prev_id2=$(ovs-vsctl --bare --columns _uuid find 
> > port external_ids:ovn-chassis-i
> >   # The hv2 is running we can remove the override file
> >   rm -f ${OVN_SYSCONFDIR}/system-id-override
> >
> > -check ovn-appctl -t ovn-controller exit --restart
> > -
> > -# Make sure ovn-controller stopped before restarting it
> > -OVS_WAIT_UNTIL([test x$(ovn-appctl -t ovn-controller debug/status) != 
> > "xrunning"])
> > +OVN_CONTROLLER_EXIT_RESTART([hv1])
> >
> >   # for some reason SSL ovsdb configuration overrides CLI, so
> >   # delete ssl config from ovsdb to give CLI arguments priority
> > @@ -37086,9 +37083,7 @@ AT_CHECK([grep -c "NXT_CT_FLUSH_ZONE" 
> > hv1/ovs-vswitchd.log], [0], [dnl
> >   ])
> >
> >   AS_BOX([Check conversion from UUID - restart])
> > -ovn-appctl -t ovn-controller exit --restart
> > -# Make sure ovn-controller stopped before restarting it
> > -OVS_WAIT_UNTIL([test "$(ovn-appctl -t ovn-controller debug/status)" != 
> > "running"])
> > +OVN_CONTROLLER_EXIT_RESTART([hv1])
> >
> >   replace_with_uuid lr0
> >   replace_with_uuid sw0
>
> ___
> dev mailing list
> 

Re: [ovs-dev] [PATCH ovn v3 3/3] Add support for overlay provider networks.

[Numan Siddique]

On Thu, Jun 6, 2024 at 4:11 PM Mark Michelson  wrote:
>
> Hi Numan,
>
> I have only one small comment below.
>
> On 5/21/24 16:17, num...@ovn.org wrote:
> > From: Numan Siddique 
> >
> > It is expected that a provider network logical switch has a localnet logical
> > switch port in order to bridge the overlay traffic to the underlay traffic.
> > There can be some usecases where a overlay logical switch (without
> > a localnet port) can act as a provider network and presently NAT doesn't
> > work as expected.  This patch adds this support.  A new config option
> > "overlay_provider_network" is added to support this feature.
> > This feature gets enabled for a logical switch 'P' if:
> >- The above option is set to true in the Logical_Switch.other_config
> >  column.
> >- The logical switch 'P' doesn't have any localnet ports.
> >- The logical router port of a router 'R' connecting to 'P'
> >  is a gateway router port.
> >- And the logical router 'R' has only one gateway router port.
> >
> > If all the above conditions are met, ovn-northd creates a chassisredirect
> > port for the logical switch port (of type router) connecting to the
> > router 'R'.  For example, if the logical port is named as "P-R" and its
> > peer router port is "R-P", then chassisredirect port cr-P-R is created
> > along with cr-R-P.  Gateway chassis binding the cr-R-P also binds cr-P-R.
> > This ensures that the routing is centralized on this gateway chassis for
> > the traffic coming from switch "P" towards the router or vice versa.
> > This centralization is required in order to support NAT (both SNAT and
> > DNAT).  Distributed NAT (i.e if external_mac and router_port is set) is
> > not supported and instead the router port mac is used for such traffic.
> >
> > Reported-at: https://issues.redhat.com/browse/FDP-364
> > Signed-off-by: Numan Siddique 
> > ---
> >   NEWS  |   2 +
> >   controller/physical.c |   4 +
> >   northd/northd.c   | 239 ++
> >   northd/northd.h   |   1 +
> >   ovn-nb.xml|  27 ++
> >   tests/multinode-macros.at |   2 +-
> >   tests/multinode.at| 177 +
> >   tests/ovn-northd.at   | 520 +-
> >   tests/ovn.at  |   8 +-
> >   9 files changed, 928 insertions(+), 52 deletions(-)
> >
> > diff --git a/NEWS b/NEWS
> > index 81c958f9a0..b501d064f0 100644
> > --- a/NEWS
> > +++ b/NEWS
> > @@ -21,6 +21,8 @@ Post v24.03.0
> >   MAC addresses configured on the LSP with "unknown", are learnt via the
> >   OVN native FDB.
> > - Add support for ovsdb-server `--config-file` option in ovn-ctl.
> > +  - Added Overlay provider network support to a logical switch if
> > +the config "overlay_provider_network" is set to true.
> >
> >   OVN v24.03.0 - 01 Mar 2024
> >   --
> > diff --git a/controller/physical.c b/controller/physical.c
> > index 7ee3086940..625e37e8a7 100644
> > --- a/controller/physical.c
> > +++ b/controller/physical.c
> > @@ -1587,6 +1587,10 @@ consider_port_binding(struct ovsdb_idl_index 
> > *sbrec_port_binding_by_name,
> >   ct_zones);
> >   put_zones_ofpacts(_ids, ofpacts_p);
> >
> > +/* Clear the MFF_INPORT.  Its possible that the same packet may
> > + * go out from the same tunnel inport. */
> > +put_load(ofp_to_u16(OFPP_NONE), MFF_IN_PORT, 0, 16, ofpacts_p);
> > +
> >   /* Resubmit to table 41. */
> >   put_resubmit(OFTABLE_CHECK_LOOPBACK, ofpacts_p);
> >   }
> > diff --git a/northd/northd.c b/northd/northd.c
> > index 6393d688f6..65999d82c4 100644
> > --- a/northd/northd.c
> > +++ b/northd/northd.c
> > @@ -2098,6 +2098,53 @@ parse_lsp_addrs(struct ovn_port *op)
> >   }
> >   }
> >
> > +static struct ovn_port *
> > +create_cr_port(struct ovn_port *op, struct hmap *ports,
> > +   struct ovs_list *both_dbs, struct ovs_list *nb_only)
> > +{
> > +char *redirect_name = ovn_chassis_redirect_name(
> > +op->nbsp ? op->nbsp->name : op->nbrp->name);
> > +
> > +struct ovn_port *crp = ovn_port_find(ports, redirect_name);
> > +if (crp && crp->sb && crp->sb->datapath == op->od->sb) {
> > +ovn_port_set_

Re: [ovs-dev] [PATCH ovn 5/5] controller: Handle postponed ports release.

[Numan Siddique]

On Tue, Apr 23, 2024 at 7:54 AM Xavier Simonart  wrote:
>
> Reported-at: 
> https://mail.openvswitch.org/pipermail/ovs-dev/2023-May/405107.html
> Suggested-by: Priyankar Jain 
>
> Signed-off-by: Xavier Simonart 
> ---
>  controller/binding.c | 12 +-
>  tests/ovn.at | 57 
>  2 files changed, 68 insertions(+), 1 deletion(-)
>
> diff --git a/controller/binding.c b/controller/binding.c
> index 0bef5dc42..c37066cbe 100644
> --- a/controller/binding.c
> +++ b/controller/binding.c
> @@ -1317,6 +1317,14 @@ lport_maybe_postpone(const char *port_name, long long 
> int now,
>  return true;
>  }
>
> +static bool
> +is_postponed_port(const char *port_name)
> +{
> +struct claimed_port *cp =
> +(struct claimed_port *) sset_find(&_postponed_ports, port_name);
> +return !!cp;
> +}

This is wrong.  '_postponed_ports' is an sset and not shash and
sset_find returns 'struct sset_node'.

You can use sset_contains i.,e

static bool
is_postponed_port(const char *port_name)
{
return sset_contains(&_postponed_ports, port_name);
}



With the above addressed:

Acked-by: Numan Siddique 

Numan


> +
>  /* Returns false if lport is not claimed due to 'sb_readonly'.
>   * Returns true otherwise.
>   */
> @@ -1491,7 +1499,8 @@ is_binding_lport_this_chassis(struct binding_lport 
> *b_lport,
>  {
>  return (b_lport && b_lport->pb && chassis &&
>  (b_lport->pb->chassis == chassis
> - || is_additional_chassis(b_lport->pb, chassis)));
> + || is_additional_chassis(b_lport->pb, chassis)
> + || is_postponed_port(b_lport->pb->logical_port)));
>  }
>
>  /* Returns 'true' if the 'lbinding' has binding lports of type LP_CONTAINER,
> @@ -1593,6 +1602,7 @@ consider_vif_lport_(const struct sbrec_port_binding *pb,
>  }
>
>  if (!lbinding_set || !can_bind) {
> +remove_related_lport(pb, b_ctx_out);
>  return release_lport(pb, b_ctx_in->chassis_rec,
>   !b_ctx_in->ovnsb_idl_txn,
>   b_ctx_out->tracked_dp_bindings,
> diff --git a/tests/ovn.at b/tests/ovn.at
> index 74c5bccc0..b0aba2207 100644
> --- a/tests/ovn.at
> +++ b/tests/ovn.at
> @@ -37838,3 +37838,60 @@ OVN_CLEANUP([hv1])
>
>  AT_CLEANUP
>  ])
> +
> +OVN_FOR_EACH_NORTHD([
> +AT_SETUP([Deleting vif while controller fight for port claim])
> +ovn_start
> +
> +ovn-nbctl ls-add ls0
> +ovn-nbctl lsp-add ls0 lsp0
> +ovn-nbctl lsp-add ls0 lsp1
> +
> +net_add n1
> +for i in 1 2; do
> +sim_add hv$i
> +as hv$i
> +ovs-vsctl add-br br-phys
> +ovn_attach n1 br-phys 192.168.0.$i
> +done
> +
> +check ovn-nbctl --wait=hv sync
> +hv1_uuid=$(ovn-sbctl --bare --columns _uuid list chassis hv1)
> +hv2_uuid=$(ovn-sbctl --bare --columns _uuid list chassis hv2)
> +
> +as hv1 ovs-vsctl -- add-port br-int vif1 -- set Interface vif1 
> external-ids:iface-id=lsp1
> +as hv1 ovs-vsctl -- add-port br-int vif -- set Interface vif 
> external-ids:iface-id=lsp0
> +wait_for_ports_up
> +
> +# Delete vif => store flows w/ only vif1, and no vif
> +as hv1 ovs-vsctl -- del-port br-int vif
> +check ovn-nbctl --wait=hv sync
> +DUMP_FLOWS([hv1], [oflows1])
> +sleep_controller hv1
> +as hv2 ovs-vsctl -- add-port br-int vif -- set Interface vif 
> external-ids:iface-id=lsp0
> +as hv1 ovs-vsctl -- add-port br-int vif -- set Interface vif 
> external-ids:iface-id=lsp0
> +
> +OVS_WAIT_UNTIL([
> +chassis=$(ovn-sbctl --bare --columns chassis list port_binding lsp0)
> +test "$chassis" = $hv2_uuid
> +])
> +
> +sleep_sb
> +wake_up_controller hv1
> +sleep_controller hv2
> +
> +as hv1 ovs-vsctl -- del-port br-int vif
> +wake_up_sb
> +wake_up_controller hv2
> +
> +as hv2 ovs-vsctl -- del-port br-int vif
> +check ovn-nbctl --wait=hv sync
> +
> +DUMP_FLOWS([hv1], [oflows2])
> +
> +check diff oflows1 oflows2
> +OVN_CLEANUP([hv1],[hv2])
> +
> +AT_CLEANUP
> +])
> +
> --
> 2.31.1
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn 4/5] controller: Handle postponed ports claims.

[Numan Siddique]

On Tue, Apr 23, 2024 at 7:54 AM Xavier Simonart  wrote:
>
> When a port was claimed by two chassis, both chassis were fighting for the 
> port;
> a claim was postponed if the port was claimed recently.
> However, there were two issues:
> - Not all the flows were properly removed when the remote chassis was claiming
>   the port.
> - A port was not properly released if claim was postponed when the 
> port_binding
>   was deleted.
>
> There were also multiple cases causing ovn-controller to always wake-up
> immediately as a port was not removed from postponed_port list.
> - Changing port type to localport while port claim was postponed.
> - Deleting parent of a container port while parent was postponed.
>
> Signed-off-by: Xavier Simonart 


Acked-by: Numan Siddique 

Numan

> ---
>  controller/binding.c | 29 +++--
>  tests/ovn.at | 10 ++
>  2 files changed, 37 insertions(+), 2 deletions(-)
>
> diff --git a/controller/binding.c b/controller/binding.c
> index 1499ceae1..0bef5dc42 100644
> --- a/controller/binding.c
> +++ b/controller/binding.c
> @@ -1270,6 +1270,18 @@ update_port_additional_encap_if_needed(
>  return true;
>  }
>
> +static bool
> +is_requested_additional_chassis(const struct sbrec_port_binding *pb,
> +  const struct sbrec_chassis *chassis_rec)
> +{
> +for (size_t i = 0; i < pb->n_requested_additional_chassis; i++) {
> +if (pb->requested_additional_chassis[i] == chassis_rec) {
> +return true;
> +}
> +}
> +return false;
> +}
> +
>  bool
>  is_additional_chassis(const struct sbrec_port_binding *pb,
>const struct sbrec_chassis *chassis_rec)
> @@ -1587,6 +1599,15 @@ consider_vif_lport_(const struct sbrec_port_binding 
> *pb,
>   b_ctx_out->if_mgr);
>  }
>  }
> +if (pb->chassis != b_ctx_in->chassis_rec
> +&& !is_requested_additional_chassis(pb, b_ctx_in->chassis_rec)
> +&& if_status_is_port_claimed(b_ctx_out->if_mgr,
> + pb->logical_port)) {
> +update_lport_tracking(pb, b_ctx_out->tracked_dp_bindings, false);
> +if_status_mgr_remove_ovn_installed(b_ctx_out->if_mgr,
> +   b_lport->lbinding->iface->name,
> +   _lport->lbinding->iface->header_.uuid);
> +}
>
>  return true;
>  }
> @@ -1787,7 +1808,8 @@ consider_localport(const struct sbrec_port_binding *pb,
>  struct shash *local_bindings = _ctx_out->lbinding_data->bindings;
>  struct local_binding *lbinding = local_binding_find(local_bindings,
>  pb->logical_port);
> -
> +/* Make sure there is no previous postponed port claim */
> +sset_find_and_delete(b_ctx_out->postponed_ports, pb->logical_port);
>  if (!lbinding) {
>  return true;
>  }
> @@ -2754,11 +2776,14 @@ handle_deleted_vif_lport(const struct 
> sbrec_port_binding *pb,
>   binding_lport_delete(binding_lports, b_lport);
>  }
>
> -if (bound && lbinding && lport_type == LP_VIF) {
> +if ((lbinding && lport_type == LP_VIF) &&
> +(bound || sset_find_and_delete(b_ctx_out->postponed_ports,
> +   pb->logical_port))) {
>  /* We need to release the container/virtual binding lports (if any) 
> if
>   * deleted 'pb' type is LP_VIF. */
>  struct binding_lport *c_lport;
>  LIST_FOR_EACH (c_lport, list_node, >binding_lports) {
> +sset_find_and_delete(b_ctx_out->postponed_ports, c_lport->name);
>  remove_local_lports(c_lport->pb->logical_port, b_ctx_out);
>  if (!release_binding_lport(b_ctx_in->chassis_rec, c_lport,
> !b_ctx_in->ovnsb_idl_txn,
> diff --git a/tests/ovn.at b/tests/ovn.at
> index b68678472..74c5bccc0 100644
> --- a/tests/ovn.at
> +++ b/tests/ovn.at
> @@ -16413,6 +16413,10 @@ ovn_start
>
>  ovn-nbctl ls-add ls0
>  ovn-nbctl lsp-add ls0 lsp0
> +ovn-nbctl lsp-add ls0 lsp1
> +ovn-nbctl lsp-add ls0 lsp2
> +check ovn-nbctl lsp-add ls0 lsp-cont1 lsp0 1
> +
>
>  net_add n1
>  for i in 1 2; do
> @@ -16426,6 +16430,8 @@ for i in 1 2; do
>  as hv$i
>  ovs-vsctl -- add-port br-int vif \
>-- set Interface vif external-ids:iface-id=lsp0
> +ovs-vsctl -- add-port br-int vif$i \
> +  -- set Interfac

Re: [ovs-dev] [PATCH ovn 3/5] controller: Fix deletion of container parent port.

[Numan Siddique]

On Tue, Apr 23, 2024 at 7:54 AM Xavier Simonart  wrote:
>
> Flows were not properly removed when parent port of a container port
> was deleted.
>
> Signed-off-by: Xavier Simonart 

Acked-by: Numan Siddique 

Numan

> ---
>  controller/binding.c  |  1 +
>  controller/physical.c |  3 ++-
>  tests/ovn.at  | 34 ++
>  3 files changed, 37 insertions(+), 1 deletion(-)
>
> diff --git a/controller/binding.c b/controller/binding.c
> index 3b36ed881..1499ceae1 100644
> --- a/controller/binding.c
> +++ b/controller/binding.c
> @@ -2759,6 +2759,7 @@ handle_deleted_vif_lport(const struct 
> sbrec_port_binding *pb,
>   * deleted 'pb' type is LP_VIF. */
>  struct binding_lport *c_lport;
>  LIST_FOR_EACH (c_lport, list_node, >binding_lports) {
> +remove_local_lports(c_lport->pb->logical_port, b_ctx_out);
>  if (!release_binding_lport(b_ctx_in->chassis_rec, c_lport,
> !b_ctx_in->ovnsb_idl_txn,
> b_ctx_out)) {
> diff --git a/controller/physical.c b/controller/physical.c
> index 7ee308694..98f7dbab2 100644
> --- a/controller/physical.c
> +++ b/controller/physical.c
> @@ -1026,7 +1026,8 @@ put_local_common_flows(uint32_t dp_key,
>  put_resubmit(OFTABLE_LOG_TO_PHY, ofpacts_p);
>  put_stack(MFF_IN_PORT, ofpact_put_STACK_POP(ofpacts_p));
>  ofctrl_check_and_add_flow_metered(flow_table, OFTABLE_SAVE_INPORT, 
> 100,
> -  0, , ofpacts_p, hc_uuid,
> +  parent_pb->header_.uuid.parts[0],
> +  , ofpacts_p, 
> >header_.uuid,
>NX_CTLR_NO_METER, NULL, false);
>  }
>  }
> diff --git a/tests/ovn.at b/tests/ovn.at
> index 3c888aaf5..b68678472 100644
> --- a/tests/ovn.at
> +++ b/tests/ovn.at
> @@ -37794,3 +37794,37 @@ OVS_WAIT_FOR_OUTPUT([as hv1 ovs-ofctl dump-flows 
> br-int table=0 |grep priority=1
>  OVN_CLEANUP([hv1])
>  AT_CLEANUP
>  ])
> +
> +OVN_FOR_EACH_NORTHD([
> +AT_SETUP([Delete parent of container port])
> +ovn_start
> +
> +ovn-nbctl ls-add ls0
> +ovn-nbctl lsp-add ls0 lsp0
> +
> +# Add a second logical port, so that deleting lsp0 does not result in 
> deleting
> +# the last port of the datapath.
> +ovn-nbctl lsp-add ls0 lsp1
> +
> +check ovn-nbctl lsp-add ls0 lsp-cont1 lsp0 1
> +
> +net_add n1
> +
> +sim_add hv1
> +as hv1
> +ovs-vsctl add-br br-phys
> +ovn_attach n1 br-phys 192.168.0.1
> +
> +as hv1
> +ovs-vsctl -- add-port br-int vif \
> +  -- set Interface vif external-ids:iface-id=lsp0
> +ovs-vsctl -- add-port br-int vif1 \
> +  -- set Interface vif1 external-ids:iface-id=lsp1
> +
> +check ovn-nbctl --wait=hv lsp-del lsp0
> +CHECK_FLOWS_AFTER_RECOMPUTE([hv1], [hv1])
> +
> +OVN_CLEANUP([hv1])
> +
> +AT_CLEANUP
> +])
> --
> 2.31.1
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn 2/5] controller: Nonvif related lports handling.

[Numan Siddique]

On Tue, Apr 23, 2024 at 7:54 AM Xavier Simonart  wrote:
>
> This patches fixes flows not properly deleted in scenarios similar to:
> foo1 (hv1) - foo - R1 - join - R2 (chassis = hv2) - alice - alice1 (hv2).
>
> When R2 is deleted, alice_R2 changed from l3gateway to patch, and, on hv1,
> alice_R2 was added to related ports.
> When R2 was added back (together with R2-alice and R2-join), alice_R2 changed
> back from patch to l3gateway and alice_R2 remained in related_lports on hv1.
>
> This is now fixed: a l3_gateway port is not a related_port if not for our 
> chassis.
>
> A test case has been modified to highlight the error, but also to
> make the test easier to read (e.g avoid using same name for a port and
> for a switch).
>
> Signed-off-by: Xavier Simonart 

Acked-by: Numan Siddique 

Numan

> ---
>  controller/binding.c | 12 
>  tests/ovn.at | 12 
>  2 files changed, 16 insertions(+), 8 deletions(-)
>
> diff --git a/controller/binding.c b/controller/binding.c
> index c9658cb2a..3b36ed881 100644
> --- a/controller/binding.c
> +++ b/controller/binding.c
> @@ -1824,7 +1824,7 @@ consider_localport(const struct sbrec_port_binding *pb,
>   */
>  static bool
>  consider_nonvif_lport_(const struct sbrec_port_binding *pb,
> -   bool our_chassis,
> +   bool our_chassis, bool is_ha_chassis,
> struct binding_ctx_in *b_ctx_in,
> struct binding_ctx_out *b_ctx_out)
>  {
> @@ -1844,6 +1844,9 @@ consider_nonvif_lport_(const struct sbrec_port_binding 
> *pb,
> b_ctx_out->if_mgr,
> b_ctx_out->postponed_ports);
>  }
> +if (!is_ha_chassis) {
> +remove_related_lport(pb, b_ctx_out);
> +}
>
>  if (pb->chassis == b_ctx_in->chassis_rec
>  || is_additional_chassis(pb, b_ctx_in->chassis_rec)
> @@ -1867,7 +1870,7 @@ consider_l2gw_lport(const struct sbrec_port_binding *pb,
>  bool our_chassis = chassis_id && !strcmp(chassis_id,
>   b_ctx_in->chassis_rec->name);
>
> -return consider_nonvif_lport_(pb, our_chassis, b_ctx_in, b_ctx_out);
> +return consider_nonvif_lport_(pb, our_chassis, false, b_ctx_in, 
> b_ctx_out);
>  }
>
>  static bool
> @@ -1879,7 +1882,7 @@ consider_l3gw_lport(const struct sbrec_port_binding *pb,
>  bool our_chassis = chassis_id && !strcmp(chassis_id,
>   b_ctx_in->chassis_rec->name);
>
> -return consider_nonvif_lport_(pb, our_chassis, b_ctx_in, b_ctx_out);
> +return consider_nonvif_lport_(pb, our_chassis, false, b_ctx_in, 
> b_ctx_out);
>  }
>
>  static void
> @@ -1942,7 +1945,8 @@ consider_ha_lport(const struct sbrec_port_binding *pb,
>  update_related_lport(pb, b_ctx_out);
>  }
>
> -return consider_nonvif_lport_(pb, our_chassis, b_ctx_in, b_ctx_out);
> +return consider_nonvif_lport_(pb, our_chassis, is_ha_chassis, b_ctx_in,
> +  b_ctx_out);
>  }
>
>  static bool
> diff --git a/tests/ovn.at b/tests/ovn.at
> index f974cbb15..3c888aaf5 100644
> --- a/tests/ovn.at
> +++ b/tests/ovn.at
> @@ -7781,9 +7781,9 @@ ovn-nbctl lsp-add foo rp-foo -- set Logical_Switch_Port 
> rp-foo \
>  type=router options:router-port=foo addresses=\"00:00:01:01:02:03\"
>
>  # Connect alice to R2
> -ovn-nbctl lrp-add R2 alice 00:00:02:01:02:03 172.16.1.1/24
> -ovn-nbctl lsp-add alice rp-alice -- set Logical_Switch_Port rp-alice \
> -type=router options:router-port=alice addresses=\"00:00:02:01:02:03\"
> +ovn-nbctl lrp-add R2 R2-alice 00:00:02:01:02:03 172.16.1.1/24
> +ovn-nbctl lsp-add alice alice-R2 -- set Logical_Switch_Port alice-R2 \
> +type=router options:router-port=R2-alice addresses=\"00:00:02:01:02:03\"
>
>  # Connect R1 to join
>  ovn-nbctl lrp-add R1 R1_join 00:00:04:01:02:03 20.0.0.1/24
> @@ -7871,11 +7871,13 @@ echo ""
>  echo $expected > expected
>  OVN_CHECK_PACKETS([hv2/vif1-tx.pcap], [expected])
>
> +CHECK_FLOWS_AFTER_RECOMPUTE([hv1], [hv1])
> +
>  # Delete the router and re-create it. Things should work as before.
>  ovn-nbctl  lr-del R2
>  ovn-nbctl create Logical_Router name=R2 options:chassis="hv2"
>  # Connect alice to R2
> -ovn-nbctl lrp-add R2 alice 00:00:02:01:02:03 172.16.1.1/24
> +ovn-nbctl lrp-add R2 R2-alice 00:00:02:01:02:03 172.16.1.1/24
>  # Connect R2 to join
>  ovn-nbctl lrp-add R2 R2_join 00:00:04:01:02:04 20.0.0.2/24
>
> @@ -7887,6 +7889,8 @@ R2 static_routes @lrt
&

Re: [ovs-dev] [PATCH ovn 1/5] controller: Fix iface-id-ver handling.

[Numan Siddique]

On Tue, Apr 23, 2024 at 7:53 AM Xavier Simonart  wrote:
>
> If iface-id-ver was wrong and modified to a correct value,
> the port was correctly claimed, but the flows were not installed
> by I+P.
>
> Signed-off-by: Xavier Simonart 

Acked-by: Numan Siddique 

Numan

> ---
>  controller/binding.c | 14 ++
>  tests/ovn.at |  2 ++
>  2 files changed, 16 insertions(+)
>
> diff --git a/controller/binding.c b/controller/binding.c
> index 8ac2ce3e2..c9658cb2a 100644
> --- a/controller/binding.c
> +++ b/controller/binding.c
> @@ -757,6 +757,8 @@ update_active_pb_ras_pd(const struct sbrec_port_binding 
> *pb,
>  }
>  }
>
> +static bool is_ext_id_changed(const struct smap *a, const struct smap *b,
> +  const char *key);
>  static struct local_binding *local_binding_create(
>  const char *name, const struct ovsrec_interface *);
>  static void local_binding_add(struct shash *local_bindings,
> @@ -2311,6 +2313,18 @@ consider_iface_claim(const struct ovsrec_interface 
> *iface_rec,
>  return true;
>  }
>
> +/* Check if iface-id-ver just becomes correct */
> +struct smap *external_ids_old =
> +shash_find_data(b_ctx_in->iface_table_external_ids_old,
> +iface_rec->name);
> +
> +if (external_ids_old &&
> +is_ext_id_changed(_rec->external_ids,
> +  external_ids_old,
> +  "iface-id-ver")) {
> +b_ctx_out->local_lports_changed = true;
> +}
> +
>  /* If multiple bindings to the same port, remove the "old" binding.
>   * This ensures that change tracking is correct.
>   */
> diff --git a/tests/ovn.at b/tests/ovn.at
> index e81cd4f45..f974cbb15 100644
> --- a/tests/ovn.at
> +++ b/tests/ovn.at
> @@ -33239,6 +33239,8 @@ check as hv1 ovs-vsctl set interface vif11 
> external_ids:iface-id-ver=foo
>
>  wait_for_ports_up sw0-port1
>
> +CHECK_FLOWS_AFTER_RECOMPUTE([hv1], [hv1])
> +
>  AT_CHECK([as hv1 ovn-appctl -t ovn-controller debug/dump-local-bindings], 
> [0], [dnl
>  Local bindings:
>  name: [[sw0-port1]], OVS interface name : [[vif11]], num binding lports : 
> [[1]]
> --
> 2.31.1
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn v2] northd: Fix the match not being cleared inside the loop.

[Numan Siddique]

On Wed, May 29, 2024 at 5:54 AM Dumitru Ceara  wrote:
>
> On 5/29/24 10:26, Ales Musil wrote:
> > The match wasn't cleared which led to matches being appended together
> > and the ovn-controller failed to parse them.
> >
> > Fixes: 3faadc76ad71 ("northd: Fix pmtud for non routed traffic.")
> > Signed-off-by: Ales Musil 
> > ---
>
> Looks good to me, thanks!
>
> Acked-by: Dumitru Ceara 

Oops. Sorry,  I introduced the bug when I added the for loop before
pushing the patch.

Thanks for fixing it.

Numan

>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v4 ovn] northd: Fix pmtud for non routed traffic.

[Numan Siddique]

On Wed, Apr 24, 2024 at 11:51 AM Lorenzo Bianconi
 wrote:
>
> Similar to what is already implemented for routed e/w traffic,
> introduce pmtud support for e/w traffic between two logical switch ports
> connected to the same logical switch, but running on two different
> hypervisors.
>
> Acked-by: Mark Michelson 
> Reported-at: https://issues.redhat.com/browse/FDP-524
> Reported-at: https://issues.redhat.com/browse/FDP-362
> Signed-off-by: Lorenzo Bianconi 

Thanks for the patch.

I applied this to main with the below changes.


diff --git a/northd/northd.c b/northd/northd.c
index 75a8187e72..495b838fc5 100644
--- a/northd/northd.c
+++ b/northd/northd.c
@@ -11991,20 +11991,18 @@ build_lswitch_icmp_packet_toobig_admin_flows(

 ds_clear(match);
 if (!lsp_is_router(op->nbsp)) {
-if (!op->n_lsp_addrs) {
-return;
+for (size_t i = 0; i < op->n_lsp_addrs; i++) {
+ds_put_format(match,
+  "((ip4 && icmp4.type == 3 && icmp4.code == 4) ||"
+  " (ip6 && icmp6.type == 2 && icmp6.code == 0)) &&"
+  " eth.src == %s && outport == %s &&"
+  " !is_chassis_resident(%s) && flags.tunnel_rx == 1",
+  op->lsp_addrs[i].ea_s, op->json_key,
+  op->json_key);
+ovn_lflow_add(lflows, op->od, S_SWITCH_IN_CHECK_PORT_SEC, 110,
+  ds_cstr(match), "outport <-> inport; next;",
+  op->lflow_ref);
 }
-
-ds_put_format(match,
-  "((ip4 && icmp4.type == 3 && icmp4.code == 4) ||"
-  " (ip6 && icmp6.type == 2 && icmp6.code == 0)) &&"
-  " eth.src == "ETH_ADDR_FMT" && outport == %s &&"
-  " !is_chassis_resident(%s) && flags.tunnel_rx == 1",
-  ETH_ADDR_ARGS(op->lsp_addrs[0].ea), op->json_key,
-  op->json_key);
-ovn_lflow_add(lflows, op->od, S_SWITCH_IN_CHECK_PORT_SEC, 110,
-  ds_cstr(match), "outport <-> inport; next;",
-  op->lflow_ref);
 return;
 }



Numan

> ---
> Changes since v3:
> - fix M_NS_DAEMONIZE macro
> Changes since v2:
> - minor changes
> Changes since v1:
> - move logic in consider_port_binding
> - add more self-test
> - fix typos
> ---
>  controller/lflow.h|   1 +
>  controller/physical.c |  30 +++-
>  northd/northd.c   |  33 ++---
>  northd/ovn-northd.8.xml   |  16 +++--
>  tests/multinode-macros.at |   7 ++
>  tests/multinode.at| 147 +-
>  tests/ovn-controller.at   |  63 
>  tests/ovn-macros.at   |   1 +
>  tests/ovn-northd.at   |  24 +--
>  tests/ovn.at  |   5 +-
>  10 files changed, 304 insertions(+), 23 deletions(-)
>
> diff --git a/controller/lflow.h b/controller/lflow.h
> index 295d004f4..1d20cae35 100644
> --- a/controller/lflow.h
> +++ b/controller/lflow.h
> @@ -94,6 +94,7 @@ struct uuid;
>  #define OFTABLE_ECMP_NH  77
>  #define OFTABLE_CHK_LB_AFFINITY  78
>  #define OFTABLE_MAC_CACHE_USE79
> +#define OFTABLE_CT_ZONE_LOOKUP   80
>
>  struct lflow_ctx_in {
>  struct ovsdb_idl_index *sbrec_multicast_group_by_name_datapath;
> diff --git a/controller/physical.c b/controller/physical.c
> index 7ee308694..25da789f0 100644
> --- a/controller/physical.c
> +++ b/controller/physical.c
> @@ -1498,6 +1498,26 @@ consider_port_binding(struct ovsdb_idl_index 
> *sbrec_port_binding_by_name,
>  return;
>  }
>
> +if (get_lport_type(binding) == LP_VIF) {
> +/* Table 80, priority 100.
> + * ===
> + *
> + * Process ICMP{4,6} error packets too big locally generated from the
> + * kernel in order to lookup proper ct_zone. */
> +struct match match = MATCH_CATCHALL_INITIALIZER;
> +match_set_metadata(, htonll(dp_key));
> +match_set_reg(, MFF_LOG_INPORT - MFF_REG0, port_key);
> +
> +struct zone_ids icmp_zone_ids = get_zone_ids(binding, ct_zones);
> +ofpbuf_clear(ofpacts_p);
> +put_zones_ofpacts(_zone_ids, ofpacts_p);
> +put_resubmit(OFTABLE_LOG_INGRESS_PIPELINE, ofpacts_p);
> +ofctrl_add_flow(flow_table, OFTABLE_CT_ZONE_LOOKUP, 100,
> +binding->header_.uuid.parts[0], ,
> +ofpacts_p, >header_.uuid);
> +ofpbuf_clear(ofpacts_p);
> +}
> +
>  struct match match;
>  if (!strcmp(binding->type, "patch")
>  || (!strcmp(binding->type, "l3gateway")
> @@ -2464,6 +2484,14 @@ physical_run(struct physical_ctx *p_ctx,
>flow_table, );
>  }
>
> +/* Default flow 

Re: [ovs-dev] [PATCH ovn] Do not reply on unicast arps for targets.

[Numan Siddique]

On Mon, May 20, 2024 at 1:47 AM Vasyl Saienko  wrote:
>
> Thanks for feedback Numan.
>
> On Wed, May 15, 2024 at 12:04 AM Numan Siddique  wrote:
>
> > On Mon, May 13, 2024 at 9:00 AM Dumitru Ceara  wrote:
> > >
> > > On 5/4/24 11:38, Vasyl Saienko wrote:
> > > > Hello Numan
> > > >
> > > > Thanks for review and feedback.
> > > >
> > > > On Fri, May 3, 2024 at 7:14 PM Numan Siddique  wrote:
> > > >
> > > >> On Mon, Apr 22, 2024 at 2:54 AM Vasyl Saienko 
> > > >> wrote:
> > > >>>
> > > >>> Reply only if target ethernet address is broadcast, if
> > > >>> address is specified explicitly do noting to let target
> > > >>> reply by itself. This technique allows to monitor target
> > > >>> aliveness with arping.
> > > >>
> > > >> Thanks for the patch.
> > > >>
> > > >> This patch does change the behavior of OVN.  Having ARP responder
> > > >> flows avoids tunnelling the request packet if the destination is on a
> > > >> different compute node.
> > > >> But I don't think its a big deal.
> > > >>
> > > >> You are totally correct that the ARP responder allows limiting ARP
> > > > broadcast traffic between nodes. Normally ARP requests are sent to
> > > > broadcast ff:ff:ff:ff:ff:ff ethernet, as the protocol is designed to
> > > > identify ethernet addresses for known IP addresses. In this case since
> > > > traffic is broadcast it will be flooded among all nodes if ARP
> > responder is
> > > > not applied. At the same time the client may specify the target
> > > > ethernet address as unicast (in this case a broadcast storm will not
> > > > happen, as the destination ethernet address is unicast).
> > > >
> > > > In OpenStack we use unicast ARP requests as a way to monitor VM
> > aliveness
> > > > from remote locations to make sure there are no issues with
> > > > flows/underlying networking infra between nodes. We use ARPs due to
> > several
> > > > reasons:
> > > > 1. This protocol is mandatory and can't be disabled on the target
> > machine
> > > > (which guarantees that the target VM will always reply to ARPs if it is
> > > > alive)
> > > > 2. This protocol is not filtered by firewalls/security groups as it is
> > > > mandatory for network workability
> > > > 3. We can't use upper layers protocols such as ICMP as they will
> > require
> > > > specific firewall rules inside VMs, and we do not control VMs in cloud
> > > > cases, but still need to monitor infrastructure aliveness.
> > > >
> > > > If ARP responder replies to requests with broadcast and unicast target
> > > > ethernet address, we can't use this technique for monitoring, as even
> > if
> > > > target VM is down (not necessary that ovn port is down, the VM may
> > stuck or
> > > > be in kernel panic for example, or datapath between monitoring tool
> > and VM
> > > > is broken) the ARP responder will do reply to our request so we can't
> > > > identify if VM is really accessible or not as we will always got
> > replies
> > > > from local ARP responder. At the same time there is no need to set up
> > ARP
> > > > responder for requests with a unicast ethernet address, as they will
> > not
> > > > generate broadcast storms by design (they are unicasts).
> > > >
> > >
> > > Right, this sounds acceptable to me too.
> > >
> > > >
> > > >> 1.  Accept your patch
> > > >> 2.  Use the NB Global option - "ignore_lsp_down" and set it to false,
> > > >> so that ovn-northd will install the ARP responder flows only if the
> > > >> logical port is up.
> > > >>
> > > > This option will not allow catching a situation when there is an issue
> > in
> > > > datapath between monitoring software and VM located on another node,
> > for
> > > > example  issues with flows or some underlying networking problems.
> > > >
> > > >  Have you considered this approach for your use case ?
> > > >> 3.  Add another global option - "disable_arp_responder" which when set
> > > >> to true, ovn-northd will not install ARP resp

Re: [ovs-dev] [PATCH ovn 0/7] Bump of CI Ubuntu and Fedora versions

[Numan Siddique]

On Thu, May 16, 2024 at 12:01 PM Ales Musil  wrote:
>
> On Thu, May 16, 2024 at 5:57 PM Numan Siddique  wrote:
>
> > On Tue, May 14, 2024 at 4:41 AM Ales Musil  wrote:
> > >
> > > The series is pretty small however it is required for the
> > > bump to Ubuntu 24.04 and Fedora 40. Both have newer GCC and
> > > Clang which brought up some issues that needed to be fixed.
> > >
> > > The series also includes fix for weekly runs to use Fedora
> > > because the cache string wasn't specific enough.
> > >
> > > Ales Musil (7):
> > >   ci: Pin Fedora version for the build-rpm job.
> > >   ovs: Bump the submodule to the tip of branch-3.3.
> > >   ci: Update the Ubuntu container to 24.04.
> > >   tests: Replace wget with curl for failing commands.
> > >   ci: Add missing packages to run Fedora image in GH CI.
> > >   ci: Make sure that we are using proper image.
> > >   ci: Bump the Fedora container to 40.
> >
> > Thanks for the patch series.
> >
> > I applied this patch series to the main.  Before applying I removed
> > "dnf update" from .ci/linux-build.sh  as per
> > the comments in the patch 5.
> >
>
>
> Thank you, would you mind backporting only the first patch to 24.03?

Sure.

Numan

>
> >
> > Thanks
> > Numan
> >
> > >
> > >  .ci/linux-build.sh |  3 +++
> > >  .github/workflows/test.yml |  7 ---
> > >  ovs|  2 +-
> > >  tests/system-ovn.at| 15 +++
> > >  utilities/containers/fedora/Dockerfile |  3 ++-
> > >  utilities/containers/ubuntu/Dockerfile | 11 ++-
> > >  6 files changed, 27 insertions(+), 14 deletions(-)
> > >
> > > --
> > > 2.44.0
> > >
> > > ___
> > > dev mailing list
> > > d...@openvswitch.org
> > > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> > >
> >
> >
> Thanks,
> Ales
> --
>
> Ales Musil
>
> Senior Software Engineer - OVN Core
>
> Red Hat EMEA <https://www.redhat.com>
>
> amu...@redhat.com
> <https://red.ht/sig>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn 5/7] ci: Add missing packages to run Fedora image in GH CI.

[Numan Siddique]

On Tue, May 14, 2024 at 9:46 AM Ales Musil  wrote:
>
> On Tue, May 14, 2024 at 3:19 PM Ilya Maximets  wrote:
>
> > On 5/14/24 10:38, Ales Musil wrote:
> > > There were two things missing for the Fedora builds, 32-bit
> > > version of glibc to allows the -m32 compilation on Fedora
> > > and numactl-devel package.
> > >
> > > Signed-off-by: Ales Musil 
> > > ---
> > >  .ci/linux-build.sh | 3 +++
> > >  utilities/containers/fedora/Dockerfile | 1 +
> > >  2 files changed, 4 insertions(+)
> > >
> > > diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
> > > index 78f17f8bd..12966f532 100755
> > > --- a/.ci/linux-build.sh
> > > +++ b/.ci/linux-build.sh
> > > @@ -83,6 +83,9 @@ function configure_gcc()
> > >  # do it directly because gcc-multilib is not available
> > >  # for arm64
> > >  sudo apt update && sudo apt install -y gcc-multilib
> > > +elif which dnf; then
> > > +# Install equivalent of gcc-multilib for Fedora.
> > > +sudo dnf -y update && sudo dnf -y install glibc-devel.i686
> >
> > dnf always refreshes package cache.  'dnf update' will actually update
> > all the packages to the latest versions.  I'm not sure it is an intended
> > behavior here.
> >
>
> Yeah good point, we shouldn't update the packages just install the missing
> one. So only the install part is needed, I'll wait for other reviews before
> posting v2.

I removed "dnf -u update" and applied this patch series to main.
I thought of applying instead of spinning v2 just for this change.

Numan

>
>
> >
> > >  fi
> > >  fi
> > >  }
> > > diff --git a/utilities/containers/fedora/Dockerfile
> > b/utilities/containers/fedora/Dockerfile
> > > index 9b8386aae..d40a7b31f 100755
> > > --- a/utilities/containers/fedora/Dockerfile
> > > +++ b/utilities/containers/fedora/Dockerfile
> > > @@ -28,6 +28,7 @@ RUN dnf -y update \
> > >  libtool \
> > >  net-tools \
> > >  nmap-ncat \
> > > +numactl-devel \
> > >  openssl \
> > >  openssl-devel \
> > >  procps-ng \
> >
> >
> Thanks,
> Ales
> --
>
> Ales Musil
>
> Senior Software Engineer - OVN Core
>
> Red Hat EMEA 
>
> amu...@redhat.com
> 
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn 0/7] Bump of CI Ubuntu and Fedora versions

[Numan Siddique]

On Tue, May 14, 2024 at 4:41 AM Ales Musil  wrote:
>
> The series is pretty small however it is required for the
> bump to Ubuntu 24.04 and Fedora 40. Both have newer GCC and
> Clang which brought up some issues that needed to be fixed.
>
> The series also includes fix for weekly runs to use Fedora
> because the cache string wasn't specific enough.
>
> Ales Musil (7):
>   ci: Pin Fedora version for the build-rpm job.
>   ovs: Bump the submodule to the tip of branch-3.3.
>   ci: Update the Ubuntu container to 24.04.
>   tests: Replace wget with curl for failing commands.
>   ci: Add missing packages to run Fedora image in GH CI.
>   ci: Make sure that we are using proper image.
>   ci: Bump the Fedora container to 40.

Thanks for the patch series.

I applied this patch series to the main.  Before applying I removed
"dnf update" from .ci/linux-build.sh  as per
the comments in the patch 5.

Thanks
Numan

>
>  .ci/linux-build.sh |  3 +++
>  .github/workflows/test.yml |  7 ---
>  ovs|  2 +-
>  tests/system-ovn.at| 15 +++
>  utilities/containers/fedora/Dockerfile |  3 ++-
>  utilities/containers/ubuntu/Dockerfile | 11 ++-
>  6 files changed, 27 insertions(+), 14 deletions(-)
>
> --
> 2.44.0
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn] controller: Avoid use after free in LB I-P.

[Numan Siddique]

On Mon, May 6, 2024 at 6:37 AM Ales Musil  wrote:
>
> Avoid use after free in scenario when controller received LB deletion
> after the DB was reconnected. The reconnect led to idl clearing up
> the "old" structs, one of them being the LB. However, during recompute
> the struct was referenced when it was already gone.
>
> Clear the whole objdep_mgr instead of going one-by-one during recompute.
>
> ==143949==ERROR: AddressSanitizer: heap-use-after-free
> READ of size 4 at 0x513280d0 thread T0
> 0 0x61c3c9 in lb_data_local_lb_remove controller/ovn-controller.c:2978:5
> 1 0x5fd4df in en_lb_data_run controller/ovn-controller.c:3063:9
> 2 0x6fe0d9 in engine_recompute lib/inc-proc-eng.c:415:5
> 3 0x6fbdc2 in engine_run_node lib/inc-proc-eng.c:477:9
> 4 0x6fbdc2 in engine_run lib/inc-proc-eng.c:528:9
> 5 0x5f39a0 in main controller/ovn-controller.c
>
> Fixes: 8382127186bf ("controller: Store load balancer data in separate node")
> Reported-at: https://issues.redhat.com/browse/FDP-610
> Signed-off-by: Ales Musil 

Thanks.  Applied the patch to main and backported until 23.03

Numan

> ---
>  controller/ovn-controller.c | 20 +--
>  tests/ovn-controller.at | 38 +
>  2 files changed, 48 insertions(+), 10 deletions(-)
>
> diff --git a/controller/ovn-controller.c b/controller/ovn-controller.c
> index 23269af83..65b9ba8e5 100644
> --- a/controller/ovn-controller.c
> +++ b/controller/ovn-controller.c
> @@ -2972,7 +2972,7 @@ lb_data_local_lb_add(struct ed_type_lb_data *lb_data,
>
>  static void
>  lb_data_local_lb_remove(struct ed_type_lb_data *lb_data,
> -struct ovn_controller_lb *lb, bool tracked)
> +struct ovn_controller_lb *lb)
>  {
>  const struct uuid *uuid = >slb->header_.uuid;
>
> @@ -2981,12 +2981,8 @@ lb_data_local_lb_remove(struct ed_type_lb_data 
> *lb_data,
>
>  lb_data_removed_five_tuples_add(lb_data, lb);
>
> -if (tracked) {
> -hmap_insert(_data->old_lbs, >hmap_node, uuid_hash(uuid));
> -uuidset_insert(_data->deleted, uuid);
> -} else {
> -ovn_controller_lb_destroy(lb);
> -}
> +hmap_insert(_data->old_lbs, >hmap_node, uuid_hash(uuid));
> +uuidset_insert(_data->deleted, uuid);
>  }
>
>  static bool
> @@ -3011,7 +3007,7 @@ lb_data_handle_changed_ref(enum objdep_type type, const 
> char *res_name,
>  continue;
>  }
>
> -lb_data_local_lb_remove(lb_data, lb, true);
> +lb_data_local_lb_remove(lb_data, lb);
>
>  const struct sbrec_load_balancer *sbrec_lb =
>  sbrec_load_balancer_table_get_for_uuid(ctx_in->lb_table, uuid);
> @@ -3057,9 +3053,13 @@ en_lb_data_run(struct engine_node *node, void *data)
>  const struct sbrec_load_balancer_table *lb_table =
>  EN_OVSDB_GET(engine_get_input("SB_load_balancer", node));
>
> +objdep_mgr_clear(_data->deps_mgr);
> +
>  struct ovn_controller_lb *lb;
>  HMAP_FOR_EACH_SAFE (lb, hmap_node, _data->local_lbs) {
> -lb_data_local_lb_remove(lb_data, lb, false);
> +hmap_remove(_data->local_lbs, >hmap_node);
> +lb_data_removed_five_tuples_add(lb_data, lb);
> +ovn_controller_lb_destroy(lb);
>  }
>
>  const struct sbrec_load_balancer *sbrec_lb;
> @@ -3097,7 +3097,7 @@ lb_data_sb_load_balancer_handler(struct engine_node 
> *node, void *data)
>  continue;
>  }
>
> -lb_data_local_lb_remove(lb_data, lb, true);
> +lb_data_local_lb_remove(lb_data, lb);
>  }
>
>  if (sbrec_load_balancer_is_deleted(sbrec_lb) ||
> diff --git a/tests/ovn-controller.at b/tests/ovn-controller.at
> index 27cec2aec..cecbc190b 100644
> --- a/tests/ovn-controller.at
> +++ b/tests/ovn-controller.at
> @@ -2973,3 +2973,41 @@ 
> priority=1100,ip,reg15=0x1,metadata=0x1,nw_src=10.0.0.4 
> actions=load:0x1->OXM_OF
>
>  OVN_CLEANUP([hv1])
>  AT_CLEANUP
> +
> +AT_SETUP([ovn-controller - LB remove after disconnect])
> +ovn_start
> +
> +net_add n1
> +sim_add hv1
> +as hv1
> +check ovs-vsctl add-br br-phys
> +ovn_attach n1 br-phys 192.168.0.1
> +check ovs-vsctl -- add-port br-int vif1 -- \
> +set interface vif1 external-ids:iface-id=lsp
> +
> +check ovs-vsctl set Open_vSwitch . 
> external-ids:ovn-remote-probe-interval="5000"
> +
> +check ovn-nbctl ls-add ls
> +check ovn-nbctl lsp-add ls lsp \
> +-- lsp-set-addresses lsp "f0:00:00:00:00:01 172.16.0.10"
> +
> +check ovn-nbctl lb-add lb 192.168.100.100 172.16.0.10
> +check ovn-nbctl ls-lb-add ls lb
> +
> +wait_for_ports_up
> +check ovn-nbctl --wait=hv sync
> +
> +sleep_sb
> +OVS_WAIT_UNTIL([grep -q 'OVNSB commit failed' hv1/ovn-controller.log])
> +
> +sleep_controller hv1
> +wake_up_sb
> +
> +ovn-nbctl lb-del lb
> +
> +wake_up_controller hv1
> +check ovn-nbctl --wait=hv sync
> +
> +OVN_CLEANUP([hv1
> +/no response to inactivity probe after .* seconds, disconnecting/d])
> +AT_CLEANUP
> --
> 2.44.0
>
> 

Re: [ovs-dev] [PATCH ovn] docs: List supported rolling upgrade paths.

[Numan Siddique]

On Fri, May 3, 2024 at 1:43 AM Ales Musil  wrote:
>
> On Fri, Apr 26, 2024 at 10:49 PM Ihar Hrachyshka 
> wrote:
>
> > The wording above is not completely clear without these scenarios
> > listed. A confused reader may incorrectly read it as:
> >
> > ```
> > Only LTS-to-LTS is supported for rolling upgrades.
> > ```
> >
> > which is wrong.
> >
> > Signed-off-by: Ihar Hrachyshka 
> > ---
> >  Documentation/intro/install/ovn-upgrades.rst | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/Documentation/intro/install/ovn-upgrades.rst
> > b/Documentation/intro/install/ovn-upgrades.rst
> > index 1f99a86ec..f3dea07dc 100644
> > --- a/Documentation/intro/install/ovn-upgrades.rst
> > +++ b/Documentation/intro/install/ovn-upgrades.rst
> > @@ -74,6 +74,11 @@ To avoid buildup of complexity and technical debt we
> > limit the span of versions
> >  supported for a rolling upgrade on :ref:`long-term-support` (LTS), and it
> >  should always be possible to upgrade from the previous LTS version to the
> > next.
> >
> > +The following rolling upgrade paths are supported:
> > +
> > +1. LTS to the very next LTS release, or to any non-LTS in between the two.
> > +2. Any non-LTS to the very next LTS release.
> > +
> >  The first LTS version of OVN was 22.03.  If you want to upgrade between
> > other
> >  versions, you can use the `Fail-safe upgrade`_ procedure.
> >
> > --
> > 2.41.0
> >
> > ___
> > dev mailing list
> > d...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> >
> >
> Looks good to me, thanks.
>
> Acked-by: Ales Musil 

Thanks.  Applied to main.

Numan


>
> --
>
> Ales Musil
>
> Senior Software Engineer - OVN Core
>
> Red Hat EMEA 
>
> amu...@redhat.com
> 
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn] docs: Explain nature of ovs dependency.

[Numan Siddique]

On Fri, May 3, 2024 at 1:43 AM Ales Musil  wrote:
>
> On Fri, Apr 26, 2024 at 10:35 PM Ihar Hrachyshka 
> wrote:
>
> > The dependency is during build time, not runtime.
> >
> > Signed-off-by: Ihar Hrachyshka 
> > ---
> >  Documentation/intro/install/ovn-upgrades.rst | 18 --
> >  1 file changed, 12 insertions(+), 6 deletions(-)
> >
> > diff --git a/Documentation/intro/install/ovn-upgrades.rst
> > b/Documentation/intro/install/ovn-upgrades.rst
> > index bb387e2f8..1f99a86ec 100644
> > --- a/Documentation/intro/install/ovn-upgrades.rst
> > +++ b/Documentation/intro/install/ovn-upgrades.rst
> > @@ -40,13 +40,19 @@ Release Notes
> >  You should always check the OVS and OVN release notes (NEWS file) for any
> >  release specific notes on upgrades.
> >
> > -OVS
> > 
> > +Open vSwitch
> > +
> >
> > -OVN depends on and is included with OVS.  It's expected that OVS and OVN
> > are
> > -upgraded together, partly for convenience.  OVN is included in OVS
> > releases
> > -so it's easiest to upgrade them together.  OVN may also make use of new
> > -features of OVS only available in that release.
> > +OVN compiles with a particular version of Open vSwitch.  This is a
> > build-time
> > +dependency.
> > +
> > +In runtime, OVN should be able to work with any reasonably fresh version
> > of
> > +Open vSwitch (not necessarily the version that it was compiled against.)
> > +
> > +OVN may make use of new runtime features of Open vSwitch that are only
> > +available in a particular release. OVN is expected to test for an Open
> > vSwitch
> > +feature presence before using it, and gracefully handle scenarios where
> > Open
> > +vSwitch doesn't support a particular optional feature, yet.
> >
> >  Upgrade procedures
> >  --
> > --
> > 2.41.0
> >
> > ___
> > dev mailing list
> > d...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> >
> >
> Looks good to me, thanks.
>
> Acked-by: Ales Musil 

Thanks.  Applied to main.

Numan

>
> --
>
> Ales Musil
>
> Senior Software Engineer - OVN Core
>
> Red Hat EMEA 
>
> amu...@redhat.com
> 
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn] ovn-ctl: Support for --config-file ovsdb-server option.

[Numan Siddique]

On Fri, May 3, 2024 at 2:05 AM Ales Musil  wrote:
>
> On Tue, Apr 23, 2024 at 6:43 PM Vladislav Odintsov 
> wrote:
>
> > Since OVS 3.3.0 ovsdb-server accepts databases and remotes configuration
> > via JSON text file.  This patch adds support for such option.
> >
> > Signed-off-by: Vladislav Odintsov 

Thanks for the patch.

I applied this with the below changes

-
diff --git a/utilities/ovn-ctl b/utilities/ovn-ctl
index fd1ae12567..a4f410e4f7 100755
--- a/utilities/ovn-ctl
+++ b/utilities/ovn-ctl
@@ -1242,8 +1242,7 @@ File location options:
   --db-sb-relay-sock=SOCKET  OVN_IC_Northbound db socket (default:
$DB_SB_RELAY_SOCK)
   --db-sb-relay-pidfile=FILE OVN_Southbound relay db pidfile
(default: $DB_SB_RELAY_CTRL_PIDFILE)
   --db-sb-relay-ctrl-sock=SOCKET OVN_Southbound relay db control
socket (default: $DB_SB_RELAY_CTRL_SOCK)
-  --db-sb-relay-config-file=FILE OVN_IC_Northbound ovsdb-server
configuration file
- Mutually exclusive with
--db-ic-nb-use-remote-in-db=yes.
+  --db-sb-relay-config-file=FILE OVN_Southbound relay ovsdb-server
configuration file.
   --ovn-sb-relay-db-ssl-key=KEY OVN_Southbound DB relay SSL private key file
   --ovn-sb-relay-db-ssl-cert=CERT OVN_Southbound DB relay SSL certificate file
   --ovn-sb-relay-db-ssl-ca-cert=CERT OVN OVN_Southbound DB relay SSL
CA certificate file
diff --git a/utilities/ovn-ctl.8.xml b/utilities/ovn-ctl.8.xml
index c0fbb0792d..4f21ba4ea3 100644
--- a/utilities/ovn-ctl.8.xml
+++ b/utilities/ovn-ctl.8.xml
@@ -86,6 +86,11 @@
 --db-ic-sb-schema=FILE
 --db-ic-sb-create-insecure-remote=yes|no
 --db-ic-nb-create-insecure-remote=yes|no
+--db-nb-config-file=FILE
+--db-sb-config-file=FILE
+--db-ic-nb-config-file=FILE
+--db-ic-sb-config-file=FILE
+--db-sb-relay-config-file=FILE
 --ovn-controller-ssl-key=KEY
 --ovn-controller-ssl-cert=CERT
 --ovn-controller-ssl-ca-cert=CERT

-


Numan

> > ---
> >  NEWS  |  1 +
> >  utilities/ovn-ctl | 39 +++
> >  2 files changed, 36 insertions(+), 4 deletions(-)
> >
> > diff --git a/NEWS b/NEWS
> > index 9adf6a31c..39ea88d78 100644
> > --- a/NEWS
> > +++ b/NEWS
> > @@ -16,6 +16,7 @@ Post v24.03.0
> >- Remove "ovn-set-local-ip" config option from vswitchd
> >  external-ids, the option is no longer needed as it became effectively
> >  "true" for all scenarios.
> > +  - Add support for ovsdb-server `--config-file` option in ovn-ctl.
> >
> >  OVN v24.03.0 - 01 Mar 2024
> >  --
> > diff --git a/utilities/ovn-ctl b/utilities/ovn-ctl
> > index dae5e22f4..fd1ae1256 100755
> > --- a/utilities/ovn-ctl
> > +++ b/utilities/ovn-ctl
> > @@ -169,6 +169,7 @@ start_ovsdb__() {
> >  local sync_from_port
> >  local file
> >  local schema
> > +local config_file
> >  local logfile
> >  local log
> >  local sock
> > @@ -199,6 +200,7 @@ start_ovsdb__() {
> >  eval sync_from_port=\$DB_${DB}_SYNC_FROM_PORT
> >  eval file=\$DB_${DB}_FILE
> >  eval schema=\$DB_${DB}_SCHEMA
> > +eval config_file=\$DB_${DB}_CONFIG_FILE
> >  eval logfile=\$OVN_${DB}_LOGFILE
> >  eval log=\$OVN_${DB}_LOG
> >  eval sock=\$DB_${DB}_SOCK
> > @@ -281,7 +283,12 @@ $cluster_remote_port
> >
> >  set ovsdb-server
> >  set "$@" $log --log-file=$logfile
> > -set "$@" --remote=punix:$sock --pidfile=$db_pid_file
> > +set "$@" --pidfile=$db_pid_file
> > +if test X"$config_file" == X; then
> > +set "$@" --remote=punix:$sock
> > +else
> > +set "$@" --config-file=$config_file
> > +fi
> >  set "$@" --unixctl=$ctrl_sock
> >
> >  [ "$OVN_USER" != "" ] && set "$@" --user "$OVN_USER"
> > @@ -297,7 +304,7 @@ $cluster_remote_port
> >  set exec "$@"
> >  fi
> >
> > -if test X"$use_remote_in_db" != Xno; then
> > +if test X"$use_remote_in_db" != Xno && test X"$config_file" == X; then
> >  set "$@" --remote=db:$schema_name,$table_name,connections
> >  fi
> >
> > @@ -343,6 +350,11 @@ $cluster_remote_port
> >
> >  local run_ovsdb_in_bg="no"
> >  local process_id=
> > +
> > +if test X$config_file = X; then
> > +set "$@" "$file"
> > +fi
> > +
> >  if test X$detach = Xno && test $mode = cluster && test -z
> > "$cluster_remote_addr" ; then
> >  # When detach is no (for run_nb_ovsdb/run_sb_ovsdb commands)
> >  # we want to run ovsdb-server in background rather than running
> > it in
> > @@ -351,10 +363,10 @@ $cluster_remote_port
> >  # Note: We run only the ovsdb-server in backgroud which created
> > the
> >  # cluster (i.e cluster_remote_addr is not set.).
> >  run_ovsdb_in_bg="yes"
> > -"$@" $file &
> > +"$@" &
> >  process_id=$!
> >  else
> > -start_wrapped_daemon "$wrapper" ovsdb-$db "" "$@" 

Re: [ovs-dev] [PATCH ovn] northd, ic: Fix handling of ovn-appctl resume.

[Numan Siddique]

On Fri, May 3, 2024 at 2:07 AM Ales Musil  wrote:
>
> On Tue, Apr 23, 2024 at 2:44 PM Xavier Simonart  wrote:
>
> > After ovn-appctl resume was issued for northd or ovn-ic, there was no
> > guarantee that northd or ovn-ic were waking up, potentially handling
> > changes received while they were paused..
> > Usually, poll_block would be woken up by POLLHUP, but race conditions could
> > cause this not to happen.
> > ovn-controller is already properly handling the resume.
> >
> > This caused the following tests to fail sporadically:
> > - ovn-ic -- sync ISB status to INB
> > - propagate Port_Binding.up to NB and OVS.
> >
> > Signed-off-by: Xavier Simonart 
> > ---
> >  ic/ovn-ic.c | 2 +-
> >  northd/ovn-northd.c | 1 +
> >  2 files changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/ic/ovn-ic.c b/ic/ovn-ic.c
> > index e947323bf..be23f199d 100644
> > --- a/ic/ovn-ic.c
> > +++ b/ic/ovn-ic.c
> > @@ -2409,7 +2409,7 @@ ovn_ic_resume(struct unixctl_conn *conn, int argc
> > OVS_UNUSED,
> >  {
> >  struct ic_state *state = state_;
> >  state->paused = false;
> > -
> > +poll_immediate_wake();
> >  unixctl_command_reply(conn, NULL);
> >  }
> >
> > diff --git a/northd/ovn-northd.c b/northd/ovn-northd.c
> > index 3a5544b0c..d71114f35 100644
> > --- a/northd/ovn-northd.c
> > +++ b/northd/ovn-northd.c
> > @@ -1107,6 +1107,7 @@ ovn_northd_resume(struct unixctl_conn *conn, int
> > argc OVS_UNUSED,
> >  {
> >  struct northd_state *state = state_;
> >  state->paused = false;
> > +poll_immediate_wake();
> >
> >  unixctl_command_reply(conn, NULL);
> >  }
> > --
> > 2.31.1
> >
> > ___
> > dev mailing list
> > d...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> >
> >
> Looks good to me, thanks.
>
> Acked-by: Ales Musil 

Thanks.  Applied to main and backported until branch-23.03.

Numan

>
> --
>
> Ales Musil
>
> Senior Software Engineer - OVN Core
>
> Red Hat EMEA 
>
> amu...@redhat.com
> 
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn] northd: Add lsp option force_fdb_lookup.

[Numan Siddique]

On Thu, May 9, 2024 at 2:17 PM Numan Siddique  wrote:
>
> On Thu, May 9, 2024 at 5:54 AM Shibir Basak  wrote:
> >
> > Hi team,
> >
> > Could someone please review these changes?
>
> Sorry for the delay.  I'll take a look and come back.

Thanks for the patch.  I applied it to the main with the below changes.

-
diff --git a/AUTHORS.rst b/AUTHORS.rst
index b4e0a2695d..2f5713d8b6 100644
--- a/AUTHORS.rst
+++ b/AUTHORS.rst
@@ -366,6 +366,7 @@ Shan Wei   davids...@tencent.com
 Sharon Krendel thekaf...@gmail.com
 Shashank Ram   r...@vmware.com
 Shashwat Srivastavashashwat.srivast...@tcs.com
+Shibir-basak   shibir.ba...@nutanix.com
 Shih-Hao Lishi...@vmware.com
 Shu Shen   shu.s...@radisys.com
 Simon Horman   ho...@ovn.org
diff --git a/NEWS b/NEWS
index 3b5e93dc9a..9883fd2ae9 100644
--- a/NEWS
+++ b/NEWS
@@ -17,6 +17,9 @@ Post v24.03.0
 external-ids, the option is no longer needed as it became effectively
 "true" for all scenarios.
   - Added DHCPv4 relay support.
+  - A new LSP option "force_fdb_lookup" has been added to ensure the additional
+MAC addresses configured on the LSP with "unknown", are learnt via the
+OVN native FDB.

 OVN v24.03.0 - 01 Mar 2024
 --
diff --git a/northd/ovn-northd.8.xml b/northd/ovn-northd.8.xml
index 2e588e28f6..83cdbdd9f0 100644
--- a/northd/ovn-northd.8.xml
+++ b/northd/ovn-northd.8.xml
@@ -2038,6 +2038,12 @@ output;
   also forwarded to the  MC_UNKNOWN multicast group.
 

+
+  The above flow is not added if the logical switch port is of type
+  VIF, has unknown as one of its address and has the
+  option options:force_fdb_lookup set to true.
+
+
 
   For the Ethernet address on a logical switch port of type
   router, when that logical switch port's

-

Numan

>
> Numan
>
> >
> > Thanks,
> > Shibir Basak
> >
> > > On 24-Apr-2024, at 12:15 PM, Shibir Basak  
> > > wrote:
> > >
> > > This option is applicable only if the lsp is of default 'type'
> > > i.e. type=empty_string (which is a VM (or VIF) interface) and the
> > > lsp also has 'unknown' addresses configured.
> > > If lsp option 'force_fdb_lookup' is set to true, mac addresses
> > > of the lsp (if configured) are not installed in the l2 lookup
> > > table of the Logical Switch pipeline. However, MAC addresses
> > > are learnt using the FDB Table.
> > >
> > > Usecase:
> > > =
> > > This option is required to reduce packet loss when VM is being
> > > migrated across AZs (via VXLAN tunnel). lsp is configured in both
> > > AZs on different logical switches which are sharing the same IP
> > > subnet. If the port has unknown address set along with MAC, IP
> > > then, any packet destined to VM's MAC on destination AZ will get
> > > forwarded locally, which may lead to packet loss during VM migration.
> > >
> > > This option is useful to reduce packet loss during VM migration
> > > by forcing the logical switch to learn MAC using FDB.
> > >
> > > The other way to address this issue is to use pkt_clone_type
> > > option but this causes too much of packet duplication when there
> > > are multiple ports with unknown address in the logical switch.
> > >
> > > Signed-off-by: shibir-basak 
> > > ---
> > > northd/northd.c | 16 
> > > ovn-nb.xml  | 11 +++
> > > tests/ovn-northd.at | 38 ++
> > > 3 files changed, 65 insertions(+)
> > >
> > > diff --git a/northd/northd.c b/northd/northd.c
> > > index 37f443e70..c29396716 100644
> > > --- a/northd/northd.c
> > > +++ b/northd/northd.c
> > > @@ -1380,6 +1380,16 @@ lrport_is_enabled(const struct 
> > > nbrec_logical_router_port *lrport)
> > > return !lrport->enabled || *lrport->enabled;
> > > }
> > >
> > > +static bool
> > > +lsp_force_fdb_lookup(const struct ovn_port *op)
> > > +{
> > > +/* To enable FDB Table lookup on a logical switch port, it has to be
> > > + * of 'type' empty_string and "addresses" must have "unknown".
> > > + */
> > > +return !op->nbsp->t

Re: [ovs-dev] [PATCH ovn] Do not reply on unicast arps for targets.

[Numan Siddique]

On Mon, May 13, 2024 at 9:00 AM Dumitru Ceara  wrote:
>
> On 5/4/24 11:38, Vasyl Saienko wrote:
> > Hello Numan
> >
> > Thanks for review and feedback.
> >
> > On Fri, May 3, 2024 at 7:14 PM Numan Siddique  wrote:
> >
> >> On Mon, Apr 22, 2024 at 2:54 AM Vasyl Saienko 
> >> wrote:
> >>>
> >>> Reply only if target ethernet address is broadcast, if
> >>> address is specified explicitly do noting to let target
> >>> reply by itself. This technique allows to monitor target
> >>> aliveness with arping.
> >>
> >> Thanks for the patch.
> >>
> >> This patch does change the behavior of OVN.  Having ARP responder
> >> flows avoids tunnelling the request packet if the destination is on a
> >> different compute node.
> >> But I don't think its a big deal.
> >>
> >> You are totally correct that the ARP responder allows limiting ARP
> > broadcast traffic between nodes. Normally ARP requests are sent to
> > broadcast ff:ff:ff:ff:ff:ff ethernet, as the protocol is designed to
> > identify ethernet addresses for known IP addresses. In this case since
> > traffic is broadcast it will be flooded among all nodes if ARP responder is
> > not applied. At the same time the client may specify the target
> > ethernet address as unicast (in this case a broadcast storm will not
> > happen, as the destination ethernet address is unicast).
> >
> > In OpenStack we use unicast ARP requests as a way to monitor VM aliveness
> > from remote locations to make sure there are no issues with
> > flows/underlying networking infra between nodes. We use ARPs due to several
> > reasons:
> > 1. This protocol is mandatory and can't be disabled on the target machine
> > (which guarantees that the target VM will always reply to ARPs if it is
> > alive)
> > 2. This protocol is not filtered by firewalls/security groups as it is
> > mandatory for network workability
> > 3. We can't use upper layers protocols such as ICMP as they will require
> > specific firewall rules inside VMs, and we do not control VMs in cloud
> > cases, but still need to monitor infrastructure aliveness.
> >
> > If ARP responder replies to requests with broadcast and unicast target
> > ethernet address, we can't use this technique for monitoring, as even if
> > target VM is down (not necessary that ovn port is down, the VM may stuck or
> > be in kernel panic for example, or datapath between monitoring tool and VM
> > is broken) the ARP responder will do reply to our request so we can't
> > identify if VM is really accessible or not as we will always got replies
> > from local ARP responder. At the same time there is no need to set up ARP
> > responder for requests with a unicast ethernet address, as they will not
> > generate broadcast storms by design (they are unicasts).
> >
>
> Right, this sounds acceptable to me too.
>
> >
> >> 1.  Accept your patch
> >> 2.  Use the NB Global option - "ignore_lsp_down" and set it to false,
> >> so that ovn-northd will install the ARP responder flows only if the
> >> logical port is up.
> >>
> > This option will not allow catching a situation when there is an issue in
> > datapath between monitoring software and VM located on another node, for
> > example  issues with flows or some underlying networking problems.
> >
> >  Have you considered this approach for your use case ?
> >> 3.  Add another global option - "disable_arp_responder" which when set
> >> to true, ovn-northd will not install ARP responder flows.
> >>
> >> Disabling ARP responder for ports completely will allow broadcast storms
> > for ARP requests. Which we would like to avoid, but enable the possibility
> > to monitor infrastructure aliveness.
> >
> >
> >> Given that OpenStack neutron ml2ovs uses ARP responder flows only for
> >> broad cast my preference would be (1).
> >>
> >> I'd like to know other's opinion on this.
> >>
>
> I'd accept the patch too so I'd go for (1).
>
> Regards,
> Dumitru
>
> >> Thanks
> >> Numan
> >>
> >>>
> >>> Closes  #239
> >>>
> >>> Signed-off-by: Vasyl Saienko 
> >>> ---
> >>>  northd/northd.c | 11 +--
> >>>  tests/ovn-northd.at |  4 ++--
> >>>  2 files changed, 11 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/northd/northd.c b/northd/northd.c
> >>> index 37f443e

Re: [ovs-dev] [PATCH ovn v4] controller: Track individual address set constants.

[Numan Siddique]

On Fri, May 10, 2024 at 12:39 PM Han Zhou  wrote:
>
> On Fri, May 10, 2024 at 9:23 AM Numan Siddique  wrote:
> >
> > On Fri, May 10, 2024 at 2:37 AM Han Zhou  wrote:
> > >
> > > On Thu, May 9, 2024 at 10:32 AM Mark Michelson 
> wrote:
> > > >
> > > > On 5/7/24 02:12, Han Zhou wrote:
> > > > >
> > > > >
> > > > > On Mon, May 6, 2024 at 10:37 PM Ales Musil  > > > > <mailto:amu...@redhat.com>> wrote:
> > > > >  >
> > > > >  >
> > > > >  >
> > > > >  > On Mon, May 6, 2024 at 8:41 PM Han Zhou  > > > > <mailto:hz...@ovn.org>> wrote:
> > > > >  >>
> > > > >  >>
> > > > >  >>
> > > > >  >> On Thu, May 2, 2024 at 10:35 PM Ales Musil  > > > > <mailto:amu...@redhat.com>> wrote:
> > > > >  >> >
> > > > >  >> > On Thu, May 2, 2024 at 6:23 PM Han Zhou  > > > > <mailto:hz...@ovn.org>> wrote:
> > > > >  >> > >
> > > > >  >> > >
> > > > >  >> > >
> > > > >  >> > > On Thu, May 2, 2024 at 6:29 AM Ales Musil  > > > > <mailto:amu...@redhat.com>> wrote:
> > > > >  >> > > >
> > > > >  >> > > > Instead of tracking address set per struct
> expr_constant_set
> > > > > track it
> > > > >  >> > > > per individual struct expr_constant. This allows more fine
> > > grained
> > > > >  >> > > > control for I-P processing of address sets in controller.
> It
> > > > > helps with
> > > > >  >> > > > scenarios like matching on two address sets in one
> expression
> > > e.g.
> > > > >  >> > > > "ip4.src == {$as1, $as2}". This allows any addition or
> > > removal of
> > > > >  >> > > > individual adress from the set to be incrementally
> processed
> > > > > instead
> > > > >  >> > > > of reprocessing all the flows.
> > > > >  >> > > >
> > > > >  >> > > > This unfortunately doesn't help with the following flows:
> > > > >  >> > > > "ip4.src == $as1 && ip4.dst == $as2"
> > > > >  >> > > > "ip4.src == $as1 || ip4.dst == $as2"
> > > > >  >> > > >
> > > > >  >> > > > The memory impact should be minimal as there is only
> increase
> > > > > of 8 bytes
> > > > >  >> > > > per the struct expr_constant.
> > > > >  >> > > >
> > > > >  >> > > > Reported-at: https://issues.redhat.com/browse/FDP-509
> > > > > <https://issues.redhat.com/browse/FDP-509>
> > > > >  >> > > > Signed-off-by: Ales Musil  > > > > <mailto:amu...@redhat.com>>
> > > > >  >> > > > ---
> > > > >  >> > > > v4: Rebase on top of current main.
> > > > >  >> > > > Update the "lflow_handle_addr_set_update" comment
> > > > > according to suggestion from Han.
> > > > >  >> > >
> > > > >  >> > > Thanks Ales. I updated the commit message for the same, and
> > > > > applied to main branch.
> > > > >  >> > >
> > > > >  >> > > Regards,
> > > > >  >> > > Han
> > > > >  >> > >
> > > > >  >> > > > v3: Rebase on top of current main.
> > > > >  >> > > > Address comments from Han:
> > > > >  >> > > > - Adjust the comment for
> "lflow_handle_addr_set_update" to
> > > > > include remaning corner cases.
> > > > >  >> > > > - Make sure that the flows are consistent between I-P
> and
> > > > > recompute.
> > > > >  >> > > > v2: Rebase on top of current main.
> > > > >  >> > > > Adjust the comment for I-P optimization.
> > > > >  >> > > > ---
> > > > >  >> > > >  controller/lflow.c

Re: [ovs-dev] [PATCH ovn branch-23.06 2/2] Prepare for 23.06.5.

[Numan Siddique]

On Thu, May 9, 2024 at 3:12 PM Mark Michelson  wrote:
>
> Signed-off-by: Mark Michelson 

Acked-by: Numan Siddique 

Numan

> ---
>  NEWS | 3 +++
>  configure.ac | 2 +-
>  debian/changelog | 6 ++
>  3 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/NEWS b/NEWS
> index e98c2102c..115db073a 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -1,3 +1,6 @@
> +OVN v23.06.5 - xx xxx 
> +--
> +
>  OVN v23.06.4 - 09 May 2024
>  --
>- Bug fixes
> diff --git a/configure.ac b/configure.ac
> index 4dbcf5701..fda6ff4af 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -13,7 +13,7 @@
>  # limitations under the License.
>
>  AC_PREREQ(2.63)
> -AC_INIT(ovn, 23.06.4, b...@openvswitch.org)
> +AC_INIT(ovn, 23.06.5, b...@openvswitch.org)
>  AC_CONFIG_MACRO_DIR([m4])
>  AC_CONFIG_AUX_DIR([build-aux])
>  AC_CONFIG_HEADERS([config.h])
> diff --git a/debian/changelog b/debian/changelog
> index 42a5e69a2..728f23336 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,9 @@
> +OVN (23.06.5-1) unstable; urgency=low
> +   [ OVN team ]
> +   * New upstream version
> +
> + -- OVN team   Thu, 09 May 2024 15:10:42 -0400
> +
>  OVN (23.06.4-1) unstable; urgency=low
> [ OVN team ]
> * New upstream version
> --
> 2.44.0
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn branch-23.06 1/2] Set release date for 23.06.4.

[Numan Siddique]

On Thu, May 9, 2024 at 3:20 PM Mark Michelson  wrote:
>
> Signed-off-by: Mark Michelson 

Acked-by: Numan Siddique 

Numan


> ---
>  NEWS | 3 ++-
>  debian/changelog | 2 +-
>  2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/NEWS b/NEWS
> index a87cfd7ec..e98c2102c 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -1,5 +1,6 @@
> -OVN v23.06.4 - xx xxx 
> +OVN v23.06.4 - 09 May 2024
>  --
> +  - Bug fixes
>
>  OVN v23.06.3 - 12 Mar 2024
>  --
> diff --git a/debian/changelog b/debian/changelog
> index 8cc24162d..42a5e69a2 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -2,7 +2,7 @@ OVN (23.06.4-1) unstable; urgency=low
> [ OVN team ]
> * New upstream version
>
> - -- OVN team   Tue, 12 Mar 2024 08:35:42 -0400
> + -- OVN team   Thu, 09 May 2024 15:10:42 -0400
>
>  OVN (23.06.3-1) unstable; urgency=low
> [ OVN team ]
> --
> 2.44.0
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn branch-23.09 2/2] Prepare for 23.09.5.

[Numan Siddique]

On Thu, May 9, 2024 at 3:11 PM Mark Michelson  wrote:
>
> Signed-off-by: Mark Michelson 

Acked-by: Numan Siddique 

Numan


> ---
>  NEWS | 3 +++
>  configure.ac | 2 +-
>  debian/changelog | 6 ++
>  3 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/NEWS b/NEWS
> index 5c80fa482..472594d16 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -1,3 +1,6 @@
> +OVN v23.09.5 - xx xxx 
> +--
> +
>  OVN v23.09.4 - 09 May 2024
>  --
>- Bug fixes
> diff --git a/configure.ac b/configure.ac
> index c71ade236..4d73bf7b3 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -13,7 +13,7 @@
>  # limitations under the License.
>
>  AC_PREREQ(2.63)
> -AC_INIT(ovn, 23.09.4, b...@openvswitch.org)
> +AC_INIT(ovn, 23.09.5, b...@openvswitch.org)
>  AC_CONFIG_MACRO_DIR([m4])
>  AC_CONFIG_AUX_DIR([build-aux])
>  AC_CONFIG_HEADERS([config.h])
> diff --git a/debian/changelog b/debian/changelog
> index e06f13536..b19d71513 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,9 @@
> +OVN (23.09.5-1) unstable; urgency=low
> +   [ OVN team ]
> +   * New upstream version
> +
> + -- OVN team   Thu, 09 May 2024 15:10:37 -0400
> +
>  OVN (23.09.4-1) unstable; urgency=low
> [ OVN team ]
> * New upstream version
> --
> 2.44.0
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn branch-23.09 1/2] Set release date for 23.09.4.

[Numan Siddique]

On Thu, May 9, 2024 at 3:12 PM Mark Michelson  wrote:
>
> Signed-off-by: Mark Michelson 

Acked-by: Numan Siddique 

Numan

> ---
>  NEWS | 3 ++-
>  debian/changelog | 2 +-
>  2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/NEWS b/NEWS
> index 97e1c41d5..5c80fa482 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -1,5 +1,6 @@
> -OVN v23.09.4 - xx xxx 
> +OVN v23.09.4 - 09 May 2024
>  --
> +  - Bug fixes
>
>  OVN v23.09.3 - 12 Mar 2024
>  --
> diff --git a/debian/changelog b/debian/changelog
> index 4f2fabdd7..e06f13536 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -2,7 +2,7 @@ OVN (23.09.4-1) unstable; urgency=low
> [ OVN team ]
> * New upstream version
>
> - -- OVN team   Tue, 12 Mar 2024 08:35:34 -0400
> + -- OVN team   Thu, 09 May 2024 15:10:37 -0400
>
>  OVN (23.09.3-1) unstable; urgency=low
> [ OVN team ]
> --
> 2.44.0
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn branch-24.03 1/2] Set release date for 24.03.2.

[Numan Siddique]

On Thu, May 9, 2024 at 3:11 PM Mark Michelson  wrote:
>
> Signed-off-by: Mark Michelson 

Acked-by: Numan Siddique 

Numan

> ---
>  NEWS | 3 ++-
>  debian/changelog | 2 +-
>  2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/NEWS b/NEWS
> index ca3562425..4d16d97ff 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -1,5 +1,6 @@
> -OVN v24.03.2 - xx xxx 
> +OVN v24.03.2 - 09 May 2024
>  --
> +  - Bug fixes
>
>  OVN v24.03.1 - 12 Mar 2024
>  --
> diff --git a/debian/changelog b/debian/changelog
> index acf278a15..3025c9a40 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -2,7 +2,7 @@ OVN (24.03.2-1) unstable; urgency=low
> [ OVN team ]
> * New upstream version
>
> - -- OVN team   Tue, 12 Mar 2024 08:34:38 -0400
> + -- OVN team   Thu, 09 May 2024 15:10:30 -0400
>
>  OVN (24.03.1-1) unstable; urgency=low
> [ OVN team ]
> --
> 2.44.0
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn v2] controller: Fix an issue wrt cleanup of stale patch port.

[Numan Siddique]

On Fri, May 3, 2024 at 11:00 AM Numan Siddique  wrote:
>
> On Mon, Apr 22, 2024 at 2:49 AM Priyankar Jain
>  wrote:
> >
> > Issue:
> > Upon updating the network_name option of localnet port from one physical
> > bridge to another, ovn-controller fails to cleanup the peer localnet
> > patch port from the old bridge and ends up creating a duplicate peer
> > localnet patch port which fails in the following ovsdb transaction:
> >
> > ```
> > "Transaction causes multiple rows in \"Interface\" table to have
> > identical values
> > (patch-localnet_a7d47490-8a90-4c4d-8266-2915ad07c185-to-br-int)
> > ```
> >
> > Current workflow:
> > 1. Keep a set of all existing localnet ports on br-int. Let us call this
> >set: existing_ports.
> > 2. For each localnet port in SB:
> >2.1 Create a patch port on br-int. (if it already exists on br-int,
> >do not create but remove the entry from exisitng_ports set).
> >2.2 Create a peer patch port on br-phys-x. (if it already exists on the
> >bridge, do not create but remove the entry from exisitng_ports set).
> > 3. Finally, cleanup all the ports and its peers from exisiting_ports.
> >
> > With the above workflow, upon network_name change of localnet LSP, since
> > ports on br-int does not change, only peer port needs to be move from
> > br-phys-x to br-phys-y, the localnet port is removed from
> > exisiting_ports in #2.1 and its peer never becomes eligible for cleanup.
> >
> > Fix:
> > Include both patch port on br-int and its peer port in the
> > exisiting_ports set as part of #1.
> > This make sures that the peer port is only removed from existing_ports
> > only if it is already present on the correct bridge. (#2.1/#2.2)
> > Otherwise, during the cleanup in #3 it will be considered.
> >
> > Fixes: b600316f252a ("Don't delete patch ports that don't belong to br-int")
> > Signed-off-by: Priyankar Jain 
>
> Acked-by: Numan Siddique 

Applied this patch to main and backported till branch-23.03.  It
doesn't apply cleanly for branch-22.12.

Thanks
Numan

>
> Numan
>
> > ---
> >  controller/patch.c |  32 +++--
> >  tests/ovn.at   | 109 +
> >  2 files changed, 124 insertions(+), 17 deletions(-)
> >
> > diff --git a/controller/patch.c b/controller/patch.c
> > index c1cd5060d..4fed6e375 100644
> > --- a/controller/patch.c
> > +++ b/controller/patch.c
> > @@ -314,6 +314,21 @@ patch_run(struct ovsdb_idl_txn *ovs_idl_txn,
> >  || smap_get(>external_ids, "ovn-l3gateway-port")
> >  || smap_get(>external_ids, "ovn-logical-patch-port")) {
> >  shash_add(_ports, port->name, port);
> > +/* Also add peer ports to the list. */
> > +for (size_t j = 0; j < port->n_interfaces; j++) {
> > +struct ovsrec_interface *p_iface = port->interfaces[j];
> > +if (strcmp(p_iface->type, "patch")) {
> > +continue;
> > +}
> > +const char *peer_name = smap_get(_iface->options, 
> > "peer");
> > +if (peer_name) {
> > +const struct ovsrec_port *peer_port =
> > +get_port(ovsrec_port_by_name, peer_name);
> > +if (peer_port) {
> > +shash_add(_ports, peer_port->name, 
> > peer_port);
> > +}
> > +}
> > +}
> >  }
> >  }
> >
> > @@ -336,23 +351,6 @@ patch_run(struct ovsdb_idl_txn *ovs_idl_txn,
> >   * ovn-controller.  Otherwise it may cause unncessary dataplane
> >   * interruption during restart/upgrade. */
> >  if (!daemon_started_recently()) {
> > -/* delete peer patch port first */
> > -for (size_t i = 0; i < port->n_interfaces; i++) {
> > -struct ovsrec_interface *iface = port->interfaces[i];
> > -if (strcmp(iface->type, "patch")) {
> > -continue;
> > -}
> > -const char *iface_peer = smap_get(>options, "peer");
> > -if (iface_peer) {
> > -const struct ovsrec_port *peer_port =
> > -get_port(ovsrec_port_by_name, iface_peer);
> > -if (peer_port) {
> > -  

Re: [ovs-dev] [PATCH ovn v4] controller: Track individual address set constants.

[Numan Siddique]

On Fri, May 10, 2024 at 2:37 AM Han Zhou  wrote:
>
> On Thu, May 9, 2024 at 10:32 AM Mark Michelson  wrote:
> >
> > On 5/7/24 02:12, Han Zhou wrote:
> > >
> > >
> > > On Mon, May 6, 2024 at 10:37 PM Ales Musil  > > > wrote:
> > >  >
> > >  >
> > >  >
> > >  > On Mon, May 6, 2024 at 8:41 PM Han Zhou  > > > wrote:
> > >  >>
> > >  >>
> > >  >>
> > >  >> On Thu, May 2, 2024 at 10:35 PM Ales Musil  > > > wrote:
> > >  >> >
> > >  >> > On Thu, May 2, 2024 at 6:23 PM Han Zhou  > > > wrote:
> > >  >> > >
> > >  >> > >
> > >  >> > >
> > >  >> > > On Thu, May 2, 2024 at 6:29 AM Ales Musil  > > > wrote:
> > >  >> > > >
> > >  >> > > > Instead of tracking address set per struct expr_constant_set
> > > track it
> > >  >> > > > per individual struct expr_constant. This allows more fine
> grained
> > >  >> > > > control for I-P processing of address sets in controller. It
> > > helps with
> > >  >> > > > scenarios like matching on two address sets in one expression
> e.g.
> > >  >> > > > "ip4.src == {$as1, $as2}". This allows any addition or
> removal of
> > >  >> > > > individual adress from the set to be incrementally processed
> > > instead
> > >  >> > > > of reprocessing all the flows.
> > >  >> > > >
> > >  >> > > > This unfortunately doesn't help with the following flows:
> > >  >> > > > "ip4.src == $as1 && ip4.dst == $as2"
> > >  >> > > > "ip4.src == $as1 || ip4.dst == $as2"
> > >  >> > > >
> > >  >> > > > The memory impact should be minimal as there is only increase
> > > of 8 bytes
> > >  >> > > > per the struct expr_constant.
> > >  >> > > >
> > >  >> > > > Reported-at: https://issues.redhat.com/browse/FDP-509
> > > 
> > >  >> > > > Signed-off-by: Ales Musil  > > >
> > >  >> > > > ---
> > >  >> > > > v4: Rebase on top of current main.
> > >  >> > > > Update the "lflow_handle_addr_set_update" comment
> > > according to suggestion from Han.
> > >  >> > >
> > >  >> > > Thanks Ales. I updated the commit message for the same, and
> > > applied to main branch.
> > >  >> > >
> > >  >> > > Regards,
> > >  >> > > Han
> > >  >> > >
> > >  >> > > > v3: Rebase on top of current main.
> > >  >> > > > Address comments from Han:
> > >  >> > > > - Adjust the comment for "lflow_handle_addr_set_update" to
> > > include remaning corner cases.
> > >  >> > > > - Make sure that the flows are consistent between I-P and
> > > recompute.
> > >  >> > > > v2: Rebase on top of current main.
> > >  >> > > > Adjust the comment for I-P optimization.
> > >  >> > > > ---
> > >  >> > > >  controller/lflow.c  | 11 ++---
> > >  >> > > >  include/ovn/actions.h   |  2 +-
> > >  >> > > >  include/ovn/expr.h  | 46 ++-
> > >  >> > > >  lib/actions.c   | 20 -
> > >  >> > > >  lib/expr.c  | 99
> > > +
> > >  >> > > >  tests/ovn-controller.at  | 79
> > > +---
> > >  >> > > >  6 files changed, 154 insertions(+), 103 deletions(-)
> > >  >> > > >
> > >  >> > > > diff --git a/controller/lflow.c b/controller/lflow.c
> > >  >> > > > index 760ec0b41..1e05665a1 100644
> > >  >> > > > --- a/controller/lflow.c
> > >  >> > > > +++ b/controller/lflow.c
> > >  >> > > > @@ -278,7 +278,7 @@ lflow_handle_changed_flows(struct
> > > lflow_ctx_in *l_ctx_in,
> > >  >> > > >  }
> > >  >> > > >
> > >  >> > > >  static bool
> > >  >> > > > -as_info_from_expr_const(const char *as_name, const union
> > > expr_constant *c,
> > >  >> > > > +as_info_from_expr_const(const char *as_name, const struct
> > > expr_constant *c,
> > >  >> > > >  struct addrset_info *as_info)
> > >  >> > > >  {
> > >  >> > > >  as_info->name = as_name;
> > >  >> > > > @@ -644,14 +644,11 @@ as_update_can_be_handled(const char
> > > *as_name, struct addr_set_diff *as_diff,
> > >  >> > > >   *generated.
> > >  >> > > >   *
> > >  >> > > >   *  - The sub expression of the address set is combined
> > > with other sub-
> > >  >> > > > - *expressions/constants, usually because of
> > > disjunctions between
> > >  >> > > > - *sub-expressions/constants, e.g.:
> > >  >> > > > + *expressions/constants on different fields, e.g.:
> > >  >> > > >   *
> > >  >> > > >   *  ip.src == $as1 || ip.dst == $as2
> > >  >> > > > - *  ip.src == {$as1, $as2}
> > >  >> > > > - *  ip.src == {$as1, ip1}
> > >  >> > > >   *
> > >  >> > > > - *All these could have been split into separate
> lflows.
> > >  >> > > > + *This could have been split into separate lflows.
> > >  >> > > >   *
> > >  >> > > >   *  - Conjunctions overlapping between lflows, which can
> > > be caused by
> > >  >> > > >   *overlapping address sets or same address set used
> > > by multiple lflows
> > 

Re: [ovs-dev] [PATCH ovn 2/2 branch-24.03] northd, controller: Handle tunnel_key change consistently.

[Numan Siddique]

On Thu, May 9, 2024 at 3:36 AM Ales Musil  wrote:
>
> Currently the tunnel_key change for either LS/LR/LSP/LRP wasn't
> consistent. That would lead to a situations when some old would still
> be present, breaking the connection especially for already existing
> FDBs and MAC bindings.
>
> Make sure the FDB entries are up to date by removing them from DB
> when there is a tunnel_key change as those entries have only tunnel_key
> refrences (dp_key, port_key).
>
> MAC bindings have references to the datapath and port name, instead of
> removing those entries do recompute in the controller when we detect
> tunnel_key change. This can be costly at scale, however the tunnel_key
> is not expected to change constantly, in most cases it shouldn't change
> at all.
>
> Fixes: b337750e45be ("northd: Incremental processing of VIF changes in 
> 'northd' node.")
> Fixes: 425f699e2b20 ("controller: fixed potential segfault when changing 
> tunnel_key and deleting ls.")
> Reported-at: https://issues.redhat.com/browse/FDP-393
> Acked-by: Mark Michelson 
> Signed-off-by: Ales Musil 
> Signed-off-by: Numan Siddique 
> (cherry picked from commit ddf051cbc6af24c303bf88970750e5c5fe285400)

Thanks.  Applied both the patches to branch-24.03.

Numan

> ---
>  controller/binding.c| 13 --
>  controller/ovn-controller.c | 27 +++
>  northd/northd.c |  7 +
>  tests/ovn.at| 52 +
>  4 files changed, 79 insertions(+), 20 deletions(-)
>
> diff --git a/controller/binding.c b/controller/binding.c
> index 8ac2ce3e2..0712d7030 100644
> --- a/controller/binding.c
> +++ b/controller/binding.c
> @@ -3126,8 +3126,17 @@ delete_done:
>  update_ld_peers(pb, b_ctx_out->local_datapaths);
>  }
>
> -handled = handle_updated_port(b_ctx_in, b_ctx_out, pb);
> -if (!handled) {
> +if (!handle_updated_port(b_ctx_in, b_ctx_out, pb)) {
> +handled = false;
> +break;
> +}
> +
> +if (!sbrec_port_binding_is_new(pb) &&
> +sbrec_port_binding_is_updated(pb,
> +  SBREC_PORT_BINDING_COL_TUNNEL_KEY) 
> &&
> +get_local_datapath(b_ctx_out->local_datapaths,
> +   pb->datapath->tunnel_key)) {
> +handled = false;
>  break;
>  }
>  }
> diff --git a/controller/ovn-controller.c b/controller/ovn-controller.c
> index a40712e53..113d3e05c 100644
> --- a/controller/ovn-controller.c
> +++ b/controller/ovn-controller.c
> @@ -1893,7 +1893,6 @@ runtime_data_sb_datapath_binding_handler(struct 
> engine_node *node OVS_UNUSED,
>  engine_get_input("SB_datapath_binding", node));
>  const struct sbrec_datapath_binding *dp;
>  struct ed_type_runtime_data *rt_data = data;
> -struct local_datapath *ld;
>
>  SBREC_DATAPATH_BINDING_TABLE_FOR_EACH_TRACKED (dp, dp_table) {
>  if (sbrec_datapath_binding_is_deleted(dp)) {
> @@ -1901,27 +1900,19 @@ runtime_data_sb_datapath_binding_handler(struct 
> engine_node *node OVS_UNUSED,
> dp->tunnel_key)) {
>  return false;
>  }
> +
> +}
> +
> +if (sbrec_datapath_binding_is_updated(
> +dp, SBREC_DATAPATH_BINDING_COL_TUNNEL_KEY) &&
> +!sbrec_datapath_binding_is_new(dp)) {
>  /* If the tunnel key got updated, get_local_datapath will not 
> find
>   * the ld. Use get_local_datapath_no_hash which does not
>   * rely on the hash.
>   */
> -if (sbrec_datapath_binding_is_updated(
> -dp, SBREC_DATAPATH_BINDING_COL_TUNNEL_KEY)) {
> -if (get_local_datapath_no_hash(_data->local_datapaths,
> -   dp->tunnel_key)) {
> -return false;
> -}
> -}
> -} else if (sbrec_datapath_binding_is_updated(
> -dp, SBREC_DATAPATH_BINDING_COL_TUNNEL_KEY)
> -   && !sbrec_datapath_binding_is_new(dp)) {
> -/* If the tunnel key is updated, remove the entry (with a wrong
> - * hash) from the map. It will be (properly) added back later.
> - */
> -if ((ld = get_local_datapath_no_hash(_data->local_datapaths,
> - dp->tunnel_key))) {
> -hmap_remove(_data->local_datapaths, >hmap_node);
> -local_datapath_d

Re: [ovs-dev] [PATCH ovn] docs: Typo. Remove duplicated "to".

[Numan Siddique]

On Wed, May 8, 2024 at 1:38 PM Igor Zhukov  wrote:
>
> I came across a new patch recently: 
> https://patchwork.ozlabs.org/project/ovn/patch/20240423095006.24429-1-martin.kal...@canonical.com/
> After that, I searched the OVN source code for instances of "to to" and 
> discovered two more occurrences of the same typo.

Thanks.  Applied to main.

Numan

>
> Signed-off-by: Igor Zhukov 
> ---
>  MAINTAINERS.rst| 2 +-
>  controller/if-status.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/MAINTAINERS.rst b/MAINTAINERS.rst
> index 624aebb9d..f72c8b5ed 100644
> --- a/MAINTAINERS.rst
> +++ b/MAINTAINERS.rst
> @@ -26,7 +26,7 @@ Committers
>  ==
>
>  OVN committers are the people who have been granted access to push
> -changes to to the OVN git repository.
> +changes to the OVN git repository.
>
>  The responsibilities of an OVN committer are documented here:
>  |responsibilities|.
> diff --git a/controller/if-status.c b/controller/if-status.c
> index 6e8aa1f7e..9a7488057 100644
> --- a/controller/if-status.c
> +++ b/controller/if-status.c
> @@ -582,7 +582,7 @@ if_status_mgr_update(struct if_status_mgr *mgr,
>  if (!sb_readonly) {
>  HMAPX_FOR_EACH_SAFE (node, >ifaces_per_state[OIF_CLAIMED]) {
>  struct ovs_iface *iface = node->data;
> -/* No need to to update pb->chassis as already done
> +/* No need to update pb->chassis as already done
>   * in if_status_handle_claims or if_status_mgr_claim_iface
>   */
>  if (iface->is_vif) {
> --
> 2.43.0.windows.1
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn] Documentation: change link from ovs to ovn in the "Submitted-at" example.

[Numan Siddique]

On Wed, May 8, 2024 at 11:46 AM Igor Zhukov  wrote:
>
> It's a mega nitpick, but I observed that the example URL in the 
> "Submitted-at" points to the OVS repository instead of OVN.
>
> Signed-off-by: Igor Zhukov 

Thanks.  Applied to main.

Numan

> ---
>  Documentation/internals/contributing/submitting-patches.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/internals/contributing/submitting-patches.rst 
> b/Documentation/internals/contributing/submitting-patches.rst
> index aef8bcd70..c82e49124 100644
> --- a/Documentation/internals/contributing/submitting-patches.rst
> +++ b/Documentation/internals/contributing/submitting-patches.rst
> @@ -278,7 +278,7 @@ Examples of common tags follow.
>
>::
>
> -  Submitted-at: https://github.com/openvswitch/ovs/pull/92
> +  Submitted-at: https://github.com/ovn-org/ovn/pull/138
>
>  ``VMware-BZ: #1234567``
>
> --
> 2.43.0.windows.1
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn] northd: Add lsp option force_fdb_lookup.

[Numan Siddique]

On Thu, May 9, 2024 at 5:54 AM Shibir Basak  wrote:
>
> Hi team,
>
> Could someone please review these changes?

Sorry for the delay.  I'll take a look and come back.

Numan

>
> Thanks,
> Shibir Basak
>
> > On 24-Apr-2024, at 12:15 PM, Shibir Basak  wrote:
> >
> > This option is applicable only if the lsp is of default 'type'
> > i.e. type=empty_string (which is a VM (or VIF) interface) and the
> > lsp also has 'unknown' addresses configured.
> > If lsp option 'force_fdb_lookup' is set to true, mac addresses
> > of the lsp (if configured) are not installed in the l2 lookup
> > table of the Logical Switch pipeline. However, MAC addresses
> > are learnt using the FDB Table.
> >
> > Usecase:
> > =
> > This option is required to reduce packet loss when VM is being
> > migrated across AZs (via VXLAN tunnel). lsp is configured in both
> > AZs on different logical switches which are sharing the same IP
> > subnet. If the port has unknown address set along with MAC, IP
> > then, any packet destined to VM's MAC on destination AZ will get
> > forwarded locally, which may lead to packet loss during VM migration.
> >
> > This option is useful to reduce packet loss during VM migration
> > by forcing the logical switch to learn MAC using FDB.
> >
> > The other way to address this issue is to use pkt_clone_type
> > option but this causes too much of packet duplication when there
> > are multiple ports with unknown address in the logical switch.
> >
> > Signed-off-by: shibir-basak 
> > ---
> > northd/northd.c | 16 
> > ovn-nb.xml  | 11 +++
> > tests/ovn-northd.at | 38 ++
> > 3 files changed, 65 insertions(+)
> >
> > diff --git a/northd/northd.c b/northd/northd.c
> > index 37f443e70..c29396716 100644
> > --- a/northd/northd.c
> > +++ b/northd/northd.c
> > @@ -1380,6 +1380,16 @@ lrport_is_enabled(const struct 
> > nbrec_logical_router_port *lrport)
> > return !lrport->enabled || *lrport->enabled;
> > }
> >
> > +static bool
> > +lsp_force_fdb_lookup(const struct ovn_port *op)
> > +{
> > +/* To enable FDB Table lookup on a logical switch port, it has to be
> > + * of 'type' empty_string and "addresses" must have "unknown".
> > + */
> > +return !op->nbsp->type[0] && op->has_unknown &&
> > +smap_get_bool(>nbsp->options, "force_fdb_lookup", false);
> > +}
> > +
> > static struct ovn_port *
> > ovn_port_get_peer(const struct hmap *lr_ports, struct ovn_port *op)
> > {
> > @@ -9479,6 +9489,12 @@ build_lswitch_ip_unicast_lookup(struct ovn_port *op,
> >
> > if (ovs_scan(op->nbsp->addresses[i],
> > ETH_ADDR_SCAN_FMT, ETH_ADDR_SCAN_ARGS(mac))) {
> > +/* Skip adding flows related to the MAC address
> > + * as force FDB Lookup is enabled on the lsp.
> > + */
> > +if (lsp_force_fdb_lookup(op)) {
> > +continue;
> > +}
> > ds_clear(match);
> > ds_put_format(match, "eth.dst == "ETH_ADDR_FMT,
> >   ETH_ADDR_ARGS(mac));
> > diff --git a/ovn-nb.xml b/ovn-nb.xml
> > index b652046a7..4724d0537 100644
> > --- a/ovn-nb.xml
> > +++ b/ovn-nb.xml
> > @@ -1262,6 +1262,17 @@
> >   
> > 
> >
> > + > +type='{"type": "boolean"}'>
> > +  This option is supported only if the Logical Switch Port is of
> > +  default  (i.e. type set to empty_string) and 
> > also
> > +   column contains unknown.
> > +  If set to true, MAC addresses (if configured)
> > +  are not installed in the l2 lookup table but the MAC addresses 
> > are
> > +  learnt and stored in the FDB table.
> > +  The default value is false.
> > +
> > +
> >  > type='{"type": "string", "enum": ["set", ["mc_unknown"]]}'>
> >   If set to mc_unknown, packets going to this VIF get cloned to all
> > diff --git a/tests/ovn-northd.at b/tests/ovn-northd.at
> > index be006fb32..82e7a6574 100644
> > --- a/tests/ovn-northd.at
> > +++ b/tests/ovn-northd.at
> > @@ -6886,6 +6886,44 @@ AT_CLEANUP
> > ])
> >
> >
> > +OVN_FOR_EACH_NORTHD_NO_HV([
> > +AT_SETUP([check options: force_fdb_lookup for LSP])
> > +ovn_start NORTHD_TYPE
> > +ovn-nbctl ls-add S1
> > +ovn-nbctl --wait=sb lsp-add S1 S1-vm1
> > +ovn-nbctl --wait=sb lsp-add S1 S1-localnet
> > +ovn-nbctl --wait=sb lsp-set-addresses S1-vm1 "50:54:00:00:00:01 
> > 192.168.0.1" unknown
> > +ovn-nbctl --wait=sb lsp-set-type S1-localnet localnet
> > +
> > +#Verify the flows before setting force_fdb_lookup option
> > +ovn-sbctl dump-flows S1 > S1flows
> > +AT_CAPTURE_FILE([S1flows])
> > +
> > +AT_CHECK([grep -e "ls_in_l2_lkup.*S1-vm1" S1flows | ovn_strip_lflows], 
> > [0], [dnl
> > +  table=??(ls_in_l2_lkup  ), priority=50   , match=(eth.dst == 
> > 50:54:00:00:00:01), action=(outport = "S1-vm1"; output;)
> > +])
> > +
> > +#Set the force_fdb_lookup option and verify the flows

Re: [ovs-dev] [PATCH ovn] northd: Add documentation for is_cr_port() and is_l3dgw_port().

[Numan Siddique]

On Tue, May 7, 2024 at 5:57 PM  wrote:
>
> From: Numan Siddique 
>
> Although these util functions are correct in their implementation,
> they are confusing to the reader.  Add proper documentation
> and make the is_l3dgw_port() more clearer by checking if the
> gateway chassis or ha chassis group is set or not.
>
> Signed-off-by: Numan Siddique 

This patch is now part of the series here -
https://patchwork.ozlabs.org/project/ovn/list/?series=406203=*

Thanks
Numan

> ---
>  northd/northd.c | 22 +-
>  1 file changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/northd/northd.c b/northd/northd.c
> index 0cabda7ea0..d1afc52c4a 100644
> --- a/northd/northd.c
> +++ b/northd/northd.c
> @@ -1077,12 +1077,32 @@ struct ovn_port_routable_addresses {
>
>  static bool lsp_can_be_inc_processed(const struct nbrec_logical_switch_port 
> *);
>
> +/* This function returns true if 'op' is a gateway router port.
> + * False otherwise.
> + * For 'op' to be a gateway router port.
> + *  1. op->nbrp->gateway_chassis or op->nbrp->ha_chassis_group should
> + * be configured.
> + *  2. op->cr_port should not be NULL.  If op->nbrp->gateway_chassis or
> + * op->nbrp->ha_chassis_group is set by the user, northd WILL create
> + * a chassis resident port in the SB port binding.
> + * See join_logical_ports().
> + */
>  static bool
>  is_l3dgw_port(const struct ovn_port *op)
>  {
> -return op->cr_port;
> +return op->cr_port && op->nbrp &&
> +   (op->nbrp->n_gateway_chassis || op->nbrp->ha_chassis_group);
>  }
>
> +/* This function returns true if 'op' is a chassis resident
> + * derived port. False otherwise.
> + * There are 2 ways to check if 'op' is chassis resident port.
> + *  1. op->sb->type is "chassisresident"
> + *  2. op->l3dgw_port is not NULL.  If op->l3dgw_port is set,
> + * it means 'op' is derived from the gateway port (op->l3dgw_port).
> + *
> + * This function uses the (2) method as it doesn't involve strcmp().
> + */
>  static bool
>  is_cr_port(const struct ovn_port *op)
>  {
> --
> 2.44.0
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn v1 2/2] Add support for overlay provider networks.

[Numan Siddique]

On Wed, Apr 24, 2024 at 7:46 PM Numan Siddique  wrote:
>
> On Wed, Apr 24, 2024 at 5:14 PM Mark Michelson  wrote:
> >
> > Hi Numan,
> >
> > I haven't done a full review of this yet, but I figured I'd give some
> > initial feedback from what I had looked at.
> >
> > At a high level, this is missing documentation in ovn-nb.xml for the new
> > "overlay_provider_network" option. There should also be a NEWS entry for
> > the new functionality.
> >
>
> Thanks for the comments.   Yes.  I missed adding them.  I'll address it in v2.
>
> >
> >
> > See below for a couple more notes.
> >
> > On 4/23/24 12:43, num...@ovn.org wrote:
> > > From: Numan Siddique 
> > >
> > > It is expected that a provider network logical switch has a localnet 
> > > logical
> > > switch port in order to bridge the overlay traffic to the underlay 
> > > traffic.
> > > There can be some usecases where a overlay logical switch (without
> > > a localnet port) can act as a provider network and presently NAT doesn't
> > > work as expected.  This patch adds this support.  A new config option
> > > "overlay_provider_network" is added to support this feature.
> > > This feature gets enabled for a logical switch 'P' if:
> > >- The above option is set to true in the Logical_Switch.other_config
> > >  column.
> > >- The logical switch 'P' doesn't have any localnet ports.
> > >- The logical router port of a router 'R' connecting to 'P'
> > >  is a gateway router port.
> > >- And the logical router 'R' has only one gateway router port.
> > >
> > > If all the above conditions are met, ovn-northd creates a chassisredirect
> > > port for the logical switch port (of type router) connecting to the
> > > router 'R'.  For example, if the logical port is named as "P-R" and its
> > > peer router port is "R-P", then chassisredirect port cr-P-R is created
> > > along with cr-R-P.  Gateway chassis binding the cr-R-P also binds cr-P-R.
> > > This ensures that the routing is centralized on this gateway chassis for
> > > the traffic coming from switch "P" towards the router or vice versa.
> > > This centralization is required in order to support NAT (both SNAT and
> > > DNAT).  Distributed NAT (i.e if external_mac and router_port is set) is
> > > not supported and instead the router port mac is used for such traffic.
> > >
> > > Reported-at: https://issues.redhat.com/browse/FDP-364
> > > Signed-off-by: Numan Siddique 
> > > ---
> > >   controller/physical.c |   4 +
> > >   northd/northd.c   | 226 +
> > >   northd/northd.h   |   1 +
> > >   tests/multinode-macros.at |   2 +-
> > >   tests/multinode.at| 177 +
> > >   tests/ovn-northd.at   | 520 +-
> > >   tests/ovn.at  |   8 +-
> > >   7 files changed, 886 insertions(+), 52 deletions(-)
> > >
> > > diff --git a/controller/physical.c b/controller/physical.c
> > > index 7ee3086940..625e37e8a7 100644
> > > --- a/controller/physical.c
> > > +++ b/controller/physical.c
> > > @@ -1587,6 +1587,10 @@ consider_port_binding(struct ovsdb_idl_index 
> > > *sbrec_port_binding_by_name,
> > >   ct_zones);
> > >   put_zones_ofpacts(_ids, ofpacts_p);
> > >
> > > +/* Clear the MFF_INPORT.  Its possible that the same packet 
> > > may
> > > + * go out from the same tunnel inport. */
> > > +put_load(ofp_to_u16(OFPP_NONE), MFF_IN_PORT, 0, 16, 
> > > ofpacts_p);
> > > +
> > >   /* Resubmit to table 41. */
> > >   put_resubmit(OFTABLE_CHECK_LOOPBACK, ofpacts_p);
> > >   }
> > > diff --git a/northd/northd.c b/northd/northd.c
> > > index ead54235c8..1942f9f7a1 100644
> > > --- a/northd/northd.c
> > > +++ b/northd/northd.c
> > > @@ -2063,6 +2063,35 @@ parse_lsp_addrs(struct ovn_port *op)
> > >   }
> > >   }
> > >
> > > +static struct ovn_port *
> > > +create_cr_port(struct ovn_port *op, struct hmap *ports)
> > > +{
> > > +char *redirect_name = ovn_chassis_redirect_name(
> > > +op->nbsp ? op->nbsp->name : op->nbrp->name);
> > > +
> > > + 

Re: [ovs-dev] [PATCH ovn v1 2/2] Add support for overlay provider networks.

[Numan Siddique]

On Wed, May 8, 2024 at 2:12 PM Mark Michelson  wrote:
>
> Hi Numan,
>
> If you were waiting no further comments, I've now reviewed the full
> patch and have no comments beyond what I initially gave.

Thanks.  I'll submit v2 with the changes.  Please check out this patch
- 
https://patchwork.ozlabs.org/project/ovn/patch/20240507215713.902148-1-num...@ovn.org/
which improves documentation for is_cr_port() and is_gw_port()

Thanks
Numan


>
> On 4/23/24 12:43, num...@ovn.org wrote:
> > From: Numan Siddique 
> >
> > It is expected that a provider network logical switch has a localnet logical
> > switch port in order to bridge the overlay traffic to the underlay traffic.
> > There can be some usecases where a overlay logical switch (without
> > a localnet port) can act as a provider network and presently NAT doesn't
> > work as expected.  This patch adds this support.  A new config option
> > "overlay_provider_network" is added to support this feature.
> > This feature gets enabled for a logical switch 'P' if:
> >- The above option is set to true in the Logical_Switch.other_config
> >  column.
> >- The logical switch 'P' doesn't have any localnet ports.
> >- The logical router port of a router 'R' connecting to 'P'
> >  is a gateway router port.
> >- And the logical router 'R' has only one gateway router port.
> >
> > If all the above conditions are met, ovn-northd creates a chassisredirect
> > port for the logical switch port (of type router) connecting to the
> > router 'R'.  For example, if the logical port is named as "P-R" and its
> > peer router port is "R-P", then chassisredirect port cr-P-R is created
> > along with cr-R-P.  Gateway chassis binding the cr-R-P also binds cr-P-R.
> > This ensures that the routing is centralized on this gateway chassis for
> > the traffic coming from switch "P" towards the router or vice versa.
> > This centralization is required in order to support NAT (both SNAT and
> > DNAT).  Distributed NAT (i.e if external_mac and router_port is set) is
> > not supported and instead the router port mac is used for such traffic.
> >
> > Reported-at: https://issues.redhat.com/browse/FDP-364
> > Signed-off-by: Numan Siddique 
> > ---
> >   controller/physical.c |   4 +
> >   northd/northd.c   | 226 +
> >   northd/northd.h   |   1 +
> >   tests/multinode-macros.at |   2 +-
> >   tests/multinode.at| 177 +
> >   tests/ovn-northd.at   | 520 +-
> >   tests/ovn.at  |   8 +-
> >   7 files changed, 886 insertions(+), 52 deletions(-)
> >
> > diff --git a/controller/physical.c b/controller/physical.c
> > index 7ee3086940..625e37e8a7 100644
> > --- a/controller/physical.c
> > +++ b/controller/physical.c
> > @@ -1587,6 +1587,10 @@ consider_port_binding(struct ovsdb_idl_index 
> > *sbrec_port_binding_by_name,
> >   ct_zones);
> >   put_zones_ofpacts(_ids, ofpacts_p);
> >
> > +/* Clear the MFF_INPORT.  Its possible that the same packet may
> > + * go out from the same tunnel inport. */
> > +put_load(ofp_to_u16(OFPP_NONE), MFF_IN_PORT, 0, 16, ofpacts_p);
> > +
> >   /* Resubmit to table 41. */
> >   put_resubmit(OFTABLE_CHECK_LOOPBACK, ofpacts_p);
> >   }
> > diff --git a/northd/northd.c b/northd/northd.c
> > index ead54235c8..1942f9f7a1 100644
> > --- a/northd/northd.c
> > +++ b/northd/northd.c
> > @@ -2063,6 +2063,35 @@ parse_lsp_addrs(struct ovn_port *op)
> >   }
> >   }
> >
> > +static struct ovn_port *
> > +create_cr_port(struct ovn_port *op, struct hmap *ports)
> > +{
> > +char *redirect_name = ovn_chassis_redirect_name(
> > +op->nbsp ? op->nbsp->name : op->nbrp->name);
> > +
> > +struct ovn_datapath *od = op->od;
> > +struct ovn_port *crp = ovn_port_find(ports, redirect_name);
> > +if (!(crp && crp->sb && crp->sb->datapath == od->sb)) {
> > +crp = ovn_port_create(ports, redirect_name,
> > +  op->nbsp, op->nbrp, NULL);
> > +}
> > +
> > +crp->l3dgw_port = op;
> > +op->cr_port = crp;
> > +crp->od = od;
> > +free(redirect_name);
> > +
> > +/* Add to l3dgw_ports in od, for later use during flow creation. */
> > +if (od->n_l3

Re: [ovs-dev] [PATCH ovn v4] controller: Track individual address set constants.

[Numan Siddique]

On Tue, May 7, 2024 at 2:13 AM Han Zhou  wrote:
>
> On Mon, May 6, 2024 at 10:37 PM Ales Musil  wrote:
> >
> >
> >
> > On Mon, May 6, 2024 at 8:41 PM Han Zhou  wrote:
> >>
> >>
> >>
> >> On Thu, May 2, 2024 at 10:35 PM Ales Musil  wrote:
> >> >
> >> > On Thu, May 2, 2024 at 6:23 PM Han Zhou  wrote:
> >> > >
> >> > >
> >> > >
> >> > > On Thu, May 2, 2024 at 6:29 AM Ales Musil  wrote:
> >> > > >
> >> > > > Instead of tracking address set per struct expr_constant_set track
> it
> >> > > > per individual struct expr_constant. This allows more fine grained
> >> > > > control for I-P processing of address sets in controller. It helps
> with
> >> > > > scenarios like matching on two address sets in one expression e.g.
> >> > > > "ip4.src == {$as1, $as2}". This allows any addition or removal of
> >> > > > individual adress from the set to be incrementally processed
> instead
> >> > > > of reprocessing all the flows.
> >> > > >
> >> > > > This unfortunately doesn't help with the following flows:
> >> > > > "ip4.src == $as1 && ip4.dst == $as2"
> >> > > > "ip4.src == $as1 || ip4.dst == $as2"
> >> > > >
> >> > > > The memory impact should be minimal as there is only increase of 8
> bytes
> >> > > > per the struct expr_constant.
> >> > > >
> >> > > > Reported-at: https://issues.redhat.com/browse/FDP-509
> >> > > > Signed-off-by: Ales Musil 
> >> > > > ---
> >> > > > v4: Rebase on top of current main.
> >> > > > Update the "lflow_handle_addr_set_update" comment according to
> suggestion from Han.
> >> > >
> >> > > Thanks Ales. I updated the commit message for the same, and applied
> to main branch.
> >> > >
> >> > > Regards,
> >> > > Han
> >> > >
> >> > > > v3: Rebase on top of current main.
> >> > > > Address comments from Han:
> >> > > > - Adjust the comment for "lflow_handle_addr_set_update" to
> include remaning corner cases.
> >> > > > - Make sure that the flows are consistent between I-P and
> recompute.
> >> > > > v2: Rebase on top of current main.
> >> > > > Adjust the comment for I-P optimization.
> >> > > > ---
> >> > > >  controller/lflow.c  | 11 ++---
> >> > > >  include/ovn/actions.h   |  2 +-
> >> > > >  include/ovn/expr.h  | 46 ++-
> >> > > >  lib/actions.c   | 20 -
> >> > > >  lib/expr.c  | 99
> +
> >> > > >  tests/ovn-controller.at | 79 +---
> >> > > >  6 files changed, 154 insertions(+), 103 deletions(-)
> >> > > >
> >> > > > diff --git a/controller/lflow.c b/controller/lflow.c
> >> > > > index 760ec0b41..1e05665a1 100644
> >> > > > --- a/controller/lflow.c
> >> > > > +++ b/controller/lflow.c
> >> > > > @@ -278,7 +278,7 @@ lflow_handle_changed_flows(struct lflow_ctx_in
> *l_ctx_in,
> >> > > >  }
> >> > > >
> >> > > >  static bool
> >> > > > -as_info_from_expr_const(const char *as_name, const union
> expr_constant *c,
> >> > > > +as_info_from_expr_const(const char *as_name, const struct
> expr_constant *c,
> >> > > >  struct addrset_info *as_info)
> >> > > >  {
> >> > > >  as_info->name = as_name;
> >> > > > @@ -644,14 +644,11 @@ as_update_can_be_handled(const char
> *as_name, struct addr_set_diff *as_diff,
> >> > > >   *generated.
> >> > > >   *
> >> > > >   *  - The sub expression of the address set is combined with
> other sub-
> >> > > > - *expressions/constants, usually because of disjunctions
> between
> >> > > > - *sub-expressions/constants, e.g.:
> >> > > > + *expressions/constants on different fields, e.g.:
> >> > > >   *
> >> > > >   *  ip.src == $as1 || ip.dst == $as2
> >> > > > - *  ip.src == {$as1, $as2}
> >> > > > - *  ip.src == {$as1, ip1}
> >> > > >   *
> >> > > > - *All these could have been split into separate lflows.
> >> > > > + *This could have been split into separate lflows.
> >> > > >   *
> >> > > >   *  - Conjunctions overlapping between lflows, which can be
> caused by
> >> > > >   *overlapping address sets or same address set used by
> multiple lflows
> >> > > > @@ -714,7 +711,7 @@ lflow_handle_addr_set_update(const char
> *as_name,
> >> > > >  if (as_diff->deleted) {
> >> > > >  struct addrset_info as_info;
> >> > > >  for (size_t i = 0; i < as_diff->deleted->n_values;
> i++) {
> >> > > > -union expr_constant *c =
> _diff->deleted->values[i];
> >> > > > +struct expr_constant *c =
> _diff->deleted->values[i];
> >> > > >  if (!as_info_from_expr_const(as_name, c,
> _info)) {
> >> > > >  continue;
> >> > > >  }
> >> > > > diff --git a/include/ovn/actions.h b/include/ovn/actions.h
> >> > > > index ae0864fdd..88cf4de79 100644
> >> > > > --- a/include/ovn/actions.h
> >> > > > +++ b/include/ovn/actions.h
> >> > > > @@ -241,7 +241,7 @@ struct ovnact_next {
> >> > > >  struct ovnact_load {
> >> > > >  struct ovnact 

Re: [ovs-dev] [PATCH ovn v2 0/4] Mac cache handling refactor

[Numan Siddique]

On Tue, May 7, 2024 at 12:51 PM Ales Musil  wrote:
>
> On Tue, May 7, 2024 at 6:49 PM Numan Siddique  wrote:
>
> > On Tue, May 7, 2024 at 2:25 AM Ales Musil  wrote:
> > >
> > > There were two modules in controller mac_cache and mac-learn, both of
> > > them did very similar thing with pretty big overlap. The goal of the
> > > series is to consolidate and merge both of those modules into single
> > > one. That will reduce the duplication and should make it easier for
> > > future updates to MAC binding, FDB or packet buffering functionality.
> > >
> > > There is also fix to properly handle tunnel_key change for LSP, LRP,
> > > LR and LS. This was inconsistent and could lead to wrong flows being
> > > still present even after the tunnel key change. This is not a huge
> > > issue because the tunnel_key is rarelyt changed during runtime.
> > >
> > > Ales Musil (4):
> > >   northd, controller: Handle tunnel_key change consistently.
> > >   controller: Rename mac_cache to to mac-cache.
> > >   controller: Merge the mac-cache and mac-learn.
> > >   controller: Use datapath key for the mac cache thresholds.
> >
> > Thanks.  I applied the series to the main branch.
> > Do we need a backport ?  If so,  I'm inclined to backport the first
> > patch only as it fixes the issue.
> > Let me know your thoughts.
> >
>
> That's correct, only the first patch should be backported.
The backport doesn't apply cleanly to branch-24.03.  Can you please
submit the backport patch for branch-24.03.

Thanks
Numan

>
>
> >
> > Numan
> >
> >
> > >
> > >  controller/automake.mk  |   6 +-
> > >  controller/binding.c|  13 +-
> > >  controller/mac-cache.c  | 745 
> > >  controller/mac-cache.h  | 210 ++
> > >  controller/mac-learn.c  | 482 ---
> > >  controller/mac-learn.h  | 145 ---
> > >  controller/mac_cache.c  | 547 --
> > >  controller/mac_cache.h  | 124 --
> > >  controller/ovn-controller.c | 214 +++
> > >  controller/pinctrl.c| 165 
> > >  controller/statctrl.c   |   7 +-
> > >  controller/statctrl.h   |   2 +-
> > >  northd/northd.c |   7 +
> > >  tests/ovn.at|  56 ++-
> > >  14 files changed, 1253 insertions(+), 1470 deletions(-)
> > >  create mode 100644 controller/mac-cache.c
> > >  create mode 100644 controller/mac-cache.h
> > >  delete mode 100644 controller/mac-learn.c
> > >  delete mode 100644 controller/mac-learn.h
> > >  delete mode 100644 controller/mac_cache.c
> > >  delete mode 100644 controller/mac_cache.h
> > >
> > > --
> > > 2.44.0
> > >
> > > ___
> > > dev mailing list
> > > d...@openvswitch.org
> > > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> > >
> >
> >
> Thanks,
> Ales
>
> --
>
> Ales Musil
>
> Senior Software Engineer - OVN Core
>
> Red Hat EMEA <https://www.redhat.com>
>
> amu...@redhat.com
> <https://red.ht/sig>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn v2 0/4] Mac cache handling refactor

[Numan Siddique]

On Tue, May 7, 2024 at 2:25 AM Ales Musil  wrote:
>
> There were two modules in controller mac_cache and mac-learn, both of
> them did very similar thing with pretty big overlap. The goal of the
> series is to consolidate and merge both of those modules into single
> one. That will reduce the duplication and should make it easier for
> future updates to MAC binding, FDB or packet buffering functionality.
>
> There is also fix to properly handle tunnel_key change for LSP, LRP,
> LR and LS. This was inconsistent and could lead to wrong flows being
> still present even after the tunnel key change. This is not a huge
> issue because the tunnel_key is rarelyt changed during runtime.
>
> Ales Musil (4):
>   northd, controller: Handle tunnel_key change consistently.
>   controller: Rename mac_cache to to mac-cache.
>   controller: Merge the mac-cache and mac-learn.
>   controller: Use datapath key for the mac cache thresholds.

Thanks.  I applied the series to the main branch.
Do we need a backport ?  If so,  I'm inclined to backport the first
patch only as it fixes the issue.
Let me know your thoughts.

Numan


>
>  controller/automake.mk  |   6 +-
>  controller/binding.c|  13 +-
>  controller/mac-cache.c  | 745 
>  controller/mac-cache.h  | 210 ++
>  controller/mac-learn.c  | 482 ---
>  controller/mac-learn.h  | 145 ---
>  controller/mac_cache.c  | 547 --
>  controller/mac_cache.h  | 124 --
>  controller/ovn-controller.c | 214 +++
>  controller/pinctrl.c| 165 
>  controller/statctrl.c   |   7 +-
>  controller/statctrl.h   |   2 +-
>  northd/northd.c |   7 +
>  tests/ovn.at|  56 ++-
>  14 files changed, 1253 insertions(+), 1470 deletions(-)
>  create mode 100644 controller/mac-cache.c
>  create mode 100644 controller/mac-cache.h
>  delete mode 100644 controller/mac-learn.c
>  delete mode 100644 controller/mac-learn.h
>  delete mode 100644 controller/mac_cache.c
>  delete mode 100644 controller/mac_cache.h
>
> --
> 2.44.0
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn v2] northd: Support routing over other address families.

[Numan Siddique]

On Tue, May 7, 2024 at 11:10 AM Felix Huettner via dev
 wrote:
>
> On Tue, May 07, 2024 at 10:06:07AM -0400, Numan Siddique wrote:
> > On Tue, May 7, 2024 at 5:24 AM Felix Huettner via dev
> >  wrote:
> > >
> > > On Mon, May 06, 2024 at 11:03:42PM -0400, Numan Siddique wrote:
> > > > On Mon, Apr 22, 2024 at 9:02 AM Felix Huettner via dev
> > > >  wrote:
> > > > >
> > > > > In most cases IPv4 packets are routed only over other IPv4 networks 
> > > > > and
> > > > > IPv6 packets are routed only over IPv6 networks. However there is no
> > > > > inherent reason for this limitation. Routing IPv4 packets over IPv6
> > > > > networks just requires the router to contain a route for an IPv4 
> > > > > network
> > > > > with an IPv6 nexthop.
> > > > >
> > > > > This was previously prevented in OVN in ovn-nbctl and northd. By
> > > > > removing these filters the forwarding will work if the mac addresses 
> > > > > are
> > > > > prepopulated.
> > > > >
> > > > > If the mac addresses are not prepopulated we will attempt to resolve 
> > > > > them using
> > > > > the original address family of the packet and not the address family 
> > > > > of the
> > > > > nexthop. This will fail and we will not forward the packet.
> > > > >
> > > >
> > > > Thanks for adding this feature.
> > > >
> > > > If I understand correctly from the above commit message about
> > > > prepopulation,  is it expected that
> > > > CMS/admin needs to add a static mac binding entry in the OVN
> > > > Northbound 'Static_MAC_Binding' table
> > > > for this feature to work ?  Please correct me if I'm wrong.
> > > > If this is the case, then it needs to be documented properly (perhaps
> > > > in ovn-nb.xml)
> > >
> > > no the limitation is only that the CMS must not set
> > > dynamic_neigh_routers to true on the Logical_Routers.
> > >
> > > If there are other reasons that cause OVN to send ARP request to lookup
> > > the nexthop of a route then these will have that issue as well. I am
> > > just no aware of any such reason.
> >
> > Thanks.  I'm still not clear what happens if OVN doesn't know the
> > nexthop mac address.
> > What happens in that case ? Normally, OVN would generate ARP request
> > for the next hop IP and
> > learn the mac.  What happens in the mix route case ?
> >
> > Numan
>
> So lets assume you run an ipv4 prefix and route that over an ipv6 network.
> If you then reach the Logical_Router you will reach the arp action in
> S_ROUTER_IN_ARP_REQUEST (build_arp_request_flows_for_lrouter).
>
> This will be handled by the node executing that action as a
> packet-in to pinctrl_handle_arp which is here actually inappropriate.
> We would need to reach pinctrl_handle_nd_na as we need to send a
> neighbor discovery packet.
>
> It could be changed in northd.c when using an additional register bit
> to store the nexthop address family and then using that bit to figure
> out what address family we need to lookup against, instead of relying on
> the packet address family.
>
> However if we end up in pinctrl_handle_nd_na we seem to reuse the
> existing ipv4 packet and patch the Neighbor Discovery packet over it.
> I thought this causes the lookup then to fail, as the address families
> missmatch.
> However i am no longer sure of that explanation after writing this :)

Let's say we add this static route -  "prefix = 172.168.0.0/24,
nexthop = aef0::4"
and lets assume OVN doesn't know the next hop "aef0::4" mac address.
So with your patch, the original packet will be dropped because
pinctrl.c is not handling it properly.

I see 2 approaches here :
1.  Fix it in ovn-northd/pinctrl so that for IPv6 next hop, neigh
solicit packet is generated and for IPv4 next hop, ARP request packet
is generated.
2.  CMS should add a static mac binding entry in the OVN Northbound db
for the next hop for this scenario to work properly.
 Eg.  ovn-nbctl static-mac-binding-add lr0-public aef0::5 10:14:00:00:00:05
 In this case, ovn-controller(s) will add an openflow  like below

---
 ovs-ofctl dump-flows br-int table=66
 cookie=0xa4249f73, duration=470.024s, table=66, n_packets=0,
n_bytes=0, 
priority=50,reg0=0xaef0,reg1=0,reg2=0,reg3=0x5,reg15=0x3,metadata=0x3
actions=mod_dl_dst:10:14:00:00:00:05,load:0x1->NXM_NX_REG10[6]


ovn-northd adds below logical flows in the router ingress pipeline
stage - &q