On 24/10/2025 12:34, Ilya Maximets wrote:
On 10/22/25 5:08 PM, Brendan Doyle via discuss wrote:
Hi,
So I'm experimenting with this feature, I have a simple config:
#ovn-nbctl acl-list ls_vcn1_net1
from-lport 14000 (inport == "00bff7c0-2e2d-41ba-9485-3b5fa9801365" &&
(icmp4.type == 8 || icmp4.type == 0)) allow-related
from-lport 0 (inport == "00bff7c0-2e2d-41ba-9485-3b5fa9801365") drop
to-lport 14000 (outport == "00bff7c0-2e2d-41ba-9485-3b5fa9801365" &&
(icmp4.type == 8 || icmp4.type == 0)) allow-related
to-lport 0 (outport == "00bff7c0-2e2d-41ba-9485-3b5fa9801365") drop
I have sampling enabled on the ICMP:
collector1=$(ovn-nbctl create Sample_Collector id=1 name=c1 probability=65535
set_id=100)
ovn-nbctl create Sampling_App type="acl-new" id="42"
ovn-nbctl create Sampling_App type="acl-est" id="43"
ovn-nbctl create Sampling_App type="drop" id="44"
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_vcn1_net1 from-lport 14000 "inport == \"00bff7c0-2e2d-41ba-9485-3b5fa9801365\"
&& (icmp4.type == 8 || icmp4.type == 0)" allow-related
ovn-nbctl acl-add ls_vcn1_net1 from-lport 0 "inport ==
\"00bff7c0-2e2d-41ba-9485-3b5fa9801365\"" drop
ovn-nbctl \
-- --id=@sample_in_1c_new create Sample collector="$collector1" metadata=1003 \
-- --id=@sample_in_1c_est create Sample collector="$collector1" metadata=1004 \
-- --sample-new=@sample_in_1c_new --sample-est=@sample_in_1c_est \
acl-add ls_vcn1_net1 to-lport 14000 "outport == \"00bff7c0-2e2d-41ba-9485-3b5fa9801365\"
&& (icmp4.type == 8 || icmp4.type == 0)" allow-related
ovn-nbctl acl-add ls_vcn1_net1 to-lport 0 "outport ==
\"00bff7c0-2e2d-41ba-9485-3b5fa9801365\"" drop
I generate some traffic:
# ping -c 10 192.16.1.6
PING 192.16.1.6 (192.16.1.6) 56(84) bytes of data.
64 bytes from 192.16.1.6: icmp_seq=1 ttl=64 time=3.13 ms
64 bytes from 192.16.1.6: icmp_seq=2 ttl=64 time=1.59 ms
64 bytes from 192.16.1.6: icmp_seq=3 ttl=64 time=0.982 ms
64 bytes from 192.16.1.6: icmp_seq=4 ttl=64 time=1.27 ms
64 bytes from 192.16.1.6: icmp_seq=5 ttl=64 time=1.08 ms
64 bytes from 192.16.1.6: icmp_seq=6 ttl=64 time=1.00 ms
64 bytes from 192.16.1.6: icmp_seq=7 ttl=64 time=0.990 ms
64 bytes from 192.16.1.6: icmp_seq=8 ttl=64 time=1.37 ms
64 bytes from 192.16.1.6: icmp_seq=9 ttl=64 time=1.03 ms
--- 192.16.1.6 ping statistics ---
10 packets transmitted, 9 received, 10% packet loss, time 9012ms
rtt min/avg/max/mdev = 0.982/1.386/3.131/0.649 ms
So I expect a total of 9 pkts and 576 bytes.
But looking at the samples generated seems like OVN/OVS is reporting Total
packets
received = *543, *Total bytes received = *44,340* bytes!!!
"in_packets" and "in_bytes" are accumulative stats for the ipfix exporter.
You got 18 samples - 9 for requests and 9 for replies, as expected.
"in_packets" went from 38 on the first sample to 55 on the last also showing
that there were 18 packets (55 - 38 + 1 = 18). The number was initially 38,
probably because you had some other traffic that went through the observation
points before the collector (nfcapd) was started.
Note: the reason for the stats to be accumulative is that they show the
total number of packets that went through the observation points, even
when the sampling rate is not 100%. i.e. if your sampling rate was 50%,
then you should've received only about 9 samples, but the stats in those
samples would still account for 18, if I'm not mistaken.
Best regards, Ilya Maximets.
Ok, I was hoping it was that, in that case bytes make more sense, as far as
I'm aware I did not start traffic before the obs point was up, but as
long as this
is cumulative that's OK.
I'm curious about these dates:
"cnt" : 1,
"type" : "FLOW",
"ident" : "253-255-2-5",
"export_sysid" : 2,
"first" : "1969-12-31T19:04:22.000",
"last" : "1969-12-31T19:04:22.000",
Seems vaguely close to Unix epoch, and if converted to epoch seconds would
be negative, though I see for the last entry:
"cnt" : 18,
"type" : "FLOW",
"ident" : "253-255-2-5",
"export_sysid" : 3,
"first" : "1969-12-31T19:04:11.000",
"last" : "1969-12-31T19:04:11.000",
Less negative from epoch so time increasing, but what do these dates
represent?
In fact is there a template definition that explains each of the fields?
One other thing I'm curious about is how the Sampling_App relates to
Sample_Collector.
In the unit test I see:
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_uuid ovn-nbctl create Sampling_App type="acl-new" id="42"
check_uuid ovn-nbctl create Sampling_App type="acl-est" id="43"
And then:
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
But If I wanted to add and sample a drop rule, like:
check_uuid ovn-nbctl \
-- --id=@sample_in_1c_new create Sample collector="$collector1"
metadata=1003 \
-- --sample-new=@sample_in_1c_new --sample-est=@sample_in_1c_est
\
acl-add ls from-lport 0 "inport == \"vm1\" " drop
Would I also need to create a Sampling_App like:
ovn-nbctl create Sampling_App type="drop" id="44"
Thanks
Brendan
Here is the dump of the generated samples:
# for f in $(ls -1 nfcapd.*); do nfdump -o json -r $f; done
[
{
"cnt" : 1,
"in_packets" : 38,
"in_bytes" : 3172,
"src4_addr" : "192.16.1.5",
"dst4_addr" : "192.16.1.6",
"observationDomainID" : 704643079,
"observationPointID" : 1001,
},
<snip>
{
"cnt" : 18,
"in_packets" : 55,
"in_bytes" : 4600,
"src4_addr" : "192.16.1.6",
"dst4_addr" : "192.16.1.5",
"observationDomainID" : 721420295,
"observationPointID" : 1002,
}
]
_______________________________________________
discuss mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
