On 10/24/25 6:28 PM, Brendan Doyle via discuss wrote:
>
>
> 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?
Adrian, Dumitru, do you know where these dates are coming from?
>
>
> 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"
I replied in the other thread, but for consistency:
The "drop" app is not really for ACLs, it's for sampling any drops
happening in OVN.
>
> 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
_______________________________________________
discuss mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
