diff mbox series

[ovs-dev] northd: Commit ct_label.obs_point_id for blocked connections.

Message ID 2b94713da835e9886d69511321b46518c7262c2f.1728377302.git.lorenzo.bianconi@redhat.com
State Changes Requested
Headers show
Series [ovs-dev] northd: Commit ct_label.obs_point_id for blocked connections. | expand

Checks

Context Check Description
ovsrobot/apply-robot success apply and check: success
ovsrobot/github-robot-_Build_and_Test success github build: passed
ovsrobot/github-robot-_ovn-kubernetes fail github build: failed

Commit Message

Lorenzo Bianconi Oct. 8, 2024, 8:59 a.m. UTC
Considering the following configuration:

$ovn-nbctl acl-list sw01
from-lport   100 (inport == "sw01-port1" && udp.dst == 5201) allow-related [after-lb]
from-lport    10 (inport == "sw01-port1" && udp) drop [after-lb]

$ovn-nbctl list acl
_uuid               : e440336a-84d3-4a6d-95a9-edd1db1c3631
action              : drop
direction           : from-lport
external_ids        : {}
label               : 0
log                 : false
match               : "inport == \"sw01-port1\" && udp"
meter               : []
name                : []
options             : {apply-after-lb="true"}
priority            : 10
sample_est          : ac6a6efc-a2e0-4d68-b5f8-8cd91113e554
sample_new          : 5cdad2ab-4390-4772-ac40-74aa2980c06e
severity            : []
tier                : 0

_uuid               : 85ef08d7-aacc-41d7-b808-6ab011edd753
action              : allow-related
direction           : from-lport
external_ids        : {}
label               : 0
log                 : false
match               : "inport == \"sw01-port1\" && udp.dst == 5201"
meter               : []
name                : []
options             : {apply-after-lb="true"}
priority            : 100
sample_est          : 143ce7e2-fd13-4d5e-930c-133d5cf87d0d
sample_new          : 1d1a0a05-2a8a-4c72-ad35-77d7e2908183
severity            : []
tier                : 0

If the priority-100 acl is removed, the udp traffic with destination port
5201 will be dropped however ovn-controller will continue sampling the
existing connection with the observationPointID associated to the removed
acl. Fix the issue updating the ct_label.obs_point_id for the connection
marked with ct_mark.blocked.

Fixes: d15b12da6fe6 ("northd: Add ACL Sampling.")
Repoerted-at: https://issues.redhat.com/browse/FDP-819
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>

Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
---
 northd/northd.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

Comments

Dumitru Ceara Oct. 8, 2024, 9:51 a.m. UTC | #1
On 10/8/24 10:59, Lorenzo Bianconi wrote:
> Considering the following configuration:
> 
> $ovn-nbctl acl-list sw01
> from-lport   100 (inport == "sw01-port1" && udp.dst == 5201) allow-related [after-lb]
> from-lport    10 (inport == "sw01-port1" && udp) drop [after-lb]
> 
> $ovn-nbctl list acl
> _uuid               : e440336a-84d3-4a6d-95a9-edd1db1c3631
> action              : drop
> direction           : from-lport
> external_ids        : {}
> label               : 0
> log                 : false
> match               : "inport == \"sw01-port1\" && udp"
> meter               : []
> name                : []
> options             : {apply-after-lb="true"}
> priority            : 10
> sample_est          : ac6a6efc-a2e0-4d68-b5f8-8cd91113e554
> sample_new          : 5cdad2ab-4390-4772-ac40-74aa2980c06e
> severity            : []
> tier                : 0
> 
> _uuid               : 85ef08d7-aacc-41d7-b808-6ab011edd753
> action              : allow-related
> direction           : from-lport
> external_ids        : {}
> label               : 0
> log                 : false
> match               : "inport == \"sw01-port1\" && udp.dst == 5201"
> meter               : []
> name                : []
> options             : {apply-after-lb="true"}
> priority            : 100
> sample_est          : 143ce7e2-fd13-4d5e-930c-133d5cf87d0d
> sample_new          : 1d1a0a05-2a8a-4c72-ad35-77d7e2908183
> severity            : []
> tier                : 0
> 
> If the priority-100 acl is removed, the udp traffic with destination port
> 5201 will be dropped however ovn-controller will continue sampling the
> existing connection with the observationPointID associated to the removed
> acl. Fix the issue updating the ct_label.obs_point_id for the connection
> marked with ct_mark.blocked.
> 
> Fixes: d15b12da6fe6 ("northd: Add ACL Sampling.")
> Repoerted-at: https://issues.redhat.com/browse/FDP-819
> Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
> 
> Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
> ---

