So again the LS that the ACL is applied to is:
switch 94ffcab2-61be-44a1-8610-53babebb33de (ls_vcn1_net1)
port 47433b54-ac10-42f1-ae84-cc6fbb580297
addresses: ["52:54:00:be:06:16 192.16.1.6"]
port 00bff7c0-2e2d-41ba-9485-3b5fa9801365
addresses: ["52:54:00:e6:4f:46 192.16.1.5"]
port ls_vcn1_net1-lr_vcn1_net1
type: router
addresses: ["40:44:00:00:00:30"]
router-port: lr_vcn1_net1-ls_vcn1_net1
The ACL is applied with the following command:
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 1 "inport ==
\"00bff7c0-2e2d-41ba-9485-3b5fa9801365\" && tcp.dst == 19765" allow-related
We see it correctly applied:
# ovn-nbctl acl-list ls_vcn1_net1
from-lport 1 (inport == "00bff7c0-2e2d-41ba-9485-3b5fa9801365" &&
tcp.dst == 19765) allow-related
I see this in the south bound DB:
Datapath: "ls_vcn1_net1" (2469f380-8011-422d-be0d-c7540e0cfb92)
Pipeline: ingress
table=10(ls_in_acl_sample ), priority=1000 , match=(ip && ct.new &&
reg8[0..7] == 1 && reg8[19..20] == 0),
action=(sample(probability=65535,collector_set=100,obs_domain=42,obs_point=reg3);
next;)
table=10(ls_in_acl_sample ), priority=1000 , match=(ip && ct.trk &&
(ct.est || ct.rel) && ct_label.obs_unused == 0 && !ct.rpl &&
ct_mark.obs_collector_id == 1 && ct_mark.obs_stage == 0),
action=(sample(probability=65535,collector_set=100,obs_domain=43,obs_point=ct_label.obs_point_id);
next;)
table=23(ls_in_stateful ), priority=100 , match=(reg0[1] == 1 &&
reg0[13] == 1), action=(ct_commit { ct_mark.blocked = 0;
ct_mark.allow_established = reg0[20]; ct_mark.obs_stage = reg8[19..20];
ct_mark.obs_collector_id = reg8[8..15]; ct_label.obs_point_id = reg9;
ct_label.acl_id = reg2[16..31]; }; next;)
Datapath: "ls_vcn1_net1" (2469f380-8011-422d-be0d-c7540e0cfb92)
Pipeline: egress
table=7 (ls_out_acl_sample ), priority=1000 , match=(ip && ct.trk &&
(ct.est || ct.rel) && ct_label.obs_unused == 0 && ct.rpl &&
ct_mark.obs_collector_id == 1),
action=(sample(probability=65535,collector_set=100,obs_domain=43,obs_point=ct_label.obs_point_id);
next;)
table=11(ls_out_stateful ), priority=100 , match=(reg0[1] == 1 &&
reg0[13] == 1), action=(ct_commit { ct_mark.blocked = 0;
ct_mark.allow_established = reg0[20]; ct_mark.obs_stage = reg8[19..20];
ct_mark.obs_collector_id = reg8[8..15]; ct_label.obs_point_id = reg9;
ct_label.acl_id = reg2[16..31]; }; next;)
table=23(ls_in_stateful ), priority=100 , match=(reg0[1] == 1 &&
reg0[13] == 1), action=(ct_commit { ct_mark.blocked = 0;
ct_mark.allow_established = reg0[20]; ct_mark.obs_stage = reg8[19..20];
ct_mark.obs_collector_id = reg8[8..15]; ct_label.obs_point_id = reg9;
ct_label.acl_id = reg2[16..31]; }; next;)
So looks like there are southbound flows to generate Observation
Domain/Point ID's, in the OVS flows on the controller
node I see:
cookie=0x2172a502, duration=8319.465s, table=18, n_packets=2,
n_bytes=148, idle_age=1305, hard_age=1429,
priority=1000,ct_state=+new+trk,ip,reg8=0x1/0x1800ff,metadata=0x7
actions=sample(probability=65535,collector_set_id=100,obs_domain_id=704643079,obs_point_id=NXM_NX_XXREG0[0..31]),resubmit(,19)
cookie=0x2172a502, duration=8319.465s, table=18, n_packets=0,
n_bytes=0, idle_age=8319, hard_age=1429,
priority=1000,ct_state=+new+trk,ipv6,reg8=0x1/0x1800ff,metadata=0x7
actions=sample(probability=65535,collector_set_id=100,obs_domain_id=704643079,obs_point_id=NXM_NX_XXREG0[0..31]),resubmit(,19)
cookie=0x35784996, duration=8319.465s, table=18, n_packets=0,
n_bytes=0, idle_age=8319, hard_age=1429,
priority=1000,ct_state=+rel-rpl+trk,ct_mark=0x10000/0xff0030,ct_label=0/0xffffffffffffffffffffffff,ipv6,metadata=0x7
actions=sample(probability=65535,collector_set_id=100,obs_domain_id=721420295,obs_point_id=NXM_NX_CT_LABEL[96..127]),resubmit(,19)
cookie=0x35784996, duration=8319.465s, table=18, n_packets=0,
n_bytes=0, idle_age=8319, hard_age=1429,
priority=1000,ct_state=+rel-rpl+trk,ct_mark=0x10000/0xff0030,ct_label=0/0xffffffffffffffffffffffff,ip,metadata=0x7
actions=sample(probability=65535,collector_set_id=100,obs_domain_id=721420295,obs_point_id=NXM_NX_CT_LABEL[96..127]),resubmit(,19)
cookie=0x35784996, duration=8319.465s, table=18, n_packets=18,
n_bytes=1694, idle_age=1303, hard_age=1429,
priority=1000,ct_state=+est-rpl+trk,ct_mark=0x10000/0xff0030,ct_label=0/0xffffffffffffffffffffffff,ip,metadata=0x7
actions=sample(probability=65535,collector_set_id=100,obs_domain_id=721420295,obs_point_id=NXM_NX_CT_LABEL[96..127]),resubmit(,19)
cookie=0x35784996, duration=8319.465s, table=18, n_packets=0,
n_bytes=0, idle_age=8319, hard_age=1429,
priority=1000,ct_state=+est-rpl+trk,ct_mark=0x10000/0xff0030,ct_label=0/0xffffffffffffffffffffffff,ipv6,metadata=0x7
actions=sample(probability=65535,collector_set_id=100,obs_domain_id=721420295,obs_point_id=NXM_NX_CT_LABEL[96..127]),resubmit(,19)
cookie=0x56a804f, duration=8319.468s, table=54, n_packets=0,
n_bytes=0, idle_age=8319, hard_age=1429,
priority=1000,ct_state=+rel+rpl+trk,ct_mark=0x10000/0xff0000,ct_label=0/0xffffffffffffffffffffffff,ipv6,metadata=0x7
actions=sample(probability=65535,collector_set_id=100,obs_domain_id=721420295,obs_point_id=NXM_NX_CT_LABEL[96..127]),resubmit(,55)
cookie=0x56a804f, duration=8319.468s, table=54, n_packets=0,
n_bytes=0, idle_age=8319, hard_age=1429,
priority=1000,ct_state=+rel+rpl+trk,ct_mark=0x10000/0xff0000,ct_label=0/0xffffffffffffffffffffffff,ip,metadata=0x7
actions=sample(probability=65535,collector_set_id=100,obs_domain_id=721420295,obs_point_id=NXM_NX_CT_LABEL[96..127]),resubmit(,55)
cookie=0x56a804f, duration=8319.468s, table=54, n_packets=16,
n_bytes=1646, idle_age=1303, hard_age=1429,
priority=1000,ct_state=+est+rpl+trk,ct_mark=0x10000/0xff0000,ct_label=0/0xffffffffffffffffffffffff,ip,metadata=0x7
actions=sample(probability=65535,collector_set_id=100,obs_domain_id=721420295,obs_point_id=NXM_NX_CT_LABEL[96..127]),resubmit(,55)
cookie=0x56a804f, duration=8319.468s, table=54, n_packets=0,
n_bytes=0, idle_age=8319, hard_age=1429,
priority=1000,ct_state=+est+rpl+trk,ct_mark=0x10000/0xff0000,ct_label=0/0xffffffffffffffffffffffff,ipv6,metadata=0x7
actions=sample(probability=65535,collector_set_id=100,obs_domain_id=721420295,obs_point_id=NXM_NX_CT_LABEL[96..127]),resubmit(,55)
So again looks like there are flows to generate Observation Domain/Point
ID's and looks like they are being hit, we also see:
ovs-ofctl dump-ipfix-flow br-int | grep 'sampled pkts'
id 100: flows=18, current flows=0, sampled pkts=18, ipv4 ok=18, ipv6
ok=0, tx pkts=76
When I do a tcpdump on the loopback interface, I get packets like:
00:00:00.000008 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4
(0x0800), length 381: (tos 0x0, ttl 64, id 52083, offset 0, flags [DF],
proto UDP (17), length 367)
127.0.0.1.34813 > 127.0.0.1.4242: [bad udp cksum 0xff6e -> 0xc601!]
UDP, length 339
0x0000: 0000 0000 0000 0000 0000 0000 0800 4500
0x0010: 016f cb73 4000 4011 7008 7f00 0001 7f00
0x0020: 0001 87fd 1092 015b ff6e 000a 0153 68f2
0x0030: 69be 0000 0003 2b00 0007 011a 0143 0000
0x0040: 03ea 0052 5400 be06 1652 5400 e64f 4608
0x0050: 000e 0000 0017 0000 0000 0c6f 766e 2d73
0x0060: 6361 3135 2d2d 3100 0440 0600 0000 c010
0x0070: 0106 c010 0105 4d35 ead8 fdff 0206 fdff
0x0080: 0205 1161 2917 c107 0300 0007 0004 baf0
0x0090: 0004 baf0 0000 0000 0000 0001 0000 0000
0x00a0: 0000 0002 0000 0000 0000 0001 0000 0000
0x00b0: 0000 0002 0000 0000 0000 0002 0000 0000
0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000
0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000
0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000
0x00f0: 0000 004a 0000 0000 0000 0094 0200 0000
0x0100: 0000 0000 3c00 0000 0000 0000 7800 0000
0x0110: 0000 0000 3c00 0000 0000 0000 7800 0000
0x0120: 0000 000e 1000 0000 0000 001c 2000 0000
The metadata which should map to the obs point ID was 1001 which is 03ea
hex, and I see
that in the pkts always at the same offset 0x0040, so it could be that
it is being generated
by OVS, but that nfcapd does not have a template to decode it, I don't
know what the ovn/ovs
templates are.
What we see in the nfcapd logs are:
ynamically add source ident: 127-0-0-1 in directory:
/root/nfcapd/127-0-0-1/nfcapd.current.1228009
Process_ipfix: New exporter: SysID: 1, Observation domain 0 from: 127.0.0.1
Process_ipfix: New exporter: SysID: 2, Observation domain 704643079
from: 127.0.0.1
Process_ipfix: [704643079] Add template 256
Process_ipfix: [704643079] Add template 257
But the flows are always like:
{
"type" : "FLOW",
"sampled" : 0,
"export_sysid" : 2,
"t_first" : "2025-10-17T09:07:25.687",
"t_last" : "2025-10-17T09:07:25.687",
"proto" : 6,
"src4_addr" : "192.16.1.5",
"dst4_addr" : "192.16.1.6",
"src_port" : 60120,
"dst_port" : 19765,
"fwd_status" : 0,
"tcp_flags" : "........",
"src_tos" : 0,
"in_packets" : 1,
"in_bytes" : 60,
"input_snmp" : 33,
"output_snmp" : 0,
"src_mask" : 0,
"dst_mask" : 0,
"dst_tos" : 0,
"direction" : 0,
"in_src_mac" : "52:54:00:e6:4f:46",
"out_dst_mac" : "00:00:00:00:00:00",
"in_dst_mac" : "52:54:00:be:06:16",
"out_src_mac" : "00:00:00:00:00:00",
"ip4_router" : "127.0.0.1",
"t_received" : "2025-10-17T09:07:25.691",
"label" : "<none>"
}
Could it be I need a newer version of nfcapd? or I need to specify an
arg to enable
OVN/OVS templates, where would I get these templates from?
The versions I'm using are :
# nfcapd -V
nfcapd: Version: 1.6.24
# nfdump -V
nfdump: Version: NSEL-NEL1.6.24
#nfprofile -V
nfprofile: Version: 1.6.24
# nfreplay -V
nfreplay: Version: 1.6.24
Thanks
Brendan.
On 16/10/2025 16:38, Brendan Doyle via discuss wrote:
Also in the unit test we have:
ovs-vsctl --id=@br get Bridge br-int \
-- --id=@ipfix create IPFIX targets=\"127.0.0.1:4242\"
template_interval=1 \
-- --id=@cs create Flow_Sample_Collector_Set id=100 bridge=@br
ipfix=@ipfix
This uses Flow_Sample_Collector_Set id=100, I assume that this is to
match the collector
the test created earlier:
collector1=$(ovn-nbctl create Sample_Collector id=1 name=c1
probability=65535 set_id=100)
And if we also wanted data from the collector2, the test created:
collector2=$(ovn-nbctl create Sample_Collector id=2 name=c2
probability=65535 set_id=200)
We'd have to add
ovs-vsctl --id=@br get Bridge br-int \
-- --id=@ipfix create IPFIX targets=\"127.0.0.1:4242\"
template_interval=1 \
-- --id=@cs create Flow_Sample_Collector_Set id=200 bridge=@br
ipfix=@ipfix
Brendan
On 16/10/2025 12:19, Brendan Doyle via discuss wrote:
Hi,
I'm trying to use the IPFIX feature of OVN, I'm running with the
latest STS for OVS and OVN:
# ovs-vsctl -V
ovs-vsctl (Open vSwitch) 3.6.0
DB Schema 8.8.0
# ovn-nbctl -V
ovn-nbctl 25.09.0
Open vSwitch Library 3.6.0
DB Schema 7.12.0
I have recreated the unit test for IPFIX:
https://urldefense.com/v3/__https://github.com/ovn-org/ovn/blob/800fd0681579a553c5d381dfcd30cc7ff1a50798/tests/system-ovn.at*L13353-L13567__;Iw!!ACWV5N9M2RV99hQ!K9niwcmLcrVGSeoWtxcVYSl5Z9yu4JATsCn1yUQ5TwHxc0gIwicLUevSeB5187c4RNvK_XpCndTuOAnpw-p30shho8PUQA$
Except I've set it up on a live config, part of that unit test, when
checking the results is:
AT_CHECK([for f in $(ls -1 nfcapd.*); do nfdump -o json -r $f; done |
grep observationPoint
When I look at the samples I've collected, I get:
# for f in $(ls -1 nfcapd.*); do nfdump -o json -r $f; done | grep
observation
#
Nothing because there is no Observation Domain ID or Observation
Point ID in the sample, which makes it of little use as I can't
correlate the sample to thee ACL/Logical switch that it is taken
from. The samples just contain these:
{
"type" : "FLOW",
"sampled" : 0,
"export_sysid" : 1,
"t_first" : "2025-10-16T03:40:54.183",
"t_last" : "2025-10-16T03:40:54.183",
"proto" : 6,
"src4_addr" : "192.16.1.5",
"dst4_addr" : "192.16.1.6",
"src_port" : 58178,
"dst_port" : 19765,
"fwd_status" : 0,
"tcp_flags" : "........",
"src_tos" : 0,
"in_packets" : 145,
"in_bytes" : 11996,
"input_snmp" : 33,
"output_snmp" : 0,
"src_mask" : 0,
"dst_mask" : 0,
"dst_tos" : 0,
"direction" : 0,
"in_src_mac" : "52:54:00:e6:4f:46",
"out_dst_mac" : "00:00:00:00:00:00",
"in_dst_mac" : "52:54:00:be:06:16",
"out_src_mac" : "00:00:00:00:00:00",
"ip4_router" : "127.0.0.1",
"t_received" : "2025-10-16T03:40:54.186",
"label" : "<none>"
}
1) Have I setup the test case wrong (details below)?
2) Is this a bug in OVN/OVS? Is there a southbound flow, or OVS flow
that I can examine to see if an Observation domain is being
generated?
3) Is it a bug in nfdump?
Here is how I setup the test case:
On each controller node:
ovs-vsctl --id=@br get Bridge br-int -- --id=@ipfix create IPFIX
targets=\"127.0.0.1:4242\" template_interval=1 -- --id=@cs create
Flow_Sample_Collector_Set id=100 bridge=@br ipfix=@ipfix
Then the OVN central config:
export collector1=$(ovn-nbctl create Sample_Collector id=1 name=c1
probability=65535 set_id=100)
export collector2=$(ovn-nbctl create Sample_Collector id=2 name=c2
probability=65535 set_id=200)
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 list Sample_Collector
_uuid : b8e7dac8-7761-401f-92cf-8b8dfd02c84e
external_ids : {}
id : 1
name : c1
probability : 65535
set_id : 100
_uuid : bfb3679d-5d14-40c5-b31a-b294228722d8
external_ids : {}
id : 2
name : c2
probability : 65535
set_id : 200
export collector1="b8e7dac8-7761-401f-92cf-8b8dfd02c84e"
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 1 "inport ==
\"00bff7c0-2e2d-41ba-9485-3b5fa9801365\" && tcp.dst == 19765"
allow-related
# ovn-nbctl acl-list ls_vcn1_net1
from-lport 1 (inport == "00bff7c0-2e2d-41ba-9485-3b5fa9801365" &&
tcp.dst == 19765) allow-related
# ovn-nbctl list Sample
_uuid : f06aad64-ee19-49b4-a1c6-231f2f0b71a6
collectors : [b8e7dac8-7761-401f-92cf-8b8dfd02c84e]
metadata : 1002
_uuid : 1fb536ae-baf9-4c47-a3df-b064b4b4e3ce
collectors : [b8e7dac8-7761-401f-92cf-8b8dfd02c84e]
metadata : 1001
[root@sca15-rain01 v3]# ovn-nbctl list Sample_Collector
_uuid : b8e7dac8-7761-401f-92cf-8b8dfd02c84e
external_ids : {}
id : 1
name : c1
probability : 65535
set_id : 100
_uuid : bfb3679d-5d14-40c5-b31a-b294228722d8
external_ids : {}
id : 2
name : c2
probability : 65535
set_id : 200
# ovn-nbctl list Sampling_App
_uuid : fddee87c-cbed-4143-b750-7377c87a2011
external_ids : {}
id : 42
type : acl-new
_uuid : 872d6ca6-54ad-4df7-ad72-748b91ca129a
external_ids : {}
id : 44
type : drop
_uuid : 808a5722-520d-466e-b200-053c77f2b77c
external_ids : {}
id : 43
type : acl-est
I generate traffic, I get samples, but they don't contain any
Observation ID data, so I can't relate them to
what ACL generated them.
Brendan.
_______________________________________________
discuss mailing list
[email protected]
https://urldefense.com/v3/__https://mail.openvswitch.org/mailman/listinfo/ovs-discuss__;!!ACWV5N9M2RV99hQ!K9niwcmLcrVGSeoWtxcVYSl5Z9yu4JATsCn1yUQ5TwHxc0gIwicLUevSeB5187c4RNvK_XpCndTuOAnpw-p30sif6yLF7w$
_______________________________________________
discuss mailing list
[email protected]
https://urldefense.com/v3/__https://mail.openvswitch.org/mailman/listinfo/ovs-discuss__;!!ACWV5N9M2RV99hQ!NfgKSRtRKAchYzPnV-2UcNVgoamgLsthQVvExD2tyLL3vCpQUR2Tvsj1W--Mnbx4o7Hq9r2X1vZJVUgH1-kZFzO98JrEOQ$
_______________________________________________
discuss mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
