Dear Adrián,
Thank you for your response. I’ve applied your suggestion to use separate
sample entries for each ACL. However, I am still seeing unexpected behavior
in the IPFIX output that I’d like to clarify.
Test Setup (Same as Before)
vm_a ---- network1 ---- router ---- network2 ---- vm_b
-
Two ACLs:
-
ACL A: allow-related *outbound* IPv4
-
ACL B: allow-related *inbound* ICMP
-
ACLs applied symmetrically to both VMs.
-
Test traffic: ICMP request from vm_b to vm_a, and reply from vm_a to vm_b
.
Key Problem Observed
When sampling is enabled on *both* ACLs, the IPFIX record for *flow (3)*
(the ICMP reply from vm_a → router) shows *120 packets/min*.
However:
-
If *only ACL B* (inbound ICMP) is sampled → (3) = 60 packets/min
-
If *only ACL A* (outbound IP4) is sampled → (3) not present
-
If both are sampled → (3) = 120 packets/min
This suggests that *flow (3) is being sampled twice* — even though it
represents a *single logical flow and matches only ACL B*.
IPFIX Observations
FlowDescriptionExpectedActual
(1) vm_b → router (ICMP request) 60 pkt/m 60
(2) router → vm_a (ICMP request) 60 pkt/m 60
(3) vm_a → router (ICMP reply) 60 pkt/m 120 ⚠️
(4) router → vm_b (ICMP reply) 60 pkt/m 60
Hypothesis
It appears that sampling action on ACL B are matching datapath flow for
direction (3)* twice*, resulting in duplicate sample actions and duplicated
IPFIX records.
I would expect ACL B to apply sampling only once.
Verification Steps
I. Sampling only ACL B (inbound ICMP) → flow (3) = 60 pkt/min
II. Sampling only ACL A (outbound IP4) → flow (3) not sampled
III. Sampling both A + B → flow (3) = 120 pkt/min
=> This suggests that *flow (3)* is counted *twice* when both ACLs are
active.
Request for Clarification
-
Is this duplication expected?
-
If yes, is there a best-practice to avoid sampling a single flow
multiple times when applying ACLs on both ingress and egress?
-
Could this be a bug in ovn-controller flow generation logic?
I have attached the full ACL/sample configs and IPFIX records for reference.
Both VMs are located on the *same compute node*, which might affect
recirculation or match behavior.
Best regards,
*Oscar*
On Mon, May 5, 2025 at 6:57 PM Adrián Moreno <amore...@redhat.com> wrote:
> On Tue, Apr 29, 2025 at 11:29:57AM +0700, Trọng Đạt Trần via discuss wrote:
> > Summary
> >
> > In an OpenStack deployment using Neutron with OVN as the backend, I
> > observed that enabling sampling on ACLs appears to create duplicated
> > sampling actions for certain OpenFlow datapath flows, resulting in
> > duplicated IPFIX records. This may indicate that ovn-controller is
> > installing redundant sampled flows.
> > Test Topology
> >
> > vm_a ---- network1 ---- router ---- network2 ---- vm_b
> >
> >
> > -
> >
> > OpenStack Neutron with OVN backend.
> > -
> >
> > Testing with ICMP traffic (but TCP shows the same behavior).
> > -
> >
> > Two ACLs: one allowing related outbound IPv4 traffic and one allowing
> > related inbound ICMP traffic.
> > -
> >
> > Security groups (containing the two ACLs) applied symmetrically to
> both
> > VMs.
> > -
> >
> > ACL correctness has been verified separately.
> >
> > Problem Description
> >
> > -
> >
> > When sampling is enabled on both the inbound ICMP rule and the
> outbound
> > IPv4 rule, the same OpenFlow flow (0x3d62e572) appears twice, leading
> to
> > duplicated IPFIX records.
>
> From flow dumps, I don't see an OpenFlow duplication, quoting from
> below:
>
> > cookie=0x3d62e572, duration=6.139s, table=50, n_packets=5, n_bytes=490,
> idle_age=0,
> priority=1000,ct_state=+est+rpl+trk,ct_mark=0x20000/0xff0000,ct_label=0/0xffffffffffffffffffffffff,ip,metadata=0x11
> actions=sample(probability=65535,collector_set_id=2,obs_domain_id=33554449,obs_point_id=NXM_NX_CT_LABEL[96..127]),resubmit(,51)
> > cookie=0x3d62e572, duration=6.139s, table=50, n_packets=3, n_bytes=294,
> idle_age=0,
> priority=1000,ct_state=+est+rpl+trk,ct_mark=0x20000/0xff0000,ct_label=0/0xffffffffffffffffffffffff,ip,metadata=0x12
> actions=sample(probability=65535,collector_set_id=2,obs_domain_id=33554450,obs_point_id=NXM_NX_CT_LABEL[96..127]),resubmit(,51)
>
> They match on different metadata values, each of them probably
> indicating the sampling direction.
>
>
> > -
> >
> > Dumping flows with ovs-dpctl dump-flows system@ovs-system shows
> > duplicated flow_sample actions on some flows.
> >
> >
> *"recirc_id(0x6b9d),in_port(9),ct_state(-new+est-rel+rpl-inv+trk),ct_mark(0x20020/0xff0031),ct_label(0x1c8000000000000000000000000),eth(src=fa:16:3e:01:f9:9f,dst=fa:16:3e:05:9c:9a),eth_type(0x0800),ipv4(src=10.2.1.171,dst=10.2.2.88,proto=1,ttl=64,frag=no),
> > packets:3298, bytes:323204, used:0.277s,
> >
> actions:userspace(pid=4294967295,flow_sample(probability=65535,collector_set_id=2,obs_domain_id=33554449,obs_point_id=456,output_port=4294967295)),userspace(pid=4294967295,flow_sample(probability=65535,collector_set_id=2,obs_domain_id=33554449,obs_point_id=456,output_port=4294967295)),ct_clear,set(eth(src=fa:16:3e:37:38:47,dst=fa:16:3e:b0:69:d3)),set(ipv4(ttl=63)),ct(zone=23),recirc(0x6b9e)"*
> >
> > -
> >
> > This behavior does not occur when sampling is applied to only one
> > direction (either inbound or outbound).
> >
> > Verification Steps
> >
> > 1.
> >
> > *Sampling only inbound ICMP ACL*
> > → Flows sampled once as expected.
> > 2.
> >
> > *Sampling both inbound ICMP and outbound IPv4 ACLs*
> > → Certain OpenFlow flows are installed twice with sampling, suggesting
> > duplication.
> > 3.
> >
> > *Sampling only outbound IPv4 ACL*
> > → No duplication observed.
> >
> > (Example OpenFlow outputs and logical_flow outputs included below.)
> > Observations
> >
> >
> > -
> >
> > The same cookie (e.g., 0x3d62e572) shows up multiple times when both
> > sampling rules are active.
>
>
> As mentioned above, I don't think this is an issue. A single logical
> flow (cookie) can generate multiple flows.
>
>
> > [...]
> >
> > Request for Clarification
> >
> > Based on the above, I would like to ask:
> >
> > -
> >
> > Is this duplicated sampling behavior expected when both inbound and
> > outbound ACLs sample?
> > -
>
> From what you post below, you have only configured a single entry in the
> Sample table.
>
>
> > (ovn-nb-db)[root@site2-osp-controller-01-2024 /]# ovn-nbctl
> --no-leader-only list sample
> > _uuid : 49d84040-1081-430a-be1b-a8dfbcbf6fe6
> > collectors : [60407201-e6db-4719-9908-ea0dc53c64e4]
> > metadata : 456
>
> The output of the "ACL" table is not listed but I assume you configured
> both ACLs to use the same entry in the Sample table.
>
> Since both ACLs are matched, generating a duplicated samples is expected.
> One is saying that it matched the ingress ACL and the other says it matched
> the egress one.
>
> ACL sampling uses per-flow sampling and when two OFP flows are matched,
> their actions are not magically "de-duplicated".
>
> >
> > If not expected, could this indicate a bug in how ovn-controller
> > generates OpenFlow rules under overlapping ACL sampling?
> > -
> >
> > Are there any known workarounds?
>
> If you want to distinguish both, you can create a new entry in the
> Sample table with a different metadata value and link each ACL to a
> different
> Sample entry.
>
> Thanks.
> Adrián
>
>
=============================== ACL ALLOW-REL INBOUND ICMP && OUTBOUND IP4
===============================
(ovn-nb-db)[root@site2-osp-controller-01-2024 /]# ovn-nbctl --no-leader-only
list acl 960fba5a-160f-4c89-a397-32459faae38d
_uuid : 960fba5a-160f-4c89-a397-32459faae38d
action : allow-related
direction : to-lport
external_ids :
{"neutron:security_group_rule_id"="8138e214-f7c0-487a-b91b-0824c26b2002"}
label : 0
log : false
match : "outport == @pg_ad579651_c29c_462a_a4ac_7bce9082b645 &&
ip4 && ip4.src == 0.0.0.0/0 && icmp4"
meter : []
name : []
options : {}
priority : 1002
sample_est : 49d84040-1081-430a-be1b-a8dfbcbf6fe6
sample_new : []
severity : []
tier : 0
(ovn-nb-db)[root@site2-osp-controller-01-2024 /]# ovn-nbctl --no-leader-only
list acl 145084fe-feb3-4967-822d-2d3104015fbf
_uuid : 145084fe-feb3-4967-822d-2d3104015fbf
action : allow-related
direction : from-lport
external_ids :
{"neutron:security_group_rule_id"="38e48a61-7e12-4f72-ab15-669e9b163876"}
label : 0
log : false
match : "inport == @pg_ad579651_c29c_462a_a4ac_7bce9082b645 &&
ip4"
meter : []
name : []
options : {}
priority : 1002
sample_est : 8af5443f-4142-4414-9381-769a5ab3b6d2
sample_new : []
severity : []
tier : 0
=============================== SAMPLE && SAMPLE_COLLECTOR && SAMPLING_APP
TABLE ===============================
(ovn-nb-db)[root@site2-osp-controller-01-2024 /]# ovn-nbctl list sample
_uuid : 49d84040-1081-430a-be1b-a8dfbcbf6fe6
collectors : [60407201-e6db-4719-9908-ea0dc53c64e4]
metadata : 1000000
_uuid : 8af5443f-4142-4414-9381-769a5ab3b6d2
collectors : [60407201-e6db-4719-9908-ea0dc53c64e4]
metadata : 2000000
(ovn-nb-db)[root@site2-osp-controller-01-2024 /]# ovn-nbctl list
sample_collector
_uuid : 60407201-e6db-4719-9908-ea0dc53c64e4
external_ids : {}
id : 2
name : prob-100-sample-collector
probability : 65535
set_id : 2
(ovn-nb-db)[root@site2-osp-controller-01-2024 /]# ovn-nbctl list sampling_app
_uuid : f5bcf2ad-76f9-4708-819b-1326f1857899
external_ids : {}
id : 1
type : acl-new
_uuid : 3f140431-20d5-4656-bb27-752b38444b20
external_ids : {}
id : 3
type : drop
_uuid : cf01a57b-16e7-445e-a863-5cb5161b399b
external_ids : {}
id : 2
type : acl-est
=============================== Actual Result from Test environment:
===============================
(1) vm_b → router (ICMP request) 60 pkt/m
SRC_MAC: fa:16:3e:b0:69:d3, DST_MAC: fa:16:3e:37:38:47, SRC_IP:
10.2.2.88, DST_IP: 10.2.1.171, packets: 60, obs_point_id: 2000000
(2) router → vm_a (ICMP request) 60 pkt/m
SRC_MAC: fa:16:3e:05:9c:9a , DST_MAC: fa:16:3e:01:f9:9f,
SRC_IP: 10.2.2.88, DST_IP: 10.2.1.171, packets: 60, obs_point_id: 1000000
(3) vm_a → router (ICMP reply) 120 pkt/m ### Why does this
flow get 120 packets / min?
SRC_MAC: fa:16:3e:01:f9:9f, DST_MAC: fa:16:3e:05:9c:9a, SRC_IP:
10.2.1.171, DST_IP: 10.2.2.88, packets: 120, obs_point_id: 1000000
(4) router → vm_b (ICMP reply) 60 pkt/m
SRC_MAC: fa:16:3e:37:38:47, DST_MAC: fa:16:3e:b0:69:d3, SRC_IP:
10.2.1.171, DST_IP: 10.2.2.88, packets: 60, obs_point_id: 2000000
=============================== Steps to verify my expectation:
===============================
I. Enable sampling only on acl INBOUND ICMP. IPFIX result shows there are two
flows being sampled:
(2) router → vm_a (ICMP request) 60 pkt/m
SRC_MAC: fa:16:3e:05:9c:9a , DST_MAC: fa:16:3e:01:f9:9f,
SRC_IP: 10.2.2.88, DST_IP: 10.2.1.171, packets: 60, obs_point_id: 1000000
(3) vm_a → router (ICMP reply) 60 pkt/m
SRC_MAC: fa:16:3e:01:f9:9f, DST_MAC: fa:16:3e:05:9c:9a, SRC_IP:
10.2.1.171, DST_IP: 10.2.2.88, packets: 60, obs_point_id: 1000000
-> The other two flows (1) and (4) are not sampled because they matches
the acl OUTBOUND IP4 (stateful) which currently is not configured to sample.
II. Enable sampling only on acl OUTBOUND IP4. IPFIX result shows there are two
flows being sampled:
(1) vm_b → router (ICMP request) 60 pkt/m
SRC_MAC: fa:16:3e:b0:69:d3, DST_MAC: fa:16:3e:37:38:47, SRC_IP:
10.2.2.88, DST_IP: 10.2.1.171, packets: 60, obs_point_id: 2000000
(4) router → vm_b (ICMP reply) 60 pkt/m
SRC_MAC: fa:16:3e:37:38:47, DST_MAC: fa:16:3e:b0:69:d3, SRC_IP:
10.2.1.171, DST_IP: 10.2.2.88, packets: 60, obs_point_id: 2000000
-> The other two flows (2) and (3) are not sampled because they matches
the stateful acl INBOUND ICMP (stateful) which currently is not configured to
sample.
---> When enable both (I) and (II), should my first expectation of the IPFIX
result be reasonable? Where it should be 4 flows (1), (2), (3) and (4), each 60
packets per min, not the (3) 120 packets per min?
_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