Hi Lorenzo,

Could you please also add tests for these scenarios?

>  northd/northd.c | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/northd/northd.c b/northd/northd.c
> index 2c4703301..d5b9a54b2 100644
> --- a/northd/northd.c
> +++ b/northd/northd.c
> @@ -7205,7 +7205,14 @@ consider_acl(struct lflow_table *lflows, const struct ovn_datapath *od,
>          /* For drop ACLs just sample all packets as "new" packets. */
>          build_acl_sample_label_action(actions, acl, acl->sample_new, NULL,
>                                        obs_stage);
> -        ds_put_cstr(actions, "ct_commit { ct_mark.blocked = 1; }; next;");
> +        if (acl->sample_est) {
> +            ds_put_format(actions,
> +                          "ct_commit { ct_mark.blocked = 1; "
> +                          "ct_label.obs_point_id = %"PRIu32"; }; next;",
> +                          (uint32_t) acl->sample_est->metadata);
> +        } else {
> +            ds_put_cstr(actions, "ct_commit { ct_mark.blocked = 1; }; next;");
> +        }

Will this ct_commit change the value of ct_label.obs_point_id to 0?  I
guess not.  Shouldn't we explicitly do that here?  Otherwise, if the
drop ACL doesn't have sampling enabled, I'm afraid we'll still generate
samples with the stale point ID.

>          ovn_lflow_add_with_hint(lflows, od, stage, priority,
>                                  ds_cstr(match), ds_cstr(actions),
>                                  &acl->header_, lflow_ref);

Regards,
Dumitru
Adrián Moreno Oct. 8, 2024, 11:16 a.m. UTC | #2
On Tue, Oct 08, 2024 at 11:51:54AM GMT, Dumitru Ceara wrote:
> On 10/8/24 10:59, Lorenzo Bianconi wrote:
> > Considering the following configuration:
> >
> > $ovn-nbctl acl-list sw01
> > from-lport   100 (inport == "sw01-port1" && udp.dst == 5201) allow-related [after-lb]
> > from-lport    10 (inport == "sw01-port1" && udp) drop [after-lb]
> >
> > $ovn-nbctl list acl
> > _uuid               : e440336a-84d3-4a6d-95a9-edd1db1c3631
> > action              : drop
> > direction           : from-lport
> > external_ids        : {}
> > label               : 0
> > log                 : false
> > match               : "inport == \"sw01-port1\" && udp"
> > meter               : []
> > name                : []
> > options             : {apply-after-lb="true"}
> > priority            : 10
> > sample_est          : ac6a6efc-a2e0-4d68-b5f8-8cd91113e554
> > sample_new          : 5cdad2ab-4390-4772-ac40-74aa2980c06e
> > severity            : []
> > tier                : 0
> >
> > _uuid               : 85ef08d7-aacc-41d7-b808-6ab011edd753
> > action              : allow-related
> > direction           : from-lport
> > external_ids        : {}
> > label               : 0
> > log                 : false
> > match               : "inport == \"sw01-port1\" && udp.dst == 5201"
> > meter               : []
> > name                : []
> > options             : {apply-after-lb="true"}
> > priority            : 100
> > sample_est          : 143ce7e2-fd13-4d5e-930c-133d5cf87d0d
> > sample_new          : 1d1a0a05-2a8a-4c72-ad35-77d7e2908183
> > severity            : []
> > tier                : 0
> >
> > If the priority-100 acl is removed, the udp traffic with destination port
> > 5201 will be dropped however ovn-controller will continue sampling the
> > existing connection with the observationPointID associated to the removed
> > acl. Fix the issue updating the ct_label.obs_point_id for the connection
> > marked with ct_mark.blocked.
> >
> > Fixes: d15b12da6fe6 ("northd: Add ACL Sampling.")
> > Repoerted-at: https://issues.redhat.com/browse/FDP-819

small typo: s/Repoerted-at/Reported-at/

> > Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
> >
> > Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
> > ---
>
> Hi Lorenzo,
>
> Could you please also add tests for these scenarios?
>
> >  northd/northd.c | 9 ++++++++-
> >  1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/northd/northd.c b/northd/northd.c
> > index 2c4703301..d5b9a54b2 100644
> > --- a/northd/northd.c
> > +++ b/northd/northd.c
> > @@ -7205,7 +7205,14 @@ consider_acl(struct lflow_table *lflows, const struct ovn_datapath *od,
> >          /* For drop ACLs just sample all packets as "new" packets. */
> >          build_acl_sample_label_action(actions, acl, acl->sample_new, NULL,
> >                                        obs_stage);
> > -        ds_put_cstr(actions, "ct_commit { ct_mark.blocked = 1; }; next;");
> > +        if (acl->sample_est) {
> > +            ds_put_format(actions,
> > +                          "ct_commit { ct_mark.blocked = 1; "
> > +                          "ct_label.obs_point_id = %"PRIu32"; }; next;",
> > +                          (uint32_t) acl->sample_est->metadata);
> > +        } else {
> > +            ds_put_cstr(actions, "ct_commit { ct_mark.blocked = 1; }; next;");
> > +        }
>
> Will this ct_commit change the value of ct_label.obs_point_id to 0?  I
> guess not.  Shouldn't we explicitly do that here?  Otherwise, if the
> drop ACL doesn't have sampling enabled, I'm afraid we'll still generate
> samples with the stale point ID.
>

Maybe a stupid question:
A zero obs_point_id (zero label) is still a valid one from OVS's pov
(probably not for the reader), right? If we cannot avoid emitting the
sample based on the mark, how would we know if the label should be
used or not?

Thanks.
Adrián

> >          ovn_lflow_add_with_hint(lflows, od, stage, priority,
> >                                  ds_cstr(match), ds_cstr(actions),
> >                                  &acl->header_, lflow_ref);
>
> Regards,
> Dumitru
>
Dumitru Ceara Oct. 8, 2024, 11:30 a.m. UTC | #3
On 10/8/24 13:16, Adrián Moreno wrote:
> On Tue, Oct 08, 2024 at 11:51:54AM GMT, Dumitru Ceara wrote:
>> On 10/8/24 10:59, Lorenzo Bianconi wrote:
>>> Considering the following configuration:
>>>
>>> $ovn-nbctl acl-list sw01
>>> from-lport   100 (inport == "sw01-port1" && udp.dst == 5201) allow-related [after-lb]
>>> from-lport    10 (inport == "sw01-port1" && udp) drop [after-lb]
>>>
>>> $ovn-nbctl list acl
>>> _uuid               : e440336a-84d3-4a6d-95a9-edd1db1c3631
>>> action              : drop
>>> direction           : from-lport
>>> external_ids        : {}
>>> label               : 0
>>> log                 : false
>>> match               : "inport == \"sw01-port1\" && udp"
>>> meter               : []
>>> name                : []
>>> options             : {apply-after-lb="true"}
>>> priority            : 10
>>> sample_est          : ac6a6efc-a2e0-4d68-b5f8-8cd91113e554
>>> sample_new          : 5cdad2ab-4390-4772-ac40-74aa2980c06e
>>> severity            : []
>>> tier                : 0
>>>
>>> _uuid               : 85ef08d7-aacc-41d7-b808-6ab011edd753
>>> action              : allow-related
>>> direction           : from-lport
>>> external_ids        : {}
>>> label               : 0
>>> log                 : false
>>> match               : "inport == \"sw01-port1\" && udp.dst == 5201"
>>> meter               : []
>>> name                : []
>>> options             : {apply-after-lb="true"}
>>> priority            : 100
>>> sample_est          : 143ce7e2-fd13-4d5e-930c-133d5cf87d0d
>>> sample_new          : 1d1a0a05-2a8a-4c72-ad35-77d7e2908183
>>> severity            : []
>>> tier                : 0
>>>
>>> If the priority-100 acl is removed, the udp traffic with destination port
>>> 5201 will be dropped however ovn-controller will continue sampling the
>>> existing connection with the observationPointID associated to the removed
>>> acl. Fix the issue updating the ct_label.obs_point_id for the connection
>>> marked with ct_mark.blocked.
>>>
>>> Fixes: d15b12da6fe6 ("northd: Add ACL Sampling.")
>>> Repoerted-at: https://issues.redhat.com/browse/FDP-819
> 
> small typo: s/Repoerted-at/Reported-at/
> 
>>> Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
>>>
>>> Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
>>> ---
>>
>> Hi Lorenzo,
>>
>> Could you please also add tests for these scenarios?
>>
>>>  northd/northd.c | 9 ++++++++-
>>>  1 file changed, 8 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/northd/northd.c b/northd/northd.c
>>> index 2c4703301..d5b9a54b2 100644
>>> --- a/northd/northd.c
>>> +++ b/northd/northd.c
>>> @@ -7205,7 +7205,14 @@ consider_acl(struct lflow_table *lflows, const struct ovn_datapath *od,
>>>          /* For drop ACLs just sample all packets as "new" packets. */
>>>          build_acl_sample_label_action(actions, acl, acl->sample_new, NULL,
>>>                                        obs_stage);
>>> -        ds_put_cstr(actions, "ct_commit { ct_mark.blocked = 1; }; next;");
>>> +        if (acl->sample_est) {
>>> +            ds_put_format(actions,
>>> +                          "ct_commit { ct_mark.blocked = 1; "
>>> +                          "ct_label.obs_point_id = %"PRIu32"; }; next;",
>>> +                          (uint32_t) acl->sample_est->metadata);
>>> +        } else {
>>> +            ds_put_cstr(actions, "ct_commit { ct_mark.blocked = 1; }; next;");
>>> +        }
>>
>> Will this ct_commit change the value of ct_label.obs_point_id to 0?  I
>> guess not.  Shouldn't we explicitly do that here?  Otherwise, if the
>> drop ACL doesn't have sampling enabled, I'm afraid we'll still generate
>> samples with the stale point ID.
>>
> 
> Maybe a stupid question:
> A zero obs_point_id (zero label) is still a valid one from OVS's pov
> (probably not for the reader), right? If we cannot avoid emitting the

0 is not a valid sample ID (obs_point_id) from OVN's perspective.  From
ovn-nb.ovsschema:

                "metadata": {"type": {"key": {"type": "integer",
                                              "minInteger": 1,
                                              "maxInteger": 4294967295},
                                      "min": 1, "max":1}}

> sample based on the mark, how would we know if the label should be
> used or not?
> 

I'm not sure I follow this part.  ct_mark.blocked doesn't decide whether
a sample should be generated or not.  It only is used to "tag" sessions
that used to be allowed and now are not anymore (the ACL that used to
allow them was removed).

From a sampling perspective, after the original ACL is removed we need
to either:

a. sample with the drop ACL configured sample ID, if that's non-zero
b. don't sample, if the drop ACL doesn't have sampling configured

Regards,
Dumitru
diff mbox series

Patch

diff --git a/northd/northd.c b/northd/northd.c
index 2c4703301..d5b9a54b2 100644
--- a/northd/northd.c
+++ b/northd/northd.c
@@ -7205,7 +7205,14 @@  consider_acl(struct lflow_table *lflows, const struct ovn_datapath *od,
         /* For drop ACLs just sample all packets as "new" packets. */
         build_acl_sample_label_action(actions, acl, acl->sample_new, NULL,
                                       obs_stage);
-        ds_put_cstr(actions, "ct_commit { ct_mark.blocked = 1; }; next;");
+        if (acl->sample_est) {
+            ds_put_format(actions,
+                          "ct_commit { ct_mark.blocked = 1; "
+                          "ct_label.obs_point_id = %"PRIu32"; }; next;",
+                          (uint32_t) acl->sample_est->metadata);
+        } else {
+            ds_put_cstr(actions, "ct_commit { ct_mark.blocked = 1; }; next;");
+        }
         ovn_lflow_add_with_hint(lflows, od, stage, priority,
                                 ds_cstr(match), ds_cstr(actions),
                                 &acl->header_, lflow_ref);