On Mon, Nov 03, 2025 at 11:23:03AM +0100, Adrián Moreno wrote: > On Fri, Oct 31, 2025 at 02:59:24PM +0100, Dumitru Ceara wrote: > > 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? > > > > > The IPFIX protocol specifies a temlate record that describes the fields > that other records contain. In OVS, we generate these templates for each > type of header combination we support. > > You can take a look at ipfix_define_template_fields() > (ofproto/ofproto-dpif-ipfix.c) for more details. It contains field > definitions such as: > > DEF(OBSERVATION_POINT_ID); > > Where each field identifier maps to a definition in the autogenerated > "ofproto/ipfix-entities.def". You'll find the number and standard name > of each field as defined by IANA in: > > https://www.iana.org/assignments/ipfix/ipfix.xhtml > > > > > > 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. > > I think this is might be a bug in nfdump. >
I reported the issue and nfdump master branch now has fixed this problem: https://github.com/phaag/nfdump/issues/642 Thanks. Adrián _______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
