Hi Brendan, Ilya, On 10/31/25 2:30 PM, Ilya Maximets wrote: > 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? >
It seems nfdump dumps them here: https://github.com/phaag/nfdump/blob/c3f5e39e6cc41e0749e91afdc2e294578c4eaa6d/src/output/output_json.c#L126-L148 I think "first" and "last" are taken from the msecEvent field here: https://github.com/phaag/nfdump/blob/c3f5e39e6cc41e0749e91afdc2e294578c4eaa6d/src/libnffile/nfxV3.h#L412 typedef struct EXnselCommon_s { #define EXnselCommonID 19 uint64_t msecEvent; // NF_F_EVENT_TIME_MSEC(323) uint32_t connID; // NF_F_CONN_ID(148) uint16_t fwXevent; // NF_F_FW_EXT_EVENT(33002) uint8_t fwEvent; // NF_F_FW_EVENT(233), NF_F_FW_EVENT_84(40005) uint8_t fill; But I couldn't figure out if that's based on a packet field or not, I suspect not. >> >> >> 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. > That's correct, thanks for clarifying this, Ilya! Regards, Dumitru >> >> 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
