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.
OVS does not send the absolute timestamp (element 323), but the relative
timestamp in microseconds (element 158, flowStartDeltaMicroseconds).
Quoting IANA:
"""
This is a relative timestamp only valid within the scope of a single
IPFIX Message. It contains the negative time offset of the first observed
packet of this Flow relative to the export time specified in the
IPFIX Message Header.
"""
So it seems nfdump is interpreting the relative offset as an absolute
time.
Note this has nothing to do with per-flow sampling or OVN configuration.
Per-bridge sampling uses the same mechanism to timestamp IPFIX records.
Thanks.
>
> >>
> >>
> >> 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
