Thanks  Dumitru,

One more question:

dnl Configure the OVS flow sample collector.
ovs-vsctl --id=@br get Bridge br-int \
    -- --id=@ipfix create IPFIX targets=\"127.0.0.1:4242\" template_interval=1 \     -- --id=@cs create Flow_Sample_Collector_Set id=100 bridge=@br ipfix=@ipfix

So this would need to be done on each controller node where a VM that is affected
by the IPFIX ACL could run, right?


I don't see a reference to 'template_interval' in ovs-vsctl(8) ,  is this how often
flow records are generated?

I don't see a reference to 'Flow_Sample_Collector_Set' in ovs-vsctl(8), does:

"-id=@cs create Flow_Sample_Collector_Set id=100"

Mean that only records are generated for samples Observation Domain ID 100,
which matches  collector1 that we configured earlier:
collector1=$(ovn-nbctl create Sample_Collector id=1 name=c1 probability=65535 set_id=100)


ipfix create IPFIX targets=\"127.0.0.1:4242\"

I assume this can be any IP/port that the samples are sent to?

Thanks

Brendan


On 10/04/2025 17:23, Dumitru Ceara wrote:
On 4/10/25 4:49 PM, brendan.do...@oracle.com wrote:
Hi,

Hi Brendan,

Thanks, that is helpful, comments inline below, and I'm sure I'll have a
few more questions
As I work though it.


On 10/04/2025 13:40, Dumitru Ceara wrote:
On 4/10/25 1:10 PM, Brendan Doyle via discuss wrote:
Hi Dumitru/Adrian,

Hi Brendan,

I'm working my way through IPFIX test in system-ovn.at, just a couple of
questions.

collector1=$(ovn-nbctl create Sample_Collector id=1 name=c1
probability=65535 set_id=100)
collector2=$(ovn-nbctl create Sample_Collector id=2 name=c2
probability=65535 set_id=200)
check_row_count nb:Sample_Collector 2

check_uuid ovn-nbctl create Sampling_App type="acl-new" id="42"
check_uuid ovn-nbctl create Sampling_App type="acl-est" id="43"
check_row_count nb:Sampling_App 2

dnl Create ACLs that match the 3 types of traffic in all 3 possible
stages:
dnl from-lport, from-lport-after-lb, to-lport.
check_uuid ovn-nbctl \
      -- --id=@sample_in_1c_new create Sample collector="$collector1"
metadata=1001 \
I don't follow this syntax, it is not described in the ovn-nbctl man
page, there we just
have
ovn-nbctl --sample-new=<uuid of a row of the Sample table> acl-add

The NB.Sample table is defined as non-root in the schema.  Which means
that if there's no row in any other table that references a sample
record UUID the sample record will be automatically deleted by ovsdb-
server.

So what is 'id' above?

The --id=@var syntax tells the DB client to store the uuid-name it
generates for the "create" operation (in this case the uuid-name of the
sample it creates in the first part of the transaction it received as
argument).

Then the second part of the nbctl args (the second operation in the
transaction):

-- --sample-new=@sample_in_1c_new --sample-est=@sample_in_1c_est  \
     acl-add ls from-lport 1 "inport == \"vm1\" && udp.dst == 1000" \
     allow-related

references that (to be created) uuid-name.

The result is that ovsdb-server will (in the same transaction) create
both the sample record and the ACL that references it.
OK that helps, in theory though can these be spilt into two ovn-nbctl
calls?

Not really.

ovn-nbctl                                                              \
     -- --id=@sample_in_1c_new create Sample collector="$collector1"
metadata=1001 \
     -- --id=@sample_in_1c_est create Sample collector="$collector1"
metadata=1002

The NB.Sample table is defined as non-root (default) in the schema which
means that when processing this transaction ovsdb-server will
automatically remove the two entries it just created because they're not
referenced by any other (ACL) rows in the database.

ovn-nbctl                                                              \
     -- --sample-new=@sample_in_1c_new --sample-
est=@sample_in_1c_est              \
        acl-add ls from-lport 1 "inport == \"vm1\" && udp.dst ==
1000"             \
        allow-related

I guess you would not have access to the --id@var in this case, so you'd
have to query
the DB for it.

what is '@sample_in_1c_new' is it "42"?

This is a placeholder (uuid-name) for the to-be-allocated UUID of the
sample record that ovsdb-server will insert in the database when
processing the jsonrpc request from nbctl.

Is it required to also specify 'create Sample collector', it is not
described in the ovn-nbctl man page.

In theory you could create NB.Sample records with no collectors (the
schema allows that).  The result is that no sample is generated for
packets hitting that ACL.  Once a Sample_Collector is created and added
to the NB.Sample.collectors column of a NB.Sample record, traffic that
hits ACLs with associated Sample configs will be, well, sampled
according to the Sample_Collector configuration.  That is:
- with a given probability
- and will use the OVS.Flow_Sample_Collector_Set that has the same ID as
the NB.Sample_Collector.set_id value

      <column name="set_id">
        The 8-bit integer identifier of the set of of collectors to send
        packets to. See Flow_Sample_Collector_Set Table in ovs-vswitchd's
        database schema.
      </column>

Is '$collector1' the UUID of the Sample_Collector table row we created
with set_id=100 ?

