Re: [ovs-dev] [PATCH ovn] treewide: Disable storing of other_config in external_ids
On Wed, Aug 10, 2022 at 6:15 PM Dumitru Ceara wrote: > > On 8/10/22 09:21, Ales Musil wrote: > > The update of having other_config instead of external_ids > > for configuration has been in place for some time. > > Version that released with this change was 20.06, that > > is plenty of time so we don't have to keep the compatibility > > anymore. Remove the updates of external_ids it will be stored > > only in other_config from now on. > > > > Signed-off-by: Ales Musil > > --- > > Acked-by: Dumitru Ceara I think it's better to add a NEWS entry for this. Thanks Numan > > Thanks! > > ___ > 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: Fix assigment typo
On Wed, Aug 10, 2022 at 6:10 PM Dumitru Ceara wrote:
>
> On 8/10/22 09:32, Ales Musil wrote:
> > Signed-off-by: Ales Musil
> > ---
> > controller/chassis.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/controller/chassis.c b/controller/chassis.c
> > index 92850fcc1..ba6377ac2 100644
> > --- a/controller/chassis.c
> > +++ b/controller/chassis.c
> > @@ -581,7 +581,7 @@ chassis_get_record(struct ovsdb_idl_txn *ovnsb_idl_txn,
> > const struct sbrec_chassis **chassis_rec)
> > {
> > const struct sbrec_chassis *chassis =
> > -chassis = chassis_lookup_by_name(sbrec_chassis_by_name,
> > chassis_id);
> > +chassis_lookup_by_name(sbrec_chassis_by_name, chassis_id);
>
> Oops. :)
>
> Acked-by: Dumitru Ceara
Thanks. Applied to main.
Numan
>
> >
> > if (!chassis && ovnsb_idl_txn) {
> > /* Create the chassis record. */
>
> ___
> 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 4/6] northd: Add MAC binding aging mechanism
" On Mon, Aug 15, 2022 at 3:34 PM Han Zhou wrote: > > On Sun, Aug 14, 2022 at 8:30 PM Numan Siddique wrote: > > > > On Fri, Aug 12, 2022 at 12:21 AM Ales Musil wrote: > > > > > > On Thu, Aug 11, 2022 at 2:45 PM Dumitru Ceara wrote: > > > > > > > On 8/10/22 18:37, Han Zhou wrote: > > > > > On Tue, Aug 9, 2022 at 11:22 PM Ales Musil > wrote: > > > > >> > > > > >> > > > > >> > > > > >> On Wed, Aug 10, 2022 at 8:04 AM Han Zhou wrote: > > > > >> > > > > >> Hi Han, > > > > >> > > > > >> thank you for the review, see my reply inline below. > > > > >> > > > > >>> On Tue, Aug 9, 2022 at 4:05 AM Ales Musil > wrote: > > > > >>>> > > > > >>>> Add MAC binding aging mechanism, that utilizes > > > > >>>> the timestamp column of MAC_Binding table. > > > > >>>> When the MAC binding exceeds the threshold it is > > > > >>>> removed from SB DB, this is postponed only in case > > > > >>>> we receive update ARP with update to MAC address. > > > > >>>> > > > > >>>> The threshold is configurable via option > > > > >>>> "mac_binding_age_threshold" that can be specified > > > > >>>> for each logical router. The option is defaulting to > > > > >>>> 0 which means that by default the aging is disabled > > > > >>>> and the MAC binding rows will be persisted the same > > > > >>>> way as before. > > > > >>>> > > > > >>>> Reported-at: https://bugzilla.redhat.com/2084668 > > > > >>>> Signed-off-by: Ales Musil > > > > >>>> --- > > > > >>>> v3: Rebase on top of current main. > > > > >>>> Update according to the final conclusion. > > > > >>>> v4: Rebase on top of current main. > > > > >>>> Skip one row instead of all if time elapsed is negative. > > > > >>>> Add note to NEWS. > > > > >>>> --- > > > > >>>> NEWS | 3 + > > > > >>>> northd/automake.mk | 2 + > > > > >>>> northd/inc-proc-northd.c | 13 > > > > >>>> northd/mac-binding-aging.c | 151 > > > > + > > > > >>>> northd/mac-binding-aging.h | 33 > > > > >>>> ovn-nb.xml | 7 ++ > > > > >>>> 6 files changed, 209 insertions(+) > > > > >>>> create mode 100644 northd/mac-binding-aging.c > > > > >>>> create mode 100644 northd/mac-binding-aging.h > > > > >>>> > > > > >>>> diff --git a/NEWS b/NEWS > > > > >>>> index 20cea579e..eff8e472a 100644 > > > > >>>> --- a/NEWS > > > > >>>> +++ b/NEWS > > > > >>>> @@ -14,6 +14,9 @@ Post v22.06.0 > > > > >>>> NAT-T UDP encapsulation. Requires OVS support for IPsec > custom > > > > > tunnel > > > > >>>> options (which will be available in OVS 2.18). > > > > >>>>- Removed possibility of disabling logical datapath groups. > > > > >>>> + - Added MAC binding aging mechanism, that is disabled by > default. > > > > >>>> +It can be enabled per logical router with option > > > > >>>> +"mac_binding_age_threshold". > > > > >>>> > > > > >>>> OVN v22.06.0 - 03 Jun 2022 > > > > >>>> -- > > > > >>>> diff --git a/northd/automake.mk b/northd/automake.mk > > > > >>>> index 4862ec7b7..81582867d 100644 > > > > >>>> --- a/northd/automake.mk > > > > >>>> +++ b/northd/automake.mk > > > > >>>> @@ -1,6 +1,8 @@ > > > > >>>> # ovn-northd > > > > >>>> bin_PROGRAMS += northd/ovn-northd > > > > >>>> northd_ovn_northd_SOURCES = \ > > > > >>>> + northd/mac-binding-agi
Re: [ovs-dev] [PATCH ovn] northd: support vtep LSP-attached LS to use L3 services
On Tue, Aug 16, 2022 at 12:19 AM Vladislav Odintsov wrote:
>
> If LRP's logical switch has attached LSP of vtep type, the
> is_chassis_resident() part is not added to lflow to allow traffic
> originated from logical switch to reach LR services (LBs, NAT).
>
> Signed-off-by: Vladislav Odintsov
Thanks for v2 and for the test case.
Applied the patch to main.
Numan
> ---
> This is a continuation from [1] as a v2 edition after Numan's review.
> - reworked to use od->has_vtep_lports and removed lrp's confusing option
> 'is_distributed'
> - added related tests
> - updated ovn-northd flows docs
>
> 1: https://mail.openvswitch.org/pipermail/ovs-dev/2022-August/396796.html
> ---
> northd/northd.c | 33 +---
> northd/ovn-northd.8.xml | 4 +++
> tests/ovn-northd.at | 69 +
> 3 files changed, 102 insertions(+), 4 deletions(-)
>
> diff --git a/northd/northd.c b/northd/northd.c
> index facd41a59..b1e9ffc87 100644
> --- a/northd/northd.c
> +++ b/northd/northd.c
> @@ -637,6 +637,7 @@ struct ovn_datapath {
> bool has_lb_vip;
> bool has_unknown;
> bool has_acls;
> +bool has_vtep_lports;
>
> /* IPAM data. */
> struct ipam_info ipam_info;
> @@ -1847,6 +1848,12 @@ lsp_is_localnet(const struct nbrec_logical_switch_port
> *nbsp)
> return !strcmp(nbsp->type, "localnet");
> }
>
> +static bool
> +lsp_is_vtep(const struct nbrec_logical_switch_port *nbsp)
> +{
> +return !strcmp(nbsp->type, "vtep");
> +}
> +
> static bool
> localnet_can_learn_mac(const struct nbrec_logical_switch_port *nbsp)
> {
> @@ -2655,6 +2662,10 @@ join_logical_ports(struct northd_input *input_data,
> od->localnet_ports[od->n_localnet_ports++] = op;
> }
>
> +if (lsp_is_vtep(nbsp)) {
> +od->has_vtep_lports = true;
> +}
> +
> op->lsp_addrs
> = xmalloc(sizeof *op->lsp_addrs * nbsp->n_addresses);
> for (size_t j = 0; j < nbsp->n_addresses; j++) {
> @@ -5518,7 +5529,7 @@ build_lswitch_port_sec_op(struct ovn_port *op, struct
> hmap *lflows,
> ds_put_format(actions, "set_queue(%s); ", queue_id);
> }
>
> -if (!strcmp(op->nbsp->type, "vtep")) {
> +if (lsp_is_vtep(op->nbsp)) {
> ds_put_format(actions, REGBIT_FROM_RAMP" = 1; ");
> ds_put_format(actions, "next(pipeline=ingress, table=%d);",
>ovn_stage_get_table(S_SWITCH_IN_HAIRPIN));
> @@ -10894,6 +10905,22 @@ build_gateway_mtu_flow(struct hmap *lflows, struct
> ovn_port *op,
> va_end(extra_actions_args);
> }
>
> +static bool
> +consider_l3dwg_port_is_centralized(struct ovn_port *op)
> +{
> +if (op->peer && op->peer->od->has_vtep_lports) {
> +return false;
> +}
> +
> +if (is_l3dgw_port(op)) {
> +/* Traffic with eth.dst = l3dgw_port->lrp_networks.ea_s
> + * should only be received on the gateway chassis. */
> +return true;
> +}
> +
> +return false;
> +}
> +
> /* Logical router ingress Table 0: L2 Admission Control
> * This table drops packets that the router shouldn’t see at all based
> * on their Ethernet headers.
> @@ -10930,9 +10957,7 @@ build_adm_ctrl_flows_for_lrouter_port(
> ds_clear(match);
> ds_put_format(match, "eth.dst == %s && inport == %s",
>op->lrp_networks.ea_s, op->json_key);
> -if (is_l3dgw_port(op)) {
> -/* Traffic with eth.dst = l3dgw_port->lrp_networks.ea_s
> - * should only be received on the gateway chassis. */
> +if (consider_l3dwg_port_is_centralized(op)) {
> ds_put_format(match, " && is_chassis_resident(%s)",
>op->cr_port->json_key);
> }
> diff --git a/northd/ovn-northd.8.xml b/northd/ovn-northd.8.xml
> index ff21c0737..9b6459d9e 100644
> --- a/northd/ovn-northd.8.xml
> +++ b/northd/ovn-northd.8.xml
> @@ -2114,6 +2114,10 @@ output;
>gateway chassis), the above flow matching
>eth.dst == E is only programmed on
>the gateway port instance on the gateway chassis.
> + If LRP's logical switch has attached LSP of vtep type,
> + the is_chassis_resident() part is not added to lflow
> to
> + allow traffic originated from logical switch to reach LR services
> + (LBs, NAT).
>
>
>
> diff --git a/tests/ovn-northd.at b/tests/ovn-northd.at
> index 5b5eeb0ee..3ffa39419 100644
> --- a/tests/ovn-northd.at
> +++ b/tests/ovn-northd.at
> @@ -5747,6 +5747,75 @@ AT_CHECK([grep lr_in_gw_redirect lrflows | grep cr-DR
> | sed 's/table=../table=??
> AT_CLEANUP
> ])
>
> +OVN_FOR_EACH_NORTHD([
> +AT_SETUP([ovn-northd -- lr admission with vtep lports])
> +AT_KEYWORDS([multiple-l3dgw-ports])
> +ovn_start NORTHD_TYPE
> +check ovn-sbctl chassis-add ch1 geneve 127.0.0.2
> +
> +check ovn-nbctl lr-add lr1
> +check ovn-nbctl lrp-a
Re: [ovs-dev] [PATCH ovn v2] treewide: Disable storing of other_config in external_ids
On Mon, Aug 15, 2022 at 6:18 PM Dumitru Ceara wrote: > > On 8/15/22 07:16, Ales Musil wrote: > > The update of having other_config instead of external_ids > > for configuration has been in place for some time. > > Version that released with this change was 20.06, that > > is plenty of time so we don't have to keep the compatibility > > anymore. Remove the updates of external_ids it will be stored > > only in other_config from now on. > > > > Signed-off-by: Ales Musil > > --- > > v2: Rebase on top of current main. > > Address comment from Numan. > > --- > > Acked-by: Dumitru Ceara Thanks for v2. Applied to main. Numan > > Thanks! > > ___ > 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 4/6] northd: Add MAC binding aging mechanism
On Tue, Aug 16, 2022 at 3:07 AM Han Zhou wrote: > > On Mon, Aug 15, 2022 at 1:23 AM Dumitru Ceara wrote: > > > > On 8/15/22 08:46, Numan Siddique wrote: > > > " > > > > > > On Mon, Aug 15, 2022 at 3:34 PM Han Zhou wrote: > > >> > > >> On Sun, Aug 14, 2022 at 8:30 PM Numan Siddique wrote: > > >>> > > >>> On Fri, Aug 12, 2022 at 12:21 AM Ales Musil wrote: > > >>>> > > >>>> On Thu, Aug 11, 2022 at 2:45 PM Dumitru Ceara > wrote: > > >>>> > > >>>>> On 8/10/22 18:37, Han Zhou wrote: > > >>>>>> On Tue, Aug 9, 2022 at 11:22 PM Ales Musil > > >> wrote: > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> On Wed, Aug 10, 2022 at 8:04 AM Han Zhou wrote: > > >>>>>>> > > >>>>>>> Hi Han, > > >>>>>>> > > >>>>>>> thank you for the review, see my reply inline below. > > >>>>>>> > > >>>>>>>> On Tue, Aug 9, 2022 at 4:05 AM Ales Musil > > >> wrote: > > >>>>>>>>> > > >>>>>>>>> Add MAC binding aging mechanism, that utilizes > > >>>>>>>>> the timestamp column of MAC_Binding table. > > >>>>>>>>> When the MAC binding exceeds the threshold it is > > >>>>>>>>> removed from SB DB, this is postponed only in case > > >>>>>>>>> we receive update ARP with update to MAC address. > > >>>>>>>>> > > >>>>>>>>> The threshold is configurable via option > > >>>>>>>>> "mac_binding_age_threshold" that can be specified > > >>>>>>>>> for each logical router. The option is defaulting to > > >>>>>>>>> 0 which means that by default the aging is disabled > > >>>>>>>>> and the MAC binding rows will be persisted the same > > >>>>>>>>> way as before. > > >>>>>>>>> > > >>>>>>>>> Reported-at: https://bugzilla.redhat.com/2084668 > > >>>>>>>>> Signed-off-by: Ales Musil > > >>>>>>>>> --- > > >>>>>>>>> v3: Rebase on top of current main. > > >>>>>>>>> Update according to the final conclusion. > > >>>>>>>>> v4: Rebase on top of current main. > > >>>>>>>>> Skip one row instead of all if time elapsed is negative. > > >>>>>>>>> Add note to NEWS. > > >>>>>>>>> --- > > >>>>>>>>> NEWS | 3 + > > >>>>>>>>> northd/automake.mk | 2 + > > >>>>>>>>> northd/inc-proc-northd.c | 13 > > >>>>>>>>> northd/mac-binding-aging.c | 151 > > >>>>> + > > >>>>>>>>> northd/mac-binding-aging.h | 33 > > >>>>>>>>> ovn-nb.xml | 7 ++ > > >>>>>>>>> 6 files changed, 209 insertions(+) > > >>>>>>>>> create mode 100644 northd/mac-binding-aging.c > > >>>>>>>>> create mode 100644 northd/mac-binding-aging.h > > >>>>>>>>> > > >>>>>>>>> diff --git a/NEWS b/NEWS > > >>>>>>>>> index 20cea579e..eff8e472a 100644 > > >>>>>>>>> --- a/NEWS > > >>>>>>>>> +++ b/NEWS > > >>>>>>>>> @@ -14,6 +14,9 @@ Post v22.06.0 > > >>>>>>>>> NAT-T UDP encapsulation. Requires OVS support for IPsec > > >> custom > > >>>>>> tunnel > > >>>>>>>>> options (which will be available in OVS 2.18). > > >>>>>>>>>- Removed possibility of disabling logical datapath groups. > > >>>>>>>>> + - Added MAC binding aging mechanism, that is disabled by > > >> default. > > &
Re: [ovs-dev] [ovn] Memory leak in ovn-northd: which fix is preferred?
On Wed, Aug 17, 2022 at 12:58 AM Ales Musil wrote:
>
> On Tue, Aug 16, 2022 at 1:50 PM Olaf Seibert via dev <
> ovs-dev@openvswitch.org> wrote:
>
> > Hi! We discovered a memory leak in ovn-northd, which grows quickly, caused
> > by
> > commit 7b56f69580e1f390d9c6753a2cb8f0dbfbb4c467 (dated Wed Feb 23 09:30:00
> > 2022
> > +). We also found a fix for it. I am however not familiar with this
> > code,
> > so when I looked a bit further, I wondered if a different variant would be
> > better. So here are three variants for consideration.
> >
> > Here is the first variant which is the simplest change, and the one we
> > actually
> > tested:
> >
> > From 491008b30fd2e7e09cc4cd3aab1d1a0a3f86dca7 Mon Sep 17 00:00:00 2001
> > From: Olaf Seibert
> > Date: Fri, 12 Aug 2022 11:15:47 +0200
> > Subject: [PATCH ovn] Fix memory leak.
> >
> > Commit 7b56f69580e1f390d9c6753a2cb8f0dbfbb4c467 populated ids with
> > names, but didn't clean them up. Do that here.
> >
> > Signed-off-by: Olaf Seibert
> > ---
> > northd/northd.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/northd/northd.c b/northd/northd.c
> > index 09eccf4d9..e7beed8fb 100644
> > --- a/northd/northd.c
> > +++ b/northd/northd.c
> > @@ -3438,6 +3438,7 @@ ovn_port_update_sbrec(struct northd_input
> > *input_data,
> > struct smap ids = SMAP_INITIALIZER(&ids);
> > smap_clone(&ids, &op->nbrp->external_ids);
> > sbrec_port_binding_set_external_ids(op->sb, &ids);
> > +smap_destroy(&ids);
> >
> > sbrec_port_binding_set_nat_addresses(op->sb, NULL, 0);
> > } else {
> > --
> > 2.37.2
> >
> > I realised that the `ids` variable could possibly be removed, since these
> > external_ids are in effect just passed on unmodified to
> > sbrec_port_binding_set_external_ids(). But since I didn't find the source
> > to
> > that, I am not totally sure that this is safe to do.
> >
> > So variant 2 uses that shortcut:
> >
> > From 6472d24678d3af1d622bacf7da1c9ba77e058b10 Mon Sep 17 00:00:00 2001
> > From: Olaf Seibert
> > Date: Fri, 12 Aug 2022 11:17:12 +0200
> > Subject: [PATCH ovn] Fix memory leak.
> >
> > Commit 7b56f69580e1f390d9c6753a2cb8f0dbfbb4c467 cloned the external_ids
> > to ids, then passed them to sbrec_port_binding_set_external_ids().
> > The intermediate step is unneeded (and caused a memory leak).
> > Pass the external_ids directly.
> >
> > Signed-off-by: Olaf Seibert
> > ---
> > northd/northd.c | 4 +---
> > 1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/northd/northd.c b/northd/northd.c
> > index 09eccf4d9..309b449dd 100644
> > --- a/northd/northd.c
> > +++ b/northd/northd.c
> > @@ -3435,9 +3435,7 @@ ovn_port_update_sbrec(struct northd_input
> > *input_data,
> > sbrec_port_binding_set_mac(op->sb, &addresses, 1);
> > ds_destroy(&s);
> >
> > -struct smap ids = SMAP_INITIALIZER(&ids);
> > -smap_clone(&ids, &op->nbrp->external_ids);
> > -sbrec_port_binding_set_external_ids(op->sb, &ids);
> > +sbrec_port_binding_set_external_ids(op->sb,
> > &op->nbrp->external_ids);
> >
> > sbrec_port_binding_set_nat_addresses(op->sb, NULL, 0);
> > } else {
> > --
> > 2.37.2
> >
> > Then, further down in northd.c, there is another use of
> > sbrec_port_binding_set_nat_addresses(). But in that location, there is a
> > manipulation of the names. Maybe the same is needed here. On the other
> > hand,
> > there the source of the ids is op->nbsp instead of op->nbrp here.
> > So I'm not sure if it has to be the same.
> >
> > Variant 3:
> >
> > From 4a61a02009eb450c6dfadd156968023833e4f1a6 Mon Sep 17 00:00:00 2001
> > From: Olaf Seibert
> > Date: Fri, 12 Aug 2022 11:33:23 +0200
> > Subject: [PATCH ovn] Fix a memory leak.
> >
> > Commit 7b56f69580e1f390d9c6753a2cb8f0dbfbb4c467 added another place
> > where external_ids are copied to the SB database. This had a memory
> > leak, and also differed from the other place where this happens.
> > Make this case the same as the other one.
> >
> > Signed-off-by: Olaf Seibert
> > ---
> > northd/northd.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/northd/northd.c b/northd/northd.c
> > index 09eccf4d9..4d34f7ebc 100644
> > --- a/northd/northd.c
> > +++ b/northd/northd.c
> > @@ -3437,7 +3437,12 @@ ovn_port_update_sbrec(struct northd_input
> > *input_data,
> >
> > struct smap ids = SMAP_INITIALIZER(&ids);
> > smap_clone(&ids, &op->nbrp->external_ids);
> > +const char *name = smap_get(&ids, "neutron:port_name");
> > +if (name && name[0]) {
> > +smap_add(&ids, "name", name);
> > +}
> > sbrec_port_binding_set_external_ids(op->sb, &ids);
> > +smap_destroy(&ids);
> >
> > sbrec_port_binding_set_nat_addresses(op->sb, NULL, 0);
> > } else {
> > --
> > 2.37.2
> >
> >
> > So which variant would be preferred? It looks like variant #3 might be
> > needed,
> > due to the "name" name. If not, #2 would be the s
Re: [ovs-dev] [OVN PATCH] northd: add unsnat/undnat lflow for established connections
On Thu, Aug 11, 2022 at 4:57 PM Wentao Jia wrote:
>
> Hi, Numan
>
> Thanks for you reply.
>
> The network topology as follows:
>
> vm1 -> logical switch 1
> (192.168.200.165) \
>---> router -> extenel-net
> /
> vm2 -> logical switch 2
> (192.168.210.102)
>
> Nat rules of the rotuer:
> TYPEEXTERNAL_IPLOGICAL_IP
> dnat_and_snat 1.1.1.166 192.168.210.102
> snat 1.1.1.124 192.168.200.0/24
> snat 1.1.1.124 192.168.210.0/24
>
> there is only lr_out_snat logical flows for snat rules, no lr_out_undnat
> logical flow.
> table=3 (lr_out_snat), priority=153 , match=(ip && ip4.src ==
> 192.168.200.0/24 && outport == "lrp-0e701852-85a0-4c57-8014-77a8607a9406" &&
> is_chassis_resident("cr-lrp-0e701852-85a0-4c57-8014-77a8607a9406")),
> action=(ct_snat_in_czone(1.1.1.124);)
> table=3 (lr_out_snat), priority=153 , match=(ip && ip4.src ==
> 192.168.210.0/24 && outport == "lrp-0e701852-85a0-4c57-8014-77a8607a9406" &&
> is_chassis_resident("cr-lrp-0e701852-85a0-4c57-8014-77a8607a9406")),
> action=(ct_snat_in_czone(1.1.1.124);)
>
> but there are lr_out_snat and lr_out_undnat logical flows for dnat_and_snat
> rule
> table=1 (lr_out_undnat ), priority=100 , match=(ip && ip4.src ==
> 192.168.210.102 && outport == "lrp-0e701852-85a0-4c57-8014-77a8607a9406" &&
> is_chassis_resident("cr-lrp-0e701852-85a0-4c57-8014-77a8607a9406")),
> action=(ct_dnat_in_czone;)
> table=3 (lr_out_snat), priority=161 , match=(ip && ip4.src ==
> 192.168.210.102 && outport == "lrp-0e701852-85a0-4c57-8014-77a8607a9406" &&
> is_chassis_resident("cr-lrp-0e701852-85a0-4c57-8014-77a8607a9406")),
> action=(ct_snat_in_czone(1.1.1.166);)
>
> and there are lr_in_dnat and lr_in_unsnat logical flows for dnat_and_snat
> rule too
> table=4 (lr_in_unsnat ), priority=100 , match=(ip && ip4.dst ==
> 1.1.1.166 && inport == "lrp-0e701852-85a0-4c57-8014-77a8607a9406" &&
> flags.loopback == 0 &&
> is_chassis_resident("cr-lrp-0e701852-85a0-4c57-8014-77a8607a9406")),
> action=(ct_snat_in_czone;)
> table=4 (lr_in_unsnat ), priority=100 , match=(ip && ip4.dst ==
> 1.1.1.166 && inport == "lrp-0e701852-85a0-4c57-8014-77a8607a9406" &&
> flags.loopback == 1 && flags.use_snat_zone == 1 &&
> is_chassis_resident("cr-lrp-0e701852-85a0-4c57-8014-77a8607a9406")),
> action=(ct_snat;)
> table=6 (lr_in_dnat ), priority=100 , match=(ip && ip4.dst ==
> 1.1.1.166 && inport == "lrp-0e701852-85a0-4c57-8014-77a8607a9406" &&
> is_chassis_resident("cr-lrp-0e701852-85a0-4c57-8014-77a8607a9406")),
> action=(ct_dnat_in_czone(192.168.210.102);)
>
> after patched, another lr_out_undnat logical flow for snat rule and another
> lr_in_unsnat logical flow for dnat rule, lr_out_undnat logical flows as
> follows:
> table=1 (lr_out_undnat ), priority=100 , match=(ip && ip4.src ==
> 192.168.200.0/24 && outport == "lrp-0e701852-85a0-4c57-8014-77a8607a9406" &&
> is_chassis_resident("cr-lrp-0e701852-85a0-4c57-8014-77a8607a9406")),
> action=(ct_dnat_in_czone;)
> table=1 (lr_out_undnat ), priority=100 , match=(ip && ip4.src ==
> 192.168.210.0/24 && outport == "lrp-0e701852-85a0-4c57-8014-77a8607a9406" &&
> is_chassis_resident("cr-lrp-0e701852-85a0-4c57-8014-77a8607a9406")),
> action=(ct_dnat_in_czone;)
Can you share the ovn-nbctl commands to reproduce this ? or even
better if you can share your OVN Northbound database so that I can
locally try ?
Thanks
Numan
>
> B R
> Wentao Jia
>
> -Original Message-
> From: Numan Siddique
> Sent: Thursday, August 11, 2022 12:11 PM
> To: Ales Musil
> Cc: Wentao Jia ; d...@openvswitch.org
> Subject: Re: [ovs-dev] [OVN PATCH] northd: add unsnat/undnat lflow for
> established connections
>
> On Tue, Aug 9, 2022 at 9:46 PM Ales Musil wrote:
> >
> > On Tue, Aug 2, 2022 at 9:05 PM Wentao Jia wrote:
> >
> > > snat/dnat rules of logical router, no logical flows for established
> > > connection, all natted packets deliver to kernel conntrack module by
> > > ct commit, this is low performance and difficult to offload.
> > > add a
Re: [ovs-dev] [Patch ovn] physical.c: Fix bug of wrong use in vm migration
On Thu, Aug 18, 2022 at 5:55 AM Mark Michelson wrote:
>
> Thanks for finding and fixing this!
>
> Acked-by: Mark Michelson
Thanks. I applied this patch to the main branch,
Numan
>
> On 8/15/22 03:16, wangchuanlei wrote:
> > In master branch, pointer ofpacts_p is modified or
> > cleared in setup_activation_strategy will lead the
> > following codes to unexpected exceptions.
> >
> > Signed-off-by: wangchuanlei
> > ---
> > controller/physical.c | 40 +++-
> > 1 file changed, 19 insertions(+), 21 deletions(-)
> >
> > diff --git a/controller/physical.c b/controller/physical.c
> > index a92534a03..552837bcd 100644
> > --- a/controller/physical.c
> > +++ b/controller/physical.c
> > @@ -989,37 +989,36 @@ enum access_type {
> > static void
> > setup_rarp_activation_strategy(const struct sbrec_port_binding *binding,
> > ofp_port_t ofport, struct zone_ids
> > *zone_ids,
> > - struct ovn_desired_flow_table *flow_table,
> > - struct ofpbuf *ofpacts_p)
> > + struct ovn_desired_flow_table *flow_table)
> > {
> > struct match match = MATCH_CATCHALL_INITIALIZER;
> > +struct ofpbuf ofpacts;
> > +ofpbuf_init(&ofpacts, 0);
> >
> > /* Unblock the port on ingress RARP. */
> > match_set_dl_type(&match, htons(ETH_TYPE_RARP));
> > match_set_in_port(&match, ofport);
> > -ofpbuf_clear(ofpacts_p);
> >
> > -load_logical_ingress_metadata(binding, zone_ids, ofpacts_p);
> > +load_logical_ingress_metadata(binding, zone_ids, &ofpacts);
> >
> > -size_t ofs = ofpacts_p->size;
> > -struct ofpact_controller *oc = ofpact_put_CONTROLLER(ofpacts_p);
> > +struct ofpact_controller *oc = ofpact_put_CONTROLLER(&ofpacts);
> > oc->max_len = UINT16_MAX;
> > oc->reason = OFPR_ACTION;
> >
> > struct action_header ah = {
> > .opcode = htonl(ACTION_OPCODE_ACTIVATION_STRATEGY_RARP)
> > };
> > -ofpbuf_put(ofpacts_p, &ah, sizeof ah);
> > +ofpbuf_put(&ofpacts, &ah, sizeof ah);
> >
> > -ofpacts_p->header = oc;
> > -oc->userdata_len = ofpacts_p->size - (ofs + sizeof *oc);
> > -ofpact_finish_CONTROLLER(ofpacts_p, &oc);
> > -put_resubmit(OFTABLE_LOG_INGRESS_PIPELINE, ofpacts_p);
> > +ofpacts.header = oc;
> > +oc->userdata_len = ofpacts.size - (sizeof *oc);
> > +ofpact_finish_CONTROLLER(&ofpacts, &oc);
> > +put_resubmit(OFTABLE_LOG_INGRESS_PIPELINE, &ofpacts);
> >
> > ofctrl_add_flow(flow_table, OFTABLE_PHY_TO_LOG, 1010,
> > binding->header_.uuid.parts[0],
> > -&match, ofpacts_p, &binding->header_.uuid);
> > -ofpbuf_clear(ofpacts_p);
> > +&match, &ofpacts, &binding->header_.uuid);
> > +ofpbuf_clear(&ofpacts);
> >
> > /* Block all non-RARP traffic for the port, both directions. */
> > match_init_catchall(&match);
> > @@ -1027,7 +1026,7 @@ setup_rarp_activation_strategy(const struct
> > sbrec_port_binding *binding,
> >
> > ofctrl_add_flow(flow_table, OFTABLE_PHY_TO_LOG, 1000,
> > binding->header_.uuid.parts[0],
> > -&match, ofpacts_p, &binding->header_.uuid);
> > +&match, &ofpacts, &binding->header_.uuid);
> >
> > match_init_catchall(&match);
> > uint32_t dp_key = binding->datapath->tunnel_key;
> > @@ -1037,7 +1036,9 @@ setup_rarp_activation_strategy(const struct
> > sbrec_port_binding *binding,
> >
> > ofctrl_add_flow(flow_table, OFTABLE_LOG_TO_PHY, 1000,
> > binding->header_.uuid.parts[0],
> > -&match, ofpacts_p, &binding->header_.uuid);
> > +&match, &ofpacts, &binding->header_.uuid);
> > +
> > +ofpbuf_uninit(&ofpacts);
> > }
> >
> > static void
> > @@ -1045,8 +1046,7 @@ setup_activation_strategy(const struct
> > sbrec_port_binding *binding,
> > const struct sbrec_chassis *chassis,
> > uint32_t dp_key, uint32_t port_key,
> > ofp_port_t ofport, struct zone_ids *zone_ids,
> > - struct ovn_desired_flow_table *flow_table,
> > - struct ofpbuf *ofpacts_p)
> > + struct ovn_desired_flow_table *flow_table)
> > {
> > for (size_t i = 0; i < binding->n_additional_chassis; i++) {
> > static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 1);
> > @@ -1059,8 +1059,7 @@ setup_activation_strategy(const struct
> > sbrec_port_binding *binding,
> > && !pinctrl_is_port_activated(dp_key, port_key)) {
> > if (!strcmp(strategy, "rarp")) {
> > setup_rarp_activation_strategy(binding, ofport,
> > - zone_ids, flow_table,
> > -
Re: [ovs-dev] [PATCH ovn] controller: Fix UB due to passing NULL to memcpy.
On Wed, Aug 17, 2022 at 6:01 PM Ales Musil wrote:
>
> On Tue, Aug 16, 2022 at 4:47 PM Dumitru Ceara wrote:
>
> > Reported by UndefinedBehaviorSanitizer when running in a sandbox:
> > controller/ovn-controller.c:374:21: runtime error: null pointer passed
> > as argument 2, which is declared to never be null
> > /usr/include/string.h:44:28: note: nonnull attribute specified here
> > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
> > controller/ovn-controller.c:374:21
> >
> > Signed-off-by: Dumitru Ceara
> > ---
> > controller/ovn-controller.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/controller/ovn-controller.c b/controller/ovn-controller.c
> > index 8268726e6..96270c824 100644
> > --- a/controller/ovn-controller.c
> > +++ b/controller/ovn-controller.c
> > @@ -371,7 +371,9 @@ create_br_int(struct ovsdb_idl_txn *ovs_idl_txn,
> > struct ovsrec_bridge **bridges;
> > size_t bytes = sizeof *bridges * cfg->n_bridges;
> > bridges = xmalloc(bytes + sizeof *bridges);
> > -memcpy(bridges, cfg->bridges, bytes);
> > +if (cfg->n_bridges) {
> > +memcpy(bridges, cfg->bridges, bytes);
> > +}
> > bridges[cfg->n_bridges] = bridge;
> > ovsrec_open_vswitch_verify_bridges(cfg);
> > ovsrec_open_vswitch_set_bridges(cfg, bridges, cfg->n_bridges + 1);
> > --
> > 2.31.1
> >
> > ___
> > dev mailing list
> > d...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> >
> >
> Makes sense, thanks!
>
> Acked-by: Ales Musil
Thanks. Applied to the main branch.
Numan
>
> --
>
> Ales Musil
>
> Senior Software Engineer - OVN Core
>
> Red Hat EMEA
>
> amu...@redhat.comIM: amusil
>
> ___
> 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] system-ovn.at: add connectivity test between container port and parent one
On Thu, Aug 18, 2022 at 3:47 AM Lorenzo Bianconi
wrote:
>
> Introduce system test for the following fix:
> 'd9f69b2d7 ("controller: physical: fix regression for container ports")'
Thanks for the follow up patch to add the test case. I applied this
to the main branch.
Numan
>
> Signed-off-by: Lorenzo Bianconi
> ---
> tests/system-ovn.at | 63 +
> 1 file changed, 63 insertions(+)
>
> diff --git a/tests/system-ovn.at b/tests/system-ovn.at
> index 851117f55..5c042af62 100644
> --- a/tests/system-ovn.at
> +++ b/tests/system-ovn.at
> @@ -8148,3 +8148,66 @@ OVS_TRAFFIC_VSWITCHD_STOP(["/failed to query port
> patch-.*/d
>
> AT_CLEANUP
> ])
> +
> +OVN_FOR_EACH_NORTHD([
> +AT_SETUP([Container ping parent port])
> +AT_KEYWORDS([container-parent-port])
> +
> +ovn_start
> +
> +OVS_TRAFFIC_VSWITCHD_START()
> +ADD_BR([br-int])
> +
> +# 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=unix:$ovs_base/ovn-sb/ovn-sb.sock \
> +-- 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
> +
> +ovn-nbctl ls-add sw0
> +ovn-nbctl lsp-add sw0 sw0-p1
> +ovn-nbctl lsp-set-addresses sw0-p1 "00:54:00:00:00:03 10.0.0.3"
> +
> +ovn-nbctl ls-add sw0
> +ovn-nbctl lsp-add sw0 sw0-p1.2 sw0-p1 2
> +ovn-nbctl lsp-set-addresses sw0-p1.2 "00:54:00:00:00:04 10.0.0.4"
> +
> +ADD_NAMESPACES(sw0-p1)
> +ADD_VETH(sw0-p1, sw0-p1, br-int, "10.0.0.3/24", "00:54:00:00:00:03", \
> + "10.0.0.1")
> +
> +NS_CHECK_EXEC([sw0-p1], [ip link add link sw0-p1 name sw0-p1.2 type vlan id
> 2], [0])
> +ADD_NAMESPACES(sw0-p1.2)
> +NS_CHECK_EXEC([sw0-p1], [ip link set sw0-p1.2 netns sw0-p1.2], [0])
> +NS_CHECK_EXEC([sw0-p1.2], [ip link set sw0-p1.2 address 00:54:00:00:00:04],
> [0])
> +NS_CHECK_EXEC([sw0-p1.2], [ip link set sw0-p1.2 up], [0])
> +NS_CHECK_EXEC([sw0-p1.2], [ip addr add 10.0.0.4/24 dev sw0-p1.2], [0])
> +NS_CHECK_EXEC([sw0-p1.2], [ip route add default via 10.0.0.1 dev sw0-p1.2],
> [0])
> +
> +NS_CHECK_EXEC([sw0-p1.2], [ping -q -c 3 -i 0.3 -w 2 10.0.0.3 | FORMAT_PING],
> \
> +[0], [dnl
> +3 packets transmitted, 3 received, 0% packet loss, time 0ms
> +])
> +
> +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([NORTHD_TYPE])
> +
> +as
> +OVS_TRAFFIC_VSWITCHD_STOP(["/failed to query port patch-.*/d
> +/connection dropped.*/d"])
> +
> +AT_CLEANUP
> +])
> --
> 2.37.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] [OVN PATCH] northd: add unsnat/undnat lflow for established connections
On Thu, Aug 18, 2022 at 12:16 PM Wentao Jia wrote:
>
>
> Hi, Numan
>
> This is snat rule bug，when a snat rule set，this issue is reproduced
> you can find the different between snat rule and dnat_and_snat rule
> Logical flow, ovs openflow and ovs datapath flow are all different
>
> network topology and nat rules in last mail is not enough to reproduce this?
Please understand that for me to reproduce locally, I need to create
all the switches
and routers manually or script it from your shared topology and I may
miss out on a few details.
Having the OVN Northbound database from you would definitely make it
easier for me.
Numan
>
> The switch and router table in northbound
> switch 62b0ba88-554e-46dd-9c45-cff840af9626
> (neutron-27eb266a-de05-4db6-a142-8f8dda7ed0aa) (aka priv-net)
> port 484688a3-79dd-40e7-a075-66441b34e1c7
> type: localport
> addresses: ["fa:16:3e:cd:8d:1b 192.168.200.2"]
> port 478ccbbd-680c-4f70-a87b-178462695926
> type: router
> router-port: lrp-478ccbbd-680c-4f70-a87b-178462695926
> port e1d7711b-1d29-4f53-9527-4740ff8ee653
> type: router
> router-port: lrp-e1d7711b-1d29-4f53-9527-4740ff8ee653
> port babced4e-f5ba-4130-8d12-61f48d58592b (aka port100)
> addresses: ["fa:16:3e:42:31:df 192.168.200.238", "unknown"]
> port 940d7a3d-5262-49fa-b2f0-0055f9f70fd3 (aka port103)
> addresses: ["fa:16:3e:4c:e6:1f 192.168.210.103", "unknown"]
> port 139a94d3-1eac-49e9-b4f3-052d20c4001e (aka port101)
> addresses: ["fa:16:3e:a1:50:79 192.168.200.165", "unknown"]
> port 47ca6c1e-5045-4177-9da3-1535ee9cbed7 (aka port102)
> addresses: ["fa:16:3e:a5:44:f0 192.168.210.102", "unknown"]
>
> router 2a180a00-3ccc-4537-8978-05f4fcf1b0ee
> (neutron-35b1a8c5-82dd-4fc4-83f9-8dfd2e4fb43c) (aka route2)
> port lrp-0e701852-85a0-4c57-8014-77a8607a9406
> mac: "fa:16:3e:ae:b5:e5"
> networks: ["1.1.1.124/24"]
> gateway chassis: [c7bcd287-db8b-4ad8-b38e-bbd69079a2cb]
> port lrp-e1d7711b-1d29-4f53-9527-4740ff8ee653
> mac: "fa:16:3e:39:69:0a"
> networks: ["192.168.200.1/24"]
> port lrp-478ccbbd-680c-4f70-a87b-178462695926
> mac: "fa:16:3e:c9:a7:6b"
> networks: ["192.168.210.1/24"]
> nat 1ba5d885-91ef-4c3b-a40e-ef0633c33b02
> external ip: "1.1.1.45"
> logical ip: "192.168.210.102"
> type: "dnat_and_snat"
> nat 88b9371b-a058-46b5-91f9-6741edf3391a
> external ip: "1.1.1.124"
> logical ip: "192.168.210.0/24"
> type: "snat"
> nat f9843d73-341a-4557-b996-ced76b4fa8e9
> external ip: "1.1.1.124"
> logical ip: "192.168.200.0/24"
> type: "snat"
>
> B R
> Wentao Jia
>
> -Original Message-
> From: Numan Siddique
> Sent: Thursday, August 18, 2022 9:44 AM
> To: Wentao Jia
> Cc: Ales Musil ; d...@openvswitch.org
> Subject: Re: [ovs-dev] [OVN PATCH] northd: add unsnat/undnat lflow for
> established connections
>
> On Thu, Aug 11, 2022 at 4:57 PM Wentao Jia wrote:
> >
> > Hi, Numan
> >
> > Thanks for you reply.
> >
> > The network topology as follows:
> >
> > vm1 -> logical switch 1
> > (192.168.200.165) \
> >---> router -> extenel-net
> > /
> > vm2 -> logical switch 2
> > (192.168.210.102)
> >
> > Nat rules of the rotuer:
> > TYPEEXTERNAL_IPLOGICAL_IP
> > dnat_and_snat 1.1.1.166 192.168.210.102
> > snat 1.1.1.124 192.168.200.0/24
> > snat 1.1.1.124 192.168.210.0/24
> >
> > there is only lr_out_snat logical flows for snat rules, no lr_out_undnat
> > logical flow.
> > table=3 (lr_out_snat), priority=153 , match=(ip && ip4.src ==
> > 192.168.200.0/24 && outport == "lrp-0e701852-85a0-4c57-8014-77a8607a9406"
> > && is_chassis_resident("cr-lrp-0e701852-85a0-4c57-8014-77a8607a9406")),
> > action=(ct_snat_in_czone(1.1.1.124);)
> > table=3 (lr_out_snat), priority=153 , match=(ip && ip4.src ==
> > 192.168.210.0/24 && outport == "lrp-0e701852-85a0-4c57-8014-77a8607a9406"
> > && is_chassis_resident("cr-lrp-0e701852-85a0-4c57-8014-77a8607a9406&quo
Re: [ovs-dev] [OVN PATCH] northd: add unsnat/undnat lflow for established connections
On Thu, Aug 18, 2022 at 1:16 PM Wentao Jia wrote:
>
>
> Hi, Numan
>
> It is not difficult to reproduce，this is about snat/dnat rules
> create router and create different type of nat rules of this router
> no other issues to be considered。
>
Right. I now see the issue locally. I do see that the packet from
the VM to outside is always
committed to the conntrack (along with snat) and that's causing the HWOL issues.
But I don't think the proposed solution is the right fix. Looks like
CI didn't trigger for your patch here [1].
And I pushed your patch to my local github repo and you can see lots
of test failures - [2].
In order to address this HWOL limitation, we should first send the
packet to conntrack with the action - ct_snat_in_czone (in router
egress pipeline).
If the connection was already committed, this would snat it. If it's
a new connection we should commit to it.
Seems to me we should have flows like below (assuming there is an
SNAT entry for 192.168.200.0/24 <-> 1.1.1.124) (please note I may not
be accurate with the below flows)
table=1 (lr_out_undnat ), priority=100 , match=(ip && ip4.src
== 192.168.200.0/24 && outport == "lr0-public" &&
is_chassis_resident("cr-lr0-public")), action=(ct_snat_in_czone;)
table=1 (lr_out_undnat ), priority=100 , match=(ip && ip4.src
== 192.168.200.0/24 && outport == "lr0-public" &&
is_chassis_resident("cr-lr0-public") && reg9[4] == 1),
action=(ct_snat;)
table=3 (lr_out_snat), priority=154 , match=(ip && ip4.src
== 192.168.200.0/24 && outport == "lr0-public" &&
is_chassis_resident("cr-lr0-public") && reg9[4] == 1 && ct.new),
action=(reg9[4] = 0; ct_snat(1.1.1.124);)
table=3 (lr_out_snat), priority=153 , match=(ip && ip4.src
==192.168.200.0/24 && outport == "lr0-public" &&
is_chassis_resident("cr-lr0-public") && ct.new),
action=(ct_snat_in_czone(1.1.1.124);)
Notice the "ct.new" in table 3 flows.
[1] -
https://patchwork.ozlabs.org/project/ovn/patch/bn6pr13mb120270f798be46cfa0d421a1ed...@bn6pr13mb1202.namprd13.prod.outlook.com/
[2] - https://github.com/numansiddique/ovn/tree/ct_commit_snat_issue
https://github.com/numansiddique/ovn/runs/7891302586?check_suite_focus=true
Please also add documentation in ovn-northd.8.xml about the new
logical flows you'd be adding, fix any existing test case failures and
also add a system test if possible.
Thanks
Numan
> Wentao Jia
>
> -Original Message-
> From: Numan Siddique
> Sent: Thursday, August 18, 2022 10:30 AM
> To: Wentao Jia
> Cc: d...@openvswitch.org
> Subject: Re: [ovs-dev] [OVN PATCH] northd: add unsnat/undnat lflow for
> established connections
>
> On Thu, Aug 18, 2022 at 12:16 PM Wentao Jia wrote:
> >
> >
> > Hi, Numan
> >
> > This is snat rule bug，when a snat rule set，this issue is reproduced
> > you can find the different between snat rule and dnat_and_snat rule
> > Logical flow, ovs openflow and ovs datapath flow are all different
> >
> > network topology and nat rules in last mail is not enough to reproduce this?
>
> Please understand that for me to reproduce locally, I need to create all the
> switches and routers manually or script it from your shared topology and I
> may miss out on a few details.
> Having the OVN Northbound database from you would definitely make it easier
> for me.
>
> Numan
>
> >
> > The switch and router table in northbound switch
> > 62b0ba88-554e-46dd-9c45-cff840af9626
> > (neutron-27eb266a-de05-4db6-a142-8f8dda7ed0aa) (aka priv-net)
> > port 484688a3-79dd-40e7-a075-66441b34e1c7
> > type: localport
> > addresses: ["fa:16:3e:cd:8d:1b 192.168.200.2"]
> > port 478ccbbd-680c-4f70-a87b-178462695926
> > type: router
> > router-port: lrp-478ccbbd-680c-4f70-a87b-178462695926
> > port e1d7711b-1d29-4f53-9527-4740ff8ee653
> > type: router
> > router-port: lrp-e1d7711b-1d29-4f53-9527-4740ff8ee653
> > port babced4e-f5ba-4130-8d12-61f48d58592b (aka port100)
> > addresses: ["fa:16:3e:42:31:df 192.168.200.238", "unknown"]
> > port 940d7a3d-5262-49fa-b2f0-0055f9f70fd3 (aka port103)
> > addresses: ["fa:16:3e:4c:e6:1f 192.168.210.103", "unknown"]
> > port 139a94d3-1eac-49e9-b4f3-052d20c4001e (aka port101)
> > addresses: ["fa:16:3e:a1:50:79 192.168.200.165", "unknown"]
> > port 47ca6c1e-5045-4177-9da3-1535ee9cbed7 (aka port102)
> > addresses: [&qu
Re: [ovs-dev] [PATCH ovn v3 1/5] binding.c: Avoid checking OVSDB tracking status in handle_updated_port.
On Fri, Aug 19, 2022 at 10:21 AM Han Zhou wrote:
>
> xxx_is_deleted() is an interface that is expected to be used for OVSDB
> tracked changes only, but handle_updated_port() function handles both
> tracked and untracked rows. It may happen to behave as expected in this
> case but it is risky if the OVSDB IDL implementation changes.
>
> Fixes: 3103487e087b ("Split out code to handle port binding db updates")
> Signed-off-by: Han Zhou
Acked-by: Numan Siddique
Numan
> ---
> controller/binding.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/controller/binding.c b/controller/binding.c
> index 9f5393a92..efb747d52 100644
> --- a/controller/binding.c
> +++ b/controller/binding.c
> @@ -2580,11 +2580,6 @@ handle_updated_port(struct binding_ctx_in *b_ctx_in,
> const struct sbrec_port_binding *pb,
> struct hmap *qos_map_ptr)
> {
> -/* Handle create and update changes only. */
> -if (sbrec_port_binding_is_deleted(pb)) {
> -return true;
> -}
> -
> update_active_pb_ras_pd(pb, b_ctx_out->local_active_ports_ipv6_pd,
> "ipv6_prefix_delegation");
>
> @@ -2825,6 +2820,11 @@ delete_done:
>
> SBREC_PORT_BINDING_TABLE_FOR_EACH_TRACKED (pb,
> b_ctx_in->port_binding_table)
> {
> +/* Loop to handle create and update changes only. */
> +if (sbrec_port_binding_is_deleted(pb)) {
> +continue;
> +}
> +
> handled = handle_updated_port(b_ctx_in, b_ctx_out, pb, qos_map_ptr);
> if (!handled) {
> break;
> --
> 2.30.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 v3 2/5] binding.c: Missing local_datapath update in runtime_data port_binding handler.
On Fri, Aug 19, 2022 at 10:42 AM Han Zhou wrote:
>
> On Thu, Aug 18, 2022 at 5:21 PM Han Zhou wrote:
> >
> > When handling port_binding changes, it is possible that new
> > local_datapaths are added, and the fields of the local_datapath, such as
> > localnet_port, external_ports, etc. need to be updated for the newly
> > added local_datapaths.
> >
> > This problem doesn't happen in most cases because the changes that
> > trigger the new local_datapath addition usually trigger recomputes,
> > but it may not always be the case. If recompute is not triggered,
> > local_datapaths are not properly updated and will result in missing OVS
> > flows. This is more likely to happen when we delay patch interface
> > deletion in the future, or if we implement patch interface I-P.
> >
> > Signed-off-by: Han Zhou
> > ---
> > controller/binding.c | 37 +
> > 1 file changed, 37 insertions(+)
> >
> > diff --git a/controller/binding.c b/controller/binding.c
> > index efb747d52..9f04e6f35 100644
> > --- a/controller/binding.c
> > +++ b/controller/binding.c
> > @@ -2850,6 +2850,43 @@ delete_done:
> > sset_destroy(&postponed_ports);
> > cleanup_claimed_port_timestamps();
> >
> > +if (handled) {
> > +/* There may be new local datapaths added by the above handling,
> so go
> > + * through each port_binding of newly added local datapaths to
> update
> > + * related local_datapaths if needed. */
> > +struct shash bridge_mappings =
> > +SHASH_INITIALIZER(&bridge_mappings);
> > +add_ovs_bridge_mappings(b_ctx_in->ovs_table,
> > +b_ctx_in->bridge_table,
> > +&bridge_mappings);
> > +struct tracked_datapath *t_dp;
> > +HMAP_FOR_EACH (t_dp, node, b_ctx_out->tracked_dp_bindings) {
> > +if (t_dp->tracked_type != TRACKED_RESOURCE_NEW) {
> > +continue;
> > +}
> > +struct sbrec_port_binding *target =
> > +sbrec_port_binding_index_init_row(
> > +b_ctx_in->sbrec_port_binding_by_datapath);
> > +sbrec_port_binding_index_set_datapath(target, t_dp->dp);
If you see the function add_local_datapath__() in
controller/local_data.c, we almost do
the same. i.e iterate through all the port bindings of the datapath.
Does it make sense to move the below code there ? If so, we could
avoid this loop.
Seems to me we can move the functions - update_ld_localnet_port(),
update_ld_external_ports() and
update_ld_multichassis_ports() to local_data.c
What do you think ?
Thanks
Numan
> > +
> > +SBREC_PORT_BINDING_FOR_EACH_EQUAL (pb, target,
> > +b_ctx_in->sbrec_port_binding_by_datapath) {
> > +enum en_lport_type lport_type = get_lport_type(pb);
> > +if (lport_type == LP_LOCALNET) {
> > +update_ld_localnet_port(pb, &bridge_mappings,
> > +b_ctx_out->egress_ifaces,
> > +b_ctx_out->local_datapaths);
> > +} else if (lport_type == LP_EXTERNAL) {
> > +update_ld_external_ports(pb,
> b_ctx_out->local_datapaths);
> > +} else if (pb->n_additional_chassis) {
> > +update_ld_multichassis_ports(pb,
> > +
> b_ctx_out->local_datapaths);
> > +}
> > +}
> > +}
> > +shash_destroy(&bridge_mappings);
> > +}
> > +
> > if (handled && qos_map_ptr && set_noop_qos(b_ctx_in->ovs_idl_txn,
> > b_ctx_in->port_table,
> > b_ctx_in->qos_table,
> > --
> > 2.30.2
> >
>
> Oops, I missed destroying the index row. Please consider below incremental
> patch:
> - 8><
> ><8
>
> diff --git a/controller/binding.c b/controller/binding.c
> index 9f04e6f35..beb5c8e17 100644
> --- a/controller/binding.c
> +++ b/controller/binding.c
> @@ -2883,6 +2883,7 @@ delete_done:
>
> b_ctx_out->local_datapaths);
> }
> }
> +sbrec_port_binding_index_destroy_row(target);
> }
> shash_destroy(&bridge_mappings);
> }
>
> Sorry for the mistake!
>
> Thanks,
> Han
> ___
> 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/2] Prepare for post-22.09.0
On Sat, Aug 20, 2022 at 1:09 AM Ilya Maximets wrote: > > On 8/19/22 15:45, Mark Michelson wrote: > > Signed-off-by: Mark Michelson > > --- > > NEWS | 3 +++ > > configure.ac | 2 +- > > debian/changelog | 6 ++ > > 3 files changed, 10 insertions(+), 1 deletion(-) > > LGTM, > Acked-by: Ilya Maximets Looks like the branch-22.09 is not yet created. For the entire series : Acked-by: Numan Siddique 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] [ovn] Conntrack zone is not flushed on PB release
On Tue, Sep 6, 2022 at 2:40 PM Vladislav Odintsov wrote: > > Hi, > > we’ve noticed that after port binding is released, the conntrack entries in > the associated to deleted port-binding zone are left in conntrack. > I’ve ran through the code, it seems that conntrack zone flushing after port > binding release should be done, but for some reason it isn't. You're right. ovn-controller clears the zone when the zone id is allocated to a port binding during claim but not when a port binding is released. Probably we should add this support. Thanks Numan > > I’ve done a small proof-test. > Create a one-LS topology with two LSPs and configure allow-related acl to > trigger conntrack: > > # enable debug log for ovn-controller "main": > ovn-appctl -t ovn-controller vlog/set file:main:dbg > > # create topology > ovn-nbctl ls-add test > ovn-nbctl lsp-add test lsp1 -- lsp-set-addresses lsp1 '00:00:00:00:00:01 > 192.168.20.10' > ovn-nbctl lsp-add test lsp2 -- lsp-set-addresses lsp2 '00:00:00:00:00:02 > 192.168.20.20' > ovs-vsctl add-port br-int lsp1 -- set int lsp1 type=internal > external_ids:iface-id=lsp1 > ovs-vsctl add-port br-int lsp2 -- set int lsp2 type=internal > external_ids:iface-id=lsp2 > ovn-nbctl acl-add test from-lport 1 1 allow-related > ip li set lsp1 addr 00:00:00:00:00:01 > ip a add 192.168.20.10/24 dev lsp1 > ip li set lsp1 up > > # determine zone id for lsp1: > ovn-appctl -t ovn-controller ct-zone-list | grep lsp1 > > # run ping and quit > ping -c1 192.168.20.20 & > > # check if ping appeared in conntrack > ovs-appctl dpctl/dump-conntrack zone= > > # in my case the output was: > # # ovs-appctl dpctl/dump-conntrack zone=20 > # > icmp,orig=(src=192.168.20.10,dst=192.168.20.20,id=31415,type=8,code=0),reply=(src=192.168.20.20,dst=192.168.20.10,id=31415,type=0,code=0),zone=20 > > # clear iface-id external_id from OVS to trigger port_binding release and > check conntrack again: > ovs-appctl dpctl/dump-conntrack zone= > > The empty output is expected here, but in my case it was not: > # # ovs-appctl dpctl/dump-conntrack zone=20 > # > icmp,orig=(src=192.168.20.10,dst=192.168.20.20,id=31415,type=8,code=0),reply=(src=192.168.20.20,dst=192.168.20.10,id=31415,type=0,code=0),zone=20 > > Check ovn-controller logs: > 2022-09-06T18:17:55.162Z|00976|binding|INFO|Claiming lport lsp1 for this > chassis. > 2022-09-06T18:17:55.162Z|00977|binding|INFO|lsp1: Claiming 00:00:00:00:00:01 > 192.168.20.10 > 2022-09-06T18:17:55.162Z|00978|main|DBG|assigning ct zone 20 for 'lsp1' > 2022-09-06T18:17:55.163Z|00979|binding|INFO|Setting lport lsp1 ovn-installed > in OVS > 2022-09-06T18:17:55.164Z|00980|binding|INFO|Setting lport lsp1 up in > Southbound > > 2022-09-06T18:18:08.037Z|00981|binding|INFO|Releasing lport lsp1 from this > chassis (sb_readonly=0) > 2022-09-06T18:18:08.037Z|00982|main|DBG|removing ct zone 20 for 'lsp1' > > > Regards, > Vladislav Odintsov > > ___ > 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: don't add drop lflow if LB VIP matches LRP IP
On Wed, Aug 31, 2022 at 9:17 AM Vladislav Odintsov wrote:
>
> Please, add this tag before applying the patch:
>
> Reported-at:
> https://mail.openvswitch.org/pipermail/ovs-discuss/2022-August/052021.html
I'm sorry. I missed adding this tag before applying the patch.
I also backported to branch-22.09 as it can be considered a bug fix.
Thanks
Numan
>
> Regards,
> Vladislav Odintsov
>
> > On 31 Aug 2022, at 16:06, Vladislav Odintsov wrote:
> >
> > If it is needed to create Load Balancer within LR with VIP, which matches
> > any of LR's LRP IP, there is no need to create SNAT entry. Now such
> > traffic destined to LRP IP is not dropped.
> >
> > With this patch a drop lflow with match=(ipX.dst == {IP}) is not added to
> > lr_in_ip_input stage if LRP IP matches associated with this LR LB VIP.
> >
> > Tests are added as well.
> >
> > Signed-off-by: Vladislav Odintsov
> > ---
> > NEWS| 3 ++
> > northd/northd.c | 10 --
> > tests/ovn-northd.at | 86 +
> > 3 files changed, 96 insertions(+), 3 deletions(-)
> >
> > diff --git a/NEWS b/NEWS
> > index 0f12b6abf..98dc17dd3 100644
> > --- a/NEWS
> > +++ b/NEWS
> > @@ -18,6 +18,9 @@ Post v22.06.0
> > - Added MAC binding aging mechanism, that is disabled by default.
> > It can be enabled per logical router with option
> > "mac_binding_age_threshold".
> > + - If it is needed to create Load Balancer within LR with VIP, which
> > matches
> > +any of LR's LRP IP, there is no need to create SNAT entry. Now such
> > +traffic destined to LRP IP is not dropped.
> >
> > OVN v22.06.0 - 03 Jun 2022
> > --
> > diff --git a/northd/northd.c b/northd/northd.c
> > index 7e2681865..338091728 100644
> > --- a/northd/northd.c
> > +++ b/northd/northd.c
> > @@ -10664,7 +10664,9 @@ build_lrouter_drop_own_dest(struct ovn_port *op,
> > enum ovn_stage stage,
> > const char *ip = op->lrp_networks.ipv4_addrs[i].addr_s;
> >
> > bool router_ip_in_snat_ips = !!shash_find(&op->od->snat_ips,
> > ip);
> > -bool drop_router_ip = (drop_snat_ip == router_ip_in_snat_ips);
> > +bool router_ip_in_lb_ips = !!sset_find(&op->od->lb_ips_v4, ip);
> > +bool drop_router_ip = (drop_snat_ip == (router_ip_in_snat_ips
> > ||
> > +router_ip_in_lb_ips));
> >
> > if (drop_router_ip) {
> > ds_put_format(&match_ips, "%s, ", ip);
> > @@ -10690,7 +10692,9 @@ build_lrouter_drop_own_dest(struct ovn_port *op,
> > enum ovn_stage stage,
> > const char *ip = op->lrp_networks.ipv6_addrs[i].addr_s;
> >
> > bool router_ip_in_snat_ips = !!shash_find(&op->od->snat_ips,
> > ip);
> > -bool drop_router_ip = (drop_snat_ip == router_ip_in_snat_ips);
> > +bool router_ip_in_lb_ips = !!sset_find(&op->od->lb_ips_v6, ip);
> > +bool drop_router_ip = (drop_snat_ip == (router_ip_in_snat_ips
> > ||
> > +router_ip_in_lb_ips));
> >
> > if (drop_router_ip) {
> > ds_put_format(&match_ips, "%s, ", ip);
> > @@ -12865,7 +12869,7 @@ build_lrouter_ipv4_ip_input(struct ovn_port *op,
> > * also a SNAT IP. Those are dropped later, in stage
> > * "lr_in_arp_resolve", if unSNAT was unsuccessful.
> > *
> > - * If op->pd->lb_force_snat_router_ip is true, it means the IP of
> > the
> > + * If op->od->lb_force_snat_router_ip is true, it means the IP of
> > the
> > * router port is also SNAT IP.
> > *
> > * Priority 60.
> > diff --git a/tests/ovn-northd.at b/tests/ovn-northd.at
> > index 157f9f60c..a60b3b0a9 100644
> > --- a/tests/ovn-northd.at
> > +++ b/tests/ovn-northd.at
> > @@ -1499,6 +1499,92 @@ AT_CHECK([grep "lr_in_unsnat" sbflows | sort], [0],
> > [dnl
> > AT_CLEANUP
> > ])
> >
> > +OVN_FOR_EACH_NORTHD([
> > +AT_SETUP([LRP same IP as VIP or SNAT])
> > +ovn_start
> > +
> > +check ovn-nbctl lr-add lr0
> > +check ovn-nbctl lrp-add lr0 lr0-public 00:00:00:00:00:10 192.168.0.1/24
> > 2000::1/64
> > +check ovn-nbctl --wait=sb lrp-add lr0 lr0-join 00:00:00:00:00:20
> > 10.10.0.1/24 192.168.1.1/24
> > +
> > +ovn-sbctl dump-flows lr0 > sbflows
> > +AT_CAPTURE_FILE([sbflows])
> > +
> > +# There should be drop lflows for all IPs of both LRPs
> > +AT_CHECK([grep "lr_in_ip_input" sbflows | grep 'ip.\.dst == {' | grep drop
> > | sed 's/table=../table=??/g' | sort], [0], [dnl
> > + table=??(lr_in_ip_input ), priority=60 , match=(ip4.dst ==
> > {10.10.0.1, 192.168.1.1}), action=(drop;)
> > + table=??(lr_in_ip_input ), priority=60 , match=(ip4.dst ==
> > {192.168.0.1}), action=(drop;)
> > + table=??(lr_in_ip_input ), priority=60 , match=(ip6.dst ==
> > {2000::1, fe80::200:ff:fe00:10}), action=(drop;)
> > + table=??(lr_in_ip_input ), priority=60 , match=(ip6.dst ==
> > {fe80:
Re: [ovs-dev] [PATCH ovn] northd: Always propagate LB proto to lflows
On Fri, Sep 9, 2022 at 2:11 AM Ales Musil wrote:
>
> On Fri, Sep 9, 2022 at 7:43 AM Han Zhou wrote:
>
> >
> >
> > On Tue, Sep 6, 2022 at 6:02 AM Ales Musil wrote:
> > >
> > > The current behavior is that load balancers
> > > default to tcp protocol if it is not specified.
> > > However, this is not propagated to lflows which
> > > specify proto only when port is specified as part
> > > of the protocol e.g. udp.port == X. Always include
> > > the protocol in the lb flow even if the port is not
> > > specified.
> > >
> > > Signed-off-by: Ales Musil
> >
> > Hi Ales,
> >
>
> Hi Han,
>
>
> > Sorry that I don't understand the problem. The ovn-nb.xml defines:
> >
> >
> >
> > Valid protocols are tcp, udp, or
> > sctp. This column is useful when a port number is
> > provided as part of the vips column. If this column
> > is
> > empty and a port number is provided as part of vips
> > column, OVN assumes the protocol to be tcp.
> >
> >
> >
> > So it defaults to TCP only if a port number is provided. Your patch seems
> > to change this definition and is trying to default to TCP even if a port
> > number is NOT provided? Did I misunderstand?
> >
>
> right, but everything is presented as tcp being default even if we don't
> specify proto e.g. lb-list. Also ovn-northd.8.xml specifies:
>
> For all the configured load balancing rules for a switch in
> OVN_Northbound database that includes a L4 port
> PORT of protocol P and IP address
> VIP, a priority-120 flow is added. For IPv4 VIPs
> , the flow matches ct.new && ip &&
> ip4.dst == VIP && P &&
> P.dst == PORT. For IPv6 VIPs,
> the flow matches ct.new && ip && ip6.dst ==
> VIP && P && P.dst ==
> PORT.
>
> Suggesting that the protocol should be present which was not the case for
> even if the port was specified.
>
> This patch tries to make it consistent. So that we include the protocol
> always in the rule and it default to tcp.
I think Han is correct. AFAIK we do support L3 load balancers i.e if
no protocol specified, then its an
L3 load balancer. If the documentation is not accurate, we should fix that.
Thanks
Numan
>
> Thanks,
> Ales
>
>
> > Thanks,
> > Han
> >
> > > ---
> > > northd/northd.c | 7 +++--
> > > tests/ovn-northd.at | 56 +++
> > > tests/ovn.at | 6 ++---
> > > utilities/ovn-nbctl.8.xml | 5 ++--
> > > 4 files changed, 36 insertions(+), 38 deletions(-)
> > >
> > > diff --git a/northd/northd.c b/northd/northd.c
> > > index 7e2681865..3ab335fec 100644
> > > --- a/northd/northd.c
> > > +++ b/northd/northd.c
> > > @@ -6870,9 +6870,8 @@ build_lb_rules(struct hmap *lflows, struct
> > ovn_northd_lb *lb, bool ct_lb_mark,
> > >lb_vip->vip_str);
> > > }
> > >
> > > -const char *proto = NULL;
> > > +const char *proto = "tcp";
> > > if (lb_vip->vip_port) {
> > > -proto = "tcp";
> > > if (lb->nlb->protocol) {
> > > if (!strcmp(lb->nlb->protocol, "udp")) {
> > > proto = "udp";
> > > @@ -6894,8 +6893,8 @@ build_lb_rules(struct hmap *lflows, struct
> > ovn_northd_lb *lb, bool ct_lb_mark,
> > > lb->selection_fields, true,
> > > ct_lb_mark);
> > >
> > > -ds_put_format(match, "ct.new && %s.dst == %s", ip_match,
> > > - lb_vip->vip_str);
> > > +ds_put_format(match, "ct.new && %s.dst == %s && %s", ip_match,
> > > + lb_vip->vip_str, proto);
> > > int priority = 110;
> > > if (lb_vip->vip_port) {
> > > ds_put_format(match, " && %s.dst == %d", proto,
> > lb_vip->vip_port);
> > > diff --git a/tests/ovn-northd.at b/tests/ovn-northd.at
> > > index 157f9f60c..6559a6ade 100644
> > > --- a/tests/ovn-northd.at
> > > +++ b/tests/ovn-northd.at
> > > @@ -1227,7 +1227,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' | sed 's/table=..//'], 0, [dnl
> > > - (ls_in_lb ), priority=120 , match=(ct.new && ip4.dst ==
> > 10.0.0.10 && tcp.dst == 80), action=(reg0[[1]] = 0; reg1 = 10.0.0.10;
> > reg2[[0..15]] = 80; ct_lb(backends=10.0.0.3:80,20.0.0.3:80);)
> > > + (ls_in_lb ), priority=120 , match=(ct.new && ip4.dst ==
> > 10.0.0.10 && tcp && tcp.dst == 80), action=(reg0[[1]] = 0; reg1 =
> > 10.0.0.10; reg2[[0..15]] = 80; ct_lb(backends=10.0.0.3:80,20.0.0.3:80);)
> > > ])
> > >
> > > AS_BOX([Delete the Load_Balancer_Health_Check])
> > > @@ -1237,7 +1237,7 @@ wait_row_count Service_Monitor 0
> > > AT_CAPTURE_FILE([sbflows2])
> > > OVS_WAIT_FOR_OUTPUT(
> > >[ovn-sbctl dump-flows sw0 | tee sbflows2 | grep
> > 'priority=120.*backends' | sed 's/table=..//'], [0],
> > > -[ (ls_in_lb
Re: [ovs-dev] [PATCH ovn] northd: Accumulate more database updates before processing.
On Fri, Sep 9, 2022 at 2:25 AM Han Zhou wrote:
>
> On Thu, Sep 8, 2022 at 8:46 AM Ilya Maximets wrote:
> >
> > northd doesn't process changes incrementally, so it makes sense to
> > accumulate more database updates and process them in bulk, so we can
> > cover everything in a single recompute.
> >
> > ovsdb-server has a mechanism to start accumulating changes if the
> > client doesn't receive them fast enough, but it relies on the receive
> > buffer size, which is a few hundreds of KB on a typical system.
> > Unfortunately, that is enough to queue up several hundreds of small
> > updates, and it takes northd a lot of time to process them if poll
> > intervals are large, receiving at most 50 messages on each iteration
> > (half of which are updates for a _Server database).
> >
> > Calling ovsdb_idl_run() as long as something changes. This allows to
> > quickly process large bursts of database updates. For example, it
> > takes only 30-40 seconds for 'ovn-nbctl --wait=hv sync' to finish on
> > a 500-node cluster after the startup phase of the density-heavy
> > ovn-heater test, instead of 6-8 minutes without this change.
> >
> > 500 ms seems like a reasonable hard limit to avoid spinning for too
> > long if the database is changed constantly at a fast pace.
> >
> > Very long polling is also logged at INFO level to notify users.
> > Not using WARN or higher because it may happen under normal conditions,
> > e.g. on the initial connection to a large database or another type
> > of a single large update. Other notable polling attempts are logged
> > at debug level.
> >
> > Signed-off-by: Ilya Maximets
> > ---
> > northd/ovn-northd.c | 38 ++
> > 1 file changed, 34 insertions(+), 4 deletions(-)
> >
> > diff --git a/northd/ovn-northd.c b/northd/ovn-northd.c
> > index bd35802ed..96f17f15f 100644
> > --- a/northd/ovn-northd.c
> > +++ b/northd/ovn-northd.c
> > @@ -685,6 +685,36 @@ get_probe_interval(const char *db, const struct
> nbrec_nb_global *nb)
> > return interval;
> > }
> >
> > +static struct ovsdb_idl_txn *
> > +run_idl_loop(struct ovsdb_idl_loop *idl_loop, const char *name)
> > +{
> > +unsigned long long duration, start = time_msec();
> > +unsigned int seqno = UINT_MAX;
> > +struct ovsdb_idl_txn *txn;
> > +int n = 0;
> > +
> > +/* Accumulate database changes as long as there are some,
> > + * but no longer than half a second. */
> > +while (seqno != ovsdb_idl_get_seqno(idl_loop->idl)
> > + && time_msec() - start < 500) {
> > +seqno = ovsdb_idl_get_seqno(idl_loop->idl);
> > +ovsdb_idl_run(idl_loop->idl);
> > +n++;
> > +}
> > +
> > +txn = ovsdb_idl_loop_run(idl_loop);
> > +
> > +duration = time_msec() - start;
> > +/* ovsdb_idl_run() is called at least 2 times. Once directly and
> > + * once in the ovsdb_idl_loop_run(). n > 2 means that we received
> > + * data on at least 2 subsequent calls. */
> > +if (n > 2 || duration > 100) {
> > +VLOG(duration > 500 ? VLL_INFO : VLL_DBG,
> > + "%s IDL run: %d iterations in %lld ms", name, n + 1,
> duration);
> > +}
> > +return txn;
> > +}
> > +
> > int
> > main(int argc, char *argv[])
> > {
> > @@ -821,8 +851,8 @@ main(int argc, char *argv[])
> > ovsdb_idl_set_lock(ovnsb_idl_loop.idl, "ovn_northd");
> > }
> >
> > -struct ovsdb_idl_txn *ovnnb_txn =
> > -ovsdb_idl_loop_run(&ovnnb_idl_loop);
> > +struct ovsdb_idl_txn *ovnnb_txn =
> run_idl_loop(&ovnnb_idl_loop,
> > +
> "OVN_Northbound");
> > unsigned int new_ovnnb_cond_seqno =
> >
> ovsdb_idl_get_condition_seqno(ovnnb_idl_loop.idl);
> > if (new_ovnnb_cond_seqno != ovnnb_cond_seqno) {
> > @@ -833,8 +863,8 @@ main(int argc, char *argv[])
> > ovnnb_cond_seqno = new_ovnnb_cond_seqno;
> > }
> >
> > - struct ovsdb_idl_txn *ovnsb_txn =
> > -ovsdb_idl_loop_run(&ovnsb_idl_loop);
> > +struct ovsdb_idl_txn *ovnsb_txn =
> run_idl_loop(&ovnsb_idl_loop,
> > +
> "OVN_Southbound");
> > unsigned int new_ovnsb_cond_seqno =
> >
> ovsdb_idl_get_condition_seqno(ovnsb_idl_loop.idl);
> > if (new_ovnsb_cond_seqno != ovnsb_cond_seqno) {
> > --
> > 2.34.3
> >
>
> Thanks Ilya for the great improvement! Applied to main.
> It is not a bug fix but it seems a good candidate for backporting to 22.09
> given that the change is small and we haven't released yet. @Mark Michelson
> @Numan Siddique what do you think?
+1 from me.
Thanks
Numan
>
> Han
> ___
> 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: drop traffic to disabled LSPs in ingress pipeline
On Thu, Sep 8, 2022 at 7:41 AM Vladislav Odintsov wrote:
>
> Prior to this patch traffic to LSPs, which are disabled with
> `ovn-nbctl lsp-set-enabled disabled` was dropped in the end of
> lswitch egress pipeline. This means that traffic is processed in vain:
> - traffic, which should be dropped, first travels from one chassis to
> another (if source/dest LSPs reside on different nodes) and dropped on
> the destination chassis;
> - when such traffic reaches destination chassis, if stateful services are
> enabled within logical switch, first traffic is sent to conntrack and
> is dropped after that.
>
> So it is costly to drop traffic in such manner especially in case LSP is
> disabled to prevent any harmful traffic to affect infrastructure. This
> patch changes "to-lport" drop behaviour. Now it is dropped in lswitch
> ingress pipeline to avoid sending traffic to disabled LSP from one
> chassis to another.
> Traffic doesn't reach conntrack in destination LSP's zone now as well.
>
> Port security testcases are updated.
>
> Signed-off-by: Vladislav Odintsov
Hi Vladislav,
It might break the scenario for the traffic from the provider network
(external) destined to a logical port connected
to a logical switch with localnet port. The traffic would be now delivered.
I'd suggest dropping the traffic both in ls_in_check_port_sec and in
ls_out_check_port_sec for a disabled logical port. What do you think
?
Thanks
Numan
> ---
> northd/northd.c | 22 +++---
> tests/ovn-northd.at | 184 +++-
> 2 files changed, 128 insertions(+), 78 deletions(-)
>
> diff --git a/northd/northd.c b/northd/northd.c
> index 4a40ec9b0..5497a88ca 100644
> --- a/northd/northd.c
> +++ b/northd/northd.c
> @@ -5475,9 +5475,8 @@ build_lswitch_port_sec_op(struct ovn_port *op, struct
> hmap *lflows,
> ds_clear(match);
> ds_put_format(match, "outport == %s", op->json_key);
> ovn_lflow_add_with_lport_and_hint(
> -lflows, op->od, S_SWITCH_OUT_CHECK_PORT_SEC, 150,
> -ds_cstr(match), REGBIT_PORT_SEC_DROP" = 1; next;",
> -op->key, &op->nbsp->header_);
> +lflows, op->od, S_SWITCH_IN_L2_UNKNOWN, 50, ds_cstr(match),
> +"drop;", op->key, &op->nbsp->header_);
> return;
> }
>
> @@ -8466,6 +8465,8 @@ build_lswitch_ip_unicast_lookup(struct ovn_port *op,
> * Ethernet address followed by zero or more IPv4
> * or IPv6 addresses (or both). */
> struct eth_addr mac;
> +bool lsp_enabled = lsp_is_enabled(op->nbsp);
> +char *action = lsp_enabled ? "output" : "drop";
> if (ovs_scan(op->nbsp->addresses[i],
> ETH_ADDR_SCAN_FMT, ETH_ADDR_SCAN_ARGS(mac))) {
> ds_clear(match);
> @@ -8473,13 +8474,14 @@ build_lswitch_ip_unicast_lookup(struct ovn_port *op,
>ETH_ADDR_ARGS(mac));
>
> ds_clear(actions);
> -ds_put_format(actions, "outport = %s; output;",
> op->json_key);
> +ds_put_format(actions, "outport = %s; %s;", op->json_key,
> + action);
> ovn_lflow_add_with_hint(lflows, op->od, S_SWITCH_IN_L2_LKUP,
> 50, ds_cstr(match),
> ds_cstr(actions),
> &op->nbsp->header_);
> } else if (!strcmp(op->nbsp->addresses[i], "unknown")) {
> -if (lsp_is_enabled(op->nbsp)) {
> +if (lsp_enabled) {
> ovs_mutex_lock(&mcgroup_mutex);
> ovn_multicast_add(mcgroups, &mc_unknown, op);
> ovs_mutex_unlock(&mcgroup_mutex);
> @@ -8496,7 +8498,8 @@ build_lswitch_ip_unicast_lookup(struct ovn_port *op,
>ETH_ADDR_ARGS(mac));
>
> ds_clear(actions);
> -ds_put_format(actions, "outport = %s; output;",
> op->json_key);
> +ds_put_format(actions, "outport = %s; %s;", op->json_key,
> + action);
> ovn_lflow_add_with_hint(lflows, op->od, S_SWITCH_IN_L2_LKUP,
> 50, ds_cstr(match),
> ds_cstr(actions),
> @@ -8544,7 +8547,8 @@ build_lswitch_ip_unicast_lookup(struct ovn_port *op,
> }
>
> ds_clear(actions);
> -ds_put_format(actions, "outport = %s; output;",
> op->json_key);
> +ds_put_format(actions, "outport = %s; %s;", op->json_key,
> + action);
> ovn_lflow_add_with_hint(lflows, op->od,
> S_SWITCH_IN_L2_LKUP, 50,
> ds_cstr(match), ds_cstr(actions),
> @@ -8567,8 +8571,8 @@ build_lswitch_ip_unica
Re: [ovs-dev] [PATCH ovn] northd: drop traffic to disabled LSPs in ingress pipeline
On Thu, Sep 15, 2022 at 10:30 AM Vladislav Odintsov wrote: > > Hi Numan, > > thanks for the provided case. Unfortunately, I’m now sure I correctly > understand it. > Could you please provide ovn-nbctl commands to create such a topology so I > could reproduce and recheck? Something like ovn-nbctl ls-add public # localnet port ovn-nbctl lsp-add public ln-public ovn-nbctl lsp-set-type ln-public localnet ovn-nbctl lsp-set-addresses ln-public unknown ovn-nbctl lsp-set-options ln-public network_name=public # create a logical port ovn-nbctl lsp-add public p-port1 ovn-nbctl lsp-set-addresses p-port1 "50:54:00:00:00:03 172.16.0.100" (assuming 172.16.0.0/24 is the provider network CIDR) # attach p-port1 to a VM/container ovs-vsctl set open . external_ids:ovn-bridge-mappings="br-ex:public" # Create br-ex and attach physical interface to br-ex. If you ping from an external machine with say IP 172.16.0.20 to p-port1 (172.16.0.100), then the packet will enter physical interface -> br-ex -> patch port -> br-int (using ln-public) and it will enter logical ingress pipeline of public and then egress pipeline of public and then delivered to p-public. Thanks Numan > > Regards, > Vladislav Odintsov > > > On 15 Sep 2022, at 15:42, Numan Siddique wrote: > > > > On Thu, Sep 8, 2022 at 7:41 AM Vladislav Odintsov > <mailto:odiv...@gmail.com>> wrote: > >> > >> Prior to this patch traffic to LSPs, which are disabled with > >> `ovn-nbctl lsp-set-enabled disabled` was dropped in the end of > >> lswitch egress pipeline. This means that traffic is processed in vain: > >> - traffic, which should be dropped, first travels from one chassis to > >> another (if source/dest LSPs reside on different nodes) and dropped on > >> the destination chassis; > >> - when such traffic reaches destination chassis, if stateful services are > >> enabled within logical switch, first traffic is sent to conntrack and > >> is dropped after that. > >> > >> So it is costly to drop traffic in such manner especially in case LSP is > >> disabled to prevent any harmful traffic to affect infrastructure. This > >> patch changes "to-lport" drop behaviour. Now it is dropped in lswitch > >> ingress pipeline to avoid sending traffic to disabled LSP from one > >> chassis to another. > >> Traffic doesn't reach conntrack in destination LSP's zone now as well. > >> > >> Port security testcases are updated. > >> > >> Signed-off-by: Vladislav Odintsov > > > > Hi Vladislav, > > > > It might break the scenario for the traffic from the provider network > > (external) destined to a logical port connected > > to a logical switch with localnet port. The traffic would be now delivered. > > > > I'd suggest dropping the traffic both in ls_in_check_port_sec and in > > ls_out_check_port_sec for a disabled logical port. What do you think > > ? > > > > Thanks > > Numan > > > > > > > >> --- > >> northd/northd.c | 22 +++--- > >> tests/ovn-northd.at | 184 +++- > >> 2 files changed, 128 insertions(+), 78 deletions(-) > >> > >> diff --git a/northd/northd.c b/northd/northd.c > >> index 4a40ec9b0..5497a88ca 100644 > >> --- a/northd/northd.c > >> +++ b/northd/northd.c > >> @@ -5475,9 +5475,8 @@ build_lswitch_port_sec_op(struct ovn_port *op, > >> struct hmap *lflows, > >> ds_clear(match); > >> ds_put_format(match, "outport == %s", op->json_key); > >> ovn_lflow_add_with_lport_and_hint( > >> -lflows, op->od, S_SWITCH_OUT_CHECK_PORT_SEC, 150, > >> -ds_cstr(match), REGBIT_PORT_SEC_DROP" = 1; next;", > >> -op->key, &op->nbsp->header_); > >> +lflows, op->od, S_SWITCH_IN_L2_UNKNOWN, 50, ds_cstr(match), > >> +"drop;", op->key, &op->nbsp->header_); > >> return; > >> } > >> > >> @@ -8466,6 +8465,8 @@ build_lswitch_ip_unicast_lookup(struct ovn_port *op, > >> * Ethernet address followed by zero or more IPv4 > >> * or IPv6 addresses (or both). */ > >> struct eth_addr mac; > >> +bool lsp_enabled = lsp_is_enabled(op->nbsp); > >> +char *action = lsp_enabled ? "output" : "drop"; > >> if (ovs_scan(op-&g
Re: [ovs-dev] [PATCH ovn] northd: Don't get stuck in the STATE_INIT_HASH_SIZES state.
On Fri, Sep 9, 2022 at 4:00 AM Ilya Maximets wrote:
>
> On 8/25/22 11:03, Dumitru Ceara wrote:
> > On 8/24/22 18:32, Ilya Maximets wrote:
> >> On 8/24/22 17:57, Dumitru Ceara wrote:
> >>> On 8/24/22 17:49, Ilya Maximets wrote:
> On 8/24/22 17:43, Ilya Maximets wrote:
> > On 8/23/22 16:42, Dumitru Ceara wrote:
> >> After removing the possibility of disabling logical datapath groups the
> >> above mentioned state should only be relevant when ovn-northd is
> >> started
> >> with more than one lflow processing threads (--n-threads > 1), to avoid
> >> a very inefficient first lflow processing run due to a suboptimally
> >> sized hmap.
> >>
> >> There's no need to ever go back to this state now that we don't allow
> >> users to disable logical datapath groups. Moreover, the previous code
> >> was wrongfully setting the state to STATE_INIT_HASH_SIZES at every
> >> iteration, essentially disabling parallelization.
> >>
> >> Fixes: 9dea0c090e91 ("nb: Remove possibility of disabling logical
> >> datapath groups.")
> >> Reported-by: Ilya Maximets
> >> Signed-off-by: Dumitru Ceara
> >> ---
> >
> > Hi, Dumitru. Thanks for the patch!
> >>>
> >>> Hi Ilya,
> >>>
> > I've been using it in multiple scale tests since it was posted,
> > and it does re-enable parallel lflow build.
> >
> >>>
> >>> Thanks for trying it out!
> >>>
> > One issue though. Not sure how to fix that or what is the desired
> > behavior, but what I noticed is:
> >
> > 1. Cluster with 3 northd instances starts up.
> > 2. After a while all of them has been active at least once, due
> > to leadership transfers or other things.
> > 3. If one instance stays active for long, a lot of database changes
> > can be accumulated.
> > 4. Once the leadership flips, new active northd is not prepared for
> > the amount of logical flows it suddenly needs to manage. So,
> > it starts parallel processing with hmap significantly smaller
> > than it actually needs right now. That iteration takes noticeably
> > more time than a usual one. After the first iteration after
> > becoming active, it can process lflows with a normal speed.
> >
> > So, I wonder if we can fall into a catastrophic scenario where
> > the current hash map size is very small and amount of flows after
> > re-connection is very high, so threads are only fighting for locks
> > all the time.
> >
> > Do you have some thoughts on this?
> >
> >>>
> >>> This seems like a possible scenario (although I wonder how often we'd
> >>> hit it in practice).
> >>>
> >>> But this was a possible scenario before 9dea0c090e91 ("nb: Remove
> >>> possibility of disabling logical datapath groups.") too, right?
> >>
> >> Probably, yes. There is no need to block this particular patch as
> >> it is fixing the separate bug. So,
> >>
> >> Acked-by: Ilya Maximets
> >>
> >
> > Thanks!
> >
> >>>
> > Should we disable parallelism when northd goes into stand-up state?
>
> * I meant 'standby', of course. :/
>
> >>>
> >>> We could, but that means every time northd becomes active it will do one
> >>> first inefficient run. Can we instead store the max_seen_lflow_size
> >>> value in the SB database and use the one we read from the DB?
> >>
> >> It's an interesting idea, if it can be implemented efficiently. I'm not
> >> sure how much extra traffic or northd wakeups that will generate.
> >> It might make more sense to store it in NB, just to avoid spamming all
> >> the controllers with monitor-all. Also, NB DB generally has more room
> >> performance-wise.
> >>
> >
> > I'll try to work on a patch to store it in NB; we already write to NB
> > for other stuff like Logical_Switch_Port.up so it should be acceptable.
> >
> > I'll run some benchmarks to see if there's any measurable negative
> > impact because of this and report back.
>
> Sounds reasonable.
>
> Meanwhile, Han, Mark, Numan, can we, please, accept the current fix?
Thanks. I applied this patch to main and to branch-22.09.
Numan
>
> The parallelization is completely broken without it on both the main
> branch and brach-22.09 as well.
>
> Thanks!
> 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 ovn] northd: don't include disabled LSP's IP to Load Balancing
On Mon, Sep 12, 2022 at 6:11 PM Vladislav Odintsov wrote:
>
> If one has a UDP load balancer with backend IP which is located under
> disabled LSP, such backend would be threated as alive and marked as
> 'online' on Service_Monitor table and added to load balancing as well.
> Though such LSP can't receive any traffic, this load balancer will be
> broken by mentioned behaviour.
>
> This patch resolves this issue for Load Balancers with enabled health
> check: if LSP is disabled, it wont be added to Service_Monitor and to
> Load Balancing flow.
>
> Signed-off-by: Vladislav Odintsov
Thanks. Applied to main and backported upto branch-22.03.
Numan
> ---
> northd/northd.c | 10 ++
> tests/ovn-northd.at | 19 +++
> 2 files changed, 25 insertions(+), 4 deletions(-)
>
> diff --git a/northd/northd.c b/northd/northd.c
> index 1eb190dc1..76007bd4d 100644
> --- a/northd/northd.c
> +++ b/northd/northd.c
> @@ -3713,7 +3713,8 @@ ovn_lb_svc_create(struct ovsdb_idl_txn *ovnsb_txn,
> struct ovn_northd_lb *lb,
> backend_nb->op = op;
> backend_nb->svc_mon_src_ip = svc_mon_src_ip;
>
> -if (!lb_vip_nb->lb_health_check || !op || !svc_mon_src_ip) {
> +if (!lb_vip_nb->lb_health_check || !op || !svc_mon_src_ip ||
> +!lsp_is_enabled(op->nbsp)) {
> continue;
> }
>
> @@ -3777,9 +3778,10 @@ build_lb_vip_actions(struct ovn_lb_vip *lb_vip,
> struct ovn_lb_backend *backend = &lb_vip->backends[i];
> struct ovn_northd_lb_backend *backend_nb =
> &lb_vip_nb->backends_nb[i];
> -if (backend_nb->health_check && backend_nb->sbrec_monitor &&
> -backend_nb->sbrec_monitor->status &&
> -strcmp(backend_nb->sbrec_monitor->status, "online")) {
> +if (!backend_nb->health_check ||
> +(backend_nb->health_check && backend_nb->sbrec_monitor &&
> + backend_nb->sbrec_monitor->status &&
> + strcmp(backend_nb->sbrec_monitor->status, "online"))) {
> continue;
> }
>
> diff --git a/tests/ovn-northd.at b/tests/ovn-northd.at
> index da83bce7c..7c3c84007 100644
> --- a/tests/ovn-northd.at
> +++ b/tests/ovn-northd.at
> @@ -1230,6 +1230,25 @@ OVS_WAIT_FOR_OUTPUT(
>(ls_in_lb ), priority=120 , match=(ct.new && ip4.dst ==
> 10.0.0.10 && tcp.dst == 80), action=(reg0[[1]] = 0;
> ct_lb(backends=10.0.0.3:80,20.0.0.3:80);)
> ])
>
> +# disabled LSPs should not be a backend of Load Balancer
> +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' |
> sed 's/table=..//'], 0, [dnl
> + (ls_in_lb ), priority=120 , match=(ct.new && ip4.dst ==
> 10.0.0.10 && tcp.dst == 80), action=(reg0[[1]] = 0;
> ct_lb(backends=20.0.0.3:80);)
> +])
> +wait_row_count Service_Monitor 1
> +
> +check ovn-nbctl lsp-set-enabled sw0-p1 enabled
> +
> +AT_CAPTURE_FILE([sbflows])
> +OVS_WAIT_FOR_OUTPUT(
> + [ovn-sbctl dump-flows sw0 | tee sbflows | grep 'priority=120.*backends' |
> sed 's/table=..//'], 0, [dnl
> + (ls_in_lb ), priority=120 , match=(ct.new && ip4.dst ==
> 10.0.0.10 && tcp.dst == 80), action=(reg0[[1]] = 0;
> ct_lb(backends=10.0.0.3:80,20.0.0.3:80);)
> +])
> +wait_row_count Service_Monitor 2
> +
> AS_BOX([Delete the Load_Balancer_Health_Check])
> ovn-nbctl --wait=sb clear load_balancer . health_check
> wait_row_count Service_Monitor 0
> --
> 2.36.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] stateless acl on ovn-k8s interface
On Tue, Sep 13, 2022 at 6:41 PM venugopal iyer via dev
wrote:
>
> Hi, Han, Numan:
> While testing a use case in our ovn-k8s cluster we ran into an issue where
> wecouldn't effectively use stateless ACL on the OVN interface. Turns out we
> will track
> all the packets here, since there will be a some VIPs configured on the
> logical
> switch and...
>
>
> if (od->has_lb_vip) {
> ovn_lflow_add(lflows, od, S_SWITCH_IN_PRE_LB,
> 100, "ip", REGBIT_CONNTRACK_NAT" = 1; next;");...
>
> even though pre_acl skips stateless flows. One option is to just try an
> excludethe flows in pre_lb with hints from pre_acl, but that alone won't work
> since
> pre_lb precedes pre_acl in egress.
>
> So, wanted to check if the following will work: - Use info from pre_acl to
> exclude stateless flows when we track for vip- Switch pre_lb and pre_acl in
> egress.
>
> I tested this with our ovn-k8s cicd, manual stateless rules and using a
> specificuse case (RoCE with stateless rules) and it worked, but not sure if i
> am missinganything by switching pre acl and lb in egress.
>
> I can send the official patch, but just as an FYI, following is the change i
> amlooking at as a proof of concept:
>
> diff --git a/northd/northd.c b/northd/northd.c
> index 98ef97f90..022b20660 100644
> --- a/northd/northd.c
> +++ b/northd/northd.c
> @@ -128,8 +128,8 @@ enum ovn_stage {
> PIPELINE_STAGE(SWITCH, IN, L2_UNKNOWN,25, "ls_in_l2_unknown")\
>\
> /* Logical switch egress stages. */ \
> -PIPELINE_STAGE(SWITCH, OUT, PRE_LB, 0, "ls_out_pre_lb") \
> -PIPELINE_STAGE(SWITCH, OUT, PRE_ACL, 1, "ls_out_pre_acl")\
> +PIPELINE_STAGE(SWITCH, OUT, PRE_ACL, 0, "ls_out_pre_acl")\
> +PIPELINE_STAGE(SWITCH, OUT, PRE_LB, 1, "ls_out_pre_lb") \
> PIPELINE_STAGE(SWITCH, OUT, PRE_STATEFUL, 2, "ls_out_pre_stateful") \
> PIPELINE_STAGE(SWITCH, OUT, ACL_HINT, 3, "ls_out_acl_hint") \
> PIPELINE_STAGE(SWITCH, OUT, ACL, 4, "ls_out_acl")\
> @@ -5839,6 +5839,54 @@ build_empty_lb_event_flow(struct ovn_lb_vip *lb_vip,
> return true;
> }
>
> static void
> build_pre_lb(struct ovn_datapath *od, struct hmap *lflows)
> {
> @@ -5904,12 +5952,17 @@ build_pre_lb(struct ovn_datapath *od, struct hmap
> *lflows)
> * To fix this issue, we send all the packets to the conntrack in the
> * ingress pipeline if a load balancer is configured. We can now
> * add a lflow to drop ct.inv packets.
> + *
> + * Skip stateless rules from being tracked.
> + * stateless flows should not have REGBIT_CONNTRACK_DEFRAG+ * set in
> build pre_acls, so we can use that as an hint here.
> */
> if (od->has_lb_vip) {
> ovn_lflow_add(lflows, od, S_SWITCH_IN_PRE_LB,
> - 100, "ip", REGBIT_CONNTRACK_NAT" = 1; next;");
> + 100, REGBIT_CONNTRACK_DEFRAG" == 1",
> REGBIT_CONNTRACK_NAT" = 1; next;");
> ovn_lflow_add(lflows, od, S_SWITCH_OUT_PRE_LB,
> - 100, "ip", REGBIT_CONNTRACK_NAT" = 1; next;");
> + 100, REGBIT_CONNTRACK_DEFRAG" == 1",
> REGBIT_CONNTRACK_NAT" = 1; next;");
> }
> }
Hi Venu,
I'm not really sure if this would work. In the case of a logical
switch with no stateful ACLs and load balancers configured,
how would the traffic work if a pod sends a packet destined to the lb VIP ?
>From what I understand with your proposed patch, the register bit
REGBIT_CONNTRACK_NAT will not be set now and hence the packet will not
be
sent to conntrack.
Also I'd suggest posting your patch so that the CI gets run.
Thanks
Numan
>
>
>
>
> thanks,
> -venu
> ___
> 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: drop traffic to disabled LSPs in ingress pipeline
9d4bf4f11) [ingress]
> * "outside" (f34ded49-cf91-4932-99dd-24f0d7653ec8) [ingress]
> * Logical flow: table=22 (ls_in_external_port), priority=0, match=(1),
> actions=(next;)
> 31. metadata=0x1,dl_dst=50:54:00:00:00:03, priority 50, cookie 0x278cc83c
> drop
> * Logical datapaths:
> * "public" (a150aaf7-99ea-4635-a768-99c9d4bf4f11) [ingress]
> * Logical flow: table=23 (ls_in_l2_lkup), priority=50, match=(eth.dst ==
> 50:54:00:00:00:03), actions=(drop;)
>* Logical Switch Port: p-port1 type (addresses ['50:54:00:00:00:03
> 172.16.0.100'], dynamic addresses [], security []
>
> Final flow: unchanged
> Megaflow:
> recirc_id=0,eth,ip,in_port=LOCAL,dl_src=9a:09:91:98:16:48,dl_dst=50:54:00:00:00:03,nw_frag=no
> Datapath actions: drop
>
> [root@dev1 ~]# ovn-nbctl show public
> switch 633ad6c1-f3e5-4f31-b2fe-215203cf5272 (public)
> port p-port1
> addresses: ["50:54:00:00:00:03 172.16.0.100"]
> port ln-public
> type: localnet
> addresses: ["unknown"]
> [root@dev1 ~]# ovn-nbctl list logical-switch-port p-port1
> _uuid : b0ac9cb9-cc13-4184-af17-3fb6505975f8
> addresses : ["50:54:00:00:00:03 172.16.0.100"]
> dhcpv4_options : []
> dhcpv6_options : []
> dynamic_addresses : []
> enabled : false
> external_ids: {}
> ha_chassis_group: []
> name: p-port1
> options : {}
> parent_name : []
> port_security : []
> tag : []
> tag_request : []
> type: ""
> up : true
> [root@dev1 ~]# ovn-nbctl list logical-switch-port ln-public
> _uuid : e51d2489-e3da-4989-935c-949533b00b35
> addresses : [unknown]
> dhcpv4_options : []
> dhcpv6_options : []
> dynamic_addresses : []
> enabled : []
> external_ids: {}
> ha_chassis_group: []
> name: ln-public
> options : {network_name=public}
> parent_name : []
> port_security : []
> tag : []
> tag_request : []
> type: localnet
> up : false
>
> Regards,
> Vladislav Odintsov
>
> > On 15 Sep 2022, at 17:51, Numan Siddique wrote:
> >
> > On Thu, Sep 15, 2022 at 10:30 AM Vladislav Odintsov > <mailto:odiv...@gmail.com>> wrote:
> >>
> >> Hi Numan,
> >>
> >> thanks for the provided case. Unfortunately, I’m now sure I correctly
> >> understand it.
> >> Could you please provide ovn-nbctl commands to create such a topology so I
> >> could reproduce and recheck?
> >
> > Something like
> >
> > ovn-nbctl ls-add public
> > # localnet port
> > ovn-nbctl lsp-add public ln-public
> > ovn-nbctl lsp-set-type ln-public localnet
> > ovn-nbctl lsp-set-addresses ln-public unknown
> > ovn-nbctl lsp-set-options ln-public network_name=public
> >
> > # create a logical port
> > ovn-nbctl lsp-add public p-port1
> > ovn-nbctl lsp-set-addresses p-port1 "50:54:00:00:00:03 172.16.0.100"
> > (assuming 172.16.0.0/24 is the provider network CIDR)
> >
> > # attach p-port1 to a VM/container
> >
> > ovs-vsctl set open . external_ids:ovn-bridge-mappings="br-ex:public"
> >
> > # Create br-ex and attach physical interface to br-ex.
> >
> > If you ping from an external machine with say IP 172.16.0.20 to
> > p-port1 (172.16.0.100), then the packet will enter
> > physical interface -> br-ex -> patch port -> br-int (using ln-public)
> > and it will enter logical ingress pipeline of public
> > and then egress pipeline of public and then delivered to p-public.
> >
> > Thanks
> > Numan
> >
> >
> >
> >
> >>
> >> Regards,
> >> Vladislav Odintsov
> >>
> >>> On 15 Sep 2022, at 15:42, Numan Siddique >>> <mailto:num...@ovn.org>> wrote:
> >>>
> >>> On Thu, Sep 8, 2022 at 7:41 AM Vladislav Odintsov >>> <mailto:odiv...@gmail.com> <mailto:odiv...@gmail.com
> >>> <mailto:odiv...@gmail.com>>> wrote:
> >>>>
> >>>> Prior to this patch traffic to LSPs, which are disabled with
> >>>> `ovn-nbctl lsp-set-enabled disabled` was dropped in the end of
> >>>> lswitch egress pipeline. This means that traffic is processed in vain:
> >>>> - traffic, which should be dropped, first travels from one chassis to
> &
Re: [ovs-dev] [PATCH ovn v3 0/4] northd: Optimize preparation of load balancers.
On Tue, Sep 13, 2022 at 1:19 PM Han Zhou wrote: > > On Mon, Sep 12, 2022 at 3:25 AM Dumitru Ceara wrote: > > > > On 9/9/22 23:32, Ilya Maximets wrote: > > > Re-compute of 'northd' node in ovn-northd may take almost half of the > > > total processing time in case there is a big number of load balancers > > > applied to multiple switches/routers or if there are huge load balancer > > > groups applied to them. The latter is a common case for ovn-kubernetes > > > clusters. > > > > > > This patch set is a result of profiling ovn-northd in ovn-heater > > > density-heavy scenario with 500 fake nodes, which supposed to resemble > > > high scale ovn-kubernetes setups. > > > > > > There are no functional changes, only mechanical optimizations that > > > allows to achieve exactly the same result by doing less work. > > > > > > In total these patches allowed to speed up ovn-northd in the > > > aforementioned scenario by about 40%. For exmaple, average northd > > > poll interval went down from 19.7 seconds to 10.2 seconds. And the > > > maximum poll interval reduced from 31.7 to 14.9 seconds. > > > > > > > > > Version 2: > > > - Moved LB-specific structures and function to lib/lb.[c,h]. > > > - 'ods' array in struct ovn_lb_group split in two: ls and lr. > > > - Added missed handling of 'skip_snat' and 'event' options. > > > - Minor re-base/re-factor. > > > - Added 'Acked-by' from Dumitru to patches 1 and 4. > > > > > > Version 3: > > > - Code to manage struct ovn_lb_group split into separate functions > > >in lib/lb.[c,h]: > > > * ovn_lb_group_create() > > > * ovn_lb_group_destroy() > > > * ovn_lb_group_add_ls/lr() > > > - Added 'Acked-by' from Dumitru to remaining patches. > > > > > > > I had another look at this version and the patches look good to go to > > me; thanks! > > > Thanks Ilya and Dumitru. > Now that this series is merged to main. Shall we discuss/vote if it is > required to be backported? Dumitru has proposed it to be backported down to > the LTS branch-22.03. > Although it is not a bug fix, it seems to be important for large scale > environments with heavy LB usage. Any objections? No objections from my side. Thanks Numan > > Thanks, > Han > ___ > 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: drop traffic to disabled LSPs in ingress pipeline
On Thu, Sep 15, 2022 at 7:59 PM Vladislav Odintsov wrote:
>
> Numan,
>
> I’ve just to be sure we’re on the same page about moving drop flow.
> You have reviewed this patch v1 or v2 [1]?
I reviewed v2.
Thanks
Numan
>
> 1:
> https://patchwork.ozlabs.org/project/ovn/patch/20220908140644.2647859-1-odiv...@gmail.com/
>
> Regards,
> Vladislav Odintsov
>
> > On 16 Sep 2022, at 02:25, Vladislav Odintsov wrote:
> >
> > Ok,
> > I’ll correct patch and resend v2.
> >
> > Regards,
> > Vladislav Odintsov
> >
> >> On 16 Sep 2022, at 01:06, Numan Siddique >> <mailto:num...@ovn.org>> wrote:
> >>
> >> On Thu, Sep 15, 2022 at 12:46 PM Vladislav Odintsov >> <mailto:odiv...@gmail.com> <mailto:odiv...@gmail.com
> >> <mailto:odiv...@gmail.com>>> wrote:
> >>>
> >>> I’ve tried this setup and it seems working correctly to me (with this
> >>> patch applied).
> >>> First, I checked that when p-port1 is enabled, the traffic passes
> >>> (succeeded), next, I’ve disabled p-port1.
> >>> The traffic got dropped if an excess drop lflow in l2_lkup table:
> >>
> >> Ok. Thanks for testing this scenario and correcting me. I think it's
> >> still better to drop both in ingress pipeline (at the beginning -
> >> in_port_sec_check stage) and in egress pipeline as I suggested if the
> >> lport is disabled.
> >>
> >>
> >> Thanks
> >> Numan
> >>
> >>>
> >>>
> >>> [root@dev1 ~]# ovs-appctl ofproto/trace
> >>> 'recirc_id(0),in_port(internet),eth(src=9a:09:91:98:16:48,dst=50:54:00:00:00:03),eth_type(0x0800),ipv4(frag=no)'
> >>> | ovn-detrace
> >>> Flow:
> >>> ip,in_port=LOCAL,vlan_tci=0x,dl_src=9a:09:91:98:16:48,dl_dst=50:54:00:00:00:03,nw_src=0.0.0.0,nw_dst=0.0.0.0,nw_proto=0,nw_tos=0,nw_ecn=0,nw_ttl=0
> >>>
> >>> bridge("internet")
> >>> --
> >>> 0. priority 0
> >>> NORMAL
> >>> -> forwarding to learned port
> >>>
> >>> bridge("br-int")
> >>>
> >>> 0. in_port=260,vlan_tci=0x/0x1000, priority 100, cookie 0x6aca4e04
> >>> set_field:0x2->reg11
> >>> set_field:0x3->reg12
> >>> set_field:0x1->metadata
> >>> set_field:0x1->reg14
> >>> resubmit(,8)
> >>> * Logical datapath: "public" (a150aaf7-99ea-4635-a768-99c9d4bf4f11)
> >>> * Port Binding: logical_port "ln-public", tunnel_key 1,
> >>> 8. metadata=0x1, priority 50, cookie 0x6e9dd5a0
> >>> set_field:0/0x1000->reg10
> >>> resubmit(,73)
> >>> * Logical datapaths:
> >>> * "public" (a150aaf7-99ea-4635-a768-99c9d4bf4f11) [ingress]
> >>> * "outside" (f34ded49-cf91-4932-99dd-24f0d7653ec8) [ingress]
> >>> * Logical flow: table=0 (ls_in_check_port_sec), priority=50, match=(1),
> >>> actions=(reg0[15] = check_in_port_sec(); next;)
> >>> 73. reg0=0x2, priority 0
> >>> drop
> >>> move:NXM_NX_REG10[12]->NXM_NX_XXREG0[111]
> >>> -> NXM_NX_XXREG0[111] is now 0
> >>> resubmit(,9)
> >>> 9. metadata=0x1, priority 0, cookie 0xe9361b4d
> >>> resubmit(,10)
> >>> * Logical datapaths:
> >>> * "public" (a150aaf7-99ea-4635-a768-99c9d4bf4f11) [ingress]
> >>> * "outside" (f34ded49-cf91-4932-99dd-24f0d7653ec8) [ingress]
> >>> * Logical flow: table=1 (ls_in_apply_port_sec), priority=0, match=(1),
> >>> actions=(next;)
> >>> 10. metadata=0x1, priority 0, cookie 0x15c54e25
> >>> resubmit(,11)
> >>> * Logical datapaths:
> >>> * "public" (a150aaf7-99ea-4635-a768-99c9d4bf4f11) [ingress]
> >>> * "outside" (f34ded49-cf91-4932-99dd-24f0d7653ec8) [ingress]
> >>> * Logical flow: table=2 (ls_in_lookup_fdb), priority=0, match=(1),
> >>> actions=(next;)
> >>> 11. metadata=0x1, priority 0, cookie 0x5ed9f6ec
> >>> resubmit(,12)
> >>> * Logical datapaths:
> >>> * "public" (a150aaf7-99ea-4635-a768-99c9d4bf4f11) [ingress]
> >>> * "outside" (f34ded49-cf91-4932-99dd-24f0d7653ec8) [ingress]
> >>> * Logical flow: table=3 (ls_in_put_fdb), priority=0, match=(1),
> >>> actions=(next;)
> >>> 12. m
Re: [ovs-dev] [PATCH ovn] northd: Use bitmaps instead of exclusive hash map for datapath groups.
On Tue, Sep 13, 2022 at 7:34 AM Ilya Maximets wrote: > > Every time a new logical flow is created, ovn-northd creates an > exclusive hash map to collect all the datapaths this logical flow is > applicable to. While adding a new datapath to existing logical flow > hmapx will perform a lookup by hash and then add a new entry by > allocating a piece of memory and putting it into a hash map. When > all the logical flows are created and all the datapath groups are > ready, northd is collecting all the unique groups by comparing them > to each other, destroying duplicates and replacing them with a pointer > to a one true group. After that, northd is analyzing all the existing > flows in the Sb DB and comparing their groups to ones that the flow > should have. At the end all the remaining exclusive hash maps > containing datapath groups are destroyed. > > The process is fairly inefficient. The number of unique datapath > groups is typically much smaller than the number of logical flows. > So, in high-scale environments we may end up generating hundreds > of thousands equal groups just to discard them later. > Every element in a group is a separately allocated piece of memory > added to a hash map. This imposes significant cost of allocating > them and freeing later. Comparison of 2 hash maps to check for > equality involves looking up every element of one hash map in another, > which is not a very fast operation either. Also hash maps are > inherently cache-unfriendly, so every access during iteration > likely results in a cache miss. > > As a result, all these datapath group manipulations end up taking > most of the processing time in northd. > > Let's enumerate all the logical datapaths we have assigning a > unique index from zero to the total number of datapaths. And > create an array of datapaths for a quick access by their index. > Having that, instead of collecting datapath pointers in hash > maps, we can use bitmaps instead and turn on bits that correspond > to datapaths relevant to particular group. Later we can reconstruct > the group by iterating over a bitmap and taking required datapaths > from the array. > > Advantages: > > - Bitmaps are relatively small. It will be only 125 bytes to >accommodate a setup with 1000 datapaths. At the same time hmapx >with just one element will end up with 2 separate memory allocations >to allocate at least 4 buckets and a hmapx_node. In total that can >be less than a bitmap with only one datapath, but it will be only >2-3x less and comparison becomes irrelevant as soon as there is at >least one big datapath group. > > - Bitmaps are trivial to compare. Simple memcmp does the trick. >And memcmp will have one the most optimized implementations for >the actual hardware in use. > > - Flipping bits or checking if a certain bit is set in constant time. >Asymptotically same as in hash maps, but the constant is much lower. > > - Cache-friendly. Depending on a system and the scale, the whole map >can fit into a single cache line or two. All the data is sequential >in memory. > > - Reduced number of memory allocations/deallocations. Bitmap is >allocated and freed only once as a single piece. hmapx allocates >memory for every datapath. > > Disadvantage: > > - Counting number of bits in a bitmap is a bit heavier than just >getting hmapx_count(), but we're not doing that very frequently, >so it doesn't seem to impact performance in any meaningful way. > > Testing with ovn-heater shows up to 3x performance improvement for > 500-node density-heavy scenario. In this case northd poll intervals > went down from 10 to 3 seconds, driving the test maximum latency from > 21 down to 6.5 seconds. And overall test time went down from 2400 to > 720 seconds. Memory consumption for the northd process also reduced > from 3.9 GB to 1.6 GB RSS. > > One design consideration was to make 'datapaths_array' and the > 'n_dataptahs' variables global. Logically, from the perspective of > the I-P engine, they should be part of the northd-generated 'data'. > And it's not a problem for the array itself, since it is only used in > a couple of places. However, 'n_datapaths' is used practically > everywhere, including ovn_lflow_add(), so we'll have to pass it around > in most of the functions in northd as an argument. Taking that into > account, I decided to make them both global to avoid touching half of > the northd code. > We also have a couple of other global variables already (mainly for > parallel processing) that should technically be part of the I-P data, > but it is way simpler to keep them
Re: [ovs-dev] [PATCH ovn branch-22.03] Allow for setting the Next server IP in the DHCP header
On Mon, Aug 22, 2022 at 3:46 PM Mark Michelson wrote:
>
> From: Lucas Alvares Gomes
>
> In order to PXE boot a baremetal server using the OVN DHCP server we
> need to allow users to set the "next-server" (siaddr) [0] field in the
> DHCP header.
>
> While investigating this issue by comparing the DHCPOFFER and DHCPACK
> packets sent my dnsmasq and OVN we saw that the "next-server" field
> was the problem for OVN, without it PXE booting was timing out while
> fetching the iPXE image from the TFTP server (see the bugzilla ticket
> below for reference).
>
> To confirm this problem we created a bogus patch hardcoding the TFTP
> address in the siaddr of the DHCP header (see the discussion in the
> maillist below) and with this in place we were able to deploy a
> baremetal node using the OVN DHCP end-to-end.
>
> This patch is a proper implementation that creates a new DHCP
> configuration option called "next_server" to allow users to set this
> field dynamically. This patch uses the DHCP code 253 which is a unsed
> code for DHCP specification as this is not a normal DHCP option but a
> special use case in OVN.
>
> [0]
> https://github.com/openvswitch/ovs/blob/9dd3031d2e0e9597449e95428320ccaaff7d8b3d/lib/dhcp.h#L42
>
> Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2083629
> Reported-at:
> https://mail.openvswitch.org/pipermail/ovs-discuss/2022-May/051821.html
> Signed-off-by: Lucas Alvares Gomes
> Signed-off-by: Numan Siddique
> (cherry picked from commit 0057cde2a64749bd2dbbaff525f7a1edccbd9c8a)
> Signed-off-by: Mark Michelson
Is this patch still not merged to OVN 22.03 ? Since it already has
all the Acks and merged in the main branch. I think you can go ahead
and apply it.
+1 from me.
Thanks
Numan
> ---
> NEWS | 2 ++
> controller/pinctrl.c | 69 ++--
> lib/actions.c| 13 -
> lib/ovn-l7.h | 8 +
> northd/ovn-northd.c | 1 +
> ovn-nb.xml | 7 +
> tests/ovn.at | 6 ++--
> tests/test-ovn.c | 1 +
> 8 files changed, 82 insertions(+), 25 deletions(-)
>
> diff --git a/NEWS b/NEWS
> index 73f92b447..6bd9f054d 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -2,6 +2,8 @@ OVN v22.03.2 - xx xxx
> --
>- Support (LSP.options:qos_min_rate) to guarantee minimal bandwidth
> available
> for a logical port.
> + - Added support for setting the Next server IP in the DHCP header
> +using the private DHCP option - 253 in native OVN DHCPv4 responder.
>
> OVN v22.03.1 - 03 Jun 2022
> --
> diff --git a/controller/pinctrl.c b/controller/pinctrl.c
> index 2c1dd8501..fd4d9a875 100644
> --- a/controller/pinctrl.c
> +++ b/controller/pinctrl.c
> @@ -2206,30 +2206,56 @@ pinctrl_handle_put_dhcp_opts(
> *| 4 Bytes padding | 1 Byte (option end 0xFF ) | 4 Bytes padding|
> * --
> */
> -struct dhcp_opt_header *in_dhcp_opt =
> -(struct dhcp_opt_header *)reply_dhcp_opts_ptr->data;
> -if (in_dhcp_opt->code == DHCP_OPT_BOOTFILE_CODE) {
> -unsigned char *ptr = (unsigned char *)in_dhcp_opt;
> -int len = sizeof *in_dhcp_opt + in_dhcp_opt->len;
> -struct dhcp_opt_header *next_dhcp_opt =
> -(struct dhcp_opt_header *)(ptr + len);
> -
> -if (next_dhcp_opt->code == DHCP_OPT_BOOTFILE_ALT_CODE) {
> -if (!ipxe_req) {
> -ofpbuf_pull(reply_dhcp_opts_ptr, len);
> -next_dhcp_opt->code = DHCP_OPT_BOOTFILE_CODE;
> -} else {
> -char *buf = xmalloc(len);
> +ovs_be32 next_server = in_dhcp_data->siaddr;
> +bool bootfile_name_set = false;
> +in_dhcp_ptr = reply_dhcp_opts_ptr->data;
> +end = (const char *)reply_dhcp_opts_ptr->data +
> reply_dhcp_opts_ptr->size;
> +
> +while (in_dhcp_ptr < end) {
> +struct dhcp_opt_header *in_dhcp_opt =
> +(struct dhcp_opt_header *)in_dhcp_ptr;
> +
> +switch (in_dhcp_opt->code) {
> +case DHCP_OPT_NEXT_SERVER_CODE:
> +next_server = get_unaligned_be32(DHCP_OPT_PAYLOAD(in_dhcp_opt));
> +break;
> +case DHCP_OPT_BOOTFILE_CODE: ;
> +unsigned char *ptr = (unsigned char *)in_dhcp_opt;
> +int len = sizeof *in_dhcp_opt + in_dhcp_opt->len;
> +struct dhcp_opt_header *next_dhcp_opt =
> +(struct dhcp_opt_header *)(ptr + len);
> +
> +if (next_dhcp_opt->code == DHCP_OPT_BOOTFILE_ALT_CODE) {
> +if (!ipxe_req) {
>
Re: [ovs-dev] [PATCH ovn branch-22.09 1/2] Set release date for 22.09.0.
On Fri, Sep 16, 2022 at 11:38 AM Mark Michelson wrote: > > Signed-off-by: Mark Michelson Acked-by: Numan Siddique I'm sure you're already aware of it (but just as a reminder) that this patch should also be merged to the main branch. Thanks Numan > --- > NEWS | 2 +- > debian/changelog | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/NEWS b/NEWS > index 4e2f18472..ef6a99fed 100644 > --- a/NEWS > +++ b/NEWS > @@ -1,4 +1,4 @@ > -OVN v22.09.0 - xx xxx > +OVN v22.09.0 - 16 Sep 2022 > -- >- ovn-controller: Add configuration knob, through OVS external-id > "ovn-encap-df_default" to enable or disable tunnel DF flag. > diff --git a/debian/changelog b/debian/changelog > index 2c0d8a864..6e0f82b7f 100644 > --- a/debian/changelog > +++ b/debian/changelog > @@ -2,7 +2,7 @@ ovn (22.09.0-1) unstable; urgency=low > > * New upstream version > > - -- OVN team Fri, 19 Aug 2022 08:46:02 -0400 > + -- OVN team Fri, 16 Sep 2022 11:37:08 -0400 > > ovn (22.06.0-1) unstable; urgency=low > > -- > 2.37.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-22.09 2/2] Prepare for 22.09.1.
On Fri, Sep 16, 2022 at 11:38 AM 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 ef6a99fed..0392d8d23 100644 > --- a/NEWS > +++ b/NEWS > @@ -1,3 +1,6 @@ > +OVN v22.09.1 - xx xxx > +-- > + > OVN v22.09.0 - 16 Sep 2022 > -- >- ovn-controller: Add configuration knob, through OVS external-id > diff --git a/configure.ac b/configure.ac > index 765aacb17..c79d79ffe 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -13,7 +13,7 @@ > # limitations under the License. > > AC_PREREQ(2.63) > -AC_INIT(ovn, 22.09.0, b...@openvswitch.org) > +AC_INIT(ovn, 22.09.1, 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 6e0f82b7f..2d29ae027 100644 > --- a/debian/changelog > +++ b/debian/changelog > @@ -1,3 +1,9 @@ > +OVN (22.09.1-1) unstable; urgency=low > + [ OVN team ] > + * New upstream version > + > + -- OVN team Fri, 16 Sep 2022 11:37:08 -0400 > + > ovn (22.09.0-1) unstable; urgency=low > > * New upstream version > -- > 2.37.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] northd: Use bitmaps instead of exclusive hash map for datapath groups.
On Fri, Sep 16, 2022 at 11:59 AM Numan Siddique wrote: > > On Tue, Sep 13, 2022 at 7:34 AM Ilya Maximets wrote: > > > > Every time a new logical flow is created, ovn-northd creates an > > exclusive hash map to collect all the datapaths this logical flow is > > applicable to. While adding a new datapath to existing logical flow > > hmapx will perform a lookup by hash and then add a new entry by > > allocating a piece of memory and putting it into a hash map. When > > all the logical flows are created and all the datapath groups are > > ready, northd is collecting all the unique groups by comparing them > > to each other, destroying duplicates and replacing them with a pointer > > to a one true group. After that, northd is analyzing all the existing > > flows in the Sb DB and comparing their groups to ones that the flow > > should have. At the end all the remaining exclusive hash maps > > containing datapath groups are destroyed. > > > > The process is fairly inefficient. The number of unique datapath > > groups is typically much smaller than the number of logical flows. > > So, in high-scale environments we may end up generating hundreds > > of thousands equal groups just to discard them later. > > Every element in a group is a separately allocated piece of memory > > added to a hash map. This imposes significant cost of allocating > > them and freeing later. Comparison of 2 hash maps to check for > > equality involves looking up every element of one hash map in another, > > which is not a very fast operation either. Also hash maps are > > inherently cache-unfriendly, so every access during iteration > > likely results in a cache miss. > > > > As a result, all these datapath group manipulations end up taking > > most of the processing time in northd. > > > > Let's enumerate all the logical datapaths we have assigning a > > unique index from zero to the total number of datapaths. And > > create an array of datapaths for a quick access by their index. > > Having that, instead of collecting datapath pointers in hash > > maps, we can use bitmaps instead and turn on bits that correspond > > to datapaths relevant to particular group. Later we can reconstruct > > the group by iterating over a bitmap and taking required datapaths > > from the array. > > > > Advantages: > > > > - Bitmaps are relatively small. It will be only 125 bytes to > >accommodate a setup with 1000 datapaths. At the same time hmapx > >with just one element will end up with 2 separate memory allocations > >to allocate at least 4 buckets and a hmapx_node. In total that can > >be less than a bitmap with only one datapath, but it will be only > >2-3x less and comparison becomes irrelevant as soon as there is at > >least one big datapath group. > > > > - Bitmaps are trivial to compare. Simple memcmp does the trick. > >And memcmp will have one the most optimized implementations for > >the actual hardware in use. > > > > - Flipping bits or checking if a certain bit is set in constant time. > >Asymptotically same as in hash maps, but the constant is much lower. > > > > - Cache-friendly. Depending on a system and the scale, the whole map > >can fit into a single cache line or two. All the data is sequential > >in memory. > > > > - Reduced number of memory allocations/deallocations. Bitmap is > >allocated and freed only once as a single piece. hmapx allocates > >memory for every datapath. > > > > Disadvantage: > > > > - Counting number of bits in a bitmap is a bit heavier than just > >getting hmapx_count(), but we're not doing that very frequently, > >so it doesn't seem to impact performance in any meaningful way. > > > > Testing with ovn-heater shows up to 3x performance improvement for > > 500-node density-heavy scenario. In this case northd poll intervals > > went down from 10 to 3 seconds, driving the test maximum latency from > > 21 down to 6.5 seconds. And overall test time went down from 2400 to > > 720 seconds. Memory consumption for the northd process also reduced > > from 3.9 GB to 1.6 GB RSS. > > > > One design consideration was to make 'datapaths_array' and the > > 'n_dataptahs' variables global. Logically, from the perspective of > > the I-P engine, they should be part of the northd-generated 'data'. > > And it's not a problem for the array itself, since it is only used in > > a couple of places. However, 'n_d
Re: [ovs-dev] [PATCH ovn] lb: Remove unused ovn_northd_lb_vip vip_port_str member.
On Mon, Sep 19, 2022 at 2:06 AM Ales Musil wrote:
>
> On Fri, Aug 26, 2022 at 2:35 PM Dumitru Ceara wrote:
>
> > Signed-off-by: Dumitru Ceara
> > ---
> > lib/lb.c | 5 +
> > lib/lb.h | 1 -
> > 2 files changed, 1 insertion(+), 5 deletions(-)
> >
> > diff --git a/lib/lb.c b/lib/lb.c
> > index 7b0ed1abe..580efe7f7 100644
> > --- a/lib/lb.c
> > +++ b/lib/lb.c
> > @@ -103,7 +103,6 @@ void ovn_northd_lb_vip_init(struct ovn_northd_lb_vip
> > *lb_vip_nb,
> > const struct nbrec_load_balancer *nbrec_lb,
> > const char *vip_port_str, const char
> > *backend_ips)
> > {
> > -lb_vip_nb->vip_port_str = xstrdup(vip_port_str);
> > lb_vip_nb->backend_ips = xstrdup(backend_ips);
> > lb_vip_nb->n_backends = lb_vip->n_backends;
> > lb_vip_nb->backends_nb = xcalloc(lb_vip_nb->n_backends,
> > @@ -121,8 +120,7 @@ void ovn_northd_lb_vip_init(struct ovn_northd_lb_vip
> > *lb_vip_nb,
> > }
> > } else {
> > for (size_t j = 0; j < nbrec_lb->n_health_check; j++) {
> > -if (!strcmp(nbrec_lb->health_check[j]->vip,
> > -lb_vip_nb->vip_port_str)) {
> > +if (!strcmp(nbrec_lb->health_check[j]->vip, vip_port_str)) {
> > lb_health_check = nbrec_lb->health_check[j];
> > break;
> > }
> > @@ -135,7 +133,6 @@ void ovn_northd_lb_vip_init(struct ovn_northd_lb_vip
> > *lb_vip_nb,
> > static
> > void ovn_northd_lb_vip_destroy(struct ovn_northd_lb_vip *vip)
> > {
> > -free(vip->vip_port_str);
> > free(vip->backend_ips);
> > for (size_t i = 0; i < vip->n_backends; i++) {
> > free(vip->backends_nb[i].svc_mon_src_ip);
> > diff --git a/lib/lb.h b/lib/lb.h
> > index 832ed31fb..4bcf123b3 100644
> > --- a/lib/lb.h
> > +++ b/lib/lb.h
> > @@ -70,7 +70,6 @@ struct ovn_lb_backend {
> >
> > /* ovn-northd specific backend information. */
> > struct ovn_northd_lb_vip {
> > -char *vip_port_str;
> > char *backend_ips;
> > struct ovn_northd_lb_backend *backends_nb;
> > size_t n_backends;
> > --
> > 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.
Numan
>
> --
>
> Ales Musil
>
> Senior Software Engineer - OVN Core
>
> Red Hat EMEA
>
> amu...@redhat.comIM: amusil
>
> ___
> 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] MAINTAINERS: Add Dumitru Ceara.
On Wed, Sep 21, 2022 at 11:33 AM Dumitru Ceara wrote: > > On 9/21/22 16:03, Mark Michelson wrote: > > Acked-by: Mark Michelson > > > > Congrats, Dumitru! Thanks. Applied to main. Congrats, Dumitru ! Numan > > > > On 9/21/22 07:20, num...@ovn.org wrote: > >> From: Numan Siddique > >> > >> Dumitru was elected by the OVN committers on 20-Sep-2022. Welcome to the > >> team, Dumitru! > >> > >> Signed-off-by: Numan Siddique > >> --- > > Thanks! > > ___ > 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] [OVN v6] OVN - Add Support for Remote Port Mirroring
On Sun, Sep 11, 2022 at 10:26 AM Abhiram R N wrote:
>
> Added changes in ovn-nbctl, ovn-sbctl, northd and in ovn-controller.
> While Mirror creation just creates the mirror, the lsp-attach-mirror
> triggers the sequence to create Mirror in OVS DB on compute node.
> OVS already supports Port Mirroring.
>
> Note: This is targeted to mirror to destinations anywhere outside the
> cluster where the analyser resides and it need not be an OVN node.
>
> Example commands are as below:
>
> Mirror creation
> ovn-nbctl mirror-add mirror1 gre 0 from-lport 10.10.10.2
>
> Attach a logical port to the mirror.
> ovn-nbctl lsp-attach-mirror sw0-port1 mirror1
>
> Detach a source from Mirror
> ovn-nbctl lsp-detach-mirror sw0-port1 mirror1
>
> Mirror deletion
> ovn-nbctl mirror-del mirror1
>
> Co-authored-by: Veda Barrenkala
> Signed-off-by: Veda Barrenkala
> Signed-off-by: Abhiram R N
Thanks for v6.
Looks like the patch needs a rebase to resolve some conflicts.
Please see below for a few comments.
> ---
>
> V5 --> V6: Fixed a memleak issue in mirror.c (missed free)
>
> V4 --> V5: Addressed review comments on V4 by Ihar
>i) Expanded test cases in ovn.at and ovn-nbctl.at
> ii) Handled case when number of mirror references
> is same but refers to different mirrors.
> iii) Did other minor changes in schema and xmls
> Files modified (V4 --> v5):
> Code --> mirror.c, northd.c, ovn-nbctl.c
> Test --> ovn-northd.at, ovn-nbctl.at, ovn.at
> Misc --> ovn-sb.ovsschema, ovn-sb.xml, ovn-nb.xml
>
> V3 --> V4: Addressed review comments from V3
>i) Fixed Issues 1,2 and 3
> ii) Did other minor changes suggested
> iii) Included Issues 1 and 3 in test cases
> Files modified (V3 --> v4):
> Code --> mirror.c, ovn-controller.c, northd.c
> Test --> ovn-northd.at, ovn-nbctl.at, ovn.at
>
> controller/automake.mk | 4 +-
> controller/mirror.c | 535
> controller/mirror.h | 53
> controller/ovn-controller.c | 222 ++-
> northd/en-northd.c | 4 +
> northd/inc-proc-northd.c| 4 +
> northd/northd.c | 172
> northd/northd.h | 2 +
> ovn-nb.ovsschema| 31 ++-
> ovn-nb.xml | 63 +
> ovn-sb.ovsschema| 26 +-
> ovn-sb.xml | 50
> tests/ovn-nbctl.at | 116
> tests/ovn-northd.at | 102 +++
> tests/ovn.at| 215 +++
> utilities/ovn-nbctl.c | 357
> utilities/ovn-sbctl.c | 4 +
> 17 files changed, 1954 insertions(+), 6 deletions(-)
> create mode 100644 controller/mirror.c
> create mode 100644 controller/mirror.h
>
> diff --git a/controller/automake.mk b/controller/automake.mk
> index c2ab1bbe6..334672b4d 100644
> --- a/controller/automake.mk
> +++ b/controller/automake.mk
> @@ -41,7 +41,9 @@ controller_ovn_controller_SOURCES = \
> controller/ovsport.h \
> controller/ovsport.c \
> controller/vif-plug.h \
> - controller/vif-plug.c
> + controller/vif-plug.c \
> + controller/mirror.h \
> + controller/mirror.c
>
> controller_ovn_controller_LDADD = lib/libovn.la
> $(OVS_LIBDIR)/libopenvswitch.la
> man_MANS += controller/ovn-controller.8
> diff --git a/controller/mirror.c b/controller/mirror.c
> new file mode 100644
> index 0..c3eb9e727
> --- /dev/null
> +++ b/controller/mirror.c
> @@ -0,0 +1,535 @@
> +/* Copyright (c) 2022 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
> +
> +/* library headers */
> +#include "lib/sset.h"
> +#include "lib/util.h"
> +
> +/* OVS includes. */
> +#include "lib/vswitch-idl.h"
> +#include "openvswitch/vlog.h"
> +
> +/* OVN includes. */
> +#include "binding.h"
> +#include "lib/ovn-sb-idl.h"
> +#include "mirror.h"
> +
> +VLOG_DEFINE_THIS_MODULE(port_mirror);
> +
> +/* Static function declarations */
> +
> +static const struct ovsrec_port *
> +get_port_for_iface(const struct ovsrec_interface *iface,
> + const struct ovsrec_bridge *br_int)
> +{
> +for (size_t i = 0; i < br_int->n_ports; i++) {
> +const struct ovsrec_port *p = br_int->ports[i];
> +for (size_t j = 0; j < p->n_interfaces; j++) {
> +if (!strcmp(iface->name, p->interfaces[j]->name)) {
> +return p
Re: [ovs-dev] [PATCH ovn v3] northd: Use separate SNAT for already-DNATted traffic.
On Tue, Sep 27, 2022 at 3:02 PM Mark Michelson wrote:
>
> Commit 4deac4509abbedd6ffaecf27eed01ddefccea40a introduced functionality
> in ovn-northd to use a single zone for SNAT and DNAT when possible. It
> accounts for certain situations, such as hairpinned traffic, where we
> still need a separate SNAT and DNAT zone.
>
> However, one situation it did not account for was when traffic traverses
> a logical router and is DNATted as a result of a load balancer, then
> when the traffic egresses the router, it needs to be SNATted. In this
> situation, we try to use the same CT zone for the SNAT as for the load
> balancer DNAT, which does not work.
>
> This commit fixes the issue by setting the DNAT_LOCAL bit in the initial
> stage of the egress pipeline if the packet was dnatted during the
> ingress pipeline. This ensures that when the SNAT stage is reached, a
> separate CT zone is used for SNAT.
>
> Signed-off-by: Mark Michelson
Acked-by: Numan Siddique
Numan
> ---
> v2 -> v3:
> * Rebased on top of current main branch
> * Fixed checkpatch issues from v2.
> * Accounted for the ct_label -> ct_mark change.
> * All tests are now passing (locally)
> ---
> northd/northd.c | 26 -
> northd/ovn-northd.8.xml | 16 ++
> tests/ovn-northd.at | 7 ++-
> tests/system-ovn.at | 117
> 4 files changed, 163 insertions(+), 3 deletions(-)
>
> diff --git a/northd/northd.c b/northd/northd.c
> index 84440a47f..5eac7fa51 100644
> --- a/northd/northd.c
> +++ b/northd/northd.c
> @@ -13633,7 +13633,8 @@ static void
> build_lrouter_nat_defrag_and_lb(struct ovn_datapath *od, struct hmap *lflows,
> const struct hmap *ports, struct ds *match,
> struct ds *actions,
> -const struct shash *meter_groups)
> +const struct shash *meter_groups,
> +bool ct_lb_mark)
> {
> if (!od->nbr) {
> return;
> @@ -13827,6 +13828,26 @@ build_lrouter_nat_defrag_and_lb(struct ovn_datapath
> *od, struct hmap *lflows,
> }
> }
>
> +if (od->nbr->n_nat) {
> +ds_clear(match);
> +const char *ct_natted = ct_lb_mark ?
> +"ct_mark.natted" :
> +"ct_label.natted";
> +ds_put_format(match, "ip && %s == 1", ct_natted);
> +/* This flow is unique since it is in the egress pipeline but checks
> + * the value of ct_label.natted, which would have been set in the
> + * ingress pipeline. If a change is ever introduced that clears or
> + * otherwise invalidates the ct_label between the ingress and egress
> + * pipelines, then an alternative will need to be devised.
> + */
> +ds_clear(actions);
> +ds_put_cstr(actions, REGBIT_DST_NAT_IP_LOCAL" = 1; next;");
> +ovn_lflow_add_with_hint(lflows, od, S_ROUTER_OUT_CHECK_DNAT_LOCAL,
> +50, ds_cstr(match), ds_cstr(actions),
> +&od->nbr->header_);
> +
> +}
> +
> /* Handle force SNAT options set in the gateway router. */
> if (od->is_gw_router) {
> if (dnat_force_snat_ip) {
> @@ -13925,7 +13946,8 @@ build_lswitch_and_lrouter_iterate_by_od(struct
> ovn_datapath *od,
> build_misc_local_traffic_drop_flows_for_lrouter(od, lsi->lflows);
> build_lrouter_arp_nd_for_datapath(od, lsi->lflows, lsi->meter_groups);
> build_lrouter_nat_defrag_and_lb(od, lsi->lflows, lsi->ports, &lsi->match,
> -&lsi->actions, lsi->meter_groups);
> +&lsi->actions, lsi->meter_groups,
> +lsi->features->ct_no_masked_label);
> }
>
> /* Helper function to combine all lflow generation which is iterated by port.
> diff --git a/northd/ovn-northd.8.xml b/northd/ovn-northd.8.xml
> index dae961c87..177b6341d 100644
> --- a/northd/ovn-northd.8.xml
> +++ b/northd/ovn-northd.8.xml
> @@ -4392,6 +4392,22 @@ nd_ns {
>
>
>
> +
> + This table also installs a priority-50 logical flow for each logical
> + router that has NATs configured on it. The flow has match
> + ip && ct_label.natted == 1 and action
> + REGBIT_DST_NAT_IP_LOCAL = 1; next;. This is intended
> + to ensure that traffic that was DNATted locally will use a separate
> + conntrack zone for SNAT if SNAT is required later in t
Re: [ovs-dev] [PATCH ovn] spec: require python3-openvswitch for ovn-detrace
On Tue, Oct 4, 2022 at 5:41 AM Dumitru Ceara wrote: > > On 9/21/22 15:36, Vladislav Odintsov wrote: > > Signed-off-by: Vladislav Odintsov > > --- > > Hi Vladislav, > > > rhel/ovn-fedora.spec.in | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/rhel/ovn-fedora.spec.in b/rhel/ovn-fedora.spec.in > > index 821eb03cc..57dc977c1 100644 > > --- a/rhel/ovn-fedora.spec.in > > +++ b/rhel/ovn-fedora.spec.in > > @@ -65,6 +65,7 @@ BuildRequires: tcpdump > > BuildRequires: unbound unbound-devel > > > > Requires: openssl hostname iproute module-init-tools openvswitch > > +Requires: python3-openvswitch > > > > Requires(post): systemd-units > > Requires(preun): systemd-units > > This change looks good to me, I tested it locally and it works fine: > > Acked-by: Dumitru Ceara > > Numan, you have more Fedora packaging experience, do you agree? LGTM Thanks. I applied this patch to the main branch and backported till branch-22.03. > > This is not something this patch should fix but it reminded me of: OVS > builds Debian packages in CI; there's a patch to do the same thing in > OVN [0]; should we do it for Fedora packages too? +1. That would be beneficial IMO. Numan > > [0] > https://patchwork.ozlabs.org/project/ovn/patch/20220805203452.3060165-6-frode.nord...@canonical.com/ > > Thanks, > 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] [OVN PATCH] northd: add unsnat/undnat lflow for established connections
On Sun, Oct 9, 2022 at 5:03 AM Wentao Jia wrote:
>
> Hi, Numan
>
> Sorry for long delay
>
> Base on your suggestions, lflow ct_snat_in_czone is split into 2 lflows，one
> lflow for ct.new, and other for ct.est.
> table=3 (lr_out_snat), priority=154 , match=(ct.est && ip &&
> ip4.src == 192.168.200.0/24 && outport ==
> "lrp-0e701852-85a0-4c57-8014-77a8607a9406" &&
> is_chassis_resident("cr-lrp-0e701852-85a0-4c57-8014-77a8607a9406")),
> action=(ct_snat_in_czone);)
> table=3 (lr_out_snat), priority=153 , match=(ct.new && ip &&
> ip4.src == 192.168.200.0/24 && outport ==
> "lrp-0e701852-85a0-4c57-8014-77a8607a9406" &&
> is_chassis_resident("cr-lrp-0e701852-85a0-4c57-8014-77a8607a9406")),
> action=(ct_snat_in_czone(1.1.1.124);)
My suggest is to have logical flows like below
--
table=1 (lr_out_undnat ), priority=100 , match=(ip && ip4.src
== 192.168.200.0/24 && outport == "lr0-public" &&
is_chassis_resident("cr-lr0-public")), action=(ct_snat_in_czone;)
table=1 (lr_out_undnat ), priority=100 , match=(ip && ip4.src
== 192.168.200.0/24 && outport == "lr0-public" &&
is_chassis_resident("cr-lr0-public") && reg9[4] == 1),
action=(ct_snat;)
table=3 (lr_out_snat), priority=154 , match=(ip && ip4.src
== 192.168.200.0/24 && outport == "lr0-public" &&
is_chassis_resident("cr-lr0-public") && reg9[4] == 1 && ct.new),
action=(reg9[4] = 0; ct_snat(1.1.1.124);)
table=3 (lr_out_snat), priority=153 , match=(ip && ip4.src
==192.168.200.0/24 && outport == "lr0-public" &&
is_chassis_resident("cr-lr0-public") && ct.new),
action=(ct_snat_in_czone(1.1.1.124);)
-
If you could share your patch or share it in your github repo, I
could probably try it out and comment.
Thanks
Numan
>
> traffic is failed, the nat action is skipped
> ufid:0e021319-00ce-4869-bb5a-aebfb6172eb9,
> skb_priority(0/0),skb_mark(0/0),ct_state(0/0x3f),ct_zone(0/0),ct_mark(0/0x3),ct_label(0/0),recirc_id(0),dp_hash(0/0),in_port(rep0_2),packet_type(ns=0/0,id=0/0),eth(src=fa:16:3e:4c:e6:1f,dst=fa:16:3e:c9:a7:6b),eth_type(0x0800),ipv4(src=192.168.210.103,dst=1.1.1.254,proto=6,tos=0/0,ttl=64,frag=no),tcp(src=0/0,dst=0/0),
> packets:2, bytes:148, used:3.230s, offloaded:yes, dp:tc,
> actions:set(eth(src=fa:16:3e:ae:b5:e5,dst=8c:1f:64:30:61:43)),set(ipv4(ttl=63)),enp1s0np1
>
> there maybe some wrong with ct_snat_in_czone, but I can not find it out
> do you have any idea about this ?
>
> B R
> Wentao Jia
>
> -Original Message-
> From: Numan Siddique
> Sent: Thursday, August 18, 2022 11:56 AM
> To: Wentao Jia
> Cc: d...@openvswitch.org
> Subject: Re: [ovs-dev] [OVN PATCH] northd: add unsnat/undnat lflow for
> established connections
>
> On Thu, Aug 18, 2022 at 1:16 PM Wentao Jia wrote:
> >
> >
> > Hi, Numan
> >
> > It is not difficult to reproduce，this is about snat/dnat rules create
> > router and create different type of nat rules of this router no other
> > issues to be considered。
> >
>
> Right. I now see the issue locally. I do see that the packet from the VM to
> outside is always committed to the conntrack (along with snat) and that's
> causing the HWOL issues.
>
> But I don't think the proposed solution is the right fix. Looks like CI
> didn't trigger for your patch here [1].
> And I pushed your patch to my local github repo and you can see lots of test
> failures - [2].
>
> In order to address this HWOL limitation, we should first send the packet to
> conntrack with the action - ct_snat_in_czone (in router egress pipeline).
> If the connection was already committed, this would snat it. If it's a new
> connection we should commit to it.
>
> Seems to me we should have flows like below (assuming there is an SNAT entry
> for 192.168.200.0/24 <-> 1.1.1.124) (please note I may not be accurate with
> the below flows)
>
> table=1 (lr_out_undnat ), priority=100 , match=(ip && ip4.src
> == 192.168.200.0/24 && outport == "lr0-public" &&
> is_chassis_resident("cr-lr0-public")), action=(ct_snat_in_czone;)
> table=1 (lr_out_undnat ), priority=100 , match=(ip && ip4.src
> == 192.168.200.0/24 && outport == "lr0-public" &&
> is_chassis_resident("cr-lr0-public") && reg9[4] == 1),
> action=(ct_snat;)
> table=3 (lr_out_snat), priority=154 , match=(ip && ip4.src
> ==
Re: [ovs-dev] [PATCH ovn] controller: Remove unused shash from update_ct_zone
On Wed, Oct 12, 2022 at 3:32 PM Mark Michelson wrote:
>
> Wow, this shash has been unused since branch-21.06 . Good find!
>
> Acked-by: Mark Michelson
Thanks. Applied to the main branch.
Numan
>
> On 10/12/22 04:07, Ales Musil wrote:
> > Signed-off-by: Ales Musil
> > ---
> > controller/ovn-controller.c | 4
> > 1 file changed, 4 deletions(-)
> >
> > diff --git a/controller/ovn-controller.c b/controller/ovn-controller.c
> > index 9969d317f..8895c7a2b 100644
> > --- a/controller/ovn-controller.c
> > +++ b/controller/ovn-controller.c
> > @@ -667,7 +667,6 @@ update_ct_zones(const struct shash *binding_lports,
> > }
> >
> > /* Local patched datapath (gateway routers) need zones assigned. */
> > -struct shash all_lds = SHASH_INITIALIZER(&all_lds);
> > const struct local_datapath *ld;
> > HMAP_FOR_EACH (ld, hmap_node, local_datapaths) {
> > /* XXX Add method to limit zone assignment to logical router
> > @@ -676,8 +675,6 @@ update_ct_zones(const struct shash *binding_lports,
> > char *snat = alloc_nat_zone_key(&ld->datapath->header_.uuid,
> > "snat");
> > sset_add(&all_users, dnat);
> > sset_add(&all_users, snat);
> > -shash_add(&all_lds, dnat, ld);
> > -shash_add(&all_lds, snat, ld);
> >
> > int req_snat_zone = get_snat_ct_zone(ld->datapath);
> > if (req_snat_zone >= 0) {
> > @@ -760,7 +757,6 @@ update_ct_zones(const struct shash *binding_lports,
> >
> > simap_destroy(&req_snat_zones);
> > sset_destroy(&all_users);
> > -shash_destroy(&all_lds);
> > }
> >
> > static void
>
> ___
> 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] util: Avoid double parsing of LB vip and backend ip
On Tue, Oct 18, 2022 at 7:23 AM Ales Musil wrote:
>
> The current code was parsing the ip twice, once for
> the "inet_parse_active" and second time by calling
> either "ip_parse" or "ipv6_parse". Avoid that by
> getting the "in6_addr" directly from "sockaddr_storage".
>
> Signed-off-by: Ales Musil
Thanks for the patch.
LGTM. Can you please also update the function comments in
lib/ovn-util.c now that the function
also sets 'struct in6_addr *ip'.
Acked-by: Numan Siddique
Numan
> ---
> lib/lb.c | 20 +++-
> lib/ovn-util.c| 5 -
> lib/ovn-util.h| 3 ++-
> utilities/ovn-trace.c | 20 ++--
> 4 files changed, 15 insertions(+), 33 deletions(-)
>
> diff --git a/lib/lb.c b/lib/lb.c
> index 77674ea28..ab5de38a8 100644
> --- a/lib/lb.c
> +++ b/lib/lb.c
> @@ -78,18 +78,11 @@ bool ovn_lb_vip_init(struct ovn_lb_vip *lb_vip, const
> char *lb_key,
> int addr_family;
>
> if (!ip_address_and_port_from_lb_key(lb_key, &lb_vip->vip_str,
> - &lb_vip->vip_port, &addr_family)) {
> + &lb_vip->vip, &lb_vip->vip_port,
> + &addr_family)) {
> return false;
> }
>
> -if (addr_family == AF_INET) {
> -ovs_be32 vip4;
> -ip_parse(lb_vip->vip_str, &vip4);
> -in6_addr_set_mapped_ipv4(&lb_vip->vip, vip4);
> -} else {
> -ipv6_parse(lb_vip->vip_str, &lb_vip->vip);
> -}
> -
> /* Format for backend ips: "IP1:port1,IP2:port2,...". */
> size_t n_backends = 0;
> size_t n_allocated_backends = 0;
> @@ -108,7 +101,7 @@ bool ovn_lb_vip_init(struct ovn_lb_vip *lb_vip, const
> char *lb_key,
> struct ovn_lb_backend *backend = &lb_vip->backends[n_backends];
> int backend_addr_family;
> if (!ip_address_and_port_from_lb_key(token, &backend->ip_str,
> - &backend->port,
> + &backend->ip, &backend->port,
> &backend_addr_family)) {
> continue;
> }
> @@ -118,13 +111,6 @@ bool ovn_lb_vip_init(struct ovn_lb_vip *lb_vip, const
> char *lb_key,
> continue;
> }
>
> -if (addr_family == AF_INET) {
> -ovs_be32 ip4;
> -ip_parse(backend->ip_str, &ip4);
> -in6_addr_set_mapped_ipv4(&backend->ip, ip4);
> -} else {
> -ipv6_parse(backend->ip_str, &backend->ip);
> -}
> n_backends++;
> }
> free(tokstr);
> diff --git a/lib/ovn-util.c b/lib/ovn-util.c
> index d80db179a..13659cd70 100644
> --- a/lib/ovn-util.c
> +++ b/lib/ovn-util.c
> @@ -788,7 +788,8 @@ ovn_smap_get_uint(const struct smap *smap, const char
> *key, unsigned int def)
> */
> bool
> ip_address_and_port_from_lb_key(const char *key, char **ip_address,
> -uint16_t *port, int *addr_family)
> +struct in6_addr *ip, uint16_t *port,
> +int *addr_family)
> {
> struct sockaddr_storage ss;
> if (!inet_parse_active(key, 0, &ss, false, NULL)) {
> @@ -798,12 +799,14 @@ ip_address_and_port_from_lb_key(const char *key, char
> **ip_address,
> *ip_address = NULL;
> *port = 0;
> *addr_family = 0;
> +memset(ip, 0, sizeof(*ip));
> return false;
> }
>
> struct ds s = DS_EMPTY_INITIALIZER;
> ss_format_address_nobracks(&ss, &s);
> *ip_address = ds_steal_cstr(&s);
> +*ip = ss_get_address(&ss);
> *port = ss_get_port(&ss);
> *addr_family = ss.ss_family;
> return true;
> diff --git a/lib/ovn-util.h b/lib/ovn-util.h
> index 145f974ed..a1f1cf0ad 100644
> --- a/lib/ovn-util.h
> +++ b/lib/ovn-util.h
> @@ -241,7 +241,8 @@ char *str_tolower(const char *orig);
> case OVN_OPT_USER_GROUP:
>
> bool ip_address_and_port_from_lb_key(const char *key, char **ip_address,
> - uint16_t *port, int *addr_family);
> + struct in6_addr *ip, uint16_t *port,
> + int *addr_family);
>
> /* Returns the internal OVN version. The caller must free the returned
> * value. */
> diff --git a/utilities/ovn-trace.c b/utilities/ovn-trace
Re: [ovs-dev] [PATCH v2 ovn 1/3] CoPP: add self-test for icmp{4, 6}_error controller action
On Fri, Oct 29, 2021 at 4:48 AM Mark Gray wrote:
>
> On 21/10/2021 23:18, Lorenzo Bianconi wrote:
> > Introduce CoPP selftest for icmp{4,6}_error controller action
> > Remove sleep in CoPP test and rely on tcpdump "-l" option.
> >
> > Signed-off-by: Lorenzo Bianconi
> > ---
> > tests/ovn-northd.at | 23 +++
> > tests/system-ovn.at | 43 ---
> > 2 files changed, 51 insertions(+), 15 deletions(-)
> >
> > diff --git a/tests/ovn-northd.at b/tests/ovn-northd.at
> > index 544820764..3ff0029f8 100644
> > --- a/tests/ovn-northd.at
> > +++ b/tests/ovn-northd.at
> > @@ -3249,6 +3249,29 @@ AT_CHECK([ovn-nbctl lr-copp-list r0], [0], [dnl
> >
> > AT_CHECK([ovn-sbctl list logical_flow | grep arp -A 2 | grep -q
> > meter1],[1])
> >
> > +check ovn-nbctl --wait=hv meter-add meter2 drop 400 pktps 10
> > +check ovn-nbctl --wait=hv lr-copp-add r0 icmp4-error meter2
> > +AT_CHECK([ovn-nbctl lr-copp-list r0], [0], [dnl
> > +icmp4-error: meter2
> > +])
> > +
> > +AT_CHECK([ovn-sbctl list logical_flow | grep icmp4 -A 2 | grep -q meter2])
> > +
> > +check ovn-nbctl --wait=hv lr-copp-del r0 icmp4-error
> > +AT_CHECK([ovn-nbctl lr-copp-list r0], [0], [dnl
> > +])
> > +
> > +check ovn-nbctl --wait=hv lr-copp-add r0 icmp6-error meter2
> > +AT_CHECK([ovn-nbctl lr-copp-list r0], [0], [dnl
> > +icmp6-error: meter2
> > +])
> > +
> > +AT_CHECK([ovn-sbctl list logical_flow | grep icmp6 -A 2 | grep -q meter2])
> > +
> > +check ovn-nbctl --wait=hv lr-copp-del r0 icmp6-error
> > +AT_CHECK([ovn-nbctl lr-copp-list r0], [0], [dnl
> > +])
> > +
> > check ovn-nbctl --wait=hv ls-copp-del sw1 event-elb
> > AT_CHECK([ovn-nbctl ls-copp-list sw1], [0], [dnl
> > ])
> > diff --git a/tests/system-ovn.at b/tests/system-ovn.at
> > index 345384223..d003843c3 100644
> > --- a/tests/system-ovn.at
> > +++ b/tests/system-ovn.at
> > @@ -6669,7 +6669,7 @@ check ovn-nbctl lsp-add public public1 \
> > -- lsp-set-type public1 localnet \
> > -- lsp-set-options public1 network_name=phynet
> >
> > -NS_EXEC([sw01], [tcpdump -n -i sw01 icmp -Q in > reject.pcap &])
> > +NS_EXEC([sw01], [tcpdump -l -n -i sw01 icmp -Q in > reject.pcap &])
> > check ovn-nbctl meter-add acl-meter drop 1 pktps 0
> > check ovn-nbctl --wait=hv ls-copp-add sw0 reject acl-meter
> > check ovn-nbctl acl-add sw0 from-lport 1002 'inport == "sw01" && ip &&
> > udp' reject
> > @@ -6679,37 +6679,33 @@ reject: acl-meter
> > ])
> >
> > ip netns exec sw01 scapy -H <<-EOF
> > -p = IP(src="192.168.1.2", dst="192.168.1.1")/ UDP(dport = 12345) /
> > Raw(b"X"*64)
> > +p = IP(src="192.168.1.2", dst="192.168.1.1") / UDP(dport = 12345) /
> > Raw(b"X"*64)
> > send (p, iface='sw01', loop = 0, verbose = 0, count = 20)
> > EOF
> >
> > -sleep 2
> > -kill $(pidof tcpdump)
> > -
> > # 1pps + 1 burst size
> > OVS_WAIT_UNTIL([
> > n_reject=$(grep unreachable reject.pcap | wc -l)
> > test "${n_reject}" = "2"
> > ])
> > +kill $(pidof tcpdump)
> >
> > rm -f reject.pcap
> > -NS_EXEC([sw01], [tcpdump -n -i sw01 icmp -Q in > reject.pcap &])
> > +NS_EXEC([sw01], [tcpdump -l -n -i sw01 icmp -Q in > reject.pcap &])
> > check ovn-nbctl --wait=hv ls-copp-del sw0 reject
> >
> > ip netns exec sw01 scapy -H <<-EOF
> > -p = IP(src="192.168.1.2", dst="192.168.1.1")/ UDP(dport = 12345) /
> > Raw(b"X"*64)
> > +p = IP(src="192.168.1.2", dst="192.168.1.1") / UDP(dport = 12345) /
> > Raw(b"X"*64)
> > send (p, iface='sw01', loop = 0, verbose = 0, count = 20)
> > EOF
> >
> > -sleep 2
> > -kill $(pidof tcpdump)
> > -
> > OVS_WAIT_UNTIL([
> > n_reject=$(grep unreachable reject.pcap | wc -l)
> > test "${n_reject}" = "20"
> > ])
> > +kill $(pidof tcpdump)
> >
> > -NS_EXEC([server], [tcpdump -n -i s1 arp[[24:4]]=0xac100164 > arp.pcap &])
> > +NS_EXEC([server], [tcpdump -l -n -i s1 arp[[24:4]]=0xac100164 > arp.pcap
> > &])
> > check ovn-nbctl meter-add arp-meter drop 1 pktps 0
> > check ovn-nbctl --wait=hv lr-copp-add R1 arp-resolve arp-meter
> > AT_CHECK([ovn-nbctl lr-copp-list R1], [0], [dnl
> > @@ -6717,18 +6713,35 @@ arp-resolve: arp-meter
> > ])
> >
> > ip netns exec sw01 scapy -H <<-EOF
> > -p = IP(src="192.168.1.2", dst="172.16.1.100")/ TCP(dport = 80, flags="S")
> > / Raw(b"X"*64)
> > +p = IP(src="192.168.1.2", dst="172.16.1.100") / TCP(dport = 80, flags="S")
> > / Raw(b"X"*64)
> > send (p, iface='sw01', loop = 0, verbose = 0, count = 100)
> > EOF
> >
> > -sleep 2
> > -kill $(pidof tcpdump)
> > -
> > # 1pps + 1 burst size
> > OVS_WAIT_UNTIL([
> > n_arp=$(grep ARP arp.pcap | wc -l)
> > test "${n_arp}" = "2"
> > ])
> > +kill $(pidof tcpdump)
> > +
> > +check ovn-nbctl meter-add icmp-meter drop 1 pktps 0
> > +check ovn-nbctl --wait=hv lr-copp-add R1 icmp4-error icmp-meter
> > +AT_CHECK([ovn-nbctl lr-copp-list R1 |grep icmp4-error], [0], [dnl
> > +icmp4-error: icmp-meter
> > +])
> > +
> > +NS_EXEC([sw01], [tcpdump -l -n -i sw01 icmp > icmp.pcap &])
> > +ip netns exec sw01 scapy -H <<-EOF
> > +p = IP(sr
Re: [ovs-dev] [PATCH ovn] tests: Fix requested-chassis localport test
On Tue, Nov 2, 2021 at 12:40 PM Dumitru Ceara wrote:
>
> On 11/2/21 2:31 PM, Frode Nordahl wrote:
> > The ovn-controller requested-chassis localport test currently
> > makes a change to the NB DB with --wait=sb, and subsequently does
> > an immediate check for change on a chassis. This does not allways
> > succeed.
> >
> > Update the test to use `--wait=hv` instead.
> >
> > Fixes: ad77db239d9a ("controller: Make use of
> > Port_Binding:requested_chassis.")
> > Signed-off-by: Frode Nordahl
> > ---
>
> Hi Frode,
>
> This looks good to me, thanks!
>
> Acked-by: Dumitru Ceara
Thanks. Applied.
Numan
>
> 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] ovn.at: Fix flaky test "router - check packet length - icmp defrag"
On Tue, Oct 19, 2021 at 11:58 AM Xavier Simonart wrote:
>
> This test was failing randomly, probably on slow systems.
> It was waiting for gratuitous ARP which were potentially generated earlier.
>
> Fixes: 1c9e46ab ("northd: add check_pkt_larger lflows for ingress traffic")
> Signed-off-by: Xavier Simonart
Thanks. Applied.
Numan
> ---
> tests/ovn.at | 23 +++
> 1 file changed, 11 insertions(+), 12 deletions(-)
>
> diff --git a/tests/ovn.at b/tests/ovn.at
> index 05eac4e5f..9483e4f75 100644
> --- a/tests/ovn.at
> +++ b/tests/ovn.at
> @@ -16895,7 +16895,6 @@ test_ip_packet_larger() {
> expected=${expected}
> expected=${expected}
> echo $expected > br_phys_n1.expected
> -echo $gw_ip_garp >> br_phys_n1.expected
> else
> src_ip=`ip_to_hex 10 0 0 1`
> dst_ip=`ip_to_hex 10 0 0 3`
> @@ -16916,7 +16915,9 @@ test_ip_packet_larger() {
> check as hv1 ovs-appctl netdev-dummy/receive hv1-vif1 $packet
>
> if test $mtu -ge $mtu_needed; then
> -OVN_CHECK_PACKETS([hv1/br-phys_n1-tx.pcap], [br_phys_n1.expected])
> +# Ignore gratuitous ARPs; there is no guarantee to get them here as
> they might
> +# already have been generated
> +OVN_CHECK_PACKETS_CONTAIN([hv1/br-phys_n1-tx.pcap],
> [br_phys_n1.expected])
> $PYTHON "$ovs_srcdir/utilities/ovs-pcap.in" hv1/vif1-tx.pcap > pkts
> # hv1/vif1-tx.pcap can receive the GARP packet generated by
> ovn-controller
> # for the gateway router port. So ignore this packet.
> @@ -16953,7 +16954,9 @@ test_ip_packet_larger_ext() {
> orig_packet_l3=${orig_packet_l3}
> packet=${packet}${orig_packet_l3}
>
> -
> gw_ip_garp=202012130806000108000604000120201213aca80064aca80064
> +# A Gratuitous ARP (as shown next line) might be transmitted, but
> +# it is also possible that it was transmitted earlier, so do not wait
> for it.
> +#
> optional_gw_ip_garp=202012130806000108000604000120201213aca80064aca80064
>
> ext_ip_garp=0012af11080600010800060400010012af11aca80004aca80004
>
> src_ip=`ip_to_hex 172 168 0 100`
> @@ -16967,8 +16970,6 @@ test_ip_packet_larger_ext() {
> icmp_reply=${icmp_reply}${orig_packet_l3}
> echo $icmp_reply > br-phys_n1.expected
>
> -echo $gw_ip_garp >> br-phys_n1.expected
> -
> as hv1 reset_pcap_file br-phys_n1 hv1/br-phys_n1
> as hv1 reset_pcap_file hv1-vif1 hv1/vif1
>
> @@ -16977,7 +16978,7 @@ test_ip_packet_larger_ext() {
> # Send packet from sw0-port1 to outside
> check as hv1 ovs-appctl netdev-dummy/receive br-phys_n1 $packet
>
> -OVN_CHECK_PACKETS([hv1/br-phys_n1-tx.pcap], [br-phys_n1.expected])
> +OVN_CHECK_PACKETS_CONTAIN([hv1/br-phys_n1-tx.pcap],
> [br-phys_n1.expected])
> }
>
> # IPv6 outgoing traffic generated inside the cluster
> @@ -17053,9 +17054,7 @@ test_ip6_packet_larger_ext() {
> local ip6_hdr=60583afe${ipv6_src}${ipv6_dst}
> local packet=${eth_dst}${eth_src}86dd${ip6_hdr}9000cc7662f1${payload}
>
> -local
> ns=202012130806000108000604000120201213aca80064aca80064
> -echo $ns > br-phys_n1.expected
> -
> +# Some ** ARP ** packets might still be received - ignore them
> as hv1 reset_pcap_file br-phys_n1 hv1/br-phys_n1
> as hv1 reset_pcap_file hv1-vif1 hv1/vif1
>
> @@ -17078,9 +17077,9 @@ test_ip6_packet_larger_ext() {
> outer_packet=${outer_ip6}${outer_icmp6_and_payload}
>
> icmp6_reply=${eth_src}${eth_dst}86dd${outer_packet}
> -echo $icmp6_reply >> br-phys_n1.expected
> +echo $icmp6_reply > br-phys_n1.expected
>
> -OVN_CHECK_PACKETS([hv1/br-phys_n1-tx.pcap], [br-phys_n1.expected])
> +OVN_CHECK_PACKETS_CONTAIN([hv1/br-phys_n1-tx.pcap],
> [br-phys_n1.expected])
> }
>
> wait_for_ports_up
> @@ -17200,7 +17199,7 @@ OVS_WAIT_FOR_OUTPUT([
> grep "check_pkt_larger(118)" ext-br-int-gw-flows-100 | wc -l], [0], [3
> ])
>
> -AS_BOX([testing ingress traffic mtu 100 for gw router - IPv6])
> +AS_BOX([testing ingress traffic mtu 100 for gw router - IPv4])
> test_ip_packet_larger_ext 100
>
> AS_BOX([testing ingress traffic mtu 100 for gw router - IPv6])
> --
> 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] utilities: nbctl: add --may-exist parameter to meter-add cmd
On Wed, Oct 27, 2021 at 10:54 AM Lorenzo Bianconi
wrote:
>
> Add --may-exist support to meter-add command in order to update
> meter parameters if it has been already created
>
> Signed-off-by: Lorenzo Bianconi
> ---
> tests/ovn-nbctl.at| 6 +++--
> tests/ovn-northd.at | 11 +-
> utilities/ovn-nbctl.c | 51 ---
> 3 files changed, 43 insertions(+), 25 deletions(-)
>
> diff --git a/tests/ovn-nbctl.at b/tests/ovn-nbctl.at
> index 9b80ae410..a8946fef8 100644
> --- a/tests/ovn-nbctl.at
> +++ b/tests/ovn-nbctl.at
> @@ -371,6 +371,8 @@ dnl Add duplicate meter name
> AT_CHECK([ovn-nbctl meter-add meter1 drop 10 kbps], [1], [], [stderr])
> AT_CHECK([grep 'already exists' stderr], [0], [ignore])
>
> +AT_CHECK([ovn-nbctl --may-exist meter-add meter1 drop 11 kbps])
> +
> dnl Add reserved meter name
> AT_CHECK([ovn-nbctl meter-add __meter1 drop 10 kbps], [1], [], [stderr])
> AT_CHECK([grep 'reserved' stderr], [0], [ignore])
> @@ -396,7 +398,7 @@ AT_CHECK([ovn-nbctl meter-add meter5 drop 10 10001011
> kbps], [1], [],
>
> AT_CHECK([ovn-nbctl meter-list], [0], [dnl
> meter1: bands:
> - drop: 10 kbps
> + drop: 11 kbps
> meter2: bands:
>drop: 3 kbps, 2 kb burst
> meter3: bands:
> @@ -409,7 +411,7 @@ dnl Delete a single meter.
> AT_CHECK([ovn-nbctl meter-del meter2])
> AT_CHECK([ovn-nbctl meter-list], [0], [dnl
> meter1: bands:
> - drop: 10 kbps
> + drop: 11 kbps
> meter3: bands:
>drop: 100 kbps, 200 kb burst
> meter4: (fair) bands:
> diff --git a/tests/ovn-northd.at b/tests/ovn-northd.at
> index e2b9924b6..ca1b8a117 100644
> --- a/tests/ovn-northd.at
> +++ b/tests/ovn-northd.at
> @@ -3235,7 +3235,16 @@ event-elb: meter0
>
> AT_CHECK([ovn-sbctl list logical_flow | grep trigger_event -A 2 | grep -q
> meter0])
>
> -check ovn-nbctl --wait=hv meter-add meter1 drop 200 pktps 10
> +check ovn-nbctl --wait=hv meter-add meter1 drop 300 pktps 10
> +AT_CHECK([ovn-nbctl meter-list |grep meter1 -A 1], [0], [dnl
> +meter1: bands:
> + drop: 300 pktps, 10 packet burst
> +])
> +check ovn-nbctl --wait=hv --may-exist meter-add meter1 drop 200 pktps 10
> +AT_CHECK([ovn-nbctl meter-list |grep meter1 -A 1], [0], [dnl
> +meter1: bands:
> + drop: 200 pktps, 10 packet burst
> +])
> check ovn-nbctl --wait=hv lr-copp-add r0 arp meter1
> AT_CHECK([ovn-nbctl lr-copp-list r0], [0], [dnl
> arp: meter1
> diff --git a/utilities/ovn-nbctl.c b/utilities/ovn-nbctl.c
> index b04b24d4b..1f71cae46 100644
> --- a/utilities/ovn-nbctl.c
> +++ b/utilities/ovn-nbctl.c
> @@ -2585,19 +2585,6 @@ meter_cmp(const void *meter1_, const void *meter2_)
> return strcmp(meter1->name, meter2->name);
> }
>
> -static void
> -nbctl_pre_meter_list(struct ctl_context *ctx)
> -{
> -ovsdb_idl_add_column(ctx->idl, &nbrec_meter_col_name);
> -ovsdb_idl_add_column(ctx->idl, &nbrec_meter_col_fair);
> -ovsdb_idl_add_column(ctx->idl, &nbrec_meter_col_bands);
> -ovsdb_idl_add_column(ctx->idl, &nbrec_meter_col_unit);
> -
> -ovsdb_idl_add_column(ctx->idl, &nbrec_meter_band_col_action);
> -ovsdb_idl_add_column(ctx->idl, &nbrec_meter_band_col_rate);
> -ovsdb_idl_add_column(ctx->idl, &nbrec_meter_band_col_burst_size);
> -}
> -
Hi Lorenzo,
Thanks for the patch. I applied this patch to the main branch with one change.
I kept the function nbctl_pre_meter_list() AS IS even though
nbctl_pre_meter_add()
are exactly the same. I felt it's a bit odd to call
nbctl_pre_meter_add() in the meter-list pre check command.
Thanks
Numan
> static void
> nbctl_meter_list(struct ctl_context *ctx)
> {
> @@ -2650,18 +2637,34 @@ static void
> nbctl_pre_meter_add(struct ctl_context *ctx)
> {
> ovsdb_idl_add_column(ctx->idl, &nbrec_meter_col_name);
> +ovsdb_idl_add_column(ctx->idl, &nbrec_meter_col_fair);
> +ovsdb_idl_add_column(ctx->idl, &nbrec_meter_col_bands);
> +ovsdb_idl_add_column(ctx->idl, &nbrec_meter_col_unit);
> +
> +ovsdb_idl_add_column(ctx->idl, &nbrec_meter_band_col_action);
> +ovsdb_idl_add_column(ctx->idl, &nbrec_meter_band_col_rate);
> +ovsdb_idl_add_column(ctx->idl, &nbrec_meter_band_col_burst_size);
> }
>
> static void
> nbctl_meter_add(struct ctl_context *ctx)
> {
> -const struct nbrec_meter *meter;
> +const struct nbrec_meter *meter = NULL, *iter;
> +struct nbrec_meter_band *band = NULL;
>
> const char *name = ctx->argv[1];
> -NBREC_METER_FOR_EACH (meter, ctx->idl) {
> -if (!strcmp(meter->name, name)) {
> -ctl_error(ctx, "meter with name \"%s\" already exists", name);
> -return;
> +NBREC_METER_FOR_EACH (iter, ctx->idl) {
> +if (!strcmp(iter->name, name)) {
> +if (!shash_find(&ctx->options, "--may-exist")) {
> +ctl_error(ctx, "meter with name \"%s\" already exists",
> name);
> +return;
> +} else {
> +meter = iter;
> +if (meter->n_bands) {
> +band = meter->bands
Re: [ovs-dev] [PATCH ovn v2] ovn-northd: Virtual port add ND/ARP responder flows for IPv6 VIPs.
On Wed, Sep 22, 2021 at 1:58 PM wrote:
>
> From: Mohammad Heib
>
> currently ovn-northd only handle virtual ports with VIP IPv4 and ignores
> virtual ports with VIP IPv6.
>
> This patch adds support for virtual ports with VIP IPv6 by adding
> lflows to the lsp_in_arp_rsp logical switch pipeline.
> Those lflows handle Neighbor Solicitations and Neighbor Advertisement requests
> that target the virtual port VIPs and bind the virtual port to the desired
> VIF.
>
> Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2003091
> Fixes: 054f4c85c413 ("Add a new logical switch port type - 'virtual'")
> Signed-off-by: Mohammad Heib
Hi Mohammad,
Thanks for the patch.
I didn't do a thorough review. I have just a few comments.
You need to update the documentation in northd/ovn-northd.8.xml about
the new flows added.
PSB for a couple of small nit comments.
Thanks
Numan
> ---
> northd/northd.c | 80 ++---
> tests/ovn.at| 66
> 2 files changed, 116 insertions(+), 30 deletions(-)
>
> diff --git a/northd/northd.c b/northd/northd.c
> index cf2467fe1..b934819fc 100644
> --- a/northd/northd.c
> +++ b/northd/northd.c
> @@ -7382,16 +7382,28 @@ build_lswitch_arp_nd_responder_known_ips(struct
> ovn_port *op,
> * - ARP reply from the virtual ip which belongs to a logical
> *port of type 'virtual' and bind that port.
> * */
> -ovs_be32 ip;
> +struct in6_addr ip;
> +
> const char *virtual_ip = smap_get(&op->nbsp->options,
>"virtual-ip");
> const char *virtual_parents = smap_get(&op->nbsp->options,
> "virtual-parents");
> -if (!virtual_ip || !virtual_parents ||
> -!ip_parse(virtual_ip, &ip)) {
> +if (!virtual_ip || !virtual_parents) {
> return;
> }
>
> +bool is_ipv4 = strchr(virtual_ip, '.') ? true : false;
> +if (is_ipv4) {
> +ovs_be32 ipv4;
> +if (!ip_parse(virtual_ip, &ipv4)) {
> + return;
> +}
> +} else{
> +if (!ipv6_parse(virtual_ip, &ip)) {
> + return;
> +}
> +}
> +
> char *tokstr = xstrdup(virtual_parents);
> char *save_ptr = NULL;
> char *vparent;
> @@ -7404,13 +7416,31 @@ build_lswitch_arp_nd_responder_known_ips(struct
> ovn_port *op,
> continue;
> }
>
> -ds_clear(match);
> -ds_put_format(match, "inport == \"%s\" && "
> - "((arp.op == 1 && arp.spa == %s && "
> - "arp.tpa == %s) || (arp.op == 2 && "
> - "arp.spa == %s))",
> - vparent, virtual_ip, virtual_ip,
> - virtual_ip);
> +if (is_ipv4) {
> +ds_clear(match);
> +ds_put_format(match, "inport == \"%s\" && "
> +"((arp.op == 1 && arp.spa == %s && "
> +"arp.tpa == %s) || (arp.op == 2 && "
> +"arp.spa == %s))",
> +vparent, virtual_ip, virtual_ip,
> +virtual_ip);
> +} else{
> +struct ipv6_netaddr na;
> +/* Find VIP multicast group */
> +in6_addr_solicited_node(&na.sn_addr, &ip);
> +inet_ntop(AF_INET6, &na.sn_addr, na.sn_addr_s, sizeof
> na.sn_addr_s);
> +
> +ds_clear(match);
> +ds_put_format(match, "inport == \"%s\" && "
> +"((nd_ns && ip6.dst == {%s, %s} && nd.target ==
> %s) ||"
> +"(nd_na && nd.target == %s))",
> +vparent,
> +virtual_ip,
> +na.sn_addr_s,
> +virtual_ip,
> +virtual_ip);
> +}
> +
> ds_clear(actions);
> ds_put_format(actions,
> "bind_vport(%s, inport); "
> @@ -11030,17 +11060,29 @@ build_arp_resolve_flows_for_lrouter_port(
> * 00:00:00:00:00:00 and advance to next table so that ARP is
> * resolved by router pipeline using the arp{} action.
> * The MAC_Binding entry for the virtual ip might be invalid. */
> -ovs_be32 ip;
>
> const char *vip = smap_get(&op->nbsp->options,
> "virtual-ip");
> const char *virtual_parents = smap_get(&op->nbsp->options,
> "virtu
Re: [ovs-dev] [PATCH ovn] ci: Don't run unit tests for system-test job.
On Wed, Nov 3, 2021 at 12:09 PM Ilya Maximets wrote: > > On 11/3/21 17:01, num...@ovn.org wrote: > > From: Numan Siddique > > > > For the system-test matrix, running unit tests is not > > required and if a unit test fails, then system tests > > are not run. Also test matrix covers unit tests anyway. > > Hmm. I don't think that is correct. > IIUC, the only remaining gcc unit test run is with jemalloc. > The one within a system-test job is the only normal test run > we have. Thanks for pointing this out. I missed it. I'll add another test matrix to run unit tests with gcc. The main reason for this patch is to run system tests even if unit tests fail (either due to a flake or due to genuine failure). Thanks 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] ofproto-dpif-xlate: Fix check_pkt_larger incomplete translation.
On Wed, Nov 3, 2021 at 10:34 AM Ilya Maximets wrote:
>
> On 10/29/21 19:26, num...@ovn.org wrote:
> > From: Numan Siddique
> >
> > xlate_check_pkt_larger() sets ctx->exit to 'true' at the end
> > causing the translation to stop. This results in incomplete
> > datapath rules.
> >
> > For example, for the below OF rules configured on a bridge,
> >
> > table=0,in_port=1
> > actions=load:0x1->NXM_NX_REG1[[]],resubmit(,1),load:0x2->NXM_NX_REG1[[]],resubmit(,1),load:0x3->NXM_NX_REG1[[]],resubmit(,1)
> > table=1,in_port=1,reg1=0x1
> > actions=check_pkt_larger(200)->NXM_NX_REG0[[0]],resubmit(,4)
> > table=1,in_port=1,reg1=0x2 actions=output:2
> > table=1,in_port=1,reg1=0x3 actions=output:4
> > table=4,in_port=1 actions=output:3
> >
> > the datapath flow should be
> >
> > check_pkt_len(size=200,gt(3),le(3)),2,4
> >
> > But right now it is:
> >
> > check_pkt_len(size=200,gt(3),le(3))
> >
> > Actions after the first resubmit(,1) in the first flow in table 0
> > are never applied. This patch fixes this issue.
> >
> > Fixes: 5b34f8fc3b38 ("Add a new OVS action check_pkt_larger")
> > Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2018365
> > Reported-by: Ihar Hrachyshka
> > Signed-off-by: Numan Siddique
> > ---
> > ofproto/ofproto-dpif-xlate.c | 9 -
> > tests/ofproto-dpif.at| 17 +
> > 2 files changed, 25 insertions(+), 1 deletion(-)
> >
> > diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
> > index 9d336bc6a6..e22a39a9f4 100644
> > --- a/ofproto/ofproto-dpif-xlate.c
> > +++ b/ofproto/ofproto-dpif-xlate.c
> > @@ -6371,6 +6371,7 @@ xlate_check_pkt_larger(struct xlate_ctx *ctx,
> > * then ctx->exit would be true. Reset to false so that we can
> > * do flow translation for 'IF_LESS_EQUAL' case. finish_freezing()
> > * would have taken care of Undoing the changes done for freeze. */
> > +bool old_exit = ctx->exit;
> > ctx->exit = false;
> >
> > offset_attr = nl_msg_start_nested(
> > @@ -6395,7 +6396,7 @@ xlate_check_pkt_larger(struct xlate_ctx *ctx,
> > ctx->was_mpls = old_was_mpls;
> > ctx->conntracked = old_conntracked;
> > ctx->xin->flow = old_flow;
> > -ctx->exit = true;
> > +ctx->exit = old_exit;
> > }
> >
> > static void
> > @@ -7192,6 +7193,12 @@ do_xlate_actions(const struct ofpact *ofpacts,
> > size_t ofpacts_len,
> > ofpacts_len);
> > xlate_check_pkt_larger(ctx, ofpact_get_CHECK_PKT_LARGER(a),
> > remaining_acts, remaining_acts_len);
> > +if (ctx->xbridge->support.check_pkt_len) {
> > +/* If datapath supports check_pkt_len, then
> > + * xlate_check_pkt_larger() does the translation for the
> > + * ofpacts following 'a'. */
> > +a = ofpact_end(ofpacts, ofpacts_len);
>
> Hi, Numan.
>
> Looks like this change triggers heap-buffer-overflow.
> See the ASAN report in ovsrobot's run for details.
Oops. Thanks for pointing this out. I missed running tests with
libasan locally.
Thanks
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 ovn] northd: fix check_pkt_larger ingress flows with FIP
On Wed, Nov 3, 2021 at 9:49 AM Lorenzo Bianconi
wrote:
>
> Add missing icmp{4,6}_error flows for ingress traffic destinated to FIP
> associated to the interface.
>
> Signed-off-by: Lorenzo Bianconi
> ---
> northd/northd.c | 87 ++---
> tests/ovn.at| 58 ++---
> 2 files changed, 121 insertions(+), 24 deletions(-)
Hi Lorenzo,
I haven't reviewed the patch yet. Seems like you need to update the
documentation
for the newly added logical flows ?
Also can you please link a bugzilla if it has one for this issue in
the Reported-at tag ?
Thanks
Numan
>
> diff --git a/northd/northd.c b/northd/northd.c
> index da4f9cd14..dedd38167 100644
> --- a/northd/northd.c
> +++ b/northd/northd.c
> @@ -12530,11 +12530,82 @@ build_lrouter_out_snat_flow(struct hmap *lflows,
> struct ovn_datapath *od,
> }
> }
>
> +static void
> +build_lrouter_ingress_nat_check_pkt_len(struct hmap *lflows,
> +const struct nbrec_nat *nat,
> +struct ovn_datapath *od, bool is_v6,
> +struct ds *match, struct ds *actions,
> +int mtu, struct shash *meter_groups)
> +{
> +ds_clear(match);
> +ds_put_format(match, "inport == %s && "REGBIT_PKT_LARGER
> + " && "REGBIT_EGRESS_LOOPBACK" == 0",
> + od->l3dgw_ports[0]->json_key);
> +
> +ds_clear(actions);
> +if (!is_v6) {
> +ds_put_format(match, " && ip4 && ip4.dst == %s",
> nat->external_ip);
> +/* Set icmp4.frag_mtu to gw_mtu */
> +ds_put_format(actions,
> +"icmp4_error {"
> +REGBIT_EGRESS_LOOPBACK" = 1; "
> +REGBIT_PKT_LARGER" = 0; "
> +"eth.dst = eth.src; "
> +"eth.src = %s; "
> +"ip4.dst = ip4.src; "
> +"ip4.src = %s; "
> +"ip.ttl = 254; "
> +"icmp4.type = 3; /* Destination Unreachable. */ "
> +"icmp4.code = 4; /* Frag Needed and DF was Set. */ "
> +"icmp4.frag_mtu = %d; "
> +"outport = %s; flags.loopback = 1; output; };",
> +nat->external_mac,
> +nat->external_ip,
> +mtu, od->l3dgw_ports[0]->json_key);
> +ovn_lflow_add_with_hint__(lflows, od, S_ROUTER_IN_IP_INPUT, 160,
> + ds_cstr(match), ds_cstr(actions),
> + NULL,
> + copp_meter_get(
> +COPP_ICMP4_ERR,
> +od->nbr->copp,
> +meter_groups),
> + &nat->header_);
> +} else {
> +ds_put_format(match, " && ip6 && ip6.dst == %s",
> nat->external_ip);
> +/* Set icmp6.frag_mtu to gw_mtu */
> +ds_put_format(actions,
> +"icmp6_error {"
> +REGBIT_EGRESS_LOOPBACK" = 1; "
> +REGBIT_PKT_LARGER" = 0; "
> +"eth.dst = eth.src; "
> +"eth.src = %s; "
> +"ip6.dst = ip6.src; "
> +"ip6.src = %s; "
> +"ip.ttl = 254; "
> +"icmp6.type = 2; /* Packet Too Big. */ "
> +"icmp6.code = 0; "
> +"icmp6.frag_mtu = %d; "
> +"outport = %s; flags.loopback = 1; output; };",
> +nat->external_mac,
> +nat->external_ip,
> +mtu, od->l3dgw_ports[0]->json_key);
> +ovn_lflow_add_with_hint__(lflows, od, S_ROUTER_IN_IP_INPUT, 160,
> + ds_cstr(match), ds_cstr(actions),
> + NULL,
> + copp_meter_get(
> +COPP_ICMP6_ERR,
> +od->nbr->copp,
> +meter_groups),
> + &nat->header_);
> +}
> +}
> +
> static void
> build_lrouter_ingress_flow(struct hmap *lflows, struct ovn_datapath *od,
> const struct nbrec_nat *nat, struct ds *match,
> struct ds *actions, struct eth_addr mac,
> - bool distributed, bool is_v6)
> + bool distributed, bool is_v6,
> + struct shash *meter_groups)
> {
> if (od->n_l3dgw_ports && !strcmp(nat->type, "snat")) {
> ds_clear(match);
> @@ -12558,7 +12629,8 @@ build_lrouter_ingress_flow(struct hmap *lflows,
> struct ovn_datapath *od,
> */
> ds_clear(actions);
>
> -build_check_pkt
Re: [ovs-dev] [PATCH ovn branch-21.09 0/3] Improve Load Balancer performance.
On Tue, Nov 2, 2021 at 3:35 PM Dumitru Ceara wrote: > > On 11/2/21 8:30 PM, Dumitru Ceara wrote: > > This series backports the load balancer performance improvements to > > stable branch-21.09. > > > > - patch 1/3 changes the way ARP responder flows are generated for load > > balancer VIPs, using an address set, making SB updates incremental > > and also reducing memory usage on the SB server side. > > - patch 2/3 introduces a new feature, Load_Balancer_Group, which > > simplifies load balancer configuration in large scale scenarios and > > at the same time improves performance due to the large reduction in > > database refereces between rows. > > - patch 3/3 is a follow up fix of a bug originally introduced by > > patch 1/3. > > > > Usually new features and performance fixes are not to be backported to > > stable branches, however due to the (mis)alignment of upstream and > > downstream release schedules, and due to the fact that ovn-kubernetes > > requires a database table to be part of a schema that's tagged in a > > release in ovn-org/ovn repo, if load balancer groups would be available > > only starting with v21.12.0 then downstream ovn-kubernetes (and OpenShift) > > will not be able to consume the feature for two release cycles (~6 months). > > > > On the other hand the feature itself is quite contained, doesn't break > > backwards compatibility, and, when used, hugely improves some CMSs > > (OpenShift) load balancer use cases. > > > > Dumitru Ceara (3): > > northd: Use address sets for ARP responder flows for VIPs. > > nb: Add support for Load_Balancer_Groups. > > northd: Always generate valid load balancer address set names. > > > > NEWS |2 > > northd/northd.c | 334 > > + > > ovn-nb.ovsschema | 24 +++- > > ovn-nb.xml| 37 + > > tests/ovn-northd.at | 293 ++- > > utilities/ovn-nbctl.c |3 > > 6 files changed, 517 insertions(+), 176 deletions(-) > > > > Adding OVN maintainers explicitly in order to discuss the possibility of > including this in a v21.09.1. +1 from me for the backports. Numan > > 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 1/1] ovn-northd: Treat reachable and unreachable addresses identically.
On Fri, Oct 29, 2021 at 5:28 PM Mark Michelson wrote:
>
> When an ARP request reaches a logical switch that is connected to
> gateway routers, if the IP address in the ARP is an "unreachable"
> address, then the ARP is flooded out all logical switch ports.
>
> This can become an issue when a logical switch is connected to many
> gateway logical router ports. In one particular OpenStack case, we saw a
> logical switch connected to 471 gateway logical router ports. When ARP
> requests are flooded to all of those logical router ports, it results in
> hitting the resubmit limit in OVS.
>
> To correct this issue, this patch treats reachable and unreachable
> addresses the same when receiving an ARP request. If the address can be
> traced to a particular router port, then the ARP is unicast only to that
> router port. This helps to avoid hitting the resubmit ceiling.
>
> The test "ARP flood for unreachable addresses" is removed since we no
> longer flood ARPs when destined for unreachable addresses.
>
> Reported at: https://bugzilla.redhat.com/show_bug.cgi?id=2009323
>
> Signed-off-by: Mark Michelson
Thanks for (re)addressing this issue.
I applied this patch to the main branch and branch-21.09 with the below change.
It doesn't apply cleanly to older branches. Please submit a backport
patch for branch-21.06 and others
if it needs to be backported.
---
diff --git a/northd/ovn-northd.8.xml b/northd/ovn-northd.8.xml
index d219c56186..b6a5f77670 100644
--- a/northd/ovn-northd.8.xml
+++ b/northd/ovn-northd.8.xml
@@ -1631,14 +1631,6 @@ output;
logical ports.
-
-Priority-90 flows for each IP address/VIP/NAT address configured
-outside its owning router port's subnet. These flows match ARP
-requests and ND packets for the specific IP addresses. Matched packets
-are forwarded to the MC_FLOOD multicast group which
-contains all connected logical ports.
-
-
Priority-75 flows for each port connected to a logical router
matching self originated ARP request/ND packets. These packets
---
Thanks
Numan
> ---
> northd/northd.c | 185
> tests/ovn-northd.at | 99
> tests/ovn.at| 10 +++
> 3 files changed, 23 insertions(+), 271 deletions(-)
>
> diff --git a/northd/northd.c b/northd/northd.c
> index da4f9cd14..59286034d 100644
> --- a/northd/northd.c
> +++ b/northd/northd.c
> @@ -6876,42 +6876,6 @@ build_lrouter_groups(struct hmap *ports, struct
> ovs_list *lr_list)
> }
> }
>
> -/* Returns 'true' if the IPv4 'addr' is on the same subnet with one of the
> - * IPs configured on the router port.
> - */
> -static bool
> -lrouter_port_ipv4_reachable(const struct ovn_port *op, ovs_be32 addr)
> -{
> -for (size_t i = 0; i < op->lrp_networks.n_ipv4_addrs; i++) {
> -struct ipv4_netaddr *op_addr = &op->lrp_networks.ipv4_addrs[i];
> -
> -if ((addr & op_addr->mask) == op_addr->network) {
> -return true;
> -}
> -}
> -return false;
> -}
> -
> -/* Returns 'true' if the IPv6 'addr' is on the same subnet with one of the
> - * IPs configured on the router port.
> - */
> -static bool
> -lrouter_port_ipv6_reachable(const struct ovn_port *op,
> -const struct in6_addr *addr)
> -{
> -for (size_t i = 0; i < op->lrp_networks.n_ipv6_addrs; i++) {
> -struct ipv6_netaddr *op_addr = &op->lrp_networks.ipv6_addrs[i];
> -
> -struct in6_addr nat_addr6_masked =
> -ipv6_addr_bitand(addr, &op_addr->mask);
> -
> -if (ipv6_addr_equals(&nat_addr6_masked, &op_addr->network)) {
> -return true;
> -}
> -}
> -return false;
> -}
> -
> /*
> * Ingress table 22: Flows that flood self originated ARP/ND packets in the
> * switching domain.
> @@ -6943,23 +6907,6 @@ build_lswitch_rport_arp_req_self_orig_flow(struct
> ovn_port *op,
> if (!nat->external_mac) {
> continue;
> }
> -
> -/* Check if the ovn port has a network configured on which we could
> - * expect ARP requests/NS for the DNAT external_ip.
> - */
> -if (nat_entry_is_v6(nat_entry)) {
> -struct in6_addr *addr = &nat_entry->ext_addrs.ipv6_addrs[0].addr;
> -
> -if (!lrouter_port_ipv6_reachable(op, addr)) {
> -continue;
> -}
> -} else {
> -ovs_be32 addr = nat_entry->ext_addrs.ipv4_addrs[0].addr;
> -
> -if (!lrouter_port_ipv4_reachable(op, addr)) {
> -continue;
> -}
> -}
> sset_add(&all_eth_addrs, nat->external_mac);
> }
>
> @@ -7012,7 +6959,7 @@ arp_nd_ns_match(const char *ips, int addr_family,
> struct ds *match)
> * switching domain as regular broadcast.
> */
> static void
> -build_lswitch_rport_arp_req_flow_for_reachable
Re: [ovs-dev] [PATCH v2 ovn] northd: fix check_pkt_larger ingress flows with FIP
On Thu, Nov 4, 2021 at 12:07 PM Lorenzo Bianconi
wrote:
>
> Add missing icmp{4,6}_error flows for ingress traffic destinated to FIP
> associated to the interface
>
> Related bz: https://bugzilla.redhat.com/show_bug.cgi?id=2018179
> Tested-by: Eran Kuris
>
> Signed-off-by: Lorenzo Bianconi
Thanks.
I applied this patch to the main branch and branch-21.09.
Thanks
Numan
> ---
> Changes since v1:
> - add missing northd documentation
> ---
> northd/northd.c | 87 ++---
> northd/ovn-northd.8.xml | 55 +-
> tests/ovn.at| 58 ++-
> 3 files changed, 174 insertions(+), 26 deletions(-)
>
> diff --git a/northd/northd.c b/northd/northd.c
> index 59286034d..ee4d4df26 100644
> --- a/northd/northd.c
> +++ b/northd/northd.c
> @@ -12371,11 +12371,82 @@ build_lrouter_out_snat_flow(struct hmap *lflows,
> struct ovn_datapath *od,
> }
> }
>
> +static void
> +build_lrouter_ingress_nat_check_pkt_len(struct hmap *lflows,
> +const struct nbrec_nat *nat,
> +struct ovn_datapath *od, bool is_v6,
> +struct ds *match, struct ds *actions,
> +int mtu, struct shash *meter_groups)
> +{
> +ds_clear(match);
> +ds_put_format(match, "inport == %s && "REGBIT_PKT_LARGER
> + " && "REGBIT_EGRESS_LOOPBACK" == 0",
> + od->l3dgw_ports[0]->json_key);
> +
> +ds_clear(actions);
> +if (!is_v6) {
> +ds_put_format(match, " && ip4 && ip4.dst == %s",
> nat->external_ip);
> +/* Set icmp4.frag_mtu to gw_mtu */
> +ds_put_format(actions,
> +"icmp4_error {"
> +REGBIT_EGRESS_LOOPBACK" = 1; "
> +REGBIT_PKT_LARGER" = 0; "
> +"eth.dst = eth.src; "
> +"eth.src = %s; "
> +"ip4.dst = ip4.src; "
> +"ip4.src = %s; "
> +"ip.ttl = 254; "
> +"icmp4.type = 3; /* Destination Unreachable. */ "
> +"icmp4.code = 4; /* Frag Needed and DF was Set. */ "
> +"icmp4.frag_mtu = %d; "
> +"outport = %s; flags.loopback = 1; output; };",
> +nat->external_mac,
> +nat->external_ip,
> +mtu, od->l3dgw_ports[0]->json_key);
> +ovn_lflow_add_with_hint__(lflows, od, S_ROUTER_IN_IP_INPUT, 160,
> + ds_cstr(match), ds_cstr(actions),
> + NULL,
> + copp_meter_get(
> +COPP_ICMP4_ERR,
> +od->nbr->copp,
> +meter_groups),
> + &nat->header_);
> +} else {
> +ds_put_format(match, " && ip6 && ip6.dst == %s",
> nat->external_ip);
> +/* Set icmp6.frag_mtu to gw_mtu */
> +ds_put_format(actions,
> +"icmp6_error {"
> +REGBIT_EGRESS_LOOPBACK" = 1; "
> +REGBIT_PKT_LARGER" = 0; "
> +"eth.dst = eth.src; "
> +"eth.src = %s; "
> +"ip6.dst = ip6.src; "
> +"ip6.src = %s; "
> +"ip.ttl = 254; "
> +"icmp6.type = 2; /* Packet Too Big. */ "
> +"icmp6.code = 0; "
> +"icmp6.frag_mtu = %d; "
> +"outport = %s; flags.loopback = 1; output; };",
> +nat->external_mac,
> +nat->external_ip,
> +mtu, od->l3dgw_ports[0]->json_key);
> +ovn_lflow_add_with_hint__(lflows, od, S_ROUTER_IN_IP_INPUT, 160,
> + ds_cstr(match), ds_cstr(actions),
> + NULL,
> + copp_meter_get(
> +COPP_ICMP6_ERR,
> +od->nbr->copp,
> +meter_groups),
> + &nat->header_);
> +}
> +}
> +
> static void
> build_lrouter_ingress_flow(struct hmap *lflows, struct ovn_datapath *od,
> const struct nbrec_nat *nat, struct ds *match,
> struct ds *actions, struct eth_addr mac,
> - bool distributed, bool is_v6)
> + bool distributed, bool is_v6,
> + struct shash *meter_groups)
> {
> if (od->n_l3dgw_ports && !strcmp(nat->type, "snat")) {
> ds_clear(match);
> @@ -12399,7 +12470,8 @@ build_lrouter_ingress_flow(struct hmap *lflows,
> struct ovn_datapath *od,
>
Re: [ovs-dev] [PATCH ovn v2] ci: Don't run unit tests for system-test job.
On Mon, Nov 8, 2021 at 10:43 AM Dumitru Ceara wrote: > > On 11/3/21 5:55 PM, num...@ovn.org wrote: > > From: Numan Siddique > > > > system-test matrix first runs unit tests and then system tests. > > And if unit tests fail, system tests are not run. > > > > This patch now runs only system tests for system-test matrix. > > A new entry is added in the test matrix - 'gcc compiler with > > unit tests'. > > > > Signed-off-by: Numan Siddique > > --- > > Hi Numan, > > > > > v1 -> v2 > > > > * Addressed Ilya's comments. > > > > .ci/linux-build.sh | 22 +++--- > > .github/workflows/test.yml | 2 ++ > > 2 files changed, 13 insertions(+), 11 deletions(-) > > > > diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh > > index 76a2ff459f..b0975685d4 100755 > > --- a/.ci/linux-build.sh > > +++ b/.ci/linux-build.sh > > @@ -49,17 +49,6 @@ else > > fi > > > > if [ "$TESTSUITE" ]; then > > -# 'distcheck' will reconfigure with required options. > > -# Now we only need to prepare the Makefile without sparse-wrapped CC. > > -configure_ovn > > - > > -export DISTCHECK_CONFIGURE_FLAGS="$OPTS" > > -if ! make distcheck -j4 TESTSUITEFLAGS="-j4" RECHECK=yes; then > > -# testsuite.log is necessary for debugging. > > -cat */_build/sub/tests/testsuite.log > > -exit 1 > > -fi > > - > > if [ "$TESTSUITE" = "system-test" ]; then > > # Reconfigure build with required OPTS, rebuild and run system > > tests. > > We're not really reconfiguring/rebuilding anymore, this can probably be > updated to: > > # Configure build with required OPTS, build and run system tests. > > Or, even better, the comment can be removed altogether; but I guess this > can be fixed up at apply time, therefore: > > Acked-by: Dumitru Ceara Thanks Dumitru. I removed the comment and applied the patch to the main branch. Numan > > Thanks, > 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] [ovn] chassis with VXLAN breaks setup which is using OVN-IC
+ Ihar if he has any comments. Thanks Numan On Mon, Nov 8, 2021 at 4:57 PM Vladislav Odintsov wrote: > > Hi, > > is seems like I found a regression with a latest ovn main branch code using > ovn-ic. > My setup utilises ramp switches (ovn-controller-vtep), so some chassis have > vxlan encap. > But I guess the problem affects non-vtep switch VXLAN installations too. > OVN IC transit switches use tunnel key ids > OVN_MAX_DP_KEY_LOCAL > (OVN_MAX_DP_KEY - OVN_MAX_DP_GLOBAL_NUM) > so if user has at least one VXLAN-enabled chassis and interconnected > with transit switch LRs he/she will get in northd logs lots of next messages: > > 2021-11-08T21:03:32.606Z|00132|northd|WARN|Tunnel key 16711897 for datapath > vpc-6A0E5C34-global is incompatible with VXLAN > 2021-11-08T21:04:32.607Z|00133|northd|WARN|Dropped 27 log messages in last 60 > seconds (most recently, 31 seconds ago) due to excessive rate > > In commit [1] this logic was introduced. I can’t understand from the code and > from commit itself > if previous behaviour can be supported, but maybe I’m missing something. > Can somebody help on this please? > > Thanks. > > 1: > https://github.com/ovn-org/ovn/commit/fd44d75959cedcedf1f103173be1d9fa1abd9cb8 > > Regards, > Vladislav Odintsov > > ___ > 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 v10 0/4] Introduce infrastructure for VIF plug providers.
On Fri, Nov 5, 2021 at 5:32 PM Frode Nordahl wrote: > > fre. 5. nov. 2021, 20:43 skrev Han Zhou : > > > > > > > On Fri, Nov 5, 2021 at 7:00 AM Frode Nordahl > > wrote: > > > > > > Introduce infrastructure for VIF plug providers and add feature to > > > ovn-controller to add and remove ports on the integration bridge as > > > directed by CMS through Logical_Switch_Port options. > > > > > > Traditionally it has been the CMSs responsibility to create Virtual > > > Interfaces (VIFs) as part of instance (Container, Pod, Virtual > > > Machine etc.) life cycle, and subsequently manage plug/unplug > > > operations on the Open vSwitch integration bridge. > > > > > > With the advent of NICs connected to multiple distinct CPUs we can > > > have a topology where the instance runs on one host and Open > > > vSwitch and OVN runs on a different host, the smartnic control plane > > > CPU. The host facing interfaces will be visible to Open vSwitch > > > and OVN as representor ports. > > > > > > The actions necessary for plugging and unplugging the representor > > > port in Open vSwitch running on the smartnic control plane CPU would > > > be the same for every CMS. > > > > > > Hardware or platform specific details for initialization and lookup > > > of representor ports is provided by an plugging provider hosted > > > inside or outside the core OVN repository, and linked at OVN build > > > time. > > > > > > RFC1 -> RFC2: > > > - Introduce the plug-provider interface, remove hardware/platform > > >dependent code. > > > - Add ovsport module. > > > - Integrate with binding module. > > > - Split into multiple patches. > > > > > > RFC2 -> v1: > > > - Extend build system, `--with-plug-provider`. > > > - Check for required data in b_ctx_in and lbinding data structures. > > > - Split consider_plug_lport into update and create processing > > >functions. > > > - Consider unplug on release where relevant. > > > - Add ovn-controller `--enable-dummy-plug` option for testing. > > > - Consistent function naming and move ovsport module to controller/. > > > - Rename plug-test.c -> plug-dummy.c. > > > - Add functional- and unit- tests. > > > > > > v1 -> v2: > > > - Move update to controller/binding.h from patch 6 -> patch 5. > > > - Fix lint problems reported by 0-day Robot. > > > > > > v2 -> v3: > > > - Fix build system extension for plug provider. > > > - Implement DDlog version of northd change. > > > - Rebase on tip. > > > > > > v3 -> v4: > > > - sb:Port_Binding:plugged_by -> sb:Port_Binding:requested_chassis. > > > - Move documentation of plugin specific options to plugin > > >implementation. > > > - ovn-northd-ddlog: squash changes into same patch as C version, rework > > >the DDlog implementation. > > > - controller: Use requested_chassis column instead of parsing options. > > > - plug-provider: Remove the extra class instantiation layer and > > >refcounting. Add documentation and various tweaks. > > > - controller: Add engine node for plug provider so that a plugin run > > >function can run at an appropriate time and also allow feeding back > > >information about changes that can not be handled incrementally. > > > - binding: Fix return values for plug functions so they adhere to the > > >incremental processing engine contract. > > > - Add support for building in-tree plug providers. > > > > > > v4 -> v5: > > > - binding: Make some data structures and functions public to allow > > >other modules to make use of its local binding tracking data > > >structures. > > > - Add separate incremental processing engine nodes for the plug > > >provider. > > > - Do change handling in the controller/plug module rather than piggy > > >backing on the binding module. > > > - Deal with asynchronous notification to plug provider class and > > >subsequent freeing of data structures when the transaction commits. > > > - Drop the representor plugin as in-tree plugin to address concerns > > about > > >it being Linux-only and having netlink/kernel dependencies. Will > > >upstream to ovn-org/ovn-vif instead. > > > > > > v5 -> v6: > > > - Fix 0-day Robot documentation lexer warning treated as error: > > > > > https://mail.openvswitch.org/pipermail/ovs-build/2021-September/017538.html > > > > > > v6 -> v7: > > > - lport: Fall back to strcmp when requested-chassis option is set > > > but Port_Binding->requested_chassis is not filled yet. > > > - physical: Make use of common lport_can_bind_on_this_chassis helper > > > instead of duplicating the inverse check in the code. > > > - tests: Add test cases to cover currently uncovered requested-chassis > > > functionality. > > > - plug: Make smaps struct members instead of pointers. > > > - plug: Don't use is_deleted function when not iterating over tracked > > > records. Avoid adding multiple delete or update iface requests > > > to the same transaction. > > > - p
Re: [ovs-dev] [PATCH ovn] ovs: Bump submodule to include ovsdb/IDL optimizations.
On Fri, Nov 5, 2021 at 5:11 AM Dumitru Ceara wrote: > > There are two relevant OVS commits picked with this submodule update. > The first one significantly improves performance of OVN database clients > and the second one adds memory reporting for the OVN IDL clients. > > 1bdda7b6d ovsdb-idl: Use functions to apply diff in place. > 066741d9c ovsdb-idl: Add memory report function. > > https://bugzilla.redhat.com/show_bug.cgi?id=2020533 > Signed-off-by: Dumitru Ceara Thanks. Applied. Numan > --- > ovs | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/ovs b/ovs > index 429b114c5..1bdda7b6d 16 > --- a/ovs > +++ b/ovs > @@ -1 +1 @@ > -Subproject commit 429b114c5aadee24ccfb16ad7d824f45cdcea75a > +Subproject commit 1bdda7b6d53c92e877b457157676aff326414c53 > -- > 2.27.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 v4] ovn-northd: Virtual port add ND/ARP responder flows for IPv6 VIPs.
On Wed, Nov 3, 2021 at 9:37 AM Mohammad Heib wrote:
>
> currently ovn-northd only handle virtual ports with VIP IPv4 and ignores
> virtual ports with VIP IPv6.
>
> This patch adds support for virtual ports with VIP IPv6 by adding
> lflows to the lsp_in_arp_rsp logical switch pipeline.
> Those lflows handle Neighbor Solicitations and Neighbor Advertisement requests
> that target the virtual port VIPs and bind the virtual port to the desired
> VIF.
>
> Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2003091
> Fixes: 054f4c85c413 ("Add a new logical switch port type - 'virtual'")
> Signed-off-by: Mohammad Heib
Thanks for v4. There were a couple of checkpatch warnings related to
line length limits.
I fixed those and applied the patch to the main branch.
Thanks
Numan
> ---
> northd/northd.c | 92 +
> northd/ovn-northd.8.xml | 11 +++--
> tests/ovn.at| 66 +++--
> 3 files changed, 134 insertions(+), 35 deletions(-)
>
> diff --git a/northd/northd.c b/northd/northd.c
> index da4f9cd14..4e1b6edb1 100644
> --- a/northd/northd.c
> +++ b/northd/northd.c
> @@ -7501,7 +7501,7 @@ build_lswitch_arp_nd_responder_skip_local(struct
> ovn_port *op,
> }
> }
>
> -/* Ingress table 13: ARP/ND responder, reply for known IPs.
> +/* Ingress table 16: ARP/ND responder, reply for known IPs.
> * (priority 50). */
> static void
> build_lswitch_arp_nd_responder_known_ips(struct ovn_port *op,
> @@ -7519,17 +7519,37 @@ build_lswitch_arp_nd_responder_known_ips(struct
> ovn_port *op,
> *
> * - ARP reply from the virtual ip which belongs to a logical
> *port of type 'virtual' and bind that port.
> + *
> + * - IPv6 Neighbor Solicitations requests that targets virtual
> + *ip which belongs to a logical port of type 'virtual' and
> + *bind that port.
> + *
> + * - IPv6 unsolicited Neighbor Advertisements that targets
> + *ip which belongs to a logical port of type 'virtual'
> + *and bind that port.
> * */
> -ovs_be32 ip;
> +struct in6_addr ip;
> +
> const char *virtual_ip = smap_get(&op->nbsp->options,
>"virtual-ip");
> const char *virtual_parents = smap_get(&op->nbsp->options,
> "virtual-parents");
> -if (!virtual_ip || !virtual_parents ||
> -!ip_parse(virtual_ip, &ip)) {
> +if (!virtual_ip || !virtual_parents) {
> return;
> }
>
> +bool is_ipv4 = strchr(virtual_ip, '.') ? true : false;
> +if (is_ipv4) {
> +ovs_be32 ipv4;
> +if (!ip_parse(virtual_ip, &ipv4)) {
> + return;
> +}
> +} else {
> +if (!ipv6_parse(virtual_ip, &ip)) {
> + return;
> +}
> +}
> +
> char *tokstr = xstrdup(virtual_parents);
> char *save_ptr = NULL;
> char *vparent;
> @@ -7542,13 +7562,33 @@ build_lswitch_arp_nd_responder_known_ips(struct
> ovn_port *op,
> continue;
> }
>
> -ds_clear(match);
> -ds_put_format(match, "inport == \"%s\" && "
> - "((arp.op == 1 && arp.spa == %s && "
> - "arp.tpa == %s) || (arp.op == 2 && "
> - "arp.spa == %s))",
> - vparent, virtual_ip, virtual_ip,
> - virtual_ip);
> +if (is_ipv4) {
> +ds_clear(match);
> +ds_put_format(match, "inport == \"%s\" && "
> +"((arp.op == 1 && arp.spa == %s && "
> +"arp.tpa == %s) || (arp.op == 2 && "
> +"arp.spa == %s))",
> +vparent, virtual_ip, virtual_ip,
> +virtual_ip);
> +} else {
> +struct ipv6_netaddr na;
> +/* Find VIP multicast group */
> +in6_addr_solicited_node(&na.sn_addr, &ip);
> +inet_ntop(AF_INET6, &na.sn_addr, na.sn_addr_s,
> + sizeof na.sn_addr_s);
> +
> +ds_clear(match);
> +ds_put_format(match, "inport == \"%s\" && "
> +"((nd_ns && ip6.dst == {%s, %s} && "
> +"nd.target == %s) ||"
> +"(nd_na && nd.target == %s))",
> +vparent,
> +virtual_ip,
> +na.sn_addr_s,
> +
Re: [ovs-dev] [ovn] chassis with VXLAN breaks setup which is using OVN-IC
On Mon, Nov 8, 2021 at 5:05 PM Numan Siddique wrote: > > + Ihar if he has any comments. > > Thanks > Numan > Due to the limitations of VxLAN, I don't think OVN interconnect is supported with VxLAN. Please see the ovn-architecture man pages. -- When VXLAN tunneling is enabled in an OVN cluster, due to the limited range available for VNIs, Interconnection feature is not supported. --- Thanks Numan > On Mon, Nov 8, 2021 at 4:57 PM Vladislav Odintsov wrote: > > > > Hi, > > > > is seems like I found a regression with a latest ovn main branch code using > > ovn-ic. > > My setup utilises ramp switches (ovn-controller-vtep), so some chassis have > > vxlan encap. > > But I guess the problem affects non-vtep switch VXLAN installations too. > > OVN IC transit switches use tunnel key ids > OVN_MAX_DP_KEY_LOCAL > > (OVN_MAX_DP_KEY - OVN_MAX_DP_GLOBAL_NUM) > > so if user has at least one VXLAN-enabled chassis and interconnected > > with transit switch LRs he/she will get in northd logs lots of next > > messages: > > > > 2021-11-08T21:03:32.606Z|00132|northd|WARN|Tunnel key 16711897 for datapath > > vpc-6A0E5C34-global is incompatible with VXLAN > > 2021-11-08T21:04:32.607Z|00133|northd|WARN|Dropped 27 log messages in last > > 60 seconds (most recently, 31 seconds ago) due to excessive rate > > > > In commit [1] this logic was introduced. I can’t understand from the code > > and from commit itself > > if previous behaviour can be supported, but maybe I’m missing something. > > Can somebody help on this please? > > > > Thanks. > > > > 1: > > https://github.com/ovn-org/ovn/commit/fd44d75959cedcedf1f103173be1d9fa1abd9cb8 > > > > Regards, > > Vladislav Odintsov > > > > ___ > > 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] ci: Remove generating ovn-k8s test report.
On Tue, Nov 9, 2021 at 7:43 AM Dumitru Ceara wrote:
>
> This change is backported from upstream ovn-kubernetes as we're seeing
> the same issue in OVN runs too:
>
> https://github.com/ovn-org/ovn-kubernetes/commit/c2ef04188
>
> Signed-off-by: Dumitru Ceara
Thanks for fixing this.
Applied to the main and backported to branch-21.09 and branch-21.06.
Thanks
Numan
> ---
> .github/workflows/ovn-kubernetes.yml | 14 --
> 1 file changed, 14 deletions(-)
>
> diff --git a/.github/workflows/ovn-kubernetes.yml
> b/.github/workflows/ovn-kubernetes.yml
> index f9ea33247..60c585a24 100644
> --- a/.github/workflows/ovn-kubernetes.yml
> +++ b/.github/workflows/ovn-kubernetes.yml
> @@ -141,20 +141,6 @@ jobs:
> name: kind-junit-${{ env.JOB_NAME }}-${{ github.run_id }}
> path: 'src/github.com/ovn-org/ovn-kubernetes/test/_artifacts/*.xml'
>
> -- name: Generate Test Report
> - id: xunit-viewer
> - if: always()
> - uses: AutoModality/action-xunit-viewer@v1
> - with:
> -results: src/github.com/ovn-org/ovn-kubernetes/test/_artifacts/
> -
> -- name: Upload Test Report
> - if: always()
> - uses: actions/upload-artifact@v2
> - with:
> -name: test-report-${{ env.JOB_NAME }}-${{ github.run_id }}
> -path:
> 'src/github.com/ovn-org/ovn-kubernetes/test/_artifacts/index.html'
> -
> - name: Export logs
>if: always()
>run: |
> --
> 2.27.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 1/2] northd: Treat reachable and unreachable VIPs differently.
On Tue, Nov 9, 2021 at 7:42 AM Dumitru Ceara wrote:
>
> On 11/8/21 6:10 PM, num...@ovn.org wrote:
> > From: Numan Siddique
> >
> > If a logical switch is used to join multiple gateway
> > routers and if each of these gateway routers are
> > configured with the same load balancer, then after the
> > commit [1] it's results in a flow explosion in
> > the "ls_in_l2_lkup" stage of this logical switch.
> >
> > So, this patch reverts parts of the commit [1] related to
> > the load balancer VIPs.
> >
> > Eg. If a load balancer with vip - 5.0.0.48 is configured
> > on gateway routers g0, g1 and g2. Then ovn-northd will add
> > the below logical flows
> >
> > table=22(ls_in_l2_lkup), priority=80,
> > match=(flags[1] == 0 && arp.op == 1 && arp.tpa == 5.0.0.48),
> > action=(outport = "join-to-g0-port"; output;)
> > table=22(ls_in_l2_lkup), priority=80,
> > match=(flags[1] == 0 && arp.op == 1 && arp.tpa == 5.0.0.48),
> > action=(outport = "join-to-g1-port"; output;)
> > table=22(ls_in_l2_lkup), priority=80,
> > match=(flags[1] == 0 && arp.op == 1 && arp.tpa == 5.0.0.48),
> > action=(outport = "join-to-g2-port"; output;)
> >
> > After this patch, we will just have one lflow
> > table=22(ls_in_l2_lkup), priority=90,
> > match=(flags[1] == 0 && arp.op == 1 && arp.tpa == 5.0.0.48),
> > action=(outport = "_MC_flood"; output;)
> >
> > [1] - ccbbbd0584e5("ovn-northd: Treat reachable and unreachable addresses
> > identically.")
> > Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2020710
> > Fixes: ccbbbd0584e5("ovn-northd: Treat reachable and unreachable addresses
> > identically.")
> > Signed-off-by: Numan Siddique
> > ---
>
> Some test numbers with a topology simulating 120 ovn-k8s nodes (120
> gateway routers connected to a single join switch) with 10K load
> balancers applied to all gateway router:
>
> A. Before this patch:
> - northd loop processing time: 6854ms
> - SB DB size (on disk, after compaction): 520M
> - number of logical flows: 1245942
>
> B. With this patch:
> - northd loop processing time: 2638ms
> - SB DB size (on disk, after compaction): 94M
> - number of logical flows: 55942
>
> Looks good to me, thanks for the quick fix!
>
> Acked-by: Dumitru Ceara
Thanks Dumitru for the reviews. I applied both the patches to the
main branch and branch-21.09.
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 branch-21.09 0/3] Improve Load Balancer performance.
On Wed, Nov 3, 2021 at 4:11 PM Numan Siddique wrote: > > On Tue, Nov 2, 2021 at 3:35 PM Dumitru Ceara wrote: > > > > On 11/2/21 8:30 PM, Dumitru Ceara wrote: > > > This series backports the load balancer performance improvements to > > > stable branch-21.09. > > > > > > - patch 1/3 changes the way ARP responder flows are generated for load > > > balancer VIPs, using an address set, making SB updates incremental > > > and also reducing memory usage on the SB server side. > > > - patch 2/3 introduces a new feature, Load_Balancer_Group, which > > > simplifies load balancer configuration in large scale scenarios and > > > at the same time improves performance due to the large reduction in > > > database refereces between rows. > > > - patch 3/3 is a follow up fix of a bug originally introduced by > > > patch 1/3. > > > > > > Usually new features and performance fixes are not to be backported to > > > stable branches, however due to the (mis)alignment of upstream and > > > downstream release schedules, and due to the fact that ovn-kubernetes > > > requires a database table to be part of a schema that's tagged in a > > > release in ovn-org/ovn repo, if load balancer groups would be available > > > only starting with v21.12.0 then downstream ovn-kubernetes (and OpenShift) > > > will not be able to consume the feature for two release cycles (~6 > > > months). > > > > > > On the other hand the feature itself is quite contained, doesn't break > > > backwards compatibility, and, when used, hugely improves some CMSs > > > (OpenShift) load balancer use cases. > > > > > > Dumitru Ceara (3): > > > northd: Use address sets for ARP responder flows for VIPs. > > > nb: Add support for Load_Balancer_Groups. > > > northd: Always generate valid load balancer address set names. > > > > > > NEWS |2 > > > northd/northd.c | 334 > > > + > > > ovn-nb.ovsschema | 24 +++- > > > ovn-nb.xml| 37 + > > > tests/ovn-northd.at | 293 ++- > > > utilities/ovn-nbctl.c |3 > > > 6 files changed, 517 insertions(+), 176 deletions(-) > > > > > > > Adding OVN maintainers explicitly in order to discuss the possibility of > > including this in a v21.09.1. > > +1 from me for the backports. Thanks for the backport patches. I went ahead and applied these patches to branch-21.09. I suppose the next step is to release 21.09.1 Numan > > Numan > > > > > 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] ovn-trace: Set ct_state if not already set when tracing ct(nat).
On Mon, Nov 1, 2021 at 9:36 AM Dumitru Ceara wrote:
>
> Since 0038579d1928 ("northd: Optimize ct nat for load balancer
> traffic.") calls to 'ct()' and 'ct(nat)' are merged because 'ct(nat)'
> implies 'ct()'. However ovn-trace was not setting ct_state when
> processing 'ct(nat)'. This was yielding unexpected results.
>
> Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2017540
> Reported-by: Surya Seetharaman
> Signed-off-by: Dumitru Ceara
Thanks for fixing this.
I applied this patch to the main branch and backported to branch-21.09
and branch-21.06.
Numan
> ---
> tests/ovn-northd.at | 39 +++
> utilities/ovn-trace.c | 31 +--
> 2 files changed, 60 insertions(+), 10 deletions(-)
>
> diff --git a/tests/ovn-northd.at b/tests/ovn-northd.at
> index e2b9924b6..635c028d2 100644
> --- a/tests/ovn-northd.at
> +++ b/tests/ovn-northd.at
> @@ -5466,3 +5466,42 @@ wait_row_count Datapath_Binding 1
>
> AT_CLEANUP
> ])
> +
> +OVN_FOR_EACH_NORTHD([
> +AT_SETUP([conntrack nat implies conntrack])
> +ovn_start
> +
> +check ovn-nbctl lr-add rtr \
> + -- set logical_router rtr options:chassis=hv \
> + -- lrp-add rtr rtr-ls 00:00:00:00:01:00 42.42.42.1/24 \
> + -- lb-add lb-test 43.43.43.43:4343 42.42.42.2:4242 tcp \
> + -- lr-lb-add rtr lb-test
> +check ovn-nbctl --wait=sb sync
> +
> +flow="eth.dst == 00:00:00:00:01:00 && inport == \"rtr-ls\" && ip4.src ==
> 42.42.42.42 && ip4.dst == 43.43.43.43 && ip.ttl == 64 && tcp && tcp.dst ==
> 4343"
> +
> +AT_CHECK_UNQUOTED([ovn-trace --ct new --minimal "${flow}" --lb-dst
> 42.42.42.42:4242], [0], [dnl
> +#
> tcp,reg14=0x1,vlan_tci=0x,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:01:00,nw_src=42.42.42.42,nw_dst=43.43.43.43,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=0,tp_dst=4343,tcp_flags=0
> +ct_dnat /* assuming no un-dnat entry, so no change */ {
> +ct_lb {
> +ip.ttl--;
> +eth.src = 00:00:00:00:01:00;
> +eth.dst = 00:00:00:00:00:00;
> +arp {
> +eth.dst = ff:ff:ff:ff:ff:ff;
> +arp.spa = 0x2a2a2a01;
> +arp.tpa = 0x2a2a2a02;
> +arp.op = 1;
> +output("rtr-ls");
> +};
> +};
> +};
> +])
> +
> +AT_CHECK_UNQUOTED([ovn-trace --minimal "${flow}" --lb-dst 42.42.42.42:4242],
> [0], [dnl
> +#
> tcp,reg14=0x1,vlan_tci=0x,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:01:00,nw_src=42.42.42.42,nw_dst=43.43.43.43,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=0,tp_dst=4343,tcp_flags=0
> +ct_dnat /* assuming no un-dnat entry, so no change */ /* default (use --ct
> to customize) */;
> +])
> +
> +AT_CLEANUP
> +])
> diff --git a/utilities/ovn-trace.c b/utilities/ovn-trace.c
> index 5d016b757..65a1822ea 100644
> --- a/utilities/ovn-trace.c
> +++ b/utilities/ovn-trace.c
> @@ -199,6 +199,17 @@ parse_ct_option(const char *state_s_)
> ct_states[n_ct_states++] = state;
> }
>
> +static uint32_t
> +next_ct_state(struct ds *out_comment)
> +{
> +if (ct_state_idx < n_ct_states) {
> +return ct_states[ct_state_idx++];
> +} else {
> +ds_put_format(out_comment, " /* default (use --ct to customize) */");
> +return CS_ESTABLISHED | CS_TRACKED;
> +}
> +}
> +
> static void
> parse_lb_option(const char *s)
> {
> @@ -2248,23 +2259,17 @@ execute_ct_next(const struct ovnact_ct_next *ct_next,
> enum ovnact_pipeline pipeline, struct ovs_list *super)
> {
> /* Figure out ct_state. */
> -uint32_t state;
> -const char *comment;
> -if (ct_state_idx < n_ct_states) {
> -state = ct_states[ct_state_idx++];
> -comment = "";
> -} else {
> -state = CS_ESTABLISHED | CS_TRACKED;
> -comment = " /* default (use --ct to customize) */";
> -}
> +struct ds comment = DS_EMPTY_INITIALIZER;
> +uint32_t state = next_ct_state(&comment);
>
> /* Make a sub-node for attaching the next table. */
> struct ds s = DS_EMPTY_INITIALIZER;
> format_flags(&s, ct_state_to_string, state, '|');
> struct ovntrace_node *node = ovntrace_node_append(
> super, OVNTRACE_NODE_TRANSFORMATION, "ct_next(ct_state=%s%s)",
> -ds_cstr(&s), comment);
> +ds_cstr(&s), ds_cstr(&comment));
> ds_destroy(&s);
> +ds_destroy(&comment);
>
> /* Trace the actions in the next table. */
> struct flow ct_flow = *uflow;
> @@ -2319,6 +2324,12 @@ execute_ct_nat(const struct ovnact_ct_nat *ct_nat,
> ds_put_format(&s, " /* assuming no un-%cnat entry, so no change */",
>direction[0]);
> }
> +
> +/* ct(nat) implies ct(). */
> +if (!(ct_flow.ct_state & CS_TRACKED)) {
> +ct_flow.ct_state |= next_ct_state(&s);
> +}
> +
> struct ovntrace_node *node = ovntrace_node_append(
> super, OVNTRACE_NODE_TRANSFORMATION, "%s", ds_cstr(&s));
> ds_destroy(&s);
> --
> 2.27.0
>
> ___
> dev mailing list
> d...@openvswitch.org
> http
Re: [ovs-dev] [PATCH ovn v10 0/4] Introduce infrastructure for VIF plug providers.
On Tue, Nov 9, 2021 at 1:38 AM Frode Nordahl wrote: > > On Mon, Nov 8, 2021 at 11:08 PM Numan Siddique wrote: > > > > On Fri, Nov 5, 2021 at 5:32 PM Frode Nordahl > > wrote: > > > > > > fre. 5. nov. 2021, 20:43 skrev Han Zhou : > > > > > > > > > > > > > > > On Fri, Nov 5, 2021 at 7:00 AM Frode Nordahl > > > > > > > > wrote: > > > > > > > > > > Introduce infrastructure for VIF plug providers and add feature to > > > > > ovn-controller to add and remove ports on the integration bridge as > > > > > directed by CMS through Logical_Switch_Port options. > > > > > > > > > > Traditionally it has been the CMSs responsibility to create Virtual > > > > > Interfaces (VIFs) as part of instance (Container, Pod, Virtual > > > > > Machine etc.) life cycle, and subsequently manage plug/unplug > > > > > operations on the Open vSwitch integration bridge. > > > > > > > > > > With the advent of NICs connected to multiple distinct CPUs we can > > > > > have a topology where the instance runs on one host and Open > > > > > vSwitch and OVN runs on a different host, the smartnic control plane > > > > > CPU. The host facing interfaces will be visible to Open vSwitch > > > > > and OVN as representor ports. > > > > > > > > > > The actions necessary for plugging and unplugging the representor > > > > > port in Open vSwitch running on the smartnic control plane CPU would > > > > > be the same for every CMS. > > > > > > > > > > Hardware or platform specific details for initialization and lookup > > > > > of representor ports is provided by an plugging provider hosted > > > > > inside or outside the core OVN repository, and linked at OVN build > > > > > time. > > > > > > > > > > RFC1 -> RFC2: > > > > > - Introduce the plug-provider interface, remove hardware/platform > > > > >dependent code. > > > > > - Add ovsport module. > > > > > - Integrate with binding module. > > > > > - Split into multiple patches. > > > > > > > > > > RFC2 -> v1: > > > > > - Extend build system, `--with-plug-provider`. > > > > > - Check for required data in b_ctx_in and lbinding data structures. > > > > > - Split consider_plug_lport into update and create processing > > > > >functions. > > > > > - Consider unplug on release where relevant. > > > > > - Add ovn-controller `--enable-dummy-plug` option for testing. > > > > > - Consistent function naming and move ovsport module to controller/. > > > > > - Rename plug-test.c -> plug-dummy.c. > > > > > - Add functional- and unit- tests. > > > > > > > > > > v1 -> v2: > > > > > - Move update to controller/binding.h from patch 6 -> patch 5. > > > > > - Fix lint problems reported by 0-day Robot. > > > > > > > > > > v2 -> v3: > > > > > - Fix build system extension for plug provider. > > > > > - Implement DDlog version of northd change. > > > > > - Rebase on tip. > > > > > > > > > > v3 -> v4: > > > > > - sb:Port_Binding:plugged_by -> sb:Port_Binding:requested_chassis. > > > > > - Move documentation of plugin specific options to plugin > > > > >implementation. > > > > > - ovn-northd-ddlog: squash changes into same patch as C version, > > > > > rework > > > > >the DDlog implementation. > > > > > - controller: Use requested_chassis column instead of parsing > > > > > options. > > > > > - plug-provider: Remove the extra class instantiation layer and > > > > >refcounting. Add documentation and various tweaks. > > > > > - controller: Add engine node for plug provider so that a plugin run > > > > >function can run at an appropriate time and also allow feeding back > > > > >information about changes that can not be handled incrementally. > > > > > - binding: Fix return values for plug functions so they adhere to the > > > > >incremental processing engine contract. > > > > > - Add support for building in-t
Re: [ovs-dev] [PATCH ovn v2] nb: Add support for gateway_mtu_bypass.
On Fri, Nov 5, 2021 at 5:21 AM Dumitru Ceara wrote:
>
> There are various costs (e.g., not being able to perform hardware
> offload in some cases) when using check_pkt_larger() so the CMS
> can now limit the impact by bypassing the packet length checks for
> specific types of traffic (e.g., TCP).
>
> Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2011779
> Signed-off-by: Dumitru Ceara
Hi Dumitru,
Thanks for the patch. Instead of adding a bypass option, how about adding
the option to check for the extra matches ?
i.e new option can be - gateway_mtu_match. And ovn-northd would append
this match to the existing logical flows with the action - check_pkt_larger ?
This would not increase the number of lflows ? It's possible that I may have
missed a few details/scenarios. What do you think?
Otherwise the patch LGTM.
Thanks
Numan
> ---
> v2: Rebase.
> ---
> NEWS| 1 +
> northd/northd.c | 105 ++--
> northd/ovn-northd.8.xml | 14 ++
> ovn-nb.xml | 23 +
> tests/ovn-northd.at | 72 ---
> 5 files changed, 163 insertions(+), 52 deletions(-)
>
> diff --git a/NEWS b/NEWS
> index 5f448e67d..56261d9a5 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -6,6 +6,7 @@ Post v21.09.0
> if not desired.
>- Added Load_Balancer_Group support, which simplifies large scale
> configurations of load balancers.
> + - Added Logical_Router_Port "gateway_mtu_bypass" option.
>
> OVN v21.09.0 - 01 Oct 2021
> --
> diff --git a/northd/northd.c b/northd/northd.c
> index ee4d4df26..7fc7e9471 100644
> --- a/northd/northd.c
> +++ b/northd/northd.c
> @@ -10201,8 +10201,47 @@ build_adm_ctrl_flows_for_lrouter(
> }
> }
>
> -static int
> -build_check_pkt_len_action_string(struct ovn_port *op, struct ds *actions);
> +/* All 'gateway_mtu' and 'gateway_mtu_bypass' flows should be built with this
> + * function.
> + */
> +static void OVS_PRINTF_FORMAT(9, 10)
> +build_gateway_mtu_flow(struct hmap *lflows, struct ovn_port *op,
> + enum ovn_stage stage, uint16_t prio_low,
> + uint16_t prio_high, struct ds *match,
> + struct ds *actions, const struct ovsdb_idl_row *hint,
> + const char *extra_actions_fmt, ...)
> +{
> +int gw_mtu = smap_get_int(&op->nbrp->options, "gateway_mtu", 0);
> +
> +va_list extra_actions_args;
> +va_start(extra_actions_args, extra_actions_fmt);
> +
> +ds_clear(actions);
> +if (gw_mtu > 0) {
> +ds_put_format(actions, REGBIT_PKT_LARGER" = check_pkt_larger(%d); ",
> + gw_mtu + VLAN_ETH_HEADER_LEN);
> +}
> +
> +ds_put_format_valist(actions, extra_actions_fmt, extra_actions_args);
> +ovn_lflow_add_with_hint(lflows, op->od, stage, prio_low,
> +ds_cstr(match), ds_cstr(actions),
> +hint);
> +
> +if (gw_mtu > 0) {
> +const char *gw_mtu_bypass = smap_get(&op->nbrp->options,
> + "gateway_mtu_bypass");
> +if (gw_mtu_bypass) {
> +ds_clear(actions);
> +ds_put_format_valist(actions, extra_actions_fmt,
> + extra_actions_args);
> +ds_put_format(match, " && (%s)", gw_mtu_bypass);
> +ovn_lflow_add_with_hint(lflows, op->od, stage, prio_high,
> +ds_cstr(match), ds_cstr(actions),
> +hint);
> +}
> +}
> +va_end(extra_actions_args);
> +}
>
> /* Logical router ingress Table 0: L2 Admission Control
> * This table drops packets that the router shouldn’t see at all based
> @@ -10230,17 +10269,12 @@ build_adm_ctrl_flows_for_lrouter_port(
> * This will save us from having to match on inport further down in
> * the pipeline.
> */
> -ds_clear(actions);
> -
> -build_check_pkt_len_action_string(op, actions);
> -ds_put_format(actions, REG_INPORT_ETH_ADDR " = %s; next;",
> - op->lrp_networks.ea_s);
> -
> ds_clear(match);
> ds_put_format(match, "eth.mcast && inport == %s", op->json_key);
> -ovn_lflow_add_with_hint(lflows, op->od, S_ROUTER_IN_ADMISSION, 50,
> -ds_cstr(match), ds_cstr(actions),
> -&op->nbrp->header_);
> +build_gateway_mtu_flow(lflows, op, S_ROUTER_IN_ADMISSION, 50, 55,
> + match, actions, &op->nbrp->header_,
> + REG_INPORT_ETH_ADDR " = %s; next;",
> + op->lrp_networks.ea_s);
>
> ds_clear(match);
> ds_put_format(match, "eth.dst == %s && inport == %s",
> @@ -10251,9 +10285,10 @@ build_adm_ctrl_flows_for_lrouter_port(
> ds_put_format(match, " && is_chassis_residen
Re: [ovs-dev] [PATCH ovn v1 1/5] manpages.mk: fix dependencies path
; > >>> "-*- buffer-read-only: t -*-") > >>> @@ -28,6 +63,7 @@ def sodepends(include_dirs, filenames, dst): > >>> continue > >>> # Open file. > >>> +include_dirs = [info[0] for info in include_info] > >>> fn = soutil.find_file(include_dirs, toplevel) > >>> if not fn: > >>> ok = False > >>> @@ -47,8 +83,9 @@ def sodepends(include_dirs, filenames, dst): > >>> name = soutil.extract_include_directive(line) > >>> if name: > >>> -if soutil.find_file(include_dirs, name): > >>> - dependencies.append(name) > >>> +include_file = find_include_file(include_info, name) > >>> +if include_file: > >>> +dependencies.append(include_file) > >>> else: > >>> ok = False > >>> @@ -62,6 +99,6 @@ def sodepends(include_dirs, filenames, dst): > >>> if __name__ == '__main__': > >>> -include_dirs, args = soutil.parse_include_dirs() > >>> +include_dirs, args = parse_include_dirs() > >>> error = not sodepends(include_dirs, args, sys.stdout) > >>> sys.exit(1 if error else 0) > >> > >> +Numan > >> > >> In general, I'm not completely sure about why sodepends.py needs to be > >> part of OVN and why we can't use the OVS version? > > > > OVS does not have this problem as everything is under the root tree so I > > assumed it would be preferred to implement it in OVN rather than add > > stuff to OVS that will not be used by OVS. > > But I don't have a strong opinion on this. If you prefer to implement > > this in OVS and use it from OVN, I'll remove this patch from the series, > > send it to OVS and send a patch to OVN that uses it. > > > > +Mark > > In any case, this doesn't really block the rest of the series, I think > patches 2-5 can be applied already to main branch if maintainers agree. Thanks Adrian for this patch series and Dumitru for the reviews. I applied the patches 2-5 to the main branch. For this patch Acked-by: Numan Siddique My 2 cents - I'm fine modifying the sodepends.py in OVN. I'd personally prefer to move the OVS bits into OVN for man page generation so that we can change the code (in future) if required as per OVN's requirements. Thanks Numan > > Thanks! > > ___ > 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] Add a northbound interface to program MAC_Binding table
On Wed, Nov 3, 2021 at 3:17 PM svc.eng.git-mail
wrote:
>
> Hi Lorenzo,
>
> > what will it happen if pinctrl learns a different MAC for the given IP
> > after the CMS has
> configured the static binding? Will it be overwritten? If so I guess we need a
> flag to avoid it.
>
> 1. Static binding will be overwritten by pinctrl.
> 2. Northd will again overwrite this and propagate the value that is
> statically configured. Eventual state of the system is the configuration from
> CMS.
>
> If I have to introduce a flag to prioritize one over the other, I also need
> to remember the state as to which entries are static.
>
> Option 1:
> - NB MAC_Binding has new columns: is_static: boolean,
> options:allow_override=boolean
> - SB MAC_Binding has new columns: is_static: boolean,
> options:allow_override=boolean
> - pinctrl logic would look something like
> sb->is_static && sb->allow_override {
> update_mac
> }
> - build_mac_binding_table will have to change. When an entry is removed from
> NB it has to also cleanup the corresponding SB entry in order to not leave
> behind and static entries. Something like what build_datapaths is doing. I
> think this iteration is expensive. Linear in terms of the number of
> MAC_Binding entries.
>
> Option 2:
> - Add a separate SB Static_MAC_Binding table. Now the iteration is linear in
> terms of the number of Static_MAC_Binding entries.
> - Have the get_arp function look at both SB tables and prioritize based on
> some flag.
>
> What do you recommend? Do you have any alternatives in mind?
With your present proposed patch, as you mentioned, eventually
ovn-northd will update the mac binding entry
with the configured value if ovn-controller updates the entry with a
different mac. This should be fine IMO.
However this can cause a continuous churn if the external entity keeps
using a different mac than the one
configured by CMS if ovn-controller sees the ARP packets.
I think a flag could be beneficial to specify the precedence. Having a
separate mac binding table as you mentioned in (2) makes sense.
ovn-controller adds the mac lookup flows in tables -
OFTABLE_MAC_BINDING and OFTABLE_MAC_LOOKUP.
ovn-controller can add higher priority flows for the
'Static_MAC_Binding' table entries (or the MAC_Binding table)
depending on the flag.
Thanks
Numan
>
> Thank You,
> Karthik C
>
> On 11/3/21, 10:13 AM, "Lorenzo Bianconi" wrote:
> > Hi Lorenzo,
> >
> > Thanks for the review. Do we need a flag to control statically added MACs
> > from CMS vs dynamically learnt MAC from pinctrl for a given IP?
>
> Yes, I think so.
>
> >
> > Typically static configurations for a MAC Table override dynamically learnt
> > MACs. In this patch even if pinctrl learns a different MAC for the given
> > IP, statically configured MAC will eventually be programmed.
>
> what will it happen if pinctrl learns a different MAC for the given IP after
> the CMS has
> configured the static binding? Will it be overwritten? If so I guess we need a
> flag to avoid it.
>
> Regards,
> Lorenzo
>
> >
> > Thank You,
> > Karthik C
> >
> > On 10/25/21, 2:53 AM, "Lorenzo Bianconi"
> > mailto:lorenzo.bianc...@redhat.com>> wrote:
> > > From: Karthik Chandrashekar
> > > mailto:karthi...@nutanix.com>>
> > >
> >
> > [...]
> > >
> > > +static void
> > > +build_mac_binding_table(struct northd_context *ctx, struct hmap *ports)
> > > +{
> > > +const struct nbrec_mac_binding *nb_mac_binding;
> > > +NBREC_MAC_BINDING_FOR_EACH (nb_mac_binding, ctx->ovnnb_idl) {
> > > +struct ovn_port *op = ovn_port_find(
> > > +ports, nb_mac_binding->logical_port);
> > > +if (op && op->nbrp) {
> > > +struct ovn_datapath *od = op->od;
> > > +if (od && od->sb) {
> > > +const struct sbrec_mac_binding *mb =
> > > +
> > > mac_binding_lookup(ctx->sbrec_mac_binding_by_lport_ip,
> > > + nb_mac_binding->logical_port,
> > > + nb_mac_binding->ip);
> > > +if (!mb) {
> > > +mb = sbrec_mac_binding_insert(ctx->ovnsb_txn);
> > > +sbrec_mac_binding_set_logical_port(
> > > +mb, nb_mac_binding->logical_port);
> > > +sbrec_mac_binding_set_ip(mb, nb_mac_binding->ip);
> > > +sbrec_mac_binding_set_mac(mb, nb_mac_binding->mac);
> > > +sbrec_mac_binding_set_datapath(mb, od->sb);
> > > +} else {
> > > +sbrec_mac_binding_set_mac(mb, nb_mac_binding->mac);
> > > +}
> >
> > I guess we should add some flags here to consider the case both the user/CMS
> > adds a static mac binding and pinctrl discovers the same IP address. What do
> > you think?
> >
> > > +}
> > > +}
> > > +}
> > > +}
> > > +
> > > /* Returns a string of the IP addr
Re: [ovs-dev] [PATCH ovn v2] nb: Add support for gateway_mtu_bypass.
On Wed, Nov 10, 2021 at 5:19 AM Dumitru Ceara wrote:
>
> On 11/9/21 8:24 PM, Numan Siddique wrote:
> > On Fri, Nov 5, 2021 at 5:21 AM Dumitru Ceara wrote:
> >>
> >> There are various costs (e.g., not being able to perform hardware
> >> offload in some cases) when using check_pkt_larger() so the CMS
> >> can now limit the impact by bypassing the packet length checks for
> >> specific types of traffic (e.g., TCP).
> >>
> >> Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2011779
> >> Signed-off-by: Dumitru Ceara
> >
> >
> > Hi Dumitru,
> >
>
> Hi Numan,
>
> Thanks for reviewing this!
>
> > Thanks for the patch. Instead of adding a bypass option, how about adding
> > the option to check for the extra matches ?
>
> We could do that too, even if it's just for making it more natural to
> configure.
>
> >
> > i.e new option can be - gateway_mtu_match. And ovn-northd would append
> > this match to the existing logical flows with the action - check_pkt_larger
> > ?
>
> That wouldn't work directly. That's because we already append
> check_pkt_larger() to flows that perform other actions.
Ah I see. I missed this. Thanks.
>
> Let's assume we start with gateway_mtu not configured, then we'd have
> (at least) the following flows:
>
> - table=rtr_in_admission,prio=50, eth.mcast && inport == ,
> actions='REG_INPORT_ETH_ADDR = .eth, next;'
> - table=rtr_in_admission,prio=50, eth.dst == && inport ==
> && is_chassis_resident(),
> actions='REG_INPORT_ETH_ADDR = .eth, next;'
>
> If we now configure gateway_mtu=1400 these flows get changed to:
>
> - table=rtr_in_admission,prio=50, eth.mcast && inport == ,
> actions='REG_INPORT_ETH_ADDR = .eth;
> reg9[1]=check_pkt_larger(1428); next;'
> - table=rtr_in_admission,prio=50, eth.dst == && inport ==
> && is_chassis_resident(),
> actions='REG_INPORT_ETH_ADDR = .eth;
> reg9[1]=check_pkt_larger(1428); next;'
>
> Just adding an extra gateway_mtu_match to the matches of the two flows
> above would be wrong as we would not be performing the other actions
> ("REG_INPORT_ETH_ADDR = ; next;") for all traffic that doesn't
> need check_pkt_larger.
>
> >
> > This would not increase the number of lflows ? It's possible that I may
> > have
> > missed a few details/scenarios. What do you think?
>
> Due to the reasons above, this other approach you're suggesting would
> unfortunately also have to increase the number of flows. However, we're
> not talking about a huge increase because we currently have at most 3
> flows per logical router port that has gateway_mtu enabled. I don't
> expect the number of such ports to be huge.
Agree.
>
> >
> > Otherwise the patch LGTM.
> >
>
> If you think it makes more sense to configure "gateway_mtu_match"
> instead of "gateway_mtu_bypass", I'm ok with that and I can send a v3
> but the implementation would be very similar to the one in v2.
Having a whitelist match seems more natural to me. So my suggestion
would be for "gateway_mtu_match".
Thanks
Numan
>
> Thanks,
> 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 v2] nb: Add support for gateway_mtu_bypass.
On Wed, Nov 10, 2021 at 12:24 PM Numan Siddique wrote:
>
> On Wed, Nov 10, 2021 at 5:19 AM Dumitru Ceara wrote:
> >
> > On 11/9/21 8:24 PM, Numan Siddique wrote:
> > > On Fri, Nov 5, 2021 at 5:21 AM Dumitru Ceara wrote:
> > >>
> > >> There are various costs (e.g., not being able to perform hardware
> > >> offload in some cases) when using check_pkt_larger() so the CMS
> > >> can now limit the impact by bypassing the packet length checks for
> > >> specific types of traffic (e.g., TCP).
> > >>
> > >> Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2011779
> > >> Signed-off-by: Dumitru Ceara
> > >
> > >
> > > Hi Dumitru,
> > >
> >
> > Hi Numan,
> >
> > Thanks for reviewing this!
> >
> > > Thanks for the patch. Instead of adding a bypass option, how about
> > > adding
> > > the option to check for the extra matches ?
> >
> > We could do that too, even if it's just for making it more natural to
> > configure.
> >
> > >
> > > i.e new option can be - gateway_mtu_match. And ovn-northd would append
> > > this match to the existing logical flows with the action -
> > > check_pkt_larger ?
> >
> > That wouldn't work directly. That's because we already append
> > check_pkt_larger() to flows that perform other actions.
>
> Ah I see. I missed this. Thanks.
> >
> > Let's assume we start with gateway_mtu not configured, then we'd have
> > (at least) the following flows:
> >
> > - table=rtr_in_admission,prio=50, eth.mcast && inport == ,
> > actions='REG_INPORT_ETH_ADDR = .eth, next;'
> > - table=rtr_in_admission,prio=50, eth.dst == && inport ==
> > && is_chassis_resident(),
> > actions='REG_INPORT_ETH_ADDR = .eth, next;'
> >
> > If we now configure gateway_mtu=1400 these flows get changed to:
> >
> > - table=rtr_in_admission,prio=50, eth.mcast && inport == ,
> > actions='REG_INPORT_ETH_ADDR = .eth;
> > reg9[1]=check_pkt_larger(1428); next;'
> > - table=rtr_in_admission,prio=50, eth.dst == && inport ==
> > && is_chassis_resident(),
> > actions='REG_INPORT_ETH_ADDR = .eth;
> > reg9[1]=check_pkt_larger(1428); next;'
> >
> > Just adding an extra gateway_mtu_match to the matches of the two flows
> > above would be wrong as we would not be performing the other actions
> > ("REG_INPORT_ETH_ADDR = ; next;") for all traffic that doesn't
> > need check_pkt_larger.
> >
> > >
> > > This would not increase the number of lflows ? It's possible that I may
> > > have
> > > missed a few details/scenarios. What do you think?
> >
> > Due to the reasons above, this other approach you're suggesting would
> > unfortunately also have to increase the number of flows. However, we're
> > not talking about a huge increase because we currently have at most 3
> > flows per logical router port that has gateway_mtu enabled. I don't
> > expect the number of such ports to be huge.
>
> Agree.
>
> >
> > >
> > > Otherwise the patch LGTM.
> > >
> >
> > If you think it makes more sense to configure "gateway_mtu_match"
> > instead of "gateway_mtu_bypass", I'm ok with that and I can send a v3
> > but the implementation would be very similar to the one in v2.
>
> Having a whitelist match seems more natural to me. So my suggestion
> would be for "gateway_mtu_match".
On second thought, I think "gateway_mtu_bypass" makes more sense.
If a user wants to bypass "tcp" protocol, then with gateway_mtu_match user has
to add a match like - "(udp || icmp)" which would result in more openflows.
I'll take a closer look into v2 tomorrow.
Thanks
Numan
>
> Thanks
> Numan
>
> >
> > Thanks,
> > 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 branch-21.09 1/2] Set release date for 21.09.1.
On Thu, Nov 11, 2021 at 10:44 AM 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 63d765aa4..4b0f46192 100644 > --- a/NEWS > +++ b/NEWS > @@ -1,5 +1,6 @@ > -OVN v21.09.1 - xx xxx > +OVN v21.09.1 - 11 Nov 2021 > -- > + - Bug fixes >- Added Load_Balancer_Group support, which simplifies large scale > configurations of load balancers. > > diff --git a/debian/changelog b/debian/changelog > index a0c0eda1a..f6fa0f7c1 100644 > --- a/debian/changelog > +++ b/debian/changelog > @@ -2,7 +2,7 @@ ovn (21.09.1-1) unstable; urgency=low > > * New upstream version > > - -- OVN team Fri, 01 Oct 2021 12:00:00 -0400 > + -- OVN team Thu, 11 Nov 2021 10:40:17 -0500 > > ovn (21.09.0-1) unstable; urgency=low > > -- > 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 branch-21.09 2/2] Prepare for 21.09.2.
On Thu, Nov 11, 2021 at 10:44 AM 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 4b0f46192..1b582ca1e 100644 > --- a/NEWS > +++ b/NEWS > @@ -1,3 +1,6 @@ > +OVN v21.09.2 - xx xxx > +-- > + > OVN v21.09.1 - 11 Nov 2021 > -- >- Bug fixes > diff --git a/configure.ac b/configure.ac > index 12d2509cd..31b1f4cbc 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -13,7 +13,7 @@ > # limitations under the License. > > AC_PREREQ(2.63) > -AC_INIT(ovn, 21.09.1, b...@openvswitch.org) > +AC_INIT(ovn, 21.09.2, 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 f6fa0f7c1..7a89776c4 100644 > --- a/debian/changelog > +++ b/debian/changelog > @@ -1,3 +1,9 @@ > +OVN (21.09.2-1) unstable; urgency=low > + [ OVN team ] > + * New upstream version > + > + -- OVN team Thu, 11 Nov 2021 10:40:17 -0500 > + > ovn (21.09.1-1) unstable; urgency=low > > * New upstream version > -- > 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] ovn-nbctl: Fix lrp-set-gateway-chassis.
On Wed, Nov 10, 2021 at 7:39 PM Han Zhou wrote:
>
> Currently this command assumes that if the gateway_chassis record with
> expected name exists it is set to the logical port, so once the record
> is found it not set to the lrp again. However, this assumption is not
> always true.
>
> An example is that when combined with a lrp-del and then lrp-add
> commands before lrp-set-gateway-chassis in the same transaction, the
> gateway_chassis record will be found but it is not set to the lrp. This
> is causing the gateway-chassis setting flapping in ovn-kubernetes'
> cluster router logical ports.
>
> This patch makes sure the gateway_chassis record (existed or newly
> created) is set to the lrp's gateway-chassis column.
>
> Signed-off-by: Han Zhou
Acked-by: Numan Siddique
Numan
> ---
> ovs | 2 +-
> tests/ovn-nbctl.at| 6 ++
> utilities/ovn-nbctl.c | 19 ---
> 3 files changed, 15 insertions(+), 12 deletions(-)
>
> diff --git a/ovs b/ovs
> index 1bdda7b6d..429b114c5 16
> --- a/ovs
> +++ b/ovs
> @@ -1 +1 @@
> -Subproject commit 1bdda7b6d53c92e877b457157676aff326414c53
> +Subproject commit 429b114c5aadee24ccfb16ad7d824f45cdcea75a
> diff --git a/tests/ovn-nbctl.at b/tests/ovn-nbctl.at
> index a8946fef8..3846ba727 100644
> --- a/tests/ovn-nbctl.at
> +++ b/tests/ovn-nbctl.at
> @@ -1389,6 +1389,12 @@ AT_CHECK([ovn-nbctl lrp-set-gateway-chassis lrp0
> chassis1 10])
> AT_CHECK([ovn-nbctl lrp-get-gateway-chassis lrp0], [0], [dnl
> lrp0-chassis110
> ])
> +
> +AT_CHECK([ovn-nbctl lrp-del lrp0 -- lrp-add lr0 lrp0 00:00:00:01:02:03
> 192.168.1.1/24 -- lrp-set-gateway-chassis lrp0 chassis1 10])
> +AT_CHECK([ovn-nbctl lrp-get-gateway-chassis lrp0], [0], [dnl
> +lrp0-chassis110
> +])
> +
> AT_CHECK([ovn-nbctl lrp-set-gateway-chassis lrp0 chassis1 20])
>
> AT_CHECK([ovn-nbctl lrp-get-gateway-chassis lrp0], [0], [dnl
> diff --git a/utilities/ovn-nbctl.c b/utilities/ovn-nbctl.c
> index 2a68ccd16..72049ffd8 100644
> --- a/utilities/ovn-nbctl.c
> +++ b/utilities/ovn-nbctl.c
> @@ -5100,24 +5100,21 @@ nbctl_lrp_set_gateway_chassis(struct ctl_context *ctx)
> }
>
> gc_name = xasprintf("%s-%s", lrp_name, chassis_name);
> -const struct nbrec_gateway_chassis *existing_gc;
> -error = gc_by_name_or_uuid(ctx, gc_name, false, &existing_gc);
> +const struct nbrec_gateway_chassis *gc;
> +error = gc_by_name_or_uuid(ctx, gc_name, false, &gc);
> if (error) {
> ctx->error = error;
> free(gc_name);
> return;
> }
> -if (existing_gc) {
> -nbrec_gateway_chassis_set_priority(existing_gc, priority);
> -free(gc_name);
> -return;
> +
> +if (!gc) {
> +/* Create the logical gateway chassis. */
> +gc = nbrec_gateway_chassis_insert(ctx->txn);
> +nbrec_gateway_chassis_set_name(gc, gc_name);
> +nbrec_gateway_chassis_set_chassis_name(gc, chassis_name);
> }
>
> -/* Create the logical gateway chassis. */
> -struct nbrec_gateway_chassis *gc
> -= nbrec_gateway_chassis_insert(ctx->txn);
> -nbrec_gateway_chassis_set_name(gc, gc_name);
> -nbrec_gateway_chassis_set_chassis_name(gc, chassis_name);
> nbrec_gateway_chassis_set_priority(gc, priority);
>
> /* Insert the logical gateway chassis into the logical router port. */
> --
> 2.30.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-21.09] ovs: Update submodule to include removal of pyopenssl.
On Thu, Nov 11, 2021 at 3:20 PM Mark Michelson wrote: > > On 11/11/21 14:04, Ilya Maximets wrote: > > On 11/11/21 19:02, Mark Michelson wrote: > >> RHEL 9 and CentOS 9 no longer contain a pyopenssl package. Therefore, > >> for RHEL 9 and CentOS 9 builds of OVN, we need to no longer rely on the > >> pyopenssl package. OVS's python IDL was recently updated to no longer > >> depend on pyopenssl, favoring instead to use the built-in SSL module. > >> > >> This commit pulls in that change so that packages of OVN 21.09 can be > >> made without the dependency of pyopenssl. > >> > >> Signed-off-by: Mark Michelson > >> --- > >> ovs | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/ovs b/ovs > >> index 429b114c5..68543dd52 16 > >> --- a/ovs > >> +++ b/ovs > >> @@ -1 +1 @@ > >> -Subproject commit 429b114c5aadee24ccfb16ad7d824f45cdcea75a > >> +Subproject commit 68543dd523bd00f53fa7b91777b962ccb22ce679 > >> > > > > Hey, Mark. > > > > Current version of a submodule is already > > 1bdda7b6d53c92e877b457157676aff326414c53, which is newer than > > the version you're trying to update to with this patch. > > > > Best regards, Ilya Maximets. > > > > Ah, sorry for the confusion. I failed to note that my patch is for > branch-21.09, which is on an older commit from OVS. I neglected to > indicate this in the subject line. I've amended it now. > Hi Mark, I think we can just backport this commit [1] to branch-21.09. [1] - https://github.com/ovn-org/ovn/commit/5c6f8bd7ba43b5e1e9fcfd4d6e56748d6bac3285 Thanks 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 v6 2/4] northd, utils: support for RouteTables in LRs
On Thu, Nov 11, 2021 at 2:18 PM Odintsov Vladislav wrote: > > Hi Han, Numan, > > I’ve posted a new version of this series [1] and addressed your comments and > suggestions. > I’ll appreciate if you can take a look on this please and I’d be happy if > this can be included in next OVN release. > > Thanks. Thanks Vladislav, I'll take a look at the patches next week. Numan > > 1: > https://patchwork.ozlabs.org/project/ovn/cover/2021191306.6369-1-odiv...@gmail.com/ > > Regards, > Vladislav Odintsov > > On 20 Oct 2021, at 10:09, Han Zhou mailto:hz...@ovn.org>> > wrote: > > > > > On Tue, Oct 19, 2021 at 3:21 PM Numan Siddique > mailto:num...@ovn.org>> wrote: > > > > On Tue, Oct 19, 2021 at 3:28 AM Han Zhou > > mailto:hz...@ovn.org>> wrote: > > > > > > On Mon, Oct 18, 2021 at 6:35 AM Odintsov Vladislav > > > mailto:vlodint...@croc.ru>> > > > wrote: > > > > > > > > > > > > > > > > regards, > > > > Vladislav Odintsov > > > > > > > > > On 16 Oct 2021, at 03:20, Han Zhou > > > > > mailto:hz...@ovn.org>> wrote: > > > > > > > > > > On Fri, Oct 15, 2021 at 2:36 AM Vladislav Odintsov > > > > > mailto:odiv...@gmail.com>> > > > > > wrote: > > > > > > > > > >> > > > > >> > > > > >> Regards, > > > > >> Vladislav Odintsov > > > > >> > > > > >> On 15 Oct 2021, at 08:42, Han Zhou > > > > >> mailto:hz...@ovn.org>> wrote: > > > > >> > > > > >> On Thu, Oct 14, 2021 at 12:58 AM Vladislav Odintsov > > > > >> mailto:odiv...@gmail.com>> > > > > >> wrote: > > > > >> > > > > >> > > > > >> Hi Han, > > > > >> > > > > >> Thanks for the review. > > > > >> > > > > >> Regards, > > > > >> Vladislav Odintsov > > > > >> > > > > >> On 14 Oct 2021, at 08:13, Han Zhou > > > > >> mailto:hz...@ovn.org>> wrote: > > > > >> > > > > >> > > > > >> > > > > >> On Tue, Oct 5, 2021 at 1:26 PM Vladislav Odintsov > > > > >> mailto:odiv...@gmail.com>> > > > > >> > > > > >> wrote: > > > > >> > > > > >> > > > > >> This patch extends Logical Router's routing functionality. > > > > >> Now user may create multiple routing tables within a Logical Router > > > > >> and assign them to Logical Router Ports. > > > > >> > > > > >> Traffic coming from Logical Router Port with assigned route_table > > > > >> is checked against global routes if any (Logical_Router_Static_Routes > > > > >> whith empty route_table field), next against directly connected > > > > >> routes > > > > >> > > > > >> > > > > >> This is not accurate. The "directly connected routes" is NOT after > > > > >> the > > > > >> > > > > >> global routes. Their priority only depends on the prefix length. > > > > >> > > > > >> > > > > >> and then Logical_Router_Static_Routes with same route_table value as > > > > >> in Logical_Router_Port options:route_table field. > > > > >> > > > > >> A new Logical Router ingress table #10 is added - IN_IP_ROUTING_PRE. > > > > >> In this table packets which come from LRPs with configured > > > > >> options:route_table field are checked against inport and in OVS > > > > >> register 7 unique non-zero value identifying route table is written. > > > > >> > > > > >> Then in 11th table IN_IP_ROUTING routes which have non-empty > > > > >> `route_table` field are added with additional match on reg7 value > > > > >> associated with appropriate route_table. > > > > >> > > > > >> > > > > >> Hi Vladislav, > > > > >> > > > > >> First of all, sorry for the delayed review, and thanks for > > > > >> implementing > > > > >> > > > >
Re: [ovs-dev] [PATCH ovn branch-21.09] ovs: Bump submodule to include ovsdb/IDL optimizations.
On Fri, Nov 12, 2021 at 10:54 AM Mark Michelson wrote: > > From: Dumitru Ceara > > There are two relevant OVS commits picked with this submodule update. > The first one significantly improves performance of OVN database clients > and the second one adds memory reporting for the OVN IDL clients. > > 1bdda7b6d ovsdb-idl: Use functions to apply diff in place. > 066741d9c ovsdb-idl: Add memory report function. > > https://bugzilla.redhat.com/show_bug.cgi?id=2020533 > Signed-off-by: Dumitru Ceara > Signed-off-by: Numan Siddique > Signed-off-by: Mark Michelson Acked-by: Numan Siddique Numan > --- > ovs | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/ovs b/ovs > index 429b114c5..1bdda7b6d 16 > --- a/ovs > +++ b/ovs > @@ -1 +1 @@ > -Subproject commit 429b114c5aadee24ccfb16ad7d824f45cdcea75a > +Subproject commit 1bdda7b6d53c92e877b457157676aff326414c53 > -- > 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 v10 0/4] Introduce infrastructure for VIF plug providers.
On Tue, Nov 9, 2021 at 3:03 PM Han Zhou wrote: > > On Tue, Nov 9, 2021 at 11:12 AM Numan Siddique wrote: > > > > On Tue, Nov 9, 2021 at 1:38 AM Frode Nordahl > > wrote: > > > > > > On Mon, Nov 8, 2021 at 11:08 PM Numan Siddique wrote: > > > > > > > > On Fri, Nov 5, 2021 at 5:32 PM Frode Nordahl > > > > wrote: > > > > > > > > > > fre. 5. nov. 2021, 20:43 skrev Han Zhou : > > > > > > > > > > > > > > > > > > > > > > > On Fri, Nov 5, 2021 at 7:00 AM Frode Nordahl < > frode.nord...@canonical.com> > > > > > > wrote: > > > > > > > > > > > > > > Introduce infrastructure for VIF plug providers and add feature > to > > > > > > > ovn-controller to add and remove ports on the integration > bridge as > > > > > > > directed by CMS through Logical_Switch_Port options. > > > > > > > > > > > > > > Traditionally it has been the CMSs responsibility to create > Virtual > > > > > > > Interfaces (VIFs) as part of instance (Container, Pod, Virtual > > > > > > > Machine etc.) life cycle, and subsequently manage plug/unplug > > > > > > > operations on the Open vSwitch integration bridge. > > > > > > > > > > > > > > With the advent of NICs connected to multiple distinct CPUs we > can > > > > > > > have a topology where the instance runs on one host and Open > > > > > > > vSwitch and OVN runs on a different host, the smartnic control > plane > > > > > > > CPU. The host facing interfaces will be visible to Open vSwitch > > > > > > > and OVN as representor ports. > > > > > > > > > > > > > > The actions necessary for plugging and unplugging the > representor > > > > > > > port in Open vSwitch running on the smartnic control plane CPU > would > > > > > > > be the same for every CMS. > > > > > > > > > > > > > > Hardware or platform specific details for initialization and > lookup > > > > > > > of representor ports is provided by an plugging provider hosted > > > > > > > inside or outside the core OVN repository, and linked at OVN > build > > > > > > > time. > > > > > > > > > > > > > > RFC1 -> RFC2: > > > > > > > - Introduce the plug-provider interface, remove > hardware/platform > > > > > > >dependent code. > > > > > > > - Add ovsport module. > > > > > > > - Integrate with binding module. > > > > > > > - Split into multiple patches. > > > > > > > > > > > > > > RFC2 -> v1: > > > > > > > - Extend build system, `--with-plug-provider`. > > > > > > > - Check for required data in b_ctx_in and lbinding data > structures. > > > > > > > - Split consider_plug_lport into update and create processing > > > > > > >functions. > > > > > > > - Consider unplug on release where relevant. > > > > > > > - Add ovn-controller `--enable-dummy-plug` option for testing. > > > > > > > - Consistent function naming and move ovsport module to > controller/. > > > > > > > - Rename plug-test.c -> plug-dummy.c. > > > > > > > - Add functional- and unit- tests. > > > > > > > > > > > > > > v1 -> v2: > > > > > > > - Move update to controller/binding.h from patch 6 -> patch 5. > > > > > > > - Fix lint problems reported by 0-day Robot. > > > > > > > > > > > > > > v2 -> v3: > > > > > > > - Fix build system extension for plug provider. > > > > > > > - Implement DDlog version of northd change. > > > > > > > - Rebase on tip. > > > > > > > > > > > > > > v3 -> v4: > > > > > > > - sb:Port_Binding:plugged_by -> > sb:Port_Binding:requested_chassis. > > > > > > > - Move documentation of plugin specific options to plugin > > > > > > >implementation. > > > > > > > - ovn-northd-ddlog: squash changes into same patc
Re: [ovs-dev] [PATCH ovn] northd: fix ttl exceeded with FIP
On Thu, Nov 11, 2021 at 3:44 PM Mark Michelson wrote:
>
> Hi Lorenzo, the patch looks good to me.
>
> Acked-by: Mark Michelson
>
> On 11/10/21 17:35, Lorenzo Bianconi wrote:
> > Properly manage ttl exceeded ICMP error messages when traffic is
> > directed to a FIP. The issue can be verified running traceroute from an
> > external device to a FIP:
> > $traceroute -I -z 1 -n
> >
> > Fix ttl exceeded priority respect to ping responder.
> >
> > Related bz: https://bugzilla.redhat.com/show_bug.cgi?id=2006349
> >
> > Signed-off-by: Lorenzo Bianconi
> > ---
> > northd/northd.c | 59 -
> > northd/ovn-northd.8.xml | 2 +-
> > tests/ovn.at| 10 +++
> > 3 files changed, 41 insertions(+), 30 deletions(-)
> >
> > diff --git a/northd/northd.c b/northd/northd.c
> > index 1e8a3457c..ce962cdc4 100644
> > --- a/northd/northd.c
> > +++ b/northd/northd.c
> > @@ -11798,6 +11798,7 @@ build_ipv6_input_flows_for_lrouter_port(
> > }
> >
> > /* ICMPv6 time exceeded */
> > +struct ds ip_ds = DS_EMPTY_INITIALIZER;
> > for (int i = 0; i < op->lrp_networks.n_ipv6_addrs; i++) {
> > /* skip link-local address */
> > if (in6_is_lla(&op->lrp_networks.ipv6_addrs[i].network)) {
> > @@ -11806,7 +11807,13 @@ build_ipv6_input_flows_for_lrouter_port(
> >
> > ds_clear(match);
> > ds_clear(actions);
> > -
> > +ds_clear(&ip_ds);
> > +if (op->od->n_l3dgw_ports && op->od->l3dgw_ports[0] == op) {
> > +ds_put_cstr(&ip_ds, "ip6.dst <-> ip6.src");
> > +} else {
> > +ds_put_format(&ip_ds, "ip6.dst = ip6.src; ip6.src = %s",
> > + op->lrp_networks.ipv6_addrs[i].addr_s);
> > +}
> > ds_put_format(match,
> > "inport == %s && ip6 && "
> > "ip6.src == %s/%d && "
> > @@ -11817,20 +11824,18 @@ build_ipv6_input_flows_for_lrouter_port(
> > ds_put_format(actions,
> > "icmp6 {"
> > "eth.dst <-> eth.src; "
> > - "ip6.dst = ip6.src; "
> > - "ip6.src = %s; "
> > - "ip.ttl = 255; "
> > + "%s ; ip.ttl = 254; "
Hi Lorenzo,
Can you please explain why the ttl is changed to 254 ?
> > "icmp6.type = 3; /* Time exceeded */ "
> > "icmp6.code = 0; /* TTL exceeded in transit */ "
> > - "next; };",
> > - op->lrp_networks.ipv6_addrs[i].addr_s);
> > -ovn_lflow_add_with_hint__(lflows, op->od,
> > S_ROUTER_IN_IP_INPUT, 40,
> > - ds_cstr(match), ds_cstr(actions),
> > NULL,
> > - copp_meter_get(COPP_ICMP6_ERR,
> > - op->od->nbr->copp,
> > - meter_groups),
> > - &op->nbrp->header_);
> > + "outport = %s; flags.loopback = 1; output; };",
> > + ds_cstr(&ip_ds), op->json_key);
> > +ovn_lflow_add_with_hint__(lflows, op->od, S_ROUTER_IN_IP_INPUT,
> > +100, ds_cstr(match), ds_cstr(actions), NULL,
> > +copp_meter_get(COPP_ICMP6_ERR, op->od->nbr->copp,
> > + meter_groups),
> > +&op->nbrp->header_);
> > }
> > +ds_destroy(&ip_ds);
> > }
> >
> > }
> > @@ -11930,10 +11935,17 @@ build_lrouter_ipv4_ip_input(struct ovn_port *op,
> > build_lrouter_bfd_flows(lflows, op, meter_groups);
> >
> > /* ICMP time exceeded */
> > +struct ds ip_ds = DS_EMPTY_INITIALIZER;
> > for (int i = 0; i < op->lrp_networks.n_ipv4_addrs; i++) {
> > ds_clear(match);
> > ds_clear(actions);
> > -
> > +ds_clear(&ip_ds);
> > +if (op->od->n_l3dgw_ports && op->od->l3dgw_ports[0] == op) {
> > +ds_put_cstr(&ip_ds, "ip4.dst <-> ip4.src");
> > +} else {
> > +ds_put_format(&ip_ds, "ip4.dst = ip4.src; ip4.src = %s",
> > + op->lrp_networks.ipv4_addrs[i].addr_s);
> > +}
> > ds_put_format(match,
> > "inport == %s && ip4 && "
> > "ip.ttl == {0, 1} && !ip.later_frag",
> > op->json_key);
> > @@ -11942,18 +11954,17 @@ build_lrouter_ipv4_ip_input(struct ovn_port *op,
> > "eth.dst <-> eth.src; "
> > "icmp4.type = 11; /* Time exceeded */ "
> > "icmp4.code = 0; /* TTL exceeded in transit */ "
> > -
Re: [ovs-dev] [PATCH ovn] northd: fix ttl exceeded with FIP
On Tue, Nov 16, 2021 at 4:18 AM Lorenzo Bianconi
wrote:
>
> > On Thu, Nov 11, 2021 at 3:44 PM Mark Michelson wrote:
> > >
> > > Hi Lorenzo, the patch looks good to me.
> > >
> > > Acked-by: Mark Michelson
> > >
> > > On 11/10/21 17:35, Lorenzo Bianconi wrote:
> > > > Properly manage ttl exceeded ICMP error messages when traffic is
> > > > directed to a FIP. The issue can be verified running traceroute from an
> > > > external device to a FIP:
> > > > $traceroute -I -z 1 -n
> > > >
> > > > Fix ttl exceeded priority respect to ping responder.
> > > >
> > > > Related bz: https://bugzilla.redhat.com/show_bug.cgi?id=2006349
> > > >
> > > > Signed-off-by: Lorenzo Bianconi
> > > > ---
> > > > northd/northd.c | 59 -
> > > > northd/ovn-northd.8.xml | 2 +-
> > > > tests/ovn.at| 10 +++
> > > > 3 files changed, 41 insertions(+), 30 deletions(-)
> > > >
> > > > diff --git a/northd/northd.c b/northd/northd.c
> > > > index 1e8a3457c..ce962cdc4 100644
> > > > --- a/northd/northd.c
> > > > +++ b/northd/northd.c
> > > > @@ -11798,6 +11798,7 @@ build_ipv6_input_flows_for_lrouter_port(
> > > > }
> > > >
> > > > /* ICMPv6 time exceeded */
> > > > +struct ds ip_ds = DS_EMPTY_INITIALIZER;
> > > > for (int i = 0; i < op->lrp_networks.n_ipv6_addrs; i++) {
> > > > /* skip link-local address */
> > > > if (in6_is_lla(&op->lrp_networks.ipv6_addrs[i].network)) {
> > > > @@ -11806,7 +11807,13 @@ build_ipv6_input_flows_for_lrouter_port(
> > > >
> > > > ds_clear(match);
> > > > ds_clear(actions);
> > > > -
> > > > +ds_clear(&ip_ds);
> > > > +if (op->od->n_l3dgw_ports && op->od->l3dgw_ports[0] == op)
> > > > {
> > > > +ds_put_cstr(&ip_ds, "ip6.dst <-> ip6.src");
> > > > +} else {
> > > > +ds_put_format(&ip_ds, "ip6.dst = ip6.src; ip6.src =
> > > > %s",
> > > > + op->lrp_networks.ipv6_addrs[i].addr_s);
> > > > +}
> > > > ds_put_format(match,
> > > > "inport == %s && ip6 && "
> > > > "ip6.src == %s/%d && "
> > > > @@ -11817,20 +11824,18 @@ build_ipv6_input_flows_for_lrouter_port(
> > > > ds_put_format(actions,
> > > > "icmp6 {"
> > > > "eth.dst <-> eth.src; "
> > > > - "ip6.dst = ip6.src; "
> > > > - "ip6.src = %s; "
> > > > - "ip.ttl = 255; "
> > > > + "%s ; ip.ttl = 254; "
> >
> > Hi Lorenzo,
> >
> > Can you please explain why the ttl is changed to 254 ?
>
> Hi Numan,
>
> it is to be consistent with the previous behavior since now we do not hit
> table
> table=10(lr_in_ip_routing) and we just send the packet to the egress pipeline.
>
> >
> >
> > > > "icmp6.type = 3; /* Time exceeded */ "
> > > > "icmp6.code = 0; /* TTL exceeded in transit
> > > > */ "
> > > > - "next; };",
> > > > - op->lrp_networks.ipv6_addrs[i].addr_s);
> > > > -ovn_lflow_add_with_hint__(lflows, op->od,
> > > > S_ROUTER_IN_IP_INPUT, 40,
> > > > - ds_cstr(match),
> > > > ds_cstr(actions), NULL,
> > > > - copp_meter_get(COPP_ICMP6_ERR,
> > > > - op->od->nbr->copp,
> > > > - meter_groups),
> > > > - &op->nbrp->header_);
> > > > + "outport = %s; flags.loopback = 1; output;
> > > > };",
> > > > + ds_cstr(&ip_ds), op->json_key);
> > > > +ovn_lflow_add_with_hint__(lflows, op->od,
> > > > S_ROUTER_IN_IP_INPUT,
> > > > +100, ds_cstr(match), ds_cstr(actions), NULL,
> > > > +copp_meter_get(COPP_ICMP6_ERR, op->od->nbr->copp,
> > > > + meter_groups),
> > > > +&op->nbrp->header_);
> > > > }
> > > > +ds_destroy(&ip_ds);
> > > > }
> > > >
> > > > }
> > > > @@ -11930,10 +11935,17 @@ build_lrouter_ipv4_ip_input(struct ovn_port
> > > > *op,
> > > > build_lrouter_bfd_flows(lflows, op, meter_groups);
> > > >
> > > > /* ICMP time exceeded */
> > > > +struct ds ip_ds = DS_EMPTY_INITIALIZER;
> > > > for (int i = 0; i < op->lrp_networks.n_ipv4_addrs; i++) {
> > > > ds_clear(match);
> > > > ds_clear(actions);
> > > > -
> > > > +ds_clear(&ip_ds);
> > > > +if (op->od->n_l3dgw_ports && op->od->l3dgw_ports[0] == op)
> > > > {
> > > > +ds_put_cstr(&ip_ds, "ip4.dst <-> ip
Re: [ovs-dev] [PATCH ovn v8 1/5] ic: maintain route origin - connected/static
On Sat, Nov 13, 2021 at 4:44 AM Vladislav Odintsov wrote:
>
> This commits adds ability to save route's origin while IC learning.
> Directly connected routes are saved in IC SB DB with "connected"
> origin column value.
> Static routes have "static" value in origin column.
>
> This logic would be used in next patch to compute priority
> for lr_in_ip_routing stage lflows.
>
> Signed-off-by: Vladislav Odintsov
Hi Vladislav,
The patch LGTM.
I think you missed documenting the option "origin" for the NB
Logical_Router_Static_Route
option. Was this intentional? From what I understand, ovn-ic will
set this option.
So for a setup where ovn-ic is not used, can a user/CMS configure this option ?
I think it would be good to document this in ovn-nb.xml.
With the documentation added:
Acked-by: Numan Siddique
Numan
> ---
> ic/ovn-ic.c | 34 +++
> lib/ovn-util.h | 3 +++
> ovn-ic-sb.ovsschema | 7 --
> ovn-ic-sb.xml | 10
> tests/ovn-ic.at | 57 +
> 5 files changed, 99 insertions(+), 12 deletions(-)
>
> diff --git a/ic/ovn-ic.c b/ic/ovn-ic.c
> index 303e93a4f..70abae108 100644
> --- a/ic/ovn-ic.c
> +++ b/ic/ovn-ic.c
> @@ -854,6 +854,7 @@ struct ic_route_info {
> struct in6_addr prefix;
> unsigned int plen;
> struct in6_addr nexthop;
> +const char *origin;
>
> /* Either nb_route or nb_lrp is set and the other one must be NULL.
> * - For a route that is learned from IC-SB, or a static route that is
> @@ -867,22 +868,25 @@ struct ic_route_info {
>
> static uint32_t
> ic_route_hash(const struct in6_addr *prefix, unsigned int plen,
> - const struct in6_addr *nexthop)
> + const struct in6_addr *nexthop, const char *origin)
> {
> uint32_t basis = hash_bytes(prefix, sizeof *prefix, (uint32_t)plen);
> +basis = hash_string(origin, basis);
> return hash_bytes(nexthop, sizeof *nexthop, basis);
> }
>
> static struct ic_route_info *
> ic_route_find(struct hmap *routes, const struct in6_addr *prefix,
> - unsigned int plen, const struct in6_addr *nexthop)
> + unsigned int plen, const struct in6_addr *nexthop,
> + const char *origin)
> {
> struct ic_route_info *r;
> -uint32_t hash = ic_route_hash(prefix, plen, nexthop);
> +uint32_t hash = ic_route_hash(prefix, plen, nexthop, origin);
> HMAP_FOR_EACH_WITH_HASH (r, node, hash, routes) {
> if (ipv6_addr_equals(&r->prefix, prefix) &&
> r->plen == plen &&
> -ipv6_addr_equals(&r->nexthop, nexthop)) {
> +ipv6_addr_equals(&r->nexthop, nexthop) &&
> +!strcmp(r->origin, origin)) {
> return r;
> }
> }
> @@ -926,13 +930,15 @@ add_to_routes_learned(struct hmap *routes_learned,
> &prefix, &plen, &nexthop)) {
> return false;
> }
> +const char *origin = smap_get_def(&nb_route->options, "origin", "");
> struct ic_route_info *ic_route = xzalloc(sizeof *ic_route);
> ic_route->prefix = prefix;
> ic_route->plen = plen;
> ic_route->nexthop = nexthop;
> ic_route->nb_route = nb_route;
> +ic_route->origin = origin;
> hmap_insert(routes_learned, &ic_route->node,
> -ic_route_hash(&prefix, plen, &nexthop));
> +ic_route_hash(&prefix, plen, &nexthop, origin));
> return true;
> }
>
> @@ -1093,8 +1099,9 @@ add_to_routes_ad(struct hmap *routes_ad,
> ic_route->plen = plen;
> ic_route->nexthop = nexthop;
> ic_route->nb_route = nb_route;
> +ic_route->origin = ROUTE_ORIGIN_STATIC;
> hmap_insert(routes_ad, &ic_route->node,
> -ic_route_hash(&prefix, plen, &nexthop));
> +ic_route_hash(&prefix, plen, &nexthop, ROUTE_ORIGIN_STATIC));
> }
>
> static void
> @@ -1143,8 +1150,10 @@ add_network_to_routes_ad(struct hmap *routes_ad, const
> char *network,
> ic_route->plen = plen;
> ic_route->nexthop = nexthop;
> ic_route->nb_lrp = nb_lrp;
> +ic_route->origin = ROUTE_ORIGIN_CONNECTED;
> hmap_insert(routes_ad, &ic_route->node,
> -ic_route_hash(&prefix, plen, &nexthop));
> +ic_route_hash(&prefix, plen, &nexthop,
> + ROUTE_ORIGIN_CONNECTED));
> }
>
> static bool
> @@ -1206,7 +1215,8 @@ sync_learned_route(struct ic_conte
Re: [ovs-dev] [PATCH ovn v8 2/5] northd: make connected routes have higher priority than static
On Sat, Nov 13, 2021 at 4:44 AM Vladislav Odintsov wrote:
>
> With this patch routes to connected networks have higher
> priority than static routes with same ip_prefix.
>
> This brings commonly-used behaviour for routes lookup order:
> 1: longest prefix match
> 2: metric
>
> The metric has next lookup order:
> 1: connected routes
> 2: static routes
>
> Earlier static and connected routes with same ip_prefix had
> the same priority, so it was impossible to predict which one
> is used for routing decision.
>
> Each route's prefix length has its own 'slot' in lflow prios.
> Now prefix length space is calculated using next information:
> to calculate route's priority prefixlen multiplied by 3
> + route origin offset (0 - source-based route; 1 - directly-
> connected route; 2 - static route).
>
> Also, enlarge prio for generic records in lr_in_ip_routing stage
> by 1.
>
> Signed-off-by: Vladislav Odintsov
Hi Vladislav,
Thanks for the patch. Overall it looks good to me. I've one comment.
Looks like the documentation updated in ovn-northd.8.xml is not accurate.
This patch modifies the flows in the lr_in_ip_routing stage but this
patch doesn't update the documentation.
Also the patch updates the documentation for the flow in lr_in_defrag
stage, which seems not correct.
Can you please update the documentation accurately ?
Numan
> ---
> northd/northd.c | 50 -
> northd/ovn-northd.8.xml | 12 +-
> tests/ovn-northd.at | 8 +++
> 3 files changed, 45 insertions(+), 25 deletions(-)
>
> diff --git a/northd/northd.c b/northd/northd.c
> index 1e8a3457c..0d513f039 100644
> --- a/northd/northd.c
> +++ b/northd/northd.c
> @@ -305,6 +305,15 @@ enum ovn_stage {
> *
> */
>
> +/*
> + * Route offsets implement logic to prioritize traffic for routes with
> + * same ip_prefix values:
> + * - connected route overrides static one;
> + * - static route overrides connected route. */
> +#define ROUTE_PRIO_OFFSET_MULTIPLIER 3
> +#define ROUTE_PRIO_OFFSET_STATIC 1
> +#define ROUTE_PRIO_OFFSET_CONNECTED 2
> +
> /* Returns an "enum ovn_stage" built from the arguments. */
> static enum ovn_stage
> ovn_stage_build(enum ovn_datapath_type dp_type, enum ovn_pipeline pipeline,
> @@ -8782,6 +8791,7 @@ struct ecmp_groups_node {
> struct in6_addr prefix;
> unsigned int plen;
> bool is_src_route;
> +const char *origin;
> uint16_t route_count;
> struct ovs_list route_list; /* Contains ecmp_route_list_node */
> };
> @@ -8819,6 +8829,7 @@ ecmp_groups_add(struct hmap *ecmp_groups,
> eg->prefix = route->prefix;
> eg->plen = route->plen;
> eg->is_src_route = route->is_src_route;
> +eg->origin = smap_get_def(&route->route->options, "origin", "");
> ovs_list_init(&eg->route_list);
> ecmp_groups_add_route(eg, route);
>
> @@ -8919,19 +8930,20 @@ build_route_prefix_s(const struct in6_addr *prefix,
> unsigned int plen)
> static void
> build_route_match(const struct ovn_port *op_inport, const char *network_s,
>int plen, bool is_src_route, bool is_ipv4, struct ds
> *match,
> - uint16_t *priority)
> + uint16_t *priority, int ofs)
> {
> const char *dir;
> /* The priority here is calculated to implement longest-prefix-match
> * routing. */
> if (is_src_route) {
> dir = "src";
> -*priority = plen * 2;
> +ofs = 0;
> } else {
> dir = "dst";
> -*priority = (plen * 2) + 1;
> }
>
> +*priority = (plen * ROUTE_PRIO_OFFSET_MULTIPLIER) + ofs;
> +
> if (op_inport) {
> ds_put_format(match, "inport == %s && ", op_inport->json_key);
> }
> @@ -9073,7 +9085,7 @@ add_ecmp_symmetric_reply_flows(struct hmap *lflows,
>out_port->lrp_networks.ea_s,
>IN6_IS_ADDR_V4MAPPED(&route->prefix) ? "" : "xx",
>port_ip, out_port->json_key);
> -ovn_lflow_add_with_hint(lflows, od, S_ROUTER_IN_IP_ROUTING, 300,
> +ovn_lflow_add_with_hint(lflows, od, S_ROUTER_IN_IP_ROUTING, 10300,
> ds_cstr(&match), ds_cstr(&actions),
> &st_route->header_);
>
> @@ -9103,8 +9115,10 @@ build_ecmp_route_flow(struct hmap *lflows, struct
> ovn_datapath *od,
> struct ds route_match = DS_EMPTY_INITIALIZER;
>
> char *prefix_s = build_route_prefix_s(&eg->prefix, eg->plen);
> +int ofs = !strcmp(eg->origin, ROUTE_ORIGIN_CONNECTED) ?
> +ROUTE_PRIO_OFFSET_CONNECTED: ROUTE_PRIO_OFFSET_STATIC;
> build_route_match(NULL, prefix_s, eg->plen, eg->is_src_route, is_ipv4,
> - &route_match, &priority);
> + &route_match, &priority, ofs);
> free(prefix_s);
>
> struct ds actions = DS_EMPTY_INITIALIZER;
> @@ -9180,7 +9194,7 @@ add_route(struct hmap *lflows, struct ovn_datapath *od,
>const struct ovn_port *op, const char *lrp_addr_s,
>
Re: [ovs-dev] [PATCH ovn v3 1/4] lflow-cache.h: Fix comment about lflow-cache.
On Thu, Nov 11, 2021 at 5:39 PM Han Zhou wrote:
>
> In commit fadbc04f38db it changed the lflow-cache behavior but forgot to
> update the commment.
>
> Fixes: fadbc04f38db ("ovn-controller: Fix incremental processing for logical
> port references.")
> Signed-off-by: Han Zhou
Acked-by: Numan Siddique
Numan
> ---
> controller/lflow-cache.h | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/controller/lflow-cache.h b/controller/lflow-cache.h
> index 6166fa7c5..553e05f8e 100644
> --- a/controller/lflow-cache.h
> +++ b/controller/lflow-cache.h
> @@ -32,8 +32,9 @@ struct lflow_cache;
> * - Caches
> * (1) Conjunction ID offset if the logical flow has port group/address
> * set references.
> - * (2) expr tree if the logical flow has is_chassis_resident() match.
> - * (3) expr matches if (1) and (2) are false.
> + * (2) expr tree if the logical flow doesn't have port group/address set
> + * references but has other references (such as lport).
> + * (3) expr matches if the logical flow doesn't have any references.
> */
> enum lflow_cache_type {
> LCACHE_T_CONJ_ID, /* Only conjunction id offset is cached. */
> --
> 2.30.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 v8 2/5] northd: make connected routes have higher priority than static
On Wed, Nov 17, 2021 at 9:24 AM Vladislav Odintsov wrote:
>
> Two additions:
>
> 1. Regarding documentation for flow in lr_in_defrag section:
>
> It seems to me that documentation for it is written in a wrong section
> (lr_in_defrag).
> Since the flow is installed in lr_in_ip_routing, it should be documented
> there.
> I’ll move it if you don’t mind.
Sure. Thanks. I'd suggest having a separate patch for fixing the
documentation.
>
>
> 2. Documentation for other flow changes was added, but I’ve committed it to a
> wrong patch (#3).
> I’ll move documentation update between patches.
Ack.
Thanks
Numan
>
> Regards,
> Vladislav Odintsov
>
> > On 17 Nov 2021, at 13:51, Vladislav Odintsov wrote:
> >
> > Hi Numan,
> >
> > Thanks for the review.
> > Sure I will fix this. Should I wait for more comments or that’s all and I
> > can send v9?
> >
> > Regards,
> > Vladislav Odintsov
> >
> >> On 17 Nov 2021, at 05:17, Numan Siddique wrote:
> >>
> >> On Sat, Nov 13, 2021 at 4:44 AM Vladislav Odintsov >> <mailto:odiv...@gmail.com>> wrote:
> >>>
> >>> With this patch routes to connected networks have higher
> >>> priority than static routes with same ip_prefix.
> >>>
> >>> This brings commonly-used behaviour for routes lookup order:
> >>> 1: longest prefix match
> >>> 2: metric
> >>>
> >>> The metric has next lookup order:
> >>> 1: connected routes
> >>> 2: static routes
> >>>
> >>> Earlier static and connected routes with same ip_prefix had
> >>> the same priority, so it was impossible to predict which one
> >>> is used for routing decision.
> >>>
> >>> Each route's prefix length has its own 'slot' in lflow prios.
> >>> Now prefix length space is calculated using next information:
> >>> to calculate route's priority prefixlen multiplied by 3
> >>> + route origin offset (0 - source-based route; 1 - directly-
> >>> connected route; 2 - static route).
> >>>
> >>> Also, enlarge prio for generic records in lr_in_ip_routing stage
> >>> by 1.
> >>>
> >>> Signed-off-by: Vladislav Odintsov
> >>
> >> Hi Vladislav,
> >>
> >> Thanks for the patch. Overall it looks good to me. I've one comment.
> >> Looks like the documentation updated in ovn-northd.8.xml is not accurate.
> >>
> >> This patch modifies the flows in the lr_in_ip_routing stage but this
> >> patch doesn't update the documentation.
> >> Also the patch updates the documentation for the flow in lr_in_defrag
> >> stage, which seems not correct.
> >>
> >> Can you please update the documentation accurately ?
> >>
> >> Numan
> >>
> >>> ---
> >>> northd/northd.c | 50 -
> >>> northd/ovn-northd.8.xml | 12 +-
> >>> tests/ovn-northd.at | 8 +++
> >>> 3 files changed, 45 insertions(+), 25 deletions(-)
> >>>
> >>> diff --git a/northd/northd.c b/northd/northd.c
> >>> index 1e8a3457c..0d513f039 100644
> >>> --- a/northd/northd.c
> >>> +++ b/northd/northd.c
> >>> @@ -305,6 +305,15 @@ enum ovn_stage {
> >>> *
> >>> */
> >>>
> >>> +/*
> >>> + * Route offsets implement logic to prioritize traffic for routes with
> >>> + * same ip_prefix values:
> >>> + * - connected route overrides static one;
> >>> + * - static route overrides connected route. */
> >>> +#define ROUTE_PRIO_OFFSET_MULTIPLIER 3
> >>> +#define ROUTE_PRIO_OFFSET_STATIC 1
> >>> +#define ROUTE_PRIO_OFFSET_CONNECTED 2
> >>> +
> >>> /* Returns an "enum ovn_stage" built from the arguments. */
> >>> static enum ovn_stage
> >>> ovn_stage_build(enum ovn_datapath_type dp_type, enum ovn_pipeline
> >>> pipeline,
> >>> @@ -8782,6 +8791,7 @@ struct ecmp_groups_node {
> >>>struct in6_addr prefix;
> >>>unsigned int plen;
> >>>bool is_src_route;
> >>> +const char *origin;
> >>>uint16_t route_count;
> >>>struct ovs_list route_list; /* Contains ecmp_route_list_node */
> >>> };
> >>> @@ -8819,6 +8829,7 @@ ecmp_groups_add(struct hmap *ecmp_groups,
> >>&g
Re: [ovs-dev] [PATCH ovn v8 2/5] northd: make connected routes have higher priority than static
On Wed, Nov 17, 2021 at 3:38 PM Vladislav Odintsov wrote: > > I’ve submitted a patch [1] with my findings. > Also, if no comments for other my patches from this patch series, I can > submit a new version. > Should I? No comments from my side. Perhaps you can submit another version. Numan > > 1: > https://patchwork.ozlabs.org/project/ovn/patch/2027203545.46142-1-odiv...@gmail.com/ > > Regards, > Vladislav Odintsov > > > On 17 Nov 2021, at 20:57, Numan Siddique wrote: > > > > On Wed, Nov 17, 2021 at 9:24 AM Vladislav Odintsov > <mailto:odiv...@gmail.com>> wrote: > >> > >> Two additions: > >> > >> 1. Regarding documentation for flow in lr_in_defrag section: > >> > >> It seems to me that documentation for it is written in a wrong section > >> (lr_in_defrag). > >> Since the flow is installed in lr_in_ip_routing, it should be documented > >> there. > >> I’ll move it if you don’t mind. > > > > Sure. Thanks. I'd suggest having a separate patch for fixing the > > documentation. > >> > >> > >> 2. Documentation for other flow changes was added, but I’ve committed it > >> to a wrong patch (#3). > >> I’ll move documentation update between patches. > > > > Ack. > > > > Thanks > > Numan > > > >> > >> Regards, > >> Vladislav Odintsov > >> > >>> On 17 Nov 2021, at 13:51, Vladislav Odintsov wrote: > >>> > >>> Hi Numan, > >>> > >>> Thanks for the review. > >>> Sure I will fix this. Should I wait for more comments or that’s all and I > >>> can send v9? > >>> > >>> Regards, > >>> Vladislav Odintsov > >>> > >>>> On 17 Nov 2021, at 05:17, Numan Siddique wrote: > >>>> > >>>> On Sat, Nov 13, 2021 at 4:44 AM Vladislav Odintsov >>>> <mailto:odiv...@gmail.com>> wrote: > >>>>> > >>>>> With this patch routes to connected networks have higher > >>>>> priority than static routes with same ip_prefix. > >>>>> > >>>>> This brings commonly-used behaviour for routes lookup order: > >>>>> 1: longest prefix match > >>>>> 2: metric > >>>>> > >>>>> The metric has next lookup order: > >>>>> 1: connected routes > >>>>> 2: static routes > >>>>> > >>>>> Earlier static and connected routes with same ip_prefix had > >>>>> the same priority, so it was impossible to predict which one > >>>>> is used for routing decision. > >>>>> > >>>>> Each route's prefix length has its own 'slot' in lflow prios. > >>>>> Now prefix length space is calculated using next information: > >>>>> to calculate route's priority prefixlen multiplied by 3 > >>>>> + route origin offset (0 - source-based route; 1 - directly- > >>>>> connected route; 2 - static route). > >>>>> > >>>>> Also, enlarge prio for generic records in lr_in_ip_routing stage > >>>>> by 1. > >>>>> > >>>>> Signed-off-by: Vladislav Odintsov > >>>> > >>>> Hi Vladislav, > >>>> > >>>> Thanks for the patch. Overall it looks good to me. I've one comment. > >>>> Looks like the documentation updated in ovn-northd.8.xml is not accurate. > >>>> > >>>> This patch modifies the flows in the lr_in_ip_routing stage but this > >>>> patch doesn't update the documentation. > >>>> Also the patch updates the documentation for the flow in lr_in_defrag > >>>> stage, which seems not correct. > >>>> > >>>> Can you please update the documentation accurately ? > >>>> > >>>> Numan > >>>> > >>>>> --- > >>>>> northd/northd.c | 50 - > >>>>> northd/ovn-northd.8.xml | 12 +- > >>>>> tests/ovn-northd.at | 8 +++ > >>>>> 3 files changed, 45 insertions(+), 25 deletions(-) > >>>>> > >>>>> diff --git a/northd/northd.c b/northd/northd.c > >>>>> index 1e8a3457c..0d513f039 100644 > >>>>> --- a/northd/northd.
Re: [ovs-dev] [PATCH ovn] northd: fix FIP traffic with distributed gw router port on the same hv
On Mon, Nov 15, 2021 at 11:36 AM Lorenzo Bianconi
wrote:
>
> If the hv has FIP assigned, traffic has to be sent out using the FIP
> even if a distributed gw router port is scheduled on the local hv.
> In this particular use-case without the proposed patch, the traffic
> is sent out with FIP mac but using distributed gw router port IP.
>
> Related bz: https://bugzilla.redhat.com/show_bug.cgi?id=1960096
>
> Signed-off-by: Lorenzo Bianconi
Thanks.
I applied this patch to the main branch and branch-21.09.
Numan
> ---
> northd/northd.c | 4
> tests/system-ovn.at | 16
> 2 files changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/northd/northd.c b/northd/northd.c
> index 1e8a3457c..d10470a4e 100644
> --- a/northd/northd.c
> +++ b/northd/northd.c
> @@ -12427,6 +12427,10 @@ build_lrouter_out_snat_flow(struct hmap *lflows,
> struct ovn_datapath *od,
> priority += 128;
> ds_put_format(match, " && is_chassis_resident(%s)",
>od->l3dgw_ports[0]->cr_port->json_key);
> +} else if (distributed) {
> +priority += 128;
> +ds_put_format(match, " && is_chassis_resident(\"%s\")",
> + nat->logical_port);
> }
> ds_clear(actions);
>
> diff --git a/tests/system-ovn.at b/tests/system-ovn.at
> index 77c811946..c9f5771c9 100644
> --- a/tests/system-ovn.at
> +++ b/tests/system-ovn.at
> @@ -3547,9 +3547,9 @@ NS_CHECK_EXEC([foo2], [ping -q -c 3 -i 0.3 -w 2
> 172.16.1.2 | FORMAT_PING], \
> ])
>
> # We verify that SNAT indeed happened via 'dump-conntrack' command.
> -AT_CHECK([ovs-appctl dpctl/dump-conntrack | FORMAT_CT(172.16.1.1) | \
> +AT_CHECK([ovs-appctl dpctl/dump-conntrack | FORMAT_CT(172.16.1.4) | \
> sed -e 's/zone=[[0-9]]*/zone=/'], [0], [dnl
> -icmp,orig=(src=192.168.1.3,dst=172.16.1.2,id=,type=8,code=0),reply=(src=172.16.1.2,dst=172.16.1.1,id=,type=0,code=0),zone=
> +icmp,orig=(src=192.168.1.3,dst=172.16.1.2,id=,type=8,code=0),reply=(src=172.16.1.2,dst=172.16.1.4,id=,type=0,code=0),zone=
> ])
>
> AT_CHECK([ovs-appctl dpctl/flush-conntrack])
> @@ -3719,9 +3719,9 @@ NS_CHECK_EXEC([foo2], [ping6 -q -c 3 -i 0.3 -w 2
> fd20::2 | FORMAT_PING], \
> ])
>
> # We verify that SNAT indeed happened via 'dump-conntrack' command.
> -AT_CHECK([ovs-appctl dpctl/dump-conntrack | FORMAT_CT(fd20::1) | \
> +AT_CHECK([ovs-appctl dpctl/dump-conntrack | FORMAT_CT(fd11::3) | \
> sed -e 's/zone=[[0-9]]*/zone=/'], [0], [dnl
> -icmpv6,orig=(src=fd11::3,dst=fd20::2,id=,type=128,code=0),reply=(src=fd20::2,dst=fd20::1,id=,type=129,code=0),zone=
> +icmpv6,orig=(src=fd11::3,dst=fd20::2,id=,type=128,code=0),reply=(src=fd20::2,dst=fd11::3,id=,type=129,code=0),zone=
> ])
>
> AT_CHECK([ovs-appctl dpctl/flush-conntrack])
> @@ -3907,8 +3907,8 @@ NS_CHECK_EXEC([foo1], [ping -q -c 3 -i 0.3 -w 2
> 172.16.1.4 | FORMAT_PING], \
> # Then DNAT of 'bar1' address happens (listed first below).
> AT_CHECK([ovs-appctl dpctl/dump-conntrack | FORMAT_CT(172.16.1.4) | \
> sed -e 's/zone=[[0-9]]*/zone=/'], [0], [dnl
> -icmp,orig=(src=172.16.1.1,dst=172.16.1.4,id=,type=8,code=0),reply=(src=192.168.2.2,dst=172.16.1.1,id=,type=0,code=0),zone=
> -icmp,orig=(src=192.168.1.2,dst=172.16.1.4,id=,type=8,code=0),reply=(src=172.16.1.4,dst=172.16.1.1,id=,type=0,code=0),zone=
> +icmp,orig=(src=172.16.1.3,dst=172.16.1.4,id=,type=8,code=0),reply=(src=192.168.2.2,dst=172.16.1.3,id=,type=0,code=0),zone=
> +icmp,orig=(src=192.168.1.2,dst=172.16.1.4,id=,type=8,code=0),reply=(src=172.16.1.4,dst=172.16.1.3,id=,type=0,code=0),zone=
>
> icmp,orig=(src=192.168.1.2,dst=172.16.1.4,id=,type=8,code=0),reply=(src=172.16.1.4,dst=192.168.1.2,id=,type=0,code=0),zone=
> ])
>
> @@ -4102,8 +4102,8 @@ NS_CHECK_EXEC([foo1], [ping -q -c 3 -i 0.3 -w 2 fd20::4
> | FORMAT_PING], \
> AT_CHECK([ovs-appctl dpctl/dump-conntrack | FORMAT_CT(fd20::4) | \
> sed -e 's/zone=[[0-9]]*/zone=/'], [0], [dnl
>
> icmpv6,orig=(src=fd11::2,dst=fd20::4,id=,type=128,code=0),reply=(src=fd20::4,dst=fd11::2,id=,type=129,code=0),zone=
> -icmpv6,orig=(src=fd11::2,dst=fd20::4,id=,type=128,code=0),reply=(src=fd20::4,dst=fd20::1,id=,type=129,code=0),zone=
> -icmpv6,orig=(src=fd20::1,dst=fd20::4,id=,type=128,code=0),reply=(src=fd12::2,dst=fd20::1,id=,type=129,code=0),zone=
> +icmpv6,orig=(src=fd11::2,dst=fd20::4,id=,type=128,code=0),reply=(src=fd20::4,dst=fd20::3,id=,type=129,code=0),zone=
> +icmpv6,orig=(src=fd20::3,dst=fd20::4,id=,type=128,code=0),reply=(src=fd12::2,dst=fd20::3,id=,type=129,code=0),zone=
> ])
>
> AT_CHECK([ovs-appctl dpctl/flush-conntrack])
> --
> 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 v5 ovn] controller: add memory accounting for local_datapath
On Fri, Nov 5, 2021 at 9:40 AM Dumitru Ceara wrote:
>
> On 10/21/21 11:47 AM, Lorenzo Bianconi wrote:
> > Similar to if-status-mgr, track memory allocated for local_datapath.
> >
> > Signed-off-by: Lorenzo Bianconi
> > ---
>
> Looks good to me, thanks!
>
> Acked-by: Dumitru Ceara
Thanks Lorenzo and Dumitru.
I applied this patch to the main branch. Before applying I did the
below changes which just reorganizes the code.
--
diff --git a/controller/local_data.c b/controller/local_data.c
index 251ed294f..86050f335 100644
--- a/controller/local_data.c
+++ b/controller/local_data.c
@@ -41,6 +41,9 @@ static void add_local_datapath__(
int depth, const struct sbrec_datapath_binding *,
const struct sbrec_chassis *, struct hmap *local_datapaths,
struct hmap *tracked_datapaths);
+static void local_datapath_peer_port_add(
+struct local_datapath *, const struct sbrec_port_binding *local,
+const struct sbrec_port_binding *remote);
static struct tracked_datapath *tracked_datapath_create(
const struct sbrec_datapath_binding *dp,
@@ -161,26 +164,6 @@ add_local_datapath(struct ovsdb_idl_index
*sbrec_datapath_binding_by_key,
tracked_datapaths);
}
-static void
-local_datapath_peer_port_add(struct local_datapath *ld,
- const struct sbrec_port_binding *local,
- const struct sbrec_port_binding *remote)
-{
-ld->n_peer_ports++;
-if (ld->n_peer_ports > ld->n_allocated_peer_ports) {
-size_t old_n_ports = ld->n_allocated_peer_ports;
-ld->peer_ports =
-x2nrealloc(ld->peer_ports,
- &ld->n_allocated_peer_ports,
- sizeof *ld->peer_ports);
-local_datapath_usage +=
-(ld->n_allocated_peer_ports - old_n_ports) *
-sizeof *ld->peer_ports;
-}
-ld->peer_ports[ld->n_peer_ports - 1].local = local;
-ld->peer_ports[ld->n_peer_ports - 1].remote = remote;
-}
-
void
add_local_datapath_peer_port(
const struct sbrec_port_binding *pb,
@@ -287,6 +270,13 @@ remove_local_datapath_external_port(struct
local_datapath *ld,
}
}
+void
+local_datapath_memory_usage(struct simap *usage)
+{
+simap_increase(usage, "local_datapath_usage-KB",
+ ROUND_UP(local_datapath_usage, 1024) / 1024);
+}
+
/* track datapath functions. */
struct tracked_datapath *
tracked_datapath_add(const struct sbrec_datapath_binding *dp,
@@ -595,9 +585,22 @@ tracked_datapath_create(const struct
sbrec_datapath_binding *dp,
return t_dp;
}
-void
-local_datapath_memory_usage(struct simap *usage)
+static void
+local_datapath_peer_port_add(struct local_datapath *ld,
+ const struct sbrec_port_binding *local,
+ const struct sbrec_port_binding *remote)
{
-simap_increase(usage, "local_datapath_usage-KB",
- ROUND_UP(local_datapath_usage, 1024) / 1024);
+ld->n_peer_ports++;
+if (ld->n_peer_ports > ld->n_allocated_peer_ports) {
+size_t old_n_ports = ld->n_allocated_peer_ports;
+ld->peer_ports =
+x2nrealloc(ld->peer_ports,
+ &ld->n_allocated_peer_ports,
+ sizeof *ld->peer_ports);
+local_datapath_usage +=
+(ld->n_allocated_peer_ports - old_n_ports) *
+sizeof *ld->peer_ports;
+}
+ld->peer_ports[ld->n_peer_ports - 1].local = local;
+ld->peer_ports[ld->n_peer_ports - 1].remote = remote;
}
diff --git a/controller/local_data.h b/controller/local_data.h
index 6e7253738..287f95af0 100644
--- a/controller/local_data.h
+++ b/controller/local_data.h
@@ -150,11 +150,9 @@ bool get_chassis_tunnel_ofport(const struct hmap
*chassis_tunnels,
void chassis_tunnels_destroy(struct hmap *chassis_tunnels);
void local_datapath_memory_usage(struct simap *usage);
-void
-add_local_datapath_external_port(struct local_datapath *ld,
- char *logical_port, const void *data);
-void
-remove_local_datapath_external_port(struct local_datapath *ld,
-char *logical_port);
+void add_local_datapath_external_port(struct local_datapath *ld,
+ char *logical_port, const void *data);
+void remove_local_datapath_external_port(struct local_datapath *ld,
+ char *logical_port);
--
Thanks
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 v2] ofproto-dpif-xlate: Fix check_pkt_larger incomplete translation.
On Wed, Nov 17, 2021, 7:06 PM Ilya Maximets wrote:
> On 11/9/21 15:48, Aaron Conole wrote:
> > num...@ovn.org writes:
> >
> >> From: Numan Siddique
> >>
> >> xlate_check_pkt_larger() sets ctx->exit to 'true' at the end
> >> causing the translation to stop. This results in incomplete
> >> datapath rules.
> >>
> >> For example, for the below OF rules configured on a bridge,
> >>
> >> table=0,in_port=1
> >>
> actions=load:0x1->NXM_NX_REG1[[]],resubmit(,1),load:0x2->NXM_NX_REG1[[]],resubmit(,1),load:0x3->NXM_NX_REG1[[]],resubmit(,1)
> >> table=1,in_port=1,reg1=0x1
> actions=check_pkt_larger(200)->NXM_NX_REG0[[0]],resubmit(,4)
> >> table=1,in_port=1,reg1=0x2 actions=output:2
> >> table=1,in_port=1,reg1=0x3 actions=output:4
> >> table=4,in_port=1 actions=output:3
> >>
> >> the datapath flow should be
> >>
> >> check_pkt_len(size=200,gt(3),le(3)),2,4
> >>
> >> But right now it is:
> >>
> >> check_pkt_len(size=200,gt(3),le(3))
> >>
> >> Actions after the first resubmit(,1) in the first flow in table 0
> >> are never applied. This patch fixes this issue.
> >>
> >> Fixes: 5b34f8fc3b38 ("Add a new OVS action check_pkt_larger")
> >> Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2018365
> >> Reported-by: Ihar Hrachyshka
> >> Signed-off-by: Numan Siddique
> >> ---
> >
> > LGTM.
> >
> > Acked-by: Aaron Conole
>
> Thanks, Numan and Aaron!
>
> Applied. Backported down to 2.13.
>
Thanks Ilya and Aaron.
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 ovn v8 2/5] northd: make connected routes have higher priority than static
Hi Vladislav, Once v9 is ready, please submit them. I'll take a look. Thanks Numan On Thu, Nov 18, 2021 at 2:58 AM Han Zhou wrote: > > Sounds good to me. > > On Wed, Nov 17, 2021 at 11:53 PM Vladislav Odintsov > wrote: > > > Thanks, Han. > > Please see inline. > > > > Regards, > > Vladislav Odintsov > > > > On 18 Nov 2021, at 10:26, Han Zhou wrote: > > > > On Wed, Nov 17, 2021 at 10:10 PM Vladislav Odintsov > > wrote: > > > > > > Great, thanks. > > > > Hi @Han, > > > > I’d like you to look at the patch series too. Would you have time on it? > > If yes, could you redirect me on terms please. > > > > > > Hi Vladislav, > > > > Thanks for adding me. I am sorry that I don't think I will have enough time > > for a detailed review for this series until Nov 29. Not sure if you can > > wait that long, but I don't think my review is mandatory if Numan is > > reviewing all the patches in detail. > > > > > > It’s okay from my side to wait for Dec 2-3. > > > > I have a quick comment though, regarding the priority offset. It is > > mentioned in the commit message: > > > > Each route's prefix length has its own 'slot' in lflow prios. > > Now prefix length space is calculated using next information: > > to calculate route's priority prefixlen multiplied by 3 > > + route origin offset (0 - source-based route; 1 - directly- > > connected route; 2 - static route). > > > > > > But in the code, 2 is for connected, and 1 is for static: > > > > +#define ROUTE_PRIO_OFFSET_MULTIPLIER 3 > > +#define ROUTE_PRIO_OFFSET_STATIC 1 > > +#define ROUTE_PRIO_OFFSET_CONNECTED 2 > > > > > > I wonder which one is your intent? I'd let the static route have higher > > priority, because otherwise why would the user add the static route at all? > > But this is more of a question than a suggestion. Is there any *standard* > > behavior or similar thing that we can refer from e.g. AWS? > > > > > > It’s a typo in commit message. I’ll fix that in v9. > > > > It is done to support well-known behaviour, where directly-connected > > routes take precedence over static routes for same CIDR. > > > > To support AWS feature, where user can override "subnet" route (think, > > "connected") with a static route, additional work is needed. > > It’s not what I’m currently working on, but I thought about such use case > > and it seems that it can be easily supported by adding ability to add > > Logical_Router_Static_Route with some "override" flag, which ensures this > > static route would be installed with the highest priority. > > > > So, if no objections here or other comments for now I’ll send v9. > > > > Thanks, > > Han > > > > > > Thanks. > > > > Regards, > > Vladislav Odintsov > > > > On 18 Nov 2021, at 00:05, Numan Siddique wrote: > > > > On Wed, Nov 17, 2021 at 3:38 PM Vladislav Odintsov > > > <mailto:odiv...@gmail.com >> wrote: > > > > > > I’ve submitted a patch [1] with my findings. > > Also, if no comments for other my patches from this patch series, I > > > > can submit a new version. > > > > Should I? > > > > > > No comments from my side. Perhaps you can submit another version. > > > > Numan > > > > > > 1: > > > > > > https://patchwork.ozlabs.org/project/ovn/patch/2027203545.46142-1-odiv...@gmail.com/ > > < > > > > https://patchwork.ozlabs.org/project/ovn/patch/2027203545.46142-1-odiv...@gmail.com/ > > > > > > > > Regards, > > Vladislav Odintsov > > > > On 17 Nov 2021, at 20:57, Numan Siddique > > > num...@ovn.org>> wrote: > > > > > > On Wed, Nov 17, 2021 at 9:24 AM Vladislav Odintsov > > > <mailto:odiv...@gmail.com > <mailto:odiv...@gmail.com > > > odiv...@gmail.com>>> wrote: > > > > > > Two additions: > > > > 1. Regarding documentation for flow in lr_in_defrag section: > > > > It seems to me that documentation for it is written in a wrong > > > > section (lr_in_defrag). > > > > Since the flow is installed in lr_in_ip_routing, it should be > > > > documented there. > > > > I’ll move it if you don’t mind. > > > > > > Sure. Thanks. I'd suggest having a separate patch for fixing the > > documenta
Re: [ovs-dev] [PATCH ovn v2 2/2] northd: Use ct_(snat/dnat)_in_czone action for distributed routers.
On Thu, Nov 18, 2021 at 4:49 PM Mark Michelson wrote:
>
> Hi Numan,
>
> I had one question in the code and then one small finding in the
> documentation. See below:
>
> On 11/18/21 13:13, num...@ovn.org wrote:
> > From: Numan Siddique
> >
> > Make of use of these new actions for the distributed routers
> > for NAT. These new actions ensure that both sNAT and dNAT
> > happens in the same zone. This approach solves a couple of
> > problems:
> >
> > - The datapath flows generated for external traffic which requires
> > dNAT (N -> S) or sNAT (S -> N) are completely HWOL'able.
> >
> > - Since there is only one zone, it would avoid multiple recirculations
> > (improving the performance).
> >
> > If the packet needs to be both sNATted and dNATted (for hairpin traffic
> > with source and destination on the same chassis), then sNAT is done
> > in a separate zone. To detect this scenario, this patch adds a few
> > extra logical flows. For each dnat_and_snat entry prior to this patch
> > ovn-northd was generating 9 logical flows and with this patch it now
> > generates 12 logical flows.
> >
> > Similar approach can be taken for gateway routers.
> >
> > Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1984953
> > Signed-off-by: Numan Siddique
> > ---
> >
> > v1 -> v2
> > --
> >* Rebased and resolved conflicts.
> >
> > include/ovn/logical-fields.h | 1 +
> > lib/logical-fields.c | 4 +
> > northd/northd.c | 147 +++--
> > northd/ovn-northd.8.xml | 201 +---
> > tests/ovn-northd.at | 575 +++
> > tests/ovn.at | 2 +-
> > tests/system-ovn.at | 64 ++--
> > 7 files changed, 607 insertions(+), 387 deletions(-)
> >
> > diff --git a/include/ovn/logical-fields.h b/include/ovn/logical-fields.h
> > index c9675f81c..2118f7933 100644
> > --- a/include/ovn/logical-fields.h
> > +++ b/include/ovn/logical-fields.h
> > @@ -70,6 +70,7 @@ enum mff_log_flags_bits {
> > MLF_LOOKUP_FDB_BIT = 8,
> > MLF_SKIP_SNAT_FOR_LB_BIT = 9,
> > MLF_LOCALPORT_BIT = 10,
> > +MLF_USE_SNAT_ZONE = 11,
> > };
> >
> > /* MFF_LOG_FLAGS_REG flag assignments */
> > diff --git a/lib/logical-fields.c b/lib/logical-fields.c
> > index 7b3d431e0..352a48c89 100644
> > --- a/lib/logical-fields.c
> > +++ b/lib/logical-fields.c
> > @@ -125,6 +125,10 @@ ovn_init_symtab(struct shash *symtab)
> >MLF_SKIP_SNAT_FOR_LB_BIT);
> > expr_symtab_add_subfield(symtab, "flags.skip_snat_for_lb", NULL,
> >flags_str);
> > +snprintf(flags_str, sizeof flags_str, "flags[%d]",
> > + MLF_USE_SNAT_ZONE);
> > +expr_symtab_add_subfield(symtab, "flags.use_snat_zone", NULL,
> > + flags_str);
> >
> > /* Connection tracking state. */
> > expr_symtab_add_field_scoped(symtab, "ct_mark", MFF_CT_MARK, NULL,
> > false,
> > diff --git a/northd/northd.c b/northd/northd.c
> > index 0ff61deec..e4d051a94 100644
> > --- a/northd/northd.c
> > +++ b/northd/northd.c
> > @@ -159,11 +159,14 @@ enum ovn_stage {
> > PIPELINE_STAGE(ROUTER, IN, ARP_REQUEST, 18, "lr_in_arp_request")
> > \
> > \
> > /* Logical router egress stages. */ \
> > -PIPELINE_STAGE(ROUTER, OUT, UNDNAT, 0, "lr_out_undnat")\
> > -PIPELINE_STAGE(ROUTER, OUT, POST_UNDNAT, 1, "lr_out_post_undnat") \
> > -PIPELINE_STAGE(ROUTER, OUT, SNAT,2, "lr_out_snat") \
> > -PIPELINE_STAGE(ROUTER, OUT, EGR_LOOP,3, "lr_out_egr_loop") \
> > -PIPELINE_STAGE(ROUTER, OUT, DELIVERY,4, "lr_out_delivery")
> > +PIPELINE_STAGE(ROUTER, OUT, CHECK_DNAT_LOCAL, 0,
> > \
> > + "lr_out_chk_dnat_local")
> > \
> > +PIPELINE_STAGE(ROUTER, OUT, UNDNAT, 1, "lr_out_undnat")
> > \
> > +PIPELINE_STAGE(ROUTER, OUT, POST_UNDNAT,2,
> > "lr_out_post_undnat") \
> > +PIPELINE_STAGE(ROUTER, OUT, SNAT, 3, "lr_out_snat")
> > \
> > +PIPELINE_STAGE(ROUTER, OUT, P
Re: [ovs-dev] [PATCH ovn v8 2/5] northd: make connected routes have higher priority than static
On Fri, Nov 19, 2021 at 8:12 AM Vladislav Odintsov wrote: > > Hi Numan, > > yes, it’s ready. But I’ve based it on the commit from this patch [1]. > Can you please take a look on it and apply if it’s okay. > Then I can send patch series without conflicting changes. > > Or I can send it with that patch as a part of patchset. > > 1: > https://patchwork.ozlabs.org/project/ovn/patch/2027203545.46142-1-odiv...@gmail.com/ I'd suggest if you can include [1] as part of the patchset. Numan > > Regards, > Vladislav Odintsov > > > On 18 Nov 2021, at 19:50, Numan Siddique wrote: > > > > Hi Vladislav, > > > > Once v9 is ready, please submit them. I'll take a look. > > > > Thanks > > Numan > > > > > > On Thu, Nov 18, 2021 at 2:58 AM Han Zhou wrote: > >> > >> Sounds good to me. > >> > >> On Wed, Nov 17, 2021 at 11:53 PM Vladislav Odintsov > >> wrote: > >> > >>> Thanks, Han. > >>> Please see inline. > >>> > >>> Regards, > >>> Vladislav Odintsov > >>> > >>> On 18 Nov 2021, at 10:26, Han Zhou wrote: > >>> > >>> On Wed, Nov 17, 2021 at 10:10 PM Vladislav Odintsov > >>> wrote: > >>> > >>> > >>> Great, thanks. > >>> > >>> Hi @Han, > >>> > >>> I’d like you to look at the patch series too. Would you have time on it? > >>> If yes, could you redirect me on terms please. > >>> > >>> > >>> Hi Vladislav, > >>> > >>> Thanks for adding me. I am sorry that I don't think I will have enough > >>> time > >>> for a detailed review for this series until Nov 29. Not sure if you can > >>> wait that long, but I don't think my review is mandatory if Numan is > >>> reviewing all the patches in detail. > >>> > >>> > >>> It’s okay from my side to wait for Dec 2-3. > >>> > >>> I have a quick comment though, regarding the priority offset. It is > >>> mentioned in the commit message: > >>> > >>> Each route's prefix length has its own 'slot' in lflow prios. > >>> Now prefix length space is calculated using next information: > >>> to calculate route's priority prefixlen multiplied by 3 > >>> + route origin offset (0 - source-based route; 1 - directly- > >>> connected route; 2 - static route). > >>> > >>> > >>> But in the code, 2 is for connected, and 1 is for static: > >>> > >>> +#define ROUTE_PRIO_OFFSET_MULTIPLIER 3 > >>> +#define ROUTE_PRIO_OFFSET_STATIC 1 > >>> +#define ROUTE_PRIO_OFFSET_CONNECTED 2 > >>> > >>> > >>> I wonder which one is your intent? I'd let the static route have higher > >>> priority, because otherwise why would the user add the static route at > >>> all? > >>> But this is more of a question than a suggestion. Is there any *standard* > >>> behavior or similar thing that we can refer from e.g. AWS? > >>> > >>> > >>> It’s a typo in commit message. I’ll fix that in v9. > >>> > >>> It is done to support well-known behaviour, where directly-connected > >>> routes take precedence over static routes for same CIDR. > >>> > >>> To support AWS feature, where user can override "subnet" route (think, > >>> "connected") with a static route, additional work is needed. > >>> It’s not what I’m currently working on, but I thought about such use case > >>> and it seems that it can be easily supported by adding ability to add > >>> Logical_Router_Static_Route with some "override" flag, which ensures this > >>> static route would be installed with the highest priority. > >>> > >>> So, if no objections here or other comments for now I’ll send v9. > >>> > >>> Thanks, > >>> Han > >>> > >>> > >>> Thanks. > >>> > >>> Regards, > >>> Vladislav Odintsov > >>> > >>> On 18 Nov 2021, at 00:05, Numan Siddique wrote: > >>> > >>> On Wed, Nov 17, 2021 at 3:38 PM Vladislav Odintsov >>> > >>> <mailto:odiv...@gmail.com >> wrote: > >>> > >>> > >>> I’ve submitted a patch [1] wit
Re: [ovs-dev] [PATCH ovn v2 2/2] northd: Use ct_(snat/dnat)_in_czone action for distributed routers.
On Fri, Nov 19, 2021 at 11:16 AM Mark Michelson wrote:
>
> On 11/18/21 18:42, Numan Siddique wrote:
> > On Thu, Nov 18, 2021 at 4:49 PM Mark Michelson wrote:
> >>
> >> Hi Numan,
> >>
> >> I had one question in the code and then one small finding in the
> >> documentation. See below:
> >>
> >> On 11/18/21 13:13, num...@ovn.org wrote:
> >>> From: Numan Siddique
> >>>
> >>> Make of use of these new actions for the distributed routers
> >>> for NAT. These new actions ensure that both sNAT and dNAT
> >>> happens in the same zone. This approach solves a couple of
> >>> problems:
> >>>
> >>>- The datapath flows generated for external traffic which requires
> >>> dNAT (N -> S) or sNAT (S -> N) are completely HWOL'able.
> >>>
> >>>- Since there is only one zone, it would avoid multiple recirculations
> >>> (improving the performance).
> >>>
> >>> If the packet needs to be both sNATted and dNATted (for hairpin traffic
> >>> with source and destination on the same chassis), then sNAT is done
> >>> in a separate zone. To detect this scenario, this patch adds a few
> >>> extra logical flows. For each dnat_and_snat entry prior to this patch
> >>> ovn-northd was generating 9 logical flows and with this patch it now
> >>> generates 12 logical flows.
> >>>
> >>> Similar approach can be taken for gateway routers.
> >>>
> >>> Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1984953
> >>> Signed-off-by: Numan Siddique
> >>> ---
> >>>
> >>> v1 -> v2
> >>> --
> >>> * Rebased and resolved conflicts.
> >>>
> >>>include/ovn/logical-fields.h | 1 +
> >>>lib/logical-fields.c | 4 +
> >>>northd/northd.c | 147 +++--
> >>>northd/ovn-northd.8.xml | 201 +---
> >>>tests/ovn-northd.at | 575 +++
> >>>tests/ovn.at | 2 +-
> >>>tests/system-ovn.at | 64 ++--
> >>>7 files changed, 607 insertions(+), 387 deletions(-)
> >>>
> >>> diff --git a/include/ovn/logical-fields.h b/include/ovn/logical-fields.h
> >>> index c9675f81c..2118f7933 100644
> >>> --- a/include/ovn/logical-fields.h
> >>> +++ b/include/ovn/logical-fields.h
> >>> @@ -70,6 +70,7 @@ enum mff_log_flags_bits {
> >>>MLF_LOOKUP_FDB_BIT = 8,
> >>>MLF_SKIP_SNAT_FOR_LB_BIT = 9,
> >>>MLF_LOCALPORT_BIT = 10,
> >>> +MLF_USE_SNAT_ZONE = 11,
> >>>};
> >>>
> >>>/* MFF_LOG_FLAGS_REG flag assignments */
> >>> diff --git a/lib/logical-fields.c b/lib/logical-fields.c
> >>> index 7b3d431e0..352a48c89 100644
> >>> --- a/lib/logical-fields.c
> >>> +++ b/lib/logical-fields.c
> >>> @@ -125,6 +125,10 @@ ovn_init_symtab(struct shash *symtab)
> >>> MLF_SKIP_SNAT_FOR_LB_BIT);
> >>>expr_symtab_add_subfield(symtab, "flags.skip_snat_for_lb", NULL,
> >>> flags_str);
> >>> +snprintf(flags_str, sizeof flags_str, "flags[%d]",
> >>> + MLF_USE_SNAT_ZONE);
> >>> +expr_symtab_add_subfield(symtab, "flags.use_snat_zone", NULL,
> >>> + flags_str);
> >>>
> >>>/* Connection tracking state. */
> >>>expr_symtab_add_field_scoped(symtab, "ct_mark", MFF_CT_MARK, NULL,
> >>> false,
> >>> diff --git a/northd/northd.c b/northd/northd.c
> >>> index 0ff61deec..e4d051a94 100644
> >>> --- a/northd/northd.c
> >>> +++ b/northd/northd.c
> >>> @@ -159,11 +159,14 @@ enum ovn_stage {
> >>>PIPELINE_STAGE(ROUTER, IN, ARP_REQUEST, 18,
> >>> "lr_in_arp_request") \
> >>> \
> >>>/* Logical router egress stages. */ \
> >>> -PIPELINE_STAGE(ROUTER, OUT, UNDNAT, 0, "lr_out_undnat")\
> >>> -PIPELINE_STAGE(ROUTER, OUT, POST_UNDNAT, 1, "lr_out_post_undnat") \
> >>> -PIPELINE_STAGE(ROUTER
Re: [ovs-dev] [PATCH ovn v3 0/4] uuid-based conjunction id generation.
On Thu, Nov 11, 2021 at 5:38 PM Han Zhou wrote: > > It is important to keep conjunction IDs consistent between runs to avoid > unnecessary OVS flows deletion and reinstallation. However, There are two > problems of the current lflow-cache based conjunction id peristent approach. > > 1) When n_conjs changes, the cached conj_id_ofs can overlap with other lflows. > 2) When lflow-cache is not enabled, conjunction id is not consistent across > runs. > > This series replace the lflow-cache based approach by a new way of conjunction > id generation which keeps the ids consistent regardless of the lflow-cache > enablement. > > v1 -> v2: adding the missing patch 1. > v2 -> v3: adding more tests, and minor changes for error logging and coverage > counters. > Hi Han, I've a few small comments for patch 4. Please see my reply in patch 4. With those addressed for the entire series: Acked-by: Numan Siddique Thanks Numan > Han Zhou (4): > lflow-cache.h: Fix comment about lflow-cache. > lflow-cache: Remove conjunction id cache. > test-utils: Add test_read_uint_hex_value helper. > lflow: Consistent conjunction id generation. > > controller/automake.mk | 2 + > controller/lflow-cache.c | 30 +-- > controller/lflow-cache.h | 20 +- > controller/lflow-conj-ids.c | 259 + > controller/lflow-conj-ids.h | 41 > controller/lflow.c | 154 ++--- > controller/lflow.h | 4 +- > controller/ovn-controller.c | 32 +-- > controller/test-lflow-cache.c| 44 ++-- > controller/test-lflow-conj-ids.c | 128 +++ > tests/automake.mk| 3 + > tests/ovn-lflow-cache.at | 383 +++ > tests/ovn-lflow-conj-ids.at | 112 + > tests/ovn.at | 271 -- > tests/test-utils.c | 22 +- > tests/test-utils.h | 2 + > tests/testsuite.at | 1 + > 17 files changed, 909 insertions(+), 599 deletions(-) > create mode 100644 controller/lflow-conj-ids.c > create mode 100644 controller/lflow-conj-ids.h > create mode 100644 controller/test-lflow-conj-ids.c > create mode 100644 tests/ovn-lflow-conj-ids.at > > -- > 2.30.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 v3 4/4] lflow: Consistent conjunction id generation.
On Thu, Nov 11, 2021 at 5:39 PM Han Zhou wrote:
>
> When a logical flow translation uses conjunction ids, it is better to
> keep the conjuntion ids consistent between iterations, so that the
> generated OVS flows don't change unnecessarily and avoid reinstalling
> unchanged flows to OVS. The problem was partially solved when
> lflow-cache was enabled but there was a bug for a corner case so the
> lflow-cache based approach was reverted in a previous commit.
>
> This patch takes an approach that generates conjunction ids based on the
> logical flow's uuid, which ensures the same ids being used when
> processing the same lflow in most cases. There is a very little chance
> that different logial flows happen to have the same 32-bit prefix in
> their uuids, but the probability is really low. For the very unlikely
> situation, the conflicts are handled properly and correctness is
> ensured.
>
> A new module lflow-conj-ids is created to manage the id allocations and
> maintaining the usage of each ids and their owner lflows.
>
> Unlike the previously lflow-cache based approach, this approach works
> equally well when lflow-cache is not in use.
>
> Signed-off-by: Han Zhou
Hi Han,
Few minor comments.
1. I think it would be nice to reorganize the newly added file -
controller/lflow-conj-ids.c to
be organized with public functions first and then static functions as
per the coding
guidelines -
https://github.com/ovn-org/ovn/blob/main/Documentation/internals/contributing/coding-style.rst
2. I'd suggest to add a debug function in
controller/lflow-conj-ids.c which would dump
the allocated conj ids and the lflow conj_id mapping. And the
test file can verify the dump is as expected.
What do you think ? I'm fine if you think this can be a follow up patch.
Also if required, we can add appctl command to dump the conj id
allocations.
Thanks
Numan
> ---
> controller/automake.mk | 2 +
> controller/lflow-cache.c | 6 +-
> controller/lflow-cache.h | 9 +-
> controller/lflow-conj-ids.c | 259 +++
> controller/lflow-conj-ids.h | 41 +
> controller/lflow.c | 147 --
> controller/lflow.h | 4 +-
> controller/ovn-controller.c | 32 +---
> controller/test-lflow-cache.c| 36 +++--
> controller/test-lflow-conj-ids.c | 128 +++
> tests/automake.mk| 3 +
> tests/ovn-lflow-cache.at | 123 ++-
> tests/ovn-lflow-conj-ids.at | 112 +
> tests/ovn.at | 49 --
> tests/testsuite.at | 1 +
> 15 files changed, 772 insertions(+), 180 deletions(-)
> create mode 100644 controller/lflow-conj-ids.c
> create mode 100644 controller/lflow-conj-ids.h
> create mode 100644 controller/test-lflow-conj-ids.c
> create mode 100644 tests/ovn-lflow-conj-ids.at
>
> diff --git a/controller/automake.mk b/controller/automake.mk
> index 9f9b49fe0..c2ab1bbe6 100644
> --- a/controller/automake.mk
> +++ b/controller/automake.mk
> @@ -18,6 +18,8 @@ controller_ovn_controller_SOURCES = \
> controller/lflow.h \
> controller/lflow-cache.c \
> controller/lflow-cache.h \
> + controller/lflow-conj-ids.c \
> + controller/lflow-conj-ids.h \
> controller/lport.c \
> controller/lport.h \
> controller/ofctrl.c \
> diff --git a/controller/lflow-cache.c b/controller/lflow-cache.c
> index 26228c960..6db85fc12 100644
> --- a/controller/lflow-cache.c
> +++ b/controller/lflow-cache.c
> @@ -203,7 +203,7 @@ lflow_cache_get_stats(const struct lflow_cache *lc,
> struct ds *output)
>
> void
> lflow_cache_add_expr(struct lflow_cache *lc, const struct uuid *lflow_uuid,
> - uint32_t conj_id_ofs, struct expr *expr, size_t expr_sz)
> + struct expr *expr, size_t expr_sz)
> {
> struct lflow_cache_value *lcv =
> lflow_cache_add__(lc, lflow_uuid, LCACHE_T_EXPR, expr_sz);
> @@ -213,12 +213,12 @@ lflow_cache_add_expr(struct lflow_cache *lc, const
> struct uuid *lflow_uuid,
> return;
> }
> COVERAGE_INC(lflow_cache_add_expr);
> -lcv->conj_id_ofs = conj_id_ofs;
> lcv->expr = expr;
> }
>
> void
> lflow_cache_add_matches(struct lflow_cache *lc, const struct uuid
> *lflow_uuid,
> +uint32_t conj_id_ofs, uint32_t n_conjs,
> struct hmap *matches, size_t matches_sz)
> {
> struct lflow_cache_value *lcv =
> @@ -231,6 +231,8 @@ lflow_cache_add_matches(struct lflow_cache *lc, const
> struct uuid *lflow_uuid,
> }
> COVERAGE_INC(lflow_cache_add_matches);
> lcv->expr_matches = matches;
> +lcv->n_conjs = n_conjs;
> +lcv->conj_id_ofs = conj_id_ofs;
> }
>
> struct lflow_cache_value *
> diff --git a/controller/lflow-cache.h b/controller/lflow-cache.h
> index d42bdeaa3..faad32bb6 100644
> --- a/controller/lflow-cache.h
> +++ b/contro
Re: [ovs-dev] [PATCH ovn v3 2/2] northd: Use ct_(snat/dnat)_in_czone action for distributed routers.
On Fri, Nov 19, 2021 at 1:11 PM Mark Michelson wrote:
>
> Thanks for the update, Numan.
>
> Acked-by: Mark Michelson
Thanks. I applied both the patches to the main branch.
Numan
>
> On 11/19/21 11:32, num...@ovn.org wrote:
> > From: Numan Siddique
> >
> > Make of use of these new actions for the distributed routers
> > for NAT. These new actions ensure that both sNAT and dNAT
> > happens in the same zone. This approach solves a couple of
> > problems:
> >
> > - The datapath flows generated for external traffic which requires
> > dNAT (N -> S) or sNAT (S -> N) are completely HWOL'able.
> >
> > - Since there is only one zone, it would avoid multiple recirculations
> > (improving the performance).
> >
> > If the packet needs to be both sNATted and dNATted (for hairpin traffic
> > with source and destination on the same chassis), then sNAT is done
> > in a separate zone. To detect this scenario, this patch adds a few
> > extra logical flows. For each dnat_and_snat entry prior to this patch
> > ovn-northd was generating 9 logical flows and with this patch it now
> > generates 12 logical flows.
> >
> > Similar approach can be taken for gateway routers.
> >
> > Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1984953
> > Signed-off-by: Numan Siddique
> > ---
> >
> > v2 -> v3
> > --
> >* Addressed Mark's comments and updated the documentation.
> >
> > v1 -> v2
> > --
> >* Rebased and resolved conflicts.
> >
> >
> > include/ovn/logical-fields.h | 1 +
> > lib/logical-fields.c | 4 +
> > northd/northd.c | 147 +++--
> > northd/ovn-northd.8.xml | 205 ++---
> > tests/ovn-northd.at | 575 +++
> > tests/ovn.at | 2 +-
> > tests/system-ovn.at | 64 ++--
> > 7 files changed, 610 insertions(+), 388 deletions(-)
> >
> > diff --git a/include/ovn/logical-fields.h b/include/ovn/logical-fields.h
> > index c9675f81c..2118f7933 100644
> > --- a/include/ovn/logical-fields.h
> > +++ b/include/ovn/logical-fields.h
> > @@ -70,6 +70,7 @@ enum mff_log_flags_bits {
> > MLF_LOOKUP_FDB_BIT = 8,
> > MLF_SKIP_SNAT_FOR_LB_BIT = 9,
> > MLF_LOCALPORT_BIT = 10,
> > +MLF_USE_SNAT_ZONE = 11,
> > };
> >
> > /* MFF_LOG_FLAGS_REG flag assignments */
> > diff --git a/lib/logical-fields.c b/lib/logical-fields.c
> > index 7b3d431e0..352a48c89 100644
> > --- a/lib/logical-fields.c
> > +++ b/lib/logical-fields.c
> > @@ -125,6 +125,10 @@ ovn_init_symtab(struct shash *symtab)
> >MLF_SKIP_SNAT_FOR_LB_BIT);
> > expr_symtab_add_subfield(symtab, "flags.skip_snat_for_lb", NULL,
> >flags_str);
> > +snprintf(flags_str, sizeof flags_str, "flags[%d]",
> > + MLF_USE_SNAT_ZONE);
> > +expr_symtab_add_subfield(symtab, "flags.use_snat_zone", NULL,
> > + flags_str);
> >
> > /* Connection tracking state. */
> > expr_symtab_add_field_scoped(symtab, "ct_mark", MFF_CT_MARK, NULL,
> > false,
> > diff --git a/northd/northd.c b/northd/northd.c
> > index 0ff61deec..e4d051a94 100644
> > --- a/northd/northd.c
> > +++ b/northd/northd.c
> > @@ -159,11 +159,14 @@ enum ovn_stage {
> > PIPELINE_STAGE(ROUTER, IN, ARP_REQUEST, 18, "lr_in_arp_request")
> > \
> > \
> > /* Logical router egress stages. */ \
> > -PIPELINE_STAGE(ROUTER, OUT, UNDNAT, 0, "lr_out_undnat")\
> > -PIPELINE_STAGE(ROUTER, OUT, POST_UNDNAT, 1, "lr_out_post_undnat") \
> > -PIPELINE_STAGE(ROUTER, OUT, SNAT,2, "lr_out_snat") \
> > -PIPELINE_STAGE(ROUTER, OUT, EGR_LOOP,3, "lr_out_egr_loop") \
> > -PIPELINE_STAGE(ROUTER, OUT, DELIVERY,4, "lr_out_delivery")
> > +PIPELINE_STAGE(ROUTER, OUT, CHECK_DNAT_LOCAL, 0,
> > \
> > + "lr_out_chk_dnat_local")
> > \
> > +PIPELINE_STAGE(ROUTER, OUT, UNDNAT, 1, "lr_out_undnat")
> > \
> > +PIPELINE_STAGE(ROUTER, OUT, POST_UNDNAT,2,
> > "lr_out_post_undnat") \
>
Re: [ovs-dev] [PATCH ovn v9 0/6] Add multiple routing tables support to Logical Routers
On Fri, Nov 19, 2021 at 11:07 AM Vladislav Odintsov wrote: > > v8 -> v9: > - Fix documentation errors. > - Fix commit messages. > > v7 -> v8: > - Updated manpages with and commit messages according to latest changes. > - Small fixes. > > v6 -> v7: > - Addressed Han's comments regarding saving same behaviour for route-tables > static routes as for static routes from 'global' table. > To address this 2 new patches were added (1, 2). > - "global" table terminology was replaced with ''. > > v5 -> v6: > - 2 memory leak bugs were fixed in ovn-ic code, which were introduced in > previous versions of #3 patch. > > v4 -> v5: > - Addressed Numan's review comments. > > v3 -> v4: > - Minor logging typo fixes. > - Added patch with ovn-ic routes learning bugfix. > > v2 -> v3: > - Rebased on split northd changes. > - Replaced route_tables HMAP with SIMAP as Numan suggested. > - This series stil doesn't have ddlog support yet. > It will take too much time for me to deal to ddlog language and specifics. > Help with ddlog implementation wanted. > > v1 -> v2: > - First patch of v1 patch series was applied, but new tests for new feature > were added with strict table number check. Update this tests to be table > number-independent. > - Squash pathes for northd and utilities as tests don't pass without latter. > - Add support for OVN IC routing table in routes advertisement/learning. > - Patches `ic: remove port_binding on ts deletion` > > https://patchwork.ozlabs.org/project/ovn/patch/20210824184442.35063-1-odiv...@gmail.com/ > and `ic: process only local port_bindings` > > https://patchwork.ozlabs.org/project/ovn/patch/20210830195707.98529-1-odiv...@gmail.com/ > were already sent to list separately, but other changes are based on them > so they're included. > Once those patches are accepts, I can drop them from this series. > - Added NEWS item. > - Added myself to authors list. > > Vladislav Odintsov (6): > northd: fix symmetric ECMP reply flows documentation > ic: maintain route origin - connected/static > northd: make connected routes have higher priority than static > northd,utils: support for RouteTables in LRs > ic: add support for routing tables in adv/learn routes > ic: don't learn routes which have local GW > > NEWS| 4 + > ic/ovn-ic.c | 592 ++-- > lib/ovn-util.c | 2 +- > lib/ovn-util.h | 3 + > northd/northd.c | 192 ++--- > northd/ovn-northd.8.xml | 80 -- > ovn-ic-sb.ovsschema | 8 +- > ovn-ic-sb.xml | 30 ++ > ovn-nb.ovsschema| 5 +- > ovn-nb.xml | 44 +++ > tests/ovn-ic.at | 550 + > tests/ovn-nbctl.at | 196 - > tests/ovn-northd.at | 74 - > tests/ovn.at| 546 +++- > utilities/ovn-nbctl.c | 138 +- > 15 files changed, 2181 insertions(+), 283 deletions(-) Thanks. I applied this patch series to the main branch. Numan > > -- > 2.30.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: Generate ARP responder flows only for reachable VIPs.
On Mon, Nov 22, 2021 at 11:03 AM Mark Michelson wrote:
>
> Acked-by: Mark Michelson
Thanks Dumitru and Mark.
I applied this patch to the main branch with the below changes as the
patch needed some
updates in the ovn-northd.8.xml documentation.
Numan
--
diff --git a/northd/ovn-northd.8.xml b/northd/ovn-northd.8.xml
index 9b1774005..0adeaa59d 100644
--- a/northd/ovn-northd.8.xml
+++ b/northd/ovn-northd.8.xml
@@ -2545,7 +2545,9 @@ output;
IPv4: For a configured load balancer IPv4 VIP, a similar flow is
- added with the additional match inport == P.
+ added with the additional match inport == P
+ if the VIP is reachable from any logical router port of the logical
+ router.
@@ -2557,7 +2559,8 @@ output;
IPv6: For a configured NAT (both DNAT and SNAT) IP address or a
- load balancer IPv6 VIP A, solicited node address
+ load balancer IPv6 VIP A (if the VIP is reachable from any
+ logical router port of the logical router), solicited node address
S, for each router port P with
Ethernet address E, a priority-90 flow matches
inport == P && nd_ns &&
-
>
> On 11/19/21 06:51, Dumitru Ceara wrote:
> > It's not useful to generate ARP responder flows for VIPs that are not
> > reachable on any port of a logical router port. On scaled
> > ovn-kubernetes deployments the VIP ARP responder Southbound address
> > sets become quite large, wasting resources because they are never
> > used.
> >
> > Stop generating ARP responder flows in these cases and update the tests
> > to reflect this change.
> >
> > Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2022403
> > Signed-off-by: Dumitru Ceara
> > ---
> > V2: Rebase after initial northd I-P.
> > ---
> > northd/northd.c | 87 -
> > tests/ovn-northd.at | 18 +++---
> > 2 files changed, 93 insertions(+), 12 deletions(-)
> >
> > diff --git a/northd/northd.c b/northd/northd.c
> > index 0ff61deec..da5025fd0 100644
> > --- a/northd/northd.c
> > +++ b/northd/northd.c
> > @@ -622,8 +622,10 @@ struct ovn_datapath {
> >*/
> > struct sset lb_ips_v4;
> > struct sset lb_ips_v4_routable;
> > +struct sset lb_ips_v4_reachable;
> > struct sset lb_ips_v6;
> > struct sset lb_ips_v6_routable;
> > +struct sset lb_ips_v6_reachable;
> >
> > struct ovn_port **localnet_ports;
> > size_t n_localnet_ports;
> > @@ -918,8 +920,10 @@ init_lb_for_datapath(struct ovn_datapath *od)
> > {
> > sset_init(&od->lb_ips_v4);
> > sset_init(&od->lb_ips_v4_routable);
> > +sset_init(&od->lb_ips_v4_reachable);
> > sset_init(&od->lb_ips_v6);
> > sset_init(&od->lb_ips_v6_routable);
> > +sset_init(&od->lb_ips_v6_reachable);
> >
> > if (od->nbs) {
> > od->has_lb_vip = ls_has_lb_vip(od);
> > @@ -937,8 +941,10 @@ destroy_lb_for_datapath(struct ovn_datapath *od)
> >
> > sset_destroy(&od->lb_ips_v4);
> > sset_destroy(&od->lb_ips_v4_routable);
> > +sset_destroy(&od->lb_ips_v4_reachable);
> > sset_destroy(&od->lb_ips_v6);
> > sset_destroy(&od->lb_ips_v6_routable);
> > +sset_destroy(&od->lb_ips_v6_reachable);
> > }
> >
> > /* A group of logical router datapaths which are connected - either
> > @@ -3909,6 +3915,38 @@ build_lrouter_lb_ips(struct ovn_datapath *od, const
> > struct ovn_northd_lb *lb)
> > }
> > }
> >
> > +static bool lrouter_port_ipv4_reachable(const struct ovn_port *op,
> > +ovs_be32 addr);
> > +static bool lrouter_port_ipv6_reachable(const struct ovn_port *op,
> > +const struct in6_addr *addr);
> > +static void
> > +build_lrouter_lb_reachable_ips(struct ovn_datapath *od,
> > + const struct ovn_northd_lb *lb)
> > +{
> > +for (size_t i = 0; i < lb->n_vips; i++) {
> > +if (IN6_IS_ADDR_V4MAPPED(&lb->vips[i].vip)) {
> > +ovs_be32 vip_ip4 = in6_addr_get_mapped_ipv4(&lb->vips[i].vip);
> > +struct ovn_port *op;
> > +
> > +LIST_FOR_EACH (op, dp_node, &od->port_list) {
> > +if (lrouter_port_ipv4_reachable(op, vip_ip4)) {
> > +sset_add(&od->lb_ips_v4_reachable,
> > lb->vips[i].vip_str);
> > +break;
> > +}
> > +}
> > +} else {
> > +struct ovn_port *op;
> > +
> > +LIST_FOR_EACH (op, dp_node, &od->port_list) {
> > +if (lrouter_port_ipv6_reachable(op, &lb->vips[i].vip)) {
> > +sset_add(&od->lb_ips_v6_reachable,
> > lb->vips[i].vip_str);
> > +break;
> > +}
> > +}
> > +}
> > +}
> > +}
> > +
> > static void
> > build_lrouter_lbs(struct hmap *datapaths, struc
Re: [ovs-dev] [PATCH ovn] binding: Log iface-id-ver mismatch.
On Fri, Nov 19, 2021 at 6:58 AM Dumitru Ceara wrote:
>
> This is useful for debugging.
>
> Signed-off-by: Dumitru Ceara
Thanks. I applied this patch to the main branch.
Numan
> ---
> controller/binding.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/controller/binding.c b/controller/binding.c
> index fcd319e6d..4d62b0858 100644
> --- a/controller/binding.c
> +++ b/controller/binding.c
> @@ -2843,6 +2843,11 @@ ovs_iface_matches_lport_iface_id_ver(const struct
> ovsrec_interface *iface,
> const char *iface_id_ver = smap_get(&iface->external_ids,
> "iface-id-ver");
> if (!iface_id_ver || strcmp(pb_iface_id_ver, iface_id_ver)) {
> +static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(5, 1);
> +VLOG_INFO_RL(&rl, "Mismatch iface-id-ver for lport %s, "
> + "expected %s, found %s", pb->logical_port,
> + pb_iface_id_ver,
> + iface_id_ver ? iface_id_ver : "");
> return false;
> }
> }
> --
> 2.27.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] northd: I-P add explicit dependency on Load_Balancer_Group.
On Fri, Nov 19, 2021 at 6:43 AM Dumitru Ceara wrote:
>
> The commit that added I-P for northd missed to add this explicit
> dependency. This didn't really affect functionality because:
> a. ovn-northd monitors the whole NB database
> b. changes to the Load_Balancer_Group table mark rows in Logical_Switch
>table that refer to the updated LB groups as "updated".
>
> However, it's probably better to make this dependency explicit having in
> mind that real incremental processing might be implemented in the
> future.
>
> Fixes: 4597317f16d1 ("northd: Introduce incremental processing for northd")
> Signed-off-by: Dumitru Ceara
Thanks. I applied this patch to the main branch.
Numan
> ---
> northd/inc-proc-northd.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/northd/inc-proc-northd.c b/northd/inc-proc-northd.c
> index c7f49d599..8e7428dda 100644
> --- a/northd/inc-proc-northd.c
> +++ b/northd/inc-proc-northd.c
> @@ -42,6 +42,7 @@ VLOG_DEFINE_THIS_MODULE(inc_proc_northd);
> NB_NODE(address_set, "address_set") \
> NB_NODE(port_group, "port_group") \
> NB_NODE(load_balancer, "load_balancer") \
> +NB_NODE(load_balancer_group, "load_balancer_group") \
> NB_NODE(load_balancer_health_check, "load_balancer_health_check") \
> NB_NODE(acl, "acl") \
> NB_NODE(logical_router, "logical_router") \
> @@ -159,6 +160,7 @@ void inc_proc_northd_init(struct ovsdb_idl_loop *nb,
> engine_add_input(&en_northd, &en_nb_address_set, NULL);
> engine_add_input(&en_northd, &en_nb_port_group, NULL);
> engine_add_input(&en_northd, &en_nb_load_balancer, NULL);
> +engine_add_input(&en_northd, &en_nb_load_balancer_group, NULL);
> engine_add_input(&en_northd, &en_nb_load_balancer_health_check, NULL);
> engine_add_input(&en_northd, &en_nb_acl, NULL);
> engine_add_input(&en_northd, &en_nb_logical_router, NULL);
> --
> 2.27.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] northd: I-P: fix BFD dependency.
On Tue, Nov 23, 2021 at 7:52 PM Dumitru Ceara wrote:
>
> BFD entries are updated and their ->ref field is set to 'true' when
> static routes are parsed, within build_lflows(), in the 'en_lflow' I-P
> node. Therefore we cannot clean up BFD entries in 'en_northd' which is
> an input of 'en_lflow'.
>
> To fix this we now move all BFD handling in the 'en_lflow' node.
>
> This fixes the CI failures that we've recently started hitting when
> running the ovn-kubernetes jobs, for example:
> https://github.com/ovn-org/ovn/runs/4294661249?check_suite_focus=true#step:10:9154
>
> Fixes: 1fa6612ffebf ("northd: Add lflow node")
> Signed-off-by: Dumitru Ceara
Hi Dumitru,
Thanks for fixing this issue.
In my opinion en_northd engine node should handle the DB syncs and
en_lflow engine node
should handle the flow generation. I think it would be better to move
the syncing of
NB bfd->state from en_lflow engine node (ie frombuild_lflows()) to
en_northd engine node.
This would mean en_northd engine node should iterate the logical
static routes and set the
status. Which would mean we need to move out the function
parsed_routes_add() from
build_static_route_flows_for_lrouter().
What do you think ? Would you agree with this ?
I'm not too sure about how easy it is ? I'm inclined to accept this
patch and then revisit this
as a follow up or once we branch out of 21.12.
Let me know your thoughts.
Thanks
Numan
> northd/en-lflow.c| 8
> northd/en-northd.c | 4
> northd/inc-proc-northd.c | 4 ++--
> northd/northd.c | 11 ---
> northd/northd.h | 11 +--
> tests/ovn-northd.at | 8
> 6 files changed, 31 insertions(+), 15 deletions(-)
>
> diff --git a/northd/en-lflow.c b/northd/en-lflow.c
> index 5bef35cf6..ffbdaf4e8 100644
> --- a/northd/en-lflow.c
> +++ b/northd/en-lflow.c
> @@ -38,6 +38,10 @@ void en_lflow_run(struct engine_node *node, void *data
> OVS_UNUSED)
>
> struct northd_data *northd_data = engine_get_input_data("northd", 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 =
> @@ -60,7 +64,11 @@ void en_lflow_run(struct engine_node *node, void *data
> OVS_UNUSED)
>northd_data->ovn_internal_version_changed;
>
> stopwatch_start(BUILD_LFLOWS_STOPWATCH_NAME, time_msec());
> +build_bfd_table(&lflow_input, eng_ctx->ovnsb_idl_txn,
> +&northd_data->bfd_connections,
> +&northd_data->ports);
> build_lflows(&lflow_input, eng_ctx->ovnsb_idl_txn);
> +bfd_cleanup_connections(&lflow_input, &northd_data->bfd_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 0523560f8..79da7e1c4 100644
> --- a/northd/en-northd.c
> +++ b/northd/en-northd.c
> @@ -66,8 +66,6 @@ void en_northd_run(struct engine_node *node, void *data)
> EN_OVSDB_GET(engine_get_input("NB_load_balancer", node));
> input_data.nbrec_port_group_table =
> EN_OVSDB_GET(engine_get_input("NB_port_group", node));
> -input_data.nbrec_bfd_table =
> -EN_OVSDB_GET(engine_get_input("NB_bfd", node));
> input_data.nbrec_address_set_table =
> EN_OVSDB_GET(engine_get_input("NB_address_set", node));
> input_data.nbrec_meter_table =
> @@ -93,8 +91,6 @@ void en_northd_run(struct engine_node *node, void *data)
> EN_OVSDB_GET(engine_get_input("SB_load_balancer", node));
> input_data.sbrec_service_monitor_table =
> EN_OVSDB_GET(engine_get_input("SB_service_monitor", node));
> -input_data.sbrec_bfd_table =
> -EN_OVSDB_GET(engine_get_input("SB_bfd", node));
> input_data.sbrec_address_set_table =
> EN_OVSDB_GET(engine_get_input("SB_address_set", node));
> input_data.sbrec_port_group_table =
> diff --git a/northd/inc-proc-northd.c b/northd/inc-proc-northd.c
> index 8e7428dda..c02c5a44a 100644
> --- a/northd/inc-proc-northd.c
> +++ b/northd/inc-proc-northd.c
> @@ -178,7 +178,6 @@ void inc_proc_northd_init(struct ovsdb_idl_loop *nb,
> engine_add_input(&en_northd, &en_nb_gateway_chassis, NULL);
> engine_add_input(&en_northd, &en_nb_ha_chassis_group, NULL);
> engine_add_input(&en_northd, &en_nb_ha_chassis, NULL);
> -engine_add_input(&en_northd, &en_nb_bfd, NULL);
>
> engine_add_input(&en_northd, &en_sb_sb_global, NULL);
> engine_add_input(&en_northd, &en_sb_chassis, NULL);
> @@ -206,8 +205,9 @@ void inc_proc_northd_init(struct ovsdb_idl_loop *nb,
> engine_add_input(&en_northd, &en_sb_ip_multicast, NULL);
> engine_add_input(&en_northd, &en_sb_service
Re: [ovs-dev] [PATCH ovn] northd: I-P: fix BFD dependency.
On Wed, Nov 24, 2021 at 11:19 AM Dumitru Ceara wrote:
>
> On 11/24/21 17:15, Numan Siddique wrote:
> > On Tue, Nov 23, 2021 at 7:52 PM Dumitru Ceara wrote:
> >>
> >> BFD entries are updated and their ->ref field is set to 'true' when
> >> static routes are parsed, within build_lflows(), in the 'en_lflow' I-P
> >> node. Therefore we cannot clean up BFD entries in 'en_northd' which is
> >> an input of 'en_lflow'.
> >>
> >> To fix this we now move all BFD handling in the 'en_lflow' node.
> >>
> >> This fixes the CI failures that we've recently started hitting when
> >> running the ovn-kubernetes jobs, for example:
> >> https://github.com/ovn-org/ovn/runs/4294661249?check_suite_focus=true#step:10:9154
> >>
> >> Fixes: 1fa6612ffebf ("northd: Add lflow node")
> >> Signed-off-by: Dumitru Ceara
> >
> > Hi Dumitru,
> >
>
> Hi Numan,
>
> > Thanks for fixing this issue.
> >
>
> Thanks for reviewing this.
>
> > In my opinion en_northd engine node should handle the DB syncs and
> > en_lflow engine node
> > should handle the flow generation. I think it would be better to move
> > the syncing of
> > NB bfd->state from en_lflow engine node (ie frombuild_lflows()) to
> > en_northd engine node.
> > This would mean en_northd engine node should iterate the logical
> > static routes and set the
> > status. Which would mean we need to move out the function
> > parsed_routes_add() from
> > build_static_route_flows_for_lrouter().
> >
> > What do you think ? Would you agree with this ?
> >
>
> Sounds like this would be the ideal way to implement this, yes.
>
> > I'm not too sure about how easy it is ? I'm inclined to accept this
>
> I don't see a very clean way of implementing it though.
>
> > patch and then revisit this
> > as a follow up or once we branch out of 21.12.
>
> I think this would be the safest way to go for now.
Sounds good. I applied this patch to the main branch.
Numan
>
> >
> > Let me know your thoughts.
> >
> > Thanks
> > Numan
> >
>
> Thanks,
> 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 v2] ovn-nb: Document LRP gateway_mtu option
On Fri, Nov 26, 2021 at 8:11 AM Dumitru Ceara wrote:
>
> On 11/9/21 11:11, Frode Nordahl wrote:
> > The Logical Router Port gateway_mtu option is currently only
> > documented together with implementation details in the ovn-northd
> > documentation.
> >
> > As this is CMS API we ought to document this as part of the OVN
> > Northbound Database as well.
> >
> > Reported-at: https://github.com/ovn-org/ovn/issues/78
> > Fixes: 7d42c14 ("ovn: Generate ICMPv4 packet in router pipeline for larger
> > packets")
> > Signed-off-by: Frode Nordahl
> > ---
> > ovn-nb.xml | 13 +
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/ovn-nb.xml b/ovn-nb.xml
> > index 036ffa64f..bb0970e94 100644
> > --- a/ovn-nb.xml
> > +++ b/ovn-nb.xml
> > @@ -2820,6 +2820,19 @@
> >prefix according to RFC3663
> >
> >
> > +
> > + > + type='{"type": "integer", "minInteger": 68, "maxInteger":
> > 65535}'>
> > +
> > + If set, logical flows will be added to router pipeline to check
> > + packet length. If packet length is greater than the value set,
> > + ICMPv4 type 3 (Destination Unreachable) code 4 (Fragmentation
> > Needed
> > + and Don't Fragment was Set) or ICMPv6 type 2 (Packet Too Big)
> > + code 0 (no route to destination) packets will be generated.
> > +
> > + This allows for Path MTU Discovery.
> > +
> > +
> >
> >
> >
> >
>
> I had also posted a patch that was also adding this missing doc section
> [0]. But your doc text looks better in my opinion, so I'll rebase my
> patch when needed.
>
> Acked-by: Dumitru Ceara
Thanks. I applied this patch to the main branch.
Numan
>
> Thanks,
> Dumitru
>
> [0]
> http://patchwork.ozlabs.org/project/ovn/patch/20211105092049.17353-1-dce...@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] controller I-P: Add missing FDB flows when a datapath is added locally.
On Fri, Nov 26, 2021 at 8:22 AM Dumitru Ceara wrote:
>
> On 11/10/21 15:34, num...@ovn.org wrote:
> > From: Numan Siddique
> >
> > Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1983111
> > Fixes: dd94f1266ca4("northd: MAC learning: Add logical flows for fdb.")
> > Signed-off-by: Numan Siddique
> > ---
>
> Hi Numan,
>
> This patch needs a minor rebase; with that:
>
> Acked-by: Dumitru Ceara
Thanks. I rebased and applied to the main branch. I'll be
backporting to the relevant branches soon.
Numan
>
> Thanks,
> 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