Yes.

What is 'metadata' - Is it arbitrary?

Yes, it's arbitrary, it will be included in the actual samples generated
by the datapath.  It's stored in the sample's Observation Point ID.

Also I see in the ovn-nbctl man page, we have --sample-new and --sample-
est, but no
--sample-drop, even though the ovn-nb man pages says the 'type' in the
Sampling_App
Table can be acl-est, acl-new, or  drop

I see how this might be confusing but the idea with --sample-new and
--sample-est is to match on packets that are part of either:
- new connections (no established conntrack entry for these)
- established connections (conntrack entry in state established)

Drop ACLs drop all packets that match so the connection is always "new"
from conntrack perspective.  That's why --sample-new is used for drop
ACLs.
OK so If we had a drop acl we'd just use -sample-new=@sample_in_2c_new

Yes, exactly.

Also I note that in some cases, two collectors are specified, an in
others just one,
why is this?

We wanted to be flexible and allow configurations in which traffic that
hits ACLs is sampled to multiple sinks (they can be IPFIX collectors on
remote hosts or other types of collectors), e.g.:
- one collector (sink) towards which we send samples for every packet
- one collector towards which we only send samples every 100 packets

The system tests try to cover both types of scenarios (single collector
vs multiple collectors).

check_uuid ovn-nbctl \
     -- --id=@sample_in_1c_new create Sample collector="$collector1"
metadata=1001 \
     -- --id=@sample_in_1c_est create Sample collector="$collector1"
metadata=1002 \
     -- --sample-new=@sample_in_1c_new --sample-
est=@sample_in_1c_est              \
        acl-add ls from-lport 1 "inport == \"vm1\" && udp.dst ==
1000"             \
        allow-related
check_uuid ovn-nbctl \
     -- --id=@sample_in_2c_new create Sample collector="$collector1
$collector2" metadata=1011 \
     -- --id=@sample_in_2c_est create Sample collector="$collector1
$collector2" metadata=1012 \
     -- --sample-new=@sample_in_2c_new --sample-
est=@sample_in_2c_est                          \
        acl-add ls from-lport 1 "inport == \"vm1\" && udp.dst ==
1010"                         \
        allow-related
Thanks

Regards,
Dumitru

Thanks.

Hope this helps.

Regards,
Dumitru

On 14/02/2025 13:40, Dumitru Ceara wrote:
On 2/13/25 7:50 PM, Brendan Doyle via discuss wrote:
Hi,

Hi Brendan,

Does the ACL sampling only work for stateful ACLs?

No, it works for all kinds of ACLs.

Also how is the sample data queried?

The data is forwarded to a collector based on configuration in the
local
OVS database.  That can be an IPFIX or a local collector:

https://urldefense.com/v3/__https://github.com/openvswitch/ovs/
blob/9f7eb58f77da9fd453dbfd211eb619fdb5273416/vswitchd/
vswitch.xml*L7094-L7149__;Iw!!ACWV5N9M2RV99hQ!
NkknGGZtqABNTqs6tNdA8F21-
hcz298CHOF8mVr3GQQwXfIAMStSbj2zXFAlPif8iFdWn1hLx3_9SMDH5w$

And is there any documentation/tutorial on this that shows how to use
it?

Here's an end-to-end example from the OVN system tests.  This one uses
an IPFIX collector.

https://urldefense.com/v3/__https://github.com/ovn-org/ovn/
blob/800fd0681579a553c5d381dfcd30cc7ff1a50798/tests/system-
ovn.at*L13353-L13567__;Iw!!ACWV5N9M2RV99hQ!NkknGGZtqABNTqs6tNdA8F21-
hcz298CHOF8mVr3GQQwXfIAMStSbj2zXFAlPif8iFdWn1hLx3_edaSFdw$

The ovn-nbctl section on it is pretty minimal
That's true, maybe we should improve the documentation on this front.
In case it helps, however, here's a link to a talk Nadia, Adrian and I
did on OVS/OVN/OVN-K sampling at ovscon '24:

https://urldefense.com/v3/__https://www.openvswitch.org/support/
ovscon2024/*t19__;Iw!!ACWV5N9M2RV99hQ!NkknGGZtqABNTqs6tNdA8F21-
hcz298CHOF8mVr3GQQwXfIAMStSbj2zXFAlPif8iFdWn1hLx38pGPTlIQ$
https://urldefense.com/v3/__https://www.youtube.com/watch?
v=gLwDsaiUuN4&t=2s__;!!ACWV5N9M2RV99hQ!NkknGGZtqABNTqs6tNdA8F21-
hcz298CHOF8mVr3GQQwXfIAMStSbj2zXFAlPif8iFdWn1hLx38T5E5Pzw$

I'm not sure why the slides are not linked on the conference page
but if
you think you need them I can try to share those too.

Regards,
Dumitru

Thanks

Brendan

_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://urldefense.com/v3/__https://mail.openvswitch.org/mailman/
listinfo/ovs-discuss__;!!ACWV5N9M2RV99hQ!
KDtne_fVdgIn4CsPA7hRGOjkMoZxasqVSzJ5gcCAz8OH-dBUzRjCfXqbTTieS-
EvrZTOY3V1OcdbDVzxHg$

_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Reply via email to