Repository: openshift/openshift-docs
Pull request #92375: OSDOCS-14366 Additional context about the multi-flow filtering capability, updated yaml
Author: login: gwynnemonahan
Labels: name: peer-review-done
description: Signifies that the peer review team has reviewed this PR
name: size/L
description: Denotes a PR that changes 100-499 lines, ignoring generated files.
name: qe-approved
description: Signifies that QE has signed off on this PR
Created: 2025-04-18T17:01:23Z | Merged: 2025-05-14T18:33:36Z

[OSDOCS-14366](https://issues.redhat.com//browse/OSDOCS-14366) [NETOBSERV] Additional context concept about the multi-flow filtering capability

<!--- PR title format: [GH#<gh-issue-id>][BZ#<bz-issue-id>][OCPBUGS#<jira-issue-id>][OSDOCS#<jira-issue-id>]: <short-description-of-the-pr> --->

<!--- If your changes apply to the latest release and/or in-development version of OpenShift, open your PR against the `main` branch.
Do not create or rename a top-level directory (or any subdirectory in a directory that contains a hugebook.flag file) in the repository and topic map without checking with a docs program manager first.
If a book is being created or modified, there are changes on the Customer Portal that must also be made.

* For more details about the information requested in this template, see:
  https://github.com/openshift/openshift-docs/blob/main/contributing_to_docs/create_or_edit_content.adoc#submit-PR --->

Version(s):
Merge to only the `no-1.9` branch - no cherrypicks are required.
I will open one PR against main to incorporate all of the NetObserv content just before its GA.

Cherry-pick to OCP 4.12, 4.14, 4.16+

Issue:
https://issues.redhat.com/browse/OSDOCS-14366

Link to docs preview:

* eBPF flow rule filter: https://92375--ocpdocs-pr.netlify.app/openshift-enterprise/latest/observability/network_observability/observing-network-traffic.html#network-observability-ebpf-flow-rule-filter_nw-observe-network-traffic

* Filtering eBPF flow data using multiple rules: https://92375--ocpdocs-pr.netlify.app/openshift-enterprise/latest/observability/network_observability/observing-network-traffic.html#network-observability-filtering-ebpf-rule_nw-observe-network-traffic

SME: @memodi 
QE review: @Amoghrd 
- [x] QE has approved this change.
<!--- QE approval is required to merge a PR except for changes that do not impact the meaning of the docs. --->

Additional information:
<!--- Optional: Include additional context or expand the description here.--->

<!--- After you open your PR, ask for review from the OpenShift docs team:
  For community authors: Tag @openshift/team-documentation in a GitHub comment.--->



Diff:
diff --git a/modules/network-observability-ebpf-rule-flow-filter.adoc b/modules/network-observability-ebpf-rule-flow-filter.adoc
index b20c6a803514..8c217556f4a1 100644
--- a/modules/network-observability-ebpf-rule-flow-filter.adoc
+++ b/modules/network-observability-ebpf-rule-flow-filter.adoc
@@ -5,13 +5,15 @@
 :_mod-docs-content-type: CONCEPT
 [id="network-observability-ebpf-flow-rule-filter_{context}"]
 = eBPF flow rule filter
-You can use rule-based filtering to control the volume of packets cached in the eBPF flow table. For example, a filter can specify that only packets coming from port 100 should be recorded. Then only the packets that match the filter are cached and the rest are not cached. 
+You can use rule-based filtering to control the volume of packets cached in the eBPF flow table. For example, a filter can specify that only packets coming from port 100 should be captured. Then only the packets that match the filter are captured and the rest are dropped.
+
+You can apply multiple filter rules.
 
 [id="ingress-and-egress-traffic-filtering_{context}"]
 == Ingress and egress traffic filtering
-CIDR notation efficiently represents IP address ranges by combining the base IP address with a prefix length. For both ingress and egress traffic, the source IP address is first used to match filter rules configured with CIDR notation. If there is a match, then the filtering proceeds. If there is no match, then the destination IP is used to match filter rules configured with CIDR notation. 
+Classless Inter-Domain Routing (CIDR) notation efficiently represents IP address ranges by combining the base IP address with a prefix length. For both ingress and egress traffic, the source IP address is first used to match filter rules configured with CIDR notation. If there is a match, then the filtering proceeds. If there is no match, then the destination IP is used to match filter rules configured with CIDR notation.
 
-After matching either the source IP or the destination IP CIDR, you can pinpoint specific endpoints using the `peerIP` to differentiate the destination IP address of the packet. Based on the provisioned action, the flow data is either cached in the eBPF flow table or not cached. 
+After matching either the source IP or the destination IP CIDR, you can pinpoint specific endpoints using the `peerIP` to differentiate the destination IP address of the packet. Based on the provisioned action, the flow data is either cached in the eBPF flow table or not cached.
 
 [id="dashboard-and-metrics-integrations_{context}"]
 == Dashboard and metrics integrations
diff --git a/modules/network-observability-filtering-ebpf-rule.adoc b/modules/network-observability-filtering-ebpf-rule.adoc
index 85e41e34b28e..cc00170ff89e 100644
--- a/modules/network-observability-filtering-ebpf-rule.adoc
+++ b/modules/network-observability-filtering-ebpf-rule.adoc
@@ -4,8 +4,14 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="network-observability-filtering-ebpf-rule_{context}"]
-= Filtering eBPF flow data using a global rule
-You can configure the `FlowCollector` to filter eBPF flows using a global rule to control the flow of packets cached in the eBPF flow table.
+= Filtering eBPF flow data using multiple rules
+You can configure the `FlowCollector` custom resource to filter eBPF flows using multiple rules to control the flow of packets cached in the eBPF flow table.
+
+[IMPORTANT]
+====
+* You cannot use duplicate CIDRs in filter rules.
+* When an IP address matches multiple filter rules, the rule with the most specific CIDR prefix (longest prefix) takes precedence.
+====
 
 .Procedure
 . In the web console, navigate to *Operators* -> *Installed Operators*.
@@ -13,10 +19,11 @@ You can configure the `FlowCollector` to filter eBPF flows using a global rule t
 . Select *cluster*, then select the *YAML* tab.
 . Configure the `FlowCollector` custom resource, similar to the following sample configurations:
 +
+--
+.Example YAML to sample all North-South traffic, and 1:50 East-West traffic
+
+By default, all other flows are rejected.
 
-[%collapsible]
-.Filter Kubernetes service traffic to a specific Pod IP endpoint
-====
 [source, yaml]
 ----
 apiVersion: flows.netobserv.io/v1beta2
@@ -30,22 +37,29 @@ spec:
     type: eBPF
     ebpf:
       flowFilter:
-        action: Accept  <1>
-        cidr: 172.210.150.1/24 <2>
-        protocol: SCTP
-        direction: Ingress
-        destPortRange: 80-100
-        peerIP: 10.10.10.10
-        enable: true    <3>
+        enable: true <1>
+        rules:
+         - action: Accept <2>
+           cidr: 0.0.0.0/0 <3>
+           sampling: 1 <4>
+         - action: Accept
+           cidr: 10.128.0.0/14
+           peerCIDR: 10.128.0.0/14 <5>
+         - action: Accept
+           cidr: 172.30.0.0/16
+           peerCIDR: 10.128.0.0/14
+           sampling: 50
 ----
-<1> The required `action` parameter describes the action that is taken for the flow filter rule. Possible values are `Accept` or `Reject`. 
-<2> The required `cidr` parameter provides the IP address and CIDR mask for the flow filter rule and supports IPv4 and IPv6 address formats. If you want to match against any IP address, you can use `0.0.0.0/0` for IPv4 or `::/0` for IPv6.
-<3> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable this feature.
-====
-+
-[%collapsible]
-.See flows to any addresses outside the cluster 
-====
+<1> To enable eBPF flow filtering, set `spec.agent.ebpf.flowFilter.enable` to `true`.
+<2> To define the action for the flow filter rule, set the required `action` parameter. Valid values are `Accept` or `Reject`.
+<3> To define the IP address and CIDR mask for the flow filter rule, set the required `cidr` parameter. This parameter supports both IPv4 and IPv6 address formats. To match any IP address, use 0.0.0.0/0 for IPv4 or ::/0 for IPv6.
+<4> To define the sampling rate for matched flows and override the global sampling setting `spec.agent.ebpf.sampling`, set the `sampling` parameter.
+<5> To filter flows by Peer IP CIDR, set the `peerCIDR` parameter.
+
+.Example YAML to filter flows with packet drops
+
+By default, all other flows are rejected.
+
 [source, yaml]
 ----
 apiVersion: flows.netobserv.io/v1beta2
@@ -57,18 +71,20 @@ spec:
   deploymentModel: Direct
   agent:
     type: eBPF
-    ebpf:        
+    ebpf:
+      privileged: true <1>
+      features:
+        - PacketDrop <2>
       flowFilter:
-        action: Accept  <1>
-        cidr: 0.0.0.0/0 <2>
-        protocol: TCP
-        direction: Egress
-        sourcePort: 100
-        peerIP: 192.168.127.12 <3>
-        enable: true    <4>
-----       
-<1> You can `Accept` flows based on the criteria in the `flowFilter` specification.
-<2> The `cidr` value of `0.0.0.0/0` matches against any IP address.
-<3> See flows after `peerIP` is configured with `192.168.127.12`. 
-<4> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable the feature.
-====
\ No newline at end of file
+        enable: true <3>
+        rules:
+        - action: Accept <4>
+          cidr: 172.30.0.0/16
+          pktDrops: true <5>
+----
+<1> To enable packet drops, set `spec.agent.ebpf.privileged` to `true`.
+<2> To report packet drops for each network flow, add the `PacketDrop` value to the `spec.agent.ebpf.features` list.
+<3> To enable eBPF flow filtering, set `spec.agent.ebpf.flowFilter.enable` to `true`.
+<4> To define the action for the flow filter rule, set the required `action` parameter. Valid values are `Accept` or `Reject`.
+<5> To filter flows containing drops, set `pktDrops` to `true`.
+--
diff --git a/modules/network-observability-flowcollector-api-specifications.adoc b/modules/network-observability-flowcollector-api-specifications.adoc
index 5764bb9aa881..0d2a0cde0ac2 100644
--- a/modules/network-observability-flowcollector-api-specifications.adoc
+++ b/modules/network-observability-flowcollector-api-specifications.adoc
@@ -444,7 +444,6 @@ To filter two ports, use a "port1,port2" in string format. For example, `ports:
 | `rules` defines a list of filtering rules on the eBPF Agents.
 When filtering is enabled, by default, flows that don't match any rule are rejected.
 To change the default, you can define a rule that accepts everything: `{ action: "Accept", cidr: "0.0.0.0/0" }`, and then refine with rejecting rules.
-Unsupported *.
 
 | `sampling`
 | `integer`
@@ -470,7 +469,6 @@ Description::
 `rules` defines a list of filtering rules on the eBPF Agents.
 When filtering is enabled, by default, flows that don't match any rule are rejected.
 To change the default, you can define a rule that accepts everything: `{ action: "Accept", cidr: "0.0.0.0/0" }`, and then refine with rejecting rules.
-Unsupported *.
 --
 
 Type::
@@ -483,7 +481,7 @@ Type::
 Description::
 +
 --
-`EBPFFlowFilterRule` defines the desired eBPF agent configuration regarding flow filtering rule.
+`EBPFFlowFilterRules` defines the desired eBPF agent configuration regarding flow filtering rules.
 --
 
 Type::
@@ -1480,15 +1478,15 @@ Type::
 
 | `input`
 | `string`
-| 
+|
 
 | `multiplier`
 | `integer`
-| 
+|
 
 | `output`
 | `string`
-| 
+|
 
 |===
 == .spec.exporters[].openTelemetry.logs


Reviews:
user: login: Amoghrd
state: COMMENTED
author_association: NONE
submitted_at: 2025-04-29T18:20:46Z
user: login: Amoghrd
state: COMMENTED
author_association: NONE
submitted_at: 2025-04-29T18:21:00Z
user: login: Amoghrd
state: COMMENTED
author_association: NONE
submitted_at: 2025-04-29T18:24:41Z
user: login: Amoghrd
state: COMMENTED
author_association: NONE
submitted_at: 2025-04-29T18:24:52Z
user: login: Amoghrd
state: COMMENTED
author_association: NONE
submitted_at: 2025-04-29T18:26:07Z
user: login: Amoghrd
state: COMMENTED
author_association: NONE
submitted_at: 2025-04-29T18:26:18Z
user: login: Amoghrd
state: COMMENTED
author_association: NONE
submitted_at: 2025-04-29T18:26:52Z
user: login: Amoghrd
state: COMMENTED
author_association: NONE
submitted_at: 2025-04-29T18:27:34Z
user: login: Amoghrd
state: COMMENTED
author_association: NONE
submitted_at: 2025-04-30T15:44:44Z
user: login: Amoghrd
state: COMMENTED
author_association: NONE
submitted_at: 2025-04-30T15:45:21Z
user: login: Amoghrd
state: COMMENTED
author_association: NONE
submitted_at: 2025-04-30T15:46:03Z
user: login: Amoghrd
state: COMMENTED
author_association: NONE
submitted_at: 2025-04-30T15:46:27Z
user: login: Amoghrd
state: COMMENTED
author_association: NONE
submitted_at: 2025-04-30T15:47:28Z
user: login: Amoghrd
state: COMMENTED
author_association: NONE
submitted_at: 2025-04-30T20:25:42Z
user: login: Amoghrd
state: COMMENTED
author_association: NONE
submitted_at: 2025-04-30T20:26:30Z
user: login: gwynnemonahan
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-01T14:25:28Z
user: login: memodi
state: CHANGES_REQUESTED
author_association: NONE
submitted_at: 2025-05-01T14:50:58Z
user: login: Amoghrd
state: COMMENTED
author_association: NONE
submitted_at: 2025-05-01T14:53:52Z
user: login: gwynnemonahan
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-01T17:01:05Z
user: login: jotak
state: COMMENTED
author_association: NONE
submitted_at: 2025-05-02T08:50:35Z
user: login: jotak
state: COMMENTED
author_association: NONE
submitted_at: 2025-05-02T08:52:05Z
user: login: jotak
state: COMMENTED
author_association: NONE
submitted_at: 2025-05-02T09:45:59Z
user: login: jotak
state: COMMENTED
author_association: NONE
submitted_at: 2025-05-02T09:52:10Z
user: login: gwynnemonahan
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-02T14:22:50Z
user: login: Amoghrd
state: COMMENTED
author_association: NONE
submitted_at: 2025-05-02T14:45:59Z
user: login: jotak
state: COMMENTED
author_association: NONE
submitted_at: 2025-05-02T16:58:56Z
user: login: jotak
state: COMMENTED
author_association: NONE
submitted_at: 2025-05-02T17:03:02Z
user: login: Amoghrd
state: COMMENTED
author_association: NONE
submitted_at: 2025-05-02T17:06:02Z
user: login: gwynnemonahan
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-02T17:46:55Z
user: login: Amoghrd
state: COMMENTED
author_association: NONE
submitted_at: 2025-05-02T19:07:08Z
user: login: Amoghrd
state: COMMENTED
author_association: NONE
submitted_at: 2025-05-02T19:08:07Z
user: login: Amoghrd
state: COMMENTED
author_association: NONE
submitted_at: 2025-05-02T19:08:24Z
user: login: Amoghrd
state: COMMENTED
author_association: NONE
submitted_at: 2025-05-02T19:09:03Z
user: login: Amoghrd
state: COMMENTED
author_association: NONE
submitted_at: 2025-05-02T19:09:40Z
user: login: jotak
state: COMMENTED
author_association: NONE
submitted_at: 2025-05-05T16:30:27Z
user: login: Amoghrd
state: COMMENTED
author_association: NONE
submitted_at: 2025-05-06T15:34:44Z
user: login: Amoghrd
state: COMMENTED
author_association: NONE
submitted_at: 2025-05-06T15:37:51Z
user: login: Amoghrd
state: COMMENTED
author_association: NONE
submitted_at: 2025-05-06T15:39:25Z
user: login: memodi
state: COMMENTED
author_association: NONE
submitted_at: 2025-05-06T18:38:03Z
user: login: gwynnemonahan
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-06T20:01:15Z
user: login: Amoghrd
state: COMMENTED
author_association: NONE
submitted_at: 2025-05-06T20:12:13Z
user: login: Amoghrd
state: COMMENTED
author_association: NONE
submitted_at: 2025-05-06T20:44:48Z
user: login: Amoghrd
state: COMMENTED
author_association: NONE
submitted_at: 2025-05-06T20:44:59Z
user: login: Amoghrd
state: COMMENTED
author_association: NONE
submitted_at: 2025-05-06T20:45:07Z
user: login: lpettyjo
body: A few minor comments. Otherwise, LGTM!
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-13T21:12:59Z
user: login: jeana-redhat
body: just a few format things here, overall lookin' good :sunglasses: 

/remove-label merge-review-in-progress
/remove-label merge-review-needed
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-14T14:55:45Z
user: login: gwynnemonahan
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-14T16:12:57Z
user: login: jeana-redhat
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-14T18:13:43Z

Review comments:
diff_hunk: @@ -4,19 +4,17 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="network-observability-filtering-ebpf-rule_{context}"]
-= Filtering eBPF flow data using a global rule
-You can configure the `FlowCollector` to filter eBPF flows using a global rule to control the flow of packets cached in the eBPF flow table.
+= Filtering eBPF flow data
+You can configure the `FlowCollector` to filter eBPF flows using multiple rules and features to control the flow of packets cached in the eBPF flow table.
 
 .Procedure
 . In the web console, navigate to *Operators* -> *Installed Operators*.
 . Under the *Provided APIs* heading for *Network Observability*, select *Flow Collector*.
 . Select *cluster*, then select the *YAML* tab.
-. Configure the `FlowCollector` custom resource, similar to the following sample configurations:
+. Configure the `FlowCollector` custom resource, similar to the following sample configuration:
++
+.Example `FlowCollector` YAML with multiple rules
 +
-
-[%collapsible]
-.Filter Kubernetes service traffic to a specific Pod IP endpoint
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: Amoghrd
body: should not be removed but also need to mention about PAcketDrop
created_at: 2025-04-29T18:20:46Z
author_association: NONE
diff_hunk: @@ -29,46 +27,29 @@ spec:
   agent:
     type: eBPF
     ebpf:
+      privileged: true <1>
+      features: <2>
+        - PacketDrop
+        - FlowRTT
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: Amoghrd
body: remove this one
created_at: 2025-04-29T18:21:00Z
author_association: NONE
diff_hunk: @@ -5,13 +5,15 @@
 :_mod-docs-content-type: CONCEPT
 [id="network-observability-ebpf-flow-rule-filter_{context}"]
 = eBPF flow rule filter
-You can use rule-based filtering to control the volume of packets cached in the eBPF flow table. For example, a filter can specify that only packets coming from port 100 should be recorded. Then only the packets that match the filter are cached and the rest are not cached. 
+You can use rule-based filtering to control the volume of packets cached in the eBPF flow table. For example, a filter can specify that only packets coming from port 100 should be recorded. Then only the packets that match the filter are cached and the rest are not cached.
+
+You can apply multiple features, and multiple filter rules.
path: modules/network-observability-ebpf-rule-flow-filter.adoc
user: login: Amoghrd
body: Remove features
created_at: 2025-04-29T18:24:40Z
author_association: NONE
diff_hunk: @@ -4,19 +4,17 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="network-observability-filtering-ebpf-rule_{context}"]
-= Filtering eBPF flow data using a global rule
-You can configure the `FlowCollector` to filter eBPF flows using a global rule to control the flow of packets cached in the eBPF flow table.
+= Filtering eBPF flow data
+You can configure the `FlowCollector` to filter eBPF flows using multiple rules and features to control the flow of packets cached in the eBPF flow table.
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: Amoghrd
body: same, remove features
created_at: 2025-04-29T18:24:52Z
author_association: NONE
diff_hunk: @@ -4,19 +4,17 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="network-observability-filtering-ebpf-rule_{context}"]
-= Filtering eBPF flow data using a global rule
-You can configure the `FlowCollector` to filter eBPF flows using a global rule to control the flow of packets cached in the eBPF flow table.
+= Filtering eBPF flow data
+You can configure the `FlowCollector` to filter eBPF flows using multiple rules and features to control the flow of packets cached in the eBPF flow table.
 
 .Procedure
 . In the web console, navigate to *Operators* -> *Installed Operators*.
 . Under the *Provided APIs* heading for *Network Observability*, select *Flow Collector*.
 . Select *cluster*, then select the *YAML* tab.
-. Configure the `FlowCollector` custom resource, similar to the following sample configurations:
+. Configure the `FlowCollector` custom resource, similar to the following sample configuration:
++
+.Example `FlowCollector` YAML with multiple rules
 +
-
-[%collapsible]
-.Filter Kubernetes service traffic to a specific Pod IP endpoint
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: Amoghrd
body: Filter Kubernetes service traffic to a specific Pod IP endpoint and service flows with Drops
created_at: 2025-04-29T18:26:06Z
author_association: NONE
diff_hunk: @@ -29,46 +27,29 @@ spec:
   agent:
     type: eBPF
     ebpf:
+      privileged: true <1>
+      features: <2>
+        - PacketDrop
+        - FlowRTT
       flowFilter:
-        action: Accept  <1>
-        cidr: 172.210.150.1/24 <2>
-        protocol: SCTP
-        direction: Ingress
-        destPortRange: 80-100
-        peerIP: 10.10.10.10
-        enable: true    <3>
+        enable: true <3>
+        rules:
+          - action: Accept  <4>
+            cidr: 172.210.150.1/24 <5>
+            protocol: SCTP
+            direction: Ingress
+            destPortRange: 80-100
+            peerIP: 10.10.10.10
+          - action: Accept
+            cidr: 172.30.0.0/16
+            pktDrops: true <6>
+          - action: Reject
+            cidr: 0.0.0.0/0
 ----
-<1> The required `action` parameter describes the action that is taken for the flow filter rule. Possible values are `Accept` or `Reject`. 
-<2> The required `cidr` parameter provides the IP address and CIDR mask for the flow filter rule and supports IPv4 and IPv6 address formats. If you want to match against any IP address, you can use `0.0.0.0/0` for IPv4 or `::/0` for IPv6.
-<3> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable this feature.
-====
 +
-[%collapsible]
-.See flows to any addresses outside the cluster 
-====
-[source, yaml]
-----
-apiVersion: flows.netobserv.io/v1beta2
-kind: FlowCollector
-metadata:
-  name: cluster
-spec:
-  namespace: netobserv
-  deploymentModel: Direct
-  agent:
-    type: eBPF
-    ebpf:        
-      flowFilter:
-        action: Accept  <1>
-        cidr: 0.0.0.0/0 <2>
-        protocol: TCP
-        direction: Egress
-        sourcePort: 100
-        peerIP: 192.168.127.12 <3>
-        enable: true    <4>
-----       
-<1> You can `Accept` flows based on the criteria in the `flowFilter` specification.
-<2> The `cidr` value of `0.0.0.0/0` matches against any IP address.
-<3> See flows after `peerIP` is configured with `192.168.127.12`. 
-<4> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable the feature.
-====
\ No newline at end of file
+<1> The `spec.agent.ebpf.privileged` specification value must be true for packet drop tracking.
+<2> List the parameters you want to track in the `spec.agent.ebpf.features` specification list.
+<3> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable this feature.
+<4> The required `action` parameter describes the action that is taken for the flow filter rule. Possible values are `Accept` or `Reject`.
+<5> The required `cidr` parameter provides the IP address and CIDR mask for the flow filter rule and supports IPv4 and IPv6 address formats. If you want to match against any IP address, you can use `0.0.0.0/0` for IPv4 or `::/0` for IPv6. Duplicate CIDRs are not allowed in filter rules.
+<6> The `PacketDrop` feature requires an `action` parameter.
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: Amoghrd
body: remove this line
created_at: 2025-04-29T18:26:18Z
author_association: NONE
diff_hunk: @@ -29,46 +27,29 @@ spec:
   agent:
     type: eBPF
     ebpf:
+      privileged: true <1>
+      features: <2>
+        - PacketDrop
+        - FlowRTT
       flowFilter:
-        action: Accept  <1>
-        cidr: 172.210.150.1/24 <2>
-        protocol: SCTP
-        direction: Ingress
-        destPortRange: 80-100
-        peerIP: 10.10.10.10
-        enable: true    <3>
+        enable: true <3>
+        rules:
+          - action: Accept  <4>
+            cidr: 172.210.150.1/24 <5>
+            protocol: SCTP
+            direction: Ingress
+            destPortRange: 80-100
+            peerIP: 10.10.10.10
+          - action: Accept
+            cidr: 172.30.0.0/16
+            pktDrops: true <6>
+          - action: Reject
+            cidr: 0.0.0.0/0
 ----
-<1> The required `action` parameter describes the action that is taken for the flow filter rule. Possible values are `Accept` or `Reject`. 
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: Amoghrd
body: Instead of removing this YAML, need to update it to rules config
created_at: 2025-04-29T18:26:52Z
author_association: NONE
diff_hunk: @@ -29,46 +27,29 @@ spec:
   agent:
     type: eBPF
     ebpf:
+      privileged: true <1>
+      features: <2>
+        - PacketDrop
+        - FlowRTT
       flowFilter:
-        action: Accept  <1>
-        cidr: 172.210.150.1/24 <2>
-        protocol: SCTP
-        direction: Ingress
-        destPortRange: 80-100
-        peerIP: 10.10.10.10
-        enable: true    <3>
+        enable: true <3>
+        rules:
+          - action: Accept  <4>
+            cidr: 172.210.150.1/24 <5>
+            protocol: SCTP
+            direction: Ingress
+            destPortRange: 80-100
+            peerIP: 10.10.10.10
+          - action: Accept
+            cidr: 172.30.0.0/16
+            pktDrops: true <6>
+          - action: Reject
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: Amoghrd
body: remove this Reject rule but need to mention somewhere that by default all other flows are rejected
created_at: 2025-04-29T18:27:34Z
author_association: NONE
diff_hunk: @@ -29,22 +34,31 @@ spec:
   agent:
     type: eBPF
     ebpf:
+      privileged: true <1>
+      features:
+        - PacketDrop
       flowFilter:
-        action: Accept  <1>
-        cidr: 172.210.150.1/24 <2>
-        protocol: SCTP
-        direction: Ingress
-        destPortRange: 80-100
-        peerIP: 10.10.10.10
-        enable: true    <3>
+        enable: true <2>
+        rules:
+          - action: Accept  <3>
+            cidr: 172.210.150.1/24 <4>
+            protocol: SCTP
+            direction: Ingress
+            destPortRange: 80-100
+            peerIP: 10.10.10.10
+          - action: Accept
+            cidr: 172.30.0.0/16
+            pktDrops: true <5>
 ----
-<1> The required `action` parameter describes the action that is taken for the flow filter rule. Possible values are `Accept` or `Reject`. 
-<2> The required `cidr` parameter provides the IP address and CIDR mask for the flow filter rule and supports IPv4 and IPv6 address formats. If you want to match against any IP address, you can use `0.0.0.0/0` for IPv4 or `::/0` for IPv6.
-<3> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable this feature.
+<1> The `spec.agent.ebpf.privileged` specification value must be true for packet drop tracking.
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: Amoghrd
body: ```suggestion
<1> You must set `spec.agent.ebpf.privileged` to `true` for packet drop feature.
```
created_at: 2025-04-30T15:44:43Z
author_association: NONE
diff_hunk: @@ -57,18 +71,19 @@ spec:
   deploymentModel: Direct
   agent:
     type: eBPF
-    ebpf:        
+    ebpf:
       flowFilter:
-        action: Accept  <1>
-        cidr: 0.0.0.0/0 <2>
-        protocol: TCP
-        direction: Egress
-        sourcePort: 100
-        peerIP: 192.168.127.12 <3>
-        enable: true    <4>
-----       
-<1> You can `Accept` flows based on the criteria in the `flowFilter` specification.
-<2> The `cidr` value of `0.0.0.0/0` matches against any IP address.
-<3> See flows after `peerIP` is configured with `192.168.127.12`. 
-<4> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable the feature.
+        enable: true <1>
+        rules:
+        - action: Accept  <2>
+          cidr: 0.0.0.0/0 <3>
+          protocol: TCP
+          direction: Egress
+          sourcePort: 100
+          peerIP: 192.168.127.12 <4>
+----
+<1> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable the feature.
+<2> You can `Accept` flows based on the criteria in the `flowFilter` specification.
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: Amoghrd
body: ```suggestion
<2> The required `action` parameter describes the action that is taken for the flow filter rule. Possible values are `Accept` or `Reject`.
```
created_at: 2025-04-30T15:45:20Z
author_association: NONE
diff_hunk: @@ -57,18 +71,19 @@ spec:
   deploymentModel: Direct
   agent:
     type: eBPF
-    ebpf:        
+    ebpf:
       flowFilter:
-        action: Accept  <1>
-        cidr: 0.0.0.0/0 <2>
-        protocol: TCP
-        direction: Egress
-        sourcePort: 100
-        peerIP: 192.168.127.12 <3>
-        enable: true    <4>
-----       
-<1> You can `Accept` flows based on the criteria in the `flowFilter` specification.
-<2> The `cidr` value of `0.0.0.0/0` matches against any IP address.
-<3> See flows after `peerIP` is configured with `192.168.127.12`. 
-<4> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable the feature.
+        enable: true <1>
+        rules:
+        - action: Accept  <2>
+          cidr: 0.0.0.0/0 <3>
+          protocol: TCP
+          direction: Egress
+          sourcePort: 100
+          peerIP: 192.168.127.12 <4>
+----
+<1> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable the feature.
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: Amoghrd
body: ```suggestion
<1> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable eBPF flow filtering.
```
created_at: 2025-04-30T15:46:03Z
author_association: NONE
diff_hunk: @@ -29,22 +34,31 @@ spec:
   agent:
     type: eBPF
     ebpf:
+      privileged: true <1>
+      features:
+        - PacketDrop
       flowFilter:
-        action: Accept  <1>
-        cidr: 172.210.150.1/24 <2>
-        protocol: SCTP
-        direction: Ingress
-        destPortRange: 80-100
-        peerIP: 10.10.10.10
-        enable: true    <3>
+        enable: true <2>
+        rules:
+          - action: Accept  <3>
+            cidr: 172.210.150.1/24 <4>
+            protocol: SCTP
+            direction: Ingress
+            destPortRange: 80-100
+            peerIP: 10.10.10.10
+          - action: Accept
+            cidr: 172.30.0.0/16
+            pktDrops: true <5>
 ----
-<1> The required `action` parameter describes the action that is taken for the flow filter rule. Possible values are `Accept` or `Reject`. 
-<2> The required `cidr` parameter provides the IP address and CIDR mask for the flow filter rule and supports IPv4 and IPv6 address formats. If you want to match against any IP address, you can use `0.0.0.0/0` for IPv4 or `::/0` for IPv6.
-<3> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable this feature.
+<1> The `spec.agent.ebpf.privileged` specification value must be true for packet drop tracking.
+<2> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable this feature.
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: Amoghrd
body: ```suggestion
<2> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable eBPF flow filtering.
```
created_at: 2025-04-30T15:46:27Z
author_association: NONE
diff_hunk: @@ -29,22 +34,31 @@ spec:
   agent:
     type: eBPF
     ebpf:
+      privileged: true <1>
+      features:
+        - PacketDrop
       flowFilter:
-        action: Accept  <1>
-        cidr: 172.210.150.1/24 <2>
-        protocol: SCTP
-        direction: Ingress
-        destPortRange: 80-100
-        peerIP: 10.10.10.10
-        enable: true    <3>
+        enable: true <2>
+        rules:
+          - action: Accept  <3>
+            cidr: 172.210.150.1/24 <4>
+            protocol: SCTP
+            direction: Ingress
+            destPortRange: 80-100
+            peerIP: 10.10.10.10
+          - action: Accept
+            cidr: 172.30.0.0/16
+            pktDrops: true <5>
 ----
-<1> The required `action` parameter describes the action that is taken for the flow filter rule. Possible values are `Accept` or `Reject`. 
-<2> The required `cidr` parameter provides the IP address and CIDR mask for the flow filter rule and supports IPv4 and IPv6 address formats. If you want to match against any IP address, you can use `0.0.0.0/0` for IPv4 or `::/0` for IPv6.
-<3> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable this feature.
+<1> The `spec.agent.ebpf.privileged` specification value must be true for packet drop tracking.
+<2> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable this feature.
+<3> The required `action` parameter describes the action that is taken for the flow filter rule. Possible values are `Accept` or `Reject`.
+<4> The required `cidr` parameter provides the IP address and CIDR mask for the flow filter rule and supports IPv4 and IPv6 address formats. If you want to match against any IP address, you can use `0.0.0.0/0` for IPv4 or `::/0` for IPv6.
+<5> By default, all other flows are rejected.
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: Amoghrd
body: Point <5> should be added to the next YAML as well
created_at: 2025-04-30T15:47:28Z
author_association: NONE
diff_hunk: @@ -29,22 +34,31 @@ spec:
   agent:
     type: eBPF
     ebpf:
+      privileged: true <1>
+      features:
+        - PacketDrop
       flowFilter:
-        action: Accept  <1>
-        cidr: 172.210.150.1/24 <2>
-        protocol: SCTP
-        direction: Ingress
-        destPortRange: 80-100
-        peerIP: 10.10.10.10
-        enable: true    <3>
+        enable: true <2>
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: Amoghrd
body: Thinking more about this, I feel instead of this example we can use the `Filter EastWest and NorthSouth flows` example in blog https://netobserv.io/posts/enhancing-netobserv-by-introducing-multi-rules-flow-filtering-capability-in-ebpf/
created_at: 2025-04-30T20:25:42Z
author_association: NONE
diff_hunk: @@ -29,22 +34,31 @@ spec:
   agent:
     type: eBPF
     ebpf:
+      privileged: true <1>
+      features:
+        - PacketDrop
       flowFilter:
-        action: Accept  <1>
-        cidr: 172.210.150.1/24 <2>
-        protocol: SCTP
-        direction: Ingress
-        destPortRange: 80-100
-        peerIP: 10.10.10.10
-        enable: true    <3>
+        enable: true <2>
+        rules:
+          - action: Accept  <3>
+            cidr: 172.210.150.1/24 <4>
+            protocol: SCTP
+            direction: Ingress
+            destPortRange: 80-100
+            peerIP: 10.10.10.10
+          - action: Accept
+            cidr: 172.30.0.0/16
+            pktDrops: true <5>
 ----
-<1> The required `action` parameter describes the action that is taken for the flow filter rule. Possible values are `Accept` or `Reject`. 
-<2> The required `cidr` parameter provides the IP address and CIDR mask for the flow filter rule and supports IPv4 and IPv6 address formats. If you want to match against any IP address, you can use `0.0.0.0/0` for IPv4 or `::/0` for IPv6.
-<3> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable this feature.
+<1> You must set `spec.agent.ebpf.privileged` to `true` for the packet drop feature.
+<2> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable eBPF flow filtering.
+<3> The required `action` parameter describes the action that is taken for the flow filter rule. Possible values are `Accept` or `Reject`.
+<4> The required `cidr` parameter provides the IP address and CIDR mask for the flow filter rule and supports IPv4 and IPv6 address formats. If you want to match against any IP address, you can use `0.0.0.0/0` for IPv4 or `::/0` for IPv6.
+<5> By default, all other flows are rejected.
 ====
 +
 [%collapsible]
-.See flows to any addresses outside the cluster 
+.See flows to any addresses outside the cluster
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: Amoghrd
body: And instead of this use `Filter flows with packet drops` example in the same blog
created_at: 2025-04-30T20:26:30Z
author_association: NONE
diff_hunk: @@ -5,13 +5,15 @@
 :_mod-docs-content-type: CONCEPT
 [id="network-observability-ebpf-flow-rule-filter_{context}"]
 = eBPF flow rule filter
-You can use rule-based filtering to control the volume of packets cached in the eBPF flow table. For example, a filter can specify that only packets coming from port 100 should be recorded. Then only the packets that match the filter are cached and the rest are not cached. 
+You can use rule-based filtering to control the volume of packets cached in the eBPF flow table. For example, a filter can specify that only packets coming from port 100 should be recorded. Then only the packets that match the filter are cached and the rest are not cached.
+
+You can apply multiple filter rules.
 
 [id="ingress-and-egress-traffic-filtering_{context}"]
 == Ingress and egress traffic filtering
-CIDR notation efficiently represents IP address ranges by combining the base IP address with a prefix length. For both ingress and egress traffic, the source IP address is first used to match filter rules configured with CIDR notation. If there is a match, then the filtering proceeds. If there is no match, then the destination IP is used to match filter rules configured with CIDR notation. 
+CIDR notation efficiently represents IP address ranges by combining the base IP address with a prefix length. For both ingress and egress traffic, the source IP address is first used to match filter rules configured with CIDR notation. If there is a match, then the filtering proceeds. If there is no match, then the destination IP is used to match filter rules configured with CIDR notation.
path: modules/network-observability-ebpf-rule-flow-filter.adoc
user: login: gwynnemonahan
body: Note to self: check if CIDR is spelled out anywhere/first mention
created_at: 2025-05-01T14:25:27Z
author_association: CONTRIBUTOR
diff_hunk: @@ -5,13 +5,15 @@
 :_mod-docs-content-type: CONCEPT
 [id="network-observability-ebpf-flow-rule-filter_{context}"]
 = eBPF flow rule filter
-You can use rule-based filtering to control the volume of packets cached in the eBPF flow table. For example, a filter can specify that only packets coming from port 100 should be recorded. Then only the packets that match the filter are cached and the rest are not cached. 
+You can use rule-based filtering to control the volume of packets cached in the eBPF flow table. For example, a filter can specify that only packets coming from port 100 should be recorded. Then only the packets that match the filter are cached and the rest are not cached.
path: modules/network-observability-ebpf-rule-flow-filter.adoc
user: login: memodi
body: ```suggestion
You can use rule-based filtering to control the volume of packets cached in the eBPF flow table. For example, a filter can specify that only packets coming from port 100 should be captured. Then only the packets that match the filter are captured and the rest are dropped.
```
some colloquial terminologies.
created_at: 2025-05-01T14:32:22Z
author_association: NONE
diff_hunk: @@ -27,25 +30,32 @@ spec:
   namespace: netobserv
   deploymentModel: Direct
   agent:
-    type: eBPF
-    ebpf:
-      flowFilter:
-        action: Accept  <1>
-        cidr: 172.210.150.1/24 <2>
-        protocol: SCTP
-        direction: Ingress
-        destPortRange: 80-100
-        peerIP: 10.10.10.10
-        enable: true    <3>
+  type: eBPF
+  ebpf:
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: memodi
body: seems indentation error here?
created_at: 2025-05-01T14:35:32Z
author_association: NONE
diff_hunk: @@ -27,25 +30,32 @@ spec:
   namespace: netobserv
   deploymentModel: Direct
   agent:
-    type: eBPF
-    ebpf:
-      flowFilter:
-        action: Accept  <1>
-        cidr: 172.210.150.1/24 <2>
-        protocol: SCTP
-        direction: Ingress
-        destPortRange: 80-100
-        peerIP: 10.10.10.10
-        enable: true    <3>
+  type: eBPF
+  ebpf:
+    flowFilter:
+      enable: true <1>
+      rules:
+        - action: Accept <2>
+          cidr: 172.30.0.0/16 <3>
+          peerCIDR: 10.128.0.0/14
+          sampling: 10
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: memodi
body: we should also describe `peerCIDR` and `sampling` param.
created_at: 2025-05-01T14:40:25Z
author_association: NONE
diff_hunk: @@ -27,25 +30,32 @@ spec:
   namespace: netobserv
   deploymentModel: Direct
   agent:
-    type: eBPF
-    ebpf:
-      flowFilter:
-        action: Accept  <1>
-        cidr: 172.210.150.1/24 <2>
-        protocol: SCTP
-        direction: Ingress
-        destPortRange: 80-100
-        peerIP: 10.10.10.10
-        enable: true    <3>
+  type: eBPF
+  ebpf:
+    flowFilter:
+      enable: true <1>
+      rules:
+        - action: Accept <2>
+          cidr: 172.30.0.0/16 <3>
+          peerCIDR: 10.128.0.0/14
+          sampling: 10
+        - action: Accept
+          cidr: 10.128.0.0/14
+          peerCIDR: 10.128.0.0/14
+          sampling: 20
+        - action: Accept
+          cidr: 8.8.8.8/32
+          sampling: 30
+          peerCIDR: 10.128.0.0/14
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: memodi
body: since these examples provide overlapping CIDRs, I am not sure if it's allowed to have overlapping CIDRs and what would be the behavior in that case cc @Amoghrd 
created_at: 2025-05-01T14:49:56Z
author_association: NONE
diff_hunk: @@ -27,25 +30,32 @@ spec:
   namespace: netobserv
   deploymentModel: Direct
   agent:
-    type: eBPF
-    ebpf:
-      flowFilter:
-        action: Accept  <1>
-        cidr: 172.210.150.1/24 <2>
-        protocol: SCTP
-        direction: Ingress
-        destPortRange: 80-100
-        peerIP: 10.10.10.10
-        enable: true    <3>
+  type: eBPF
+  ebpf:
+    flowFilter:
+      enable: true <1>
+      rules:
+        - action: Accept <2>
+          cidr: 172.30.0.0/16 <3>
+          peerCIDR: 10.128.0.0/14
+          sampling: 10
+        - action: Accept
+          cidr: 10.128.0.0/14
+          peerCIDR: 10.128.0.0/14
+          sampling: 20
+        - action: Accept
+          cidr: 8.8.8.8/32
+          sampling: 30
+          peerCIDR: 10.128.0.0/14
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: Amoghrd
body: Duplicate peerCIDR's are allowed. Duplicate CIDR's are not allowed. So should be good
created_at: 2025-05-01T14:53:52Z
author_association: NONE
diff_hunk: @@ -5,13 +5,15 @@
 :_mod-docs-content-type: CONCEPT
 [id="network-observability-ebpf-flow-rule-filter_{context}"]
 = eBPF flow rule filter
-You can use rule-based filtering to control the volume of packets cached in the eBPF flow table. For example, a filter can specify that only packets coming from port 100 should be recorded. Then only the packets that match the filter are cached and the rest are not cached. 
+You can use rule-based filtering to control the volume of packets cached in the eBPF flow table. For example, a filter can specify that only packets coming from port 100 should be recorded. Then only the packets that match the filter are cached and the rest are not cached.
+
+You can apply multiple filter rules.
 
 [id="ingress-and-egress-traffic-filtering_{context}"]
 == Ingress and egress traffic filtering
-CIDR notation efficiently represents IP address ranges by combining the base IP address with a prefix length. For both ingress and egress traffic, the source IP address is first used to match filter rules configured with CIDR notation. If there is a match, then the filtering proceeds. If there is no match, then the destination IP is used to match filter rules configured with CIDR notation. 
+CIDR notation efficiently represents IP address ranges by combining the base IP address with a prefix length. For both ingress and egress traffic, the source IP address is first used to match filter rules configured with CIDR notation. If there is a match, then the filtering proceeds. If there is no match, then the destination IP is used to match filter rules configured with CIDR notation.
path: modules/network-observability-ebpf-rule-flow-filter.adoc
user: login: gwynnemonahan
body: It was not. Addressed. Resolving.
created_at: 2025-05-01T17:01:05Z
author_association: CONTRIBUTOR
diff_hunk: @@ -5,13 +5,15 @@
 :_mod-docs-content-type: CONCEPT
 [id="network-observability-ebpf-flow-rule-filter_{context}"]
 = eBPF flow rule filter
-You can use rule-based filtering to control the volume of packets cached in the eBPF flow table. For example, a filter can specify that only packets coming from port 100 should be recorded. Then only the packets that match the filter are cached and the rest are not cached. 
+You can use rule-based filtering to control the volume of packets cached in the eBPF flow table. For example, a filter can specify that only packets coming from port 100 should be captured. Then only the packets that match the filter are captured and the rest are dropped.
path: modules/network-observability-ebpf-rule-flow-filter.adoc
user: login: jotak
body: I know this isn't a section added in this PR, but I just realize it's at the wrong place, it shouldn't be under "Overview view", there's nothing specific to eBPF filters in that view. Maybe it should be merged with the other section below? Honestly, this is pure configuration, there's nothing specific to these filters in the UI.
created_at: 2025-05-02T08:50:34Z
author_association: NONE
diff_hunk: @@ -4,19 +4,22 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="network-observability-filtering-ebpf-rule_{context}"]
-= Filtering eBPF flow data using a global rule
-You can configure the `FlowCollector` to filter eBPF flows using a global rule to control the flow of packets cached in the eBPF flow table.
+= Filtering eBPF flow data using multiple rules
+You can configure the `FlowCollector` to filter eBPF flows using multiple rules to control the flow of packets cached in the eBPF flow table.
 
 .Procedure
 . In the web console, navigate to *Operators* -> *Installed Operators*.
 . Under the *Provided APIs* heading for *Network Observability*, select *Flow Collector*.
 . Select *cluster*, then select the *YAML* tab.
 . Configure the `FlowCollector` custom resource, similar to the following sample configurations:
-+
 
-[%collapsible]
-.Filter Kubernetes service traffic to a specific Pod IP endpoint
+[IMPORTANT]
+====
+You cannot use duplicate CIDRs in filter rules.
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: jotak
body: There's another important remark that I think should be mentioned:

If an IP matches several rules, only the one with the longest CIDR prefix will be evaluated.
created_at: 2025-05-02T08:52:05Z
author_association: NONE
diff_hunk: @@ -26,26 +29,35 @@ metadata:
 spec:
   namespace: netobserv
   deploymentModel: Direct
-  agent:
-    type: eBPF
-    ebpf:
-      flowFilter:
-        action: Accept  <1>
-        cidr: 172.210.150.1/24 <2>
-        protocol: SCTP
-        direction: Ingress
-        destPortRange: 80-100
-        peerIP: 10.10.10.10
-        enable: true    <3>
+agent:
+  type: eBPF
+  ebpf:
+    flowFilter:
+      enable: true <1>
+      rules:
+        - action: Accept <2>
+          cidr: 172.30.0.0/16 <3>
+          peerCIDR: 10.128.0.0/16 <4>
+          sampling: 10 <5>
+        - action: Accept
+          cidr: 10.128.0.0/16
+          peerCIDR: 10.129.0.0/16
+          sampling: 20
+        - action: Accept
+          cidr: 8.8.8.8/32
+          sampling: 30
+          peerCIDR: 10.128.0.0/16
+          protocol: ICMP
+          icmpType: 8
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: jotak
body: I know it's the example taken from the blog, but to me it doesn't really correspond to what the title says (EastWest vs NorthSouth). I think we should either change the rules or change the description. The description here would be something like:
**Keep only East-West traffic, and ICMP traffic to a specific IP**
But I'm not a big fan of that, I'd rather go more for something that is a known, well identified use case like this:

**Sample all North-South traffic, and 1:50 East-West traffic**
Which would correspond to this rule:

```yaml
      rules:
        - action: Accept
          cidr: 0.0.0.0/0
          sampling: 1
        - action: Accept
          cidr: 10.128.0.0/14
          peerCIDR: 10.128.0.0/14
          sampling: 50
        - action: Accept
          cidr: 172.30.0.0/16
          peerCIDR: 10.128.0.0/14
          sampling: 50
```

wdyt ? cc @memodi do you agree?
created_at: 2025-05-02T09:45:59Z
author_association: NONE
diff_hunk: @@ -57,18 +69,23 @@ spec:
   deploymentModel: Direct
   agent:
     type: eBPF
-    ebpf:        
-      flowFilter:
-        action: Accept  <1>
-        cidr: 0.0.0.0/0 <2>
-        protocol: TCP
-        direction: Egress
-        sourcePort: 100
-        peerIP: 192.168.127.12 <3>
-        enable: true    <4>
-----       
-<1> You can `Accept` flows based on the criteria in the `flowFilter` specification.
-<2> The `cidr` value of `0.0.0.0/0` matches against any IP address.
-<3> See flows after `peerIP` is configured with `192.168.127.12`. 
-<4> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable the feature.
-====
\ No newline at end of file
+    ebpf:
+      privileged: true <1>
+    features:
+      - PacketDrop <2>
+    flowFilter:
+      enable: true <3>
+      rules:
+        - action: Accept <4>
+          cidr: 172.30.0.0/16
+          pktDrops: true <5>
+        - action: Reject
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: jotak
body: 5th annotation is on the wrong line

```suggestion
          pktDrops: true
        - action: Reject <5>
```
created_at: 2025-05-02T09:52:09Z
author_association: NONE
diff_hunk: @@ -5,13 +5,15 @@
 :_mod-docs-content-type: CONCEPT
 [id="network-observability-ebpf-flow-rule-filter_{context}"]
 = eBPF flow rule filter
-You can use rule-based filtering to control the volume of packets cached in the eBPF flow table. For example, a filter can specify that only packets coming from port 100 should be recorded. Then only the packets that match the filter are cached and the rest are not cached. 
+You can use rule-based filtering to control the volume of packets cached in the eBPF flow table. For example, a filter can specify that only packets coming from port 100 should be captured. Then only the packets that match the filter are captured and the rest are dropped.
path: modules/network-observability-ebpf-rule-flow-filter.adoc
user: login: gwynnemonahan
body: Hey @jotak ,

To clarify: when you configure eBPF flow filter rules, there is no visual, anywhere, of what happens. Configuring flow filter rules has no impact on what users see in the Network Traffic page. 

Is that correct?
created_at: 2025-05-02T14:22:49Z
author_association: CONTRIBUTOR
diff_hunk: @@ -26,26 +29,35 @@ metadata:
 spec:
   namespace: netobserv
   deploymentModel: Direct
-  agent:
-    type: eBPF
-    ebpf:
-      flowFilter:
-        action: Accept  <1>
-        cidr: 172.210.150.1/24 <2>
-        protocol: SCTP
-        direction: Ingress
-        destPortRange: 80-100
-        peerIP: 10.10.10.10
-        enable: true    <3>
+agent:
+  type: eBPF
+  ebpf:
+    flowFilter:
+      enable: true <1>
+      rules:
+        - action: Accept <2>
+          cidr: 172.30.0.0/16 <3>
+          peerCIDR: 10.128.0.0/16 <4>
+          sampling: 10 <5>
+        - action: Accept
+          cidr: 10.128.0.0/16
+          peerCIDR: 10.129.0.0/16
+          sampling: 20
+        - action: Accept
+          cidr: 8.8.8.8/32
+          sampling: 30
+          peerCIDR: 10.128.0.0/16
+          protocol: ICMP
+          icmpType: 8
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: Amoghrd
body: Yup this works too
created_at: 2025-05-02T14:45:59Z
author_association: NONE
diff_hunk: @@ -5,13 +5,15 @@
 :_mod-docs-content-type: CONCEPT
 [id="network-observability-ebpf-flow-rule-filter_{context}"]
 = eBPF flow rule filter
-You can use rule-based filtering to control the volume of packets cached in the eBPF flow table. For example, a filter can specify that only packets coming from port 100 should be recorded. Then only the packets that match the filter are cached and the rest are not cached. 
+You can use rule-based filtering to control the volume of packets cached in the eBPF flow table. For example, a filter can specify that only packets coming from port 100 should be captured. Then only the packets that match the filter are captured and the rest are dropped.
path: modules/network-observability-ebpf-rule-flow-filter.adoc
user: login: jotak
body: Well yes it has an impact, some flows that would be visible without the filters won't show up anymore as they are filtered out, but there's nothing tell you directly that there has been filters configured, it's more implicit.
created_at: 2025-05-02T16:58:56Z
author_association: NONE
diff_hunk: @@ -26,26 +29,35 @@ metadata:
 spec:
   namespace: netobserv
   deploymentModel: Direct
-  agent:
-    type: eBPF
-    ebpf:
-      flowFilter:
-        action: Accept  <1>
-        cidr: 172.210.150.1/24 <2>
-        protocol: SCTP
-        direction: Ingress
-        destPortRange: 80-100
-        peerIP: 10.10.10.10
-        enable: true    <3>
+agent:
+  type: eBPF
+  ebpf:
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: jotak
body: you sure? I don't see an indentation issue, `ebpf` must be at the same level as `type`
created_at: 2025-05-02T17:03:02Z
author_association: NONE
diff_hunk: @@ -26,26 +29,35 @@ metadata:
 spec:
   namespace: netobserv
   deploymentModel: Direct
-  agent:
-    type: eBPF
-    ebpf:
-      flowFilter:
-        action: Accept  <1>
-        cidr: 172.210.150.1/24 <2>
-        protocol: SCTP
-        direction: Ingress
-        destPortRange: 80-100
-        peerIP: 10.10.10.10
-        enable: true    <3>
+agent:
+  type: eBPF
+  ebpf:
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: Amoghrd
body: oh yes, my bad. Ignore this
created_at: 2025-05-02T17:06:02Z
author_association: NONE
diff_hunk: @@ -5,13 +5,15 @@
 :_mod-docs-content-type: CONCEPT
 [id="network-observability-ebpf-flow-rule-filter_{context}"]
 = eBPF flow rule filter
-You can use rule-based filtering to control the volume of packets cached in the eBPF flow table. For example, a filter can specify that only packets coming from port 100 should be recorded. Then only the packets that match the filter are cached and the rest are not cached. 
+You can use rule-based filtering to control the volume of packets cached in the eBPF flow table. For example, a filter can specify that only packets coming from port 100 should be captured. Then only the packets that match the filter are captured and the rest are dropped.
path: modules/network-observability-ebpf-rule-flow-filter.adoc
user: login: gwynnemonahan
body: Hey @jotak ,

Ah, OK. Thanks for the additional context.

At the moment, it sets up "7.1.6.1 Ingress and egress traffic filtering," and "7.1.6.2 Dashboard metrics and integrations", and "Dashboard metrics and integrations" looks to have a UI component: "Netobserv/Health dashboard for eBPF agent statistics now has the Filtered flows rate view. " 

You can see all of 7.1.6 here: https://docs.redhat.com/en/documentation/openshift_container_platform/4.18/html-single/network_observability/index#network-observability-ebpf-flow-rule-filter_nw-observe-network-traffic

Seems like maybe its placement should be revisited. That is outside the scope of this Jira issue, so I created a new Jira for it: https://issues.redhat.com/browse/OSDOCS-14555 . 

Thank you!

created_at: 2025-05-02T17:46:55Z
author_association: CONTRIBUTOR
diff_hunk: @@ -4,19 +4,30 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="network-observability-filtering-ebpf-rule_{context}"]
-= Filtering eBPF flow data using a global rule
-You can configure the `FlowCollector` to filter eBPF flows using a global rule to control the flow of packets cached in the eBPF flow table.
+= Filtering eBPF flow data using multiple rules
+You can configure the `FlowCollector` to filter eBPF flows using multiple rules to control the flow of packets cached in the eBPF flow table.
+
+[IMPORTANT]
+====
+You cannot use duplicate CIDRs in filter rules.
+====
 
 .Procedure
 . In the web console, navigate to *Operators* -> *Installed Operators*.
 . Under the *Provided APIs* heading for *Network Observability*, select *Flow Collector*.
 . Select *cluster*, then select the *YAML* tab.
 . Configure the `FlowCollector` custom resource, similar to the following sample configurations:
-+
 
-[%collapsible]
-.Filter Kubernetes service traffic to a specific Pod IP endpoint
+[IMPORTANT]
+====
+If an IP matches several rules, only the IP with the longest CIDR prefix is evaluated.
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: Amoghrd
body: The 2 `important` sections can be combined I feel.
So basically move this to before L13
created_at: 2025-05-02T19:07:08Z
author_association: NONE
diff_hunk: @@ -26,26 +37,32 @@ metadata:
 spec:
   namespace: netobserv
   deploymentModel: Direct
-  agent:
-    type: eBPF
-    ebpf:
-      flowFilter:
-        action: Accept  <1>
-        cidr: 172.210.150.1/24 <2>
-        protocol: SCTP
-        direction: Ingress
-        destPortRange: 80-100
-        peerIP: 10.10.10.10
-        enable: true    <3>
+agent:
+  type: eBPF
+  ebpf:
+    flowFilter:
+      enable: true <1>
+      rules:
+        - action: Accept <2>
+          cidr: 0.0.0.0/0 <3>
+          sampling: 1 <4>
+        - action: Accept
+          cidr: 10.128.0.0/14
+          peerCIDR: 10.128.0.0/14 <5>
+          sampling: 50
+        - action: Accept
+          cidr: 172.30.0.0/16
+          peerCIDR: 10.128.0.0/14
+          sampling: 50
 ----
-<1> The required `action` parameter describes the action that is taken for the flow filter rule. Possible values are `Accept` or `Reject`. 
-<2> The required `cidr` parameter provides the IP address and CIDR mask for the flow filter rule and supports IPv4 and IPv6 address formats. If you want to match against any IP address, you can use `0.0.0.0/0` for IPv4 or `::/0` for IPv6.
-<3> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable this feature.
-====
+<1> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable eBPF flow filtering.
+<2> The required `action` parameter describes the action that is taken for the flow filter rule. Possible values are `Accept` or `Reject`.
+<3> The required `cidr` parameter provides the IP address and CIDR mask for the flow filter rule and supports IPv4 and IPv6 address formats. If you want to match against any IP address, you can use `0.0.0.0/0` for IPv4 or `::/0` for IPv6. By default, all other flows are rejected.
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: Amoghrd
body: ```suggestion
<3> The required `cidr` parameter provides the IP address and CIDR mask for the flow filter rule and supports IPv4 and IPv6 address formats. If you want to match against any IP address, you can use `0.0.0.0/0` for IPv4 or `::/0` for IPv6.
```
created_at: 2025-05-02T19:08:06Z
author_association: NONE
diff_hunk: @@ -26,26 +37,32 @@ metadata:
 spec:
   namespace: netobserv
   deploymentModel: Direct
-  agent:
-    type: eBPF
-    ebpf:
-      flowFilter:
-        action: Accept  <1>
-        cidr: 172.210.150.1/24 <2>
-        protocol: SCTP
-        direction: Ingress
-        destPortRange: 80-100
-        peerIP: 10.10.10.10
-        enable: true    <3>
+agent:
+  type: eBPF
+  ebpf:
+    flowFilter:
+      enable: true <1>
+      rules:
+        - action: Accept <2>
+          cidr: 0.0.0.0/0 <3>
+          sampling: 1 <4>
+        - action: Accept
+          cidr: 10.128.0.0/14
+          peerCIDR: 10.128.0.0/14 <5>
+          sampling: 50
+        - action: Accept
+          cidr: 172.30.0.0/16
+          peerCIDR: 10.128.0.0/14
+          sampling: 50
 ----
-<1> The required `action` parameter describes the action that is taken for the flow filter rule. Possible values are `Accept` or `Reject`. 
-<2> The required `cidr` parameter provides the IP address and CIDR mask for the flow filter rule and supports IPv4 and IPv6 address formats. If you want to match against any IP address, you can use `0.0.0.0/0` for IPv4 or `::/0` for IPv6.
-<3> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable this feature.
-====
+<1> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable eBPF flow filtering.
+<2> The required `action` parameter describes the action that is taken for the flow filter rule. Possible values are `Accept` or `Reject`.
+<3> The required `cidr` parameter provides the IP address and CIDR mask for the flow filter rule and supports IPv4 and IPv6 address formats. If you want to match against any IP address, you can use `0.0.0.0/0` for IPv4 or `::/0` for IPv6. By default, all other flows are rejected.
+<4> Sampling rate for the matched flows, overriding the global sampling defined at `spec.agent.ebpf.sampling`.
+<5> The Peer IP CIDR to filter flows by.
+
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: Amoghrd
body: ```suggestion
By default, all other flows are rejected.
```
created_at: 2025-05-02T19:08:24Z
author_association: NONE
diff_hunk: @@ -57,18 +74,23 @@ spec:
   deploymentModel: Direct
   agent:
     type: eBPF
-    ebpf:        
-      flowFilter:
-        action: Accept  <1>
-        cidr: 0.0.0.0/0 <2>
-        protocol: TCP
-        direction: Egress
-        sourcePort: 100
-        peerIP: 192.168.127.12 <3>
-        enable: true    <4>
-----       
-<1> You can `Accept` flows based on the criteria in the `flowFilter` specification.
-<2> The `cidr` value of `0.0.0.0/0` matches against any IP address.
-<3> See flows after `peerIP` is configured with `192.168.127.12`. 
-<4> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable the feature.
-====
\ No newline at end of file
+    ebpf:
+      privileged: true <1>
+    features:
+      - PacketDrop <2>
+    flowFilter:
+      enable: true <3>
+      rules:
+        - action: Accept <4>
+          cidr: 172.30.0.0/16
+          pktDrops: true
+        - action: Reject <5>
+          cidr: 0.0.0.0/0
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: Amoghrd
body: Line 87,88 can be removed
created_at: 2025-05-02T19:09:03Z
author_association: NONE
diff_hunk: @@ -57,18 +74,23 @@ spec:
   deploymentModel: Direct
   agent:
     type: eBPF
-    ebpf:        
-      flowFilter:
-        action: Accept  <1>
-        cidr: 0.0.0.0/0 <2>
-        protocol: TCP
-        direction: Egress
-        sourcePort: 100
-        peerIP: 192.168.127.12 <3>
-        enable: true    <4>
-----       
-<1> You can `Accept` flows based on the criteria in the `flowFilter` specification.
-<2> The `cidr` value of `0.0.0.0/0` matches against any IP address.
-<3> See flows after `peerIP` is configured with `192.168.127.12`. 
-<4> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable the feature.
-====
\ No newline at end of file
+    ebpf:
+      privileged: true <1>
+    features:
+      - PacketDrop <2>
+    flowFilter:
+      enable: true <3>
+      rules:
+        - action: Accept <4>
+          cidr: 172.30.0.0/16
+          pktDrops: true
+        - action: Reject <5>
+          cidr: 0.0.0.0/0
+----
+<1> You must set `spec.agent.ebpf.privileged` to `true` for the packet drop feature.
+<2> You can start reporting the packet drops of each network flow by listing the `PacketDrop` parameter in the `spec.agent.ebpf.features` specification list.
+<3> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable eBPF flow filtering.
+<4> The required `action` parameter describes the action that is taken for the flow filter rule. Possible values are `Accept` or `Reject`.
+<5> By default, all other flows are rejected.
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: Amoghrd
body: ```suggestion
By default, all other flows are rejected.
```
created_at: 2025-05-02T19:09:39Z
author_association: NONE
diff_hunk: @@ -4,8 +4,14 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="network-observability-filtering-ebpf-rule_{context}"]
-= Filtering eBPF flow data using a global rule
-You can configure the `FlowCollector` to filter eBPF flows using a global rule to control the flow of packets cached in the eBPF flow table.
+= Filtering eBPF flow data using multiple rules
+You can configure the `FlowCollector` to filter eBPF flows using multiple rules to control the flow of packets cached in the eBPF flow table.
+
+[IMPORTANT]
+====
+* You cannot use duplicate CIDRs in filter rules.
+* If an IP matches several rules, only the IP with the longest CIDR prefix is evaluated.
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: jotak
body: ```suggestion
* If an IP matches several rules, only the rule with the longest CIDR prefix is evaluated.
```
created_at: 2025-05-05T16:30:27Z
author_association: NONE
diff_hunk: @@ -26,25 +31,34 @@ metadata:
 spec:
   namespace: netobserv
   deploymentModel: Direct
-  agent:
-    type: eBPF
-    ebpf:
-      flowFilter:
-        action: Accept  <1>
-        cidr: 172.210.150.1/24 <2>
-        protocol: SCTP
-        direction: Ingress
-        destPortRange: 80-100
-        peerIP: 10.10.10.10
-        enable: true    <3>
+agent:
+  type: eBPF
+  ebpf:
+    flowFilter:
+      enable: true <1>
+      rules:
+        - action: Accept <2>
+          cidr: 0.0.0.0/0 <3>
+          sampling: 1 <4>
+        - action: Accept
+          cidr: 10.128.0.0/14
+          peerCIDR: 10.128.0.0/14 <5>
+          sampling: 50
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: Amoghrd
body: ```suggestion
```
created_at: 2025-05-06T15:34:44Z
author_association: NONE
diff_hunk: @@ -57,18 +71,22 @@ spec:
   deploymentModel: Direct
   agent:
     type: eBPF
-    ebpf:        
-      flowFilter:
-        action: Accept  <1>
-        cidr: 0.0.0.0/0 <2>
-        protocol: TCP
-        direction: Egress
-        sourcePort: 100
-        peerIP: 192.168.127.12 <3>
-        enable: true    <4>
-----       
-<1> You can `Accept` flows based on the criteria in the `flowFilter` specification.
-<2> The `cidr` value of `0.0.0.0/0` matches against any IP address.
-<3> See flows after `peerIP` is configured with `192.168.127.12`. 
-<4> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable the feature.
-====
\ No newline at end of file
+    ebpf:
+      privileged: true <1>
+    features:
+      - PacketDrop <2>
+    flowFilter:
+      enable: true <3>
+      rules:
+        - action: Accept <4>
+          cidr: 172.30.0.0/16
+          pktDrops: true
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: Amoghrd
body: ```suggestion
          pktDrops: true <5>
```
created_at: 2025-05-06T15:37:51Z
author_association: NONE
diff_hunk: @@ -57,18 +71,22 @@ spec:
   deploymentModel: Direct
   agent:
     type: eBPF
-    ebpf:        
-      flowFilter:
-        action: Accept  <1>
-        cidr: 0.0.0.0/0 <2>
-        protocol: TCP
-        direction: Egress
-        sourcePort: 100
-        peerIP: 192.168.127.12 <3>
-        enable: true    <4>
-----       
-<1> You can `Accept` flows based on the criteria in the `flowFilter` specification.
-<2> The `cidr` value of `0.0.0.0/0` matches against any IP address.
-<3> See flows after `peerIP` is configured with `192.168.127.12`. 
-<4> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable the feature.
-====
\ No newline at end of file
+    ebpf:
+      privileged: true <1>
+    features:
+      - PacketDrop <2>
+    flowFilter:
+      enable: true <3>
+      rules:
+        - action: Accept <4>
+          cidr: 172.30.0.0/16
+          pktDrops: true
+----
+<1> You must set `spec.agent.ebpf.privileged` to `true` for the packet drop feature.
+<2> You can start reporting the packet drops of each network flow by listing the `PacketDrop` parameter in the `spec.agent.ebpf.features` specification list.
+<3> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable eBPF flow filtering.
+<4> The required `action` parameter describes the action that is taken for the flow filter rule. Possible values are `Accept` or `Reject`.
+
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: Amoghrd
body: ```suggestion
<5> Set `pktDrops` to `true` to filter flows containing drops

```
created_at: 2025-05-06T15:39:24Z
author_association: NONE
diff_hunk: @@ -26,26 +29,35 @@ metadata:
 spec:
   namespace: netobserv
   deploymentModel: Direct
-  agent:
-    type: eBPF
-    ebpf:
-      flowFilter:
-        action: Accept  <1>
-        cidr: 172.210.150.1/24 <2>
-        protocol: SCTP
-        direction: Ingress
-        destPortRange: 80-100
-        peerIP: 10.10.10.10
-        enable: true    <3>
+agent:
+  type: eBPF
+  ebpf:
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: memodi
body: @jotak `spec` and `agent` are on the same level, `agent` and everything else below should be one level right.
created_at: 2025-05-06T18:38:02Z
author_association: NONE
diff_hunk: @@ -26,26 +29,35 @@ metadata:
 spec:
   namespace: netobserv
   deploymentModel: Direct
-  agent:
-    type: eBPF
-    ebpf:
-      flowFilter:
-        action: Accept  <1>
-        cidr: 172.210.150.1/24 <2>
-        protocol: SCTP
-        direction: Ingress
-        destPortRange: 80-100
-        peerIP: 10.10.10.10
-        enable: true    <3>
+agent:
+  type: eBPF
+  ebpf:
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: gwynnemonahan
body: I see it now.
created_at: 2025-05-06T20:01:15Z
author_association: CONTRIBUTOR
diff_hunk: @@ -57,18 +70,23 @@ spec:
   deploymentModel: Direct
   agent:
     type: eBPF
-    ebpf:        
-      flowFilter:
-        action: Accept  <1>
-        cidr: 0.0.0.0/0 <2>
-        protocol: TCP
-        direction: Egress
-        sourcePort: 100
-        peerIP: 192.168.127.12 <3>
-        enable: true    <4>
-----       
-<1> You can `Accept` flows based on the criteria in the `flowFilter` specification.
-<2> The `cidr` value of `0.0.0.0/0` matches against any IP address.
-<3> See flows after `peerIP` is configured with `192.168.127.12`. 
-<4> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable the feature.
-====
\ No newline at end of file
+    ebpf:
+      privileged: true <1>
+    features:
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: Amoghrd
body: The following lines(L75-82) also have incorrect indentation
created_at: 2025-05-06T20:12:13Z
author_association: NONE
diff_hunk: @@ -57,18 +70,23 @@ spec:
   deploymentModel: Direct
   agent:
     type: eBPF
-    ebpf:        
+    ebpf:
+      privileged: true <1>
+      features:
+        - PacketDrop <2>
       flowFilter:
-        action: Accept  <1>
-        cidr: 0.0.0.0/0 <2>
-        protocol: TCP
-        direction: Egress
-        sourcePort: 100
-        peerIP: 192.168.127.12 <3>
-        enable: true    <4>
-----       
-<1> You can `Accept` flows based on the criteria in the `flowFilter` specification.
-<2> The `cidr` value of `0.0.0.0/0` matches against any IP address.
-<3> See flows after `peerIP` is configured with `192.168.127.12`. 
-<4> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable the feature.
-====
\ No newline at end of file
+        enable: true <3>
+        rules:
+          - action: Accept <4>
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: Amoghrd
body: ```suggestion
        - action: Accept <4>
```
created_at: 2025-05-06T20:44:48Z
author_association: NONE
diff_hunk: @@ -57,18 +70,23 @@ spec:
   deploymentModel: Direct
   agent:
     type: eBPF
-    ebpf:        
+    ebpf:
+      privileged: true <1>
+      features:
+        - PacketDrop <2>
       flowFilter:
-        action: Accept  <1>
-        cidr: 0.0.0.0/0 <2>
-        protocol: TCP
-        direction: Egress
-        sourcePort: 100
-        peerIP: 192.168.127.12 <3>
-        enable: true    <4>
-----       
-<1> You can `Accept` flows based on the criteria in the `flowFilter` specification.
-<2> The `cidr` value of `0.0.0.0/0` matches against any IP address.
-<3> See flows after `peerIP` is configured with `192.168.127.12`. 
-<4> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable the feature.
-====
\ No newline at end of file
+        enable: true <3>
+        rules:
+          - action: Accept <4>
+            cidr: 172.30.0.0/16
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: Amoghrd
body: ```suggestion
          cidr: 172.30.0.0/16
```
created_at: 2025-05-06T20:44:59Z
author_association: NONE
diff_hunk: @@ -57,18 +70,23 @@ spec:
   deploymentModel: Direct
   agent:
     type: eBPF
-    ebpf:        
+    ebpf:
+      privileged: true <1>
+      features:
+        - PacketDrop <2>
       flowFilter:
-        action: Accept  <1>
-        cidr: 0.0.0.0/0 <2>
-        protocol: TCP
-        direction: Egress
-        sourcePort: 100
-        peerIP: 192.168.127.12 <3>
-        enable: true    <4>
-----       
-<1> You can `Accept` flows based on the criteria in the `flowFilter` specification.
-<2> The `cidr` value of `0.0.0.0/0` matches against any IP address.
-<3> See flows after `peerIP` is configured with `192.168.127.12`. 
-<4> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable the feature.
-====
\ No newline at end of file
+        enable: true <3>
+        rules:
+          - action: Accept <4>
+            cidr: 172.30.0.0/16
+            pktDrops: true <5>
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: Amoghrd
body: ```suggestion
          pktDrops: true <5>
```
created_at: 2025-05-06T20:45:07Z
author_association: NONE
diff_hunk: @@ -30,21 +35,29 @@ spec:
     type: eBPF
     ebpf:
       flowFilter:
-        action: Accept  <1>
-        cidr: 172.210.150.1/24 <2>
-        protocol: SCTP
-        direction: Ingress
-        destPortRange: 80-100
-        peerIP: 10.10.10.10
-        enable: true    <3>
+        enable: true <1>
+        rules:
+         - action: Accept <2>
+           cidr: 0.0.0.0/0 <3>
+           sampling: 1 <4>
+         - action: Accept
+           cidr: 10.128.0.0/14
+           peerCIDR: 10.128.0.0/14 <5>
+         - action: Accept
+           cidr: 172.30.0.0/16
+           peerCIDR: 10.128.0.0/14
+           sampling: 50
 ----
-<1> The required `action` parameter describes the action that is taken for the flow filter rule. Possible values are `Accept` or `Reject`. 
-<2> The required `cidr` parameter provides the IP address and CIDR mask for the flow filter rule and supports IPv4 and IPv6 address formats. If you want to match against any IP address, you can use `0.0.0.0/0` for IPv4 or `::/0` for IPv6.
-<3> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable this feature.
+<1> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable eBPF flow filtering.
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: lpettyjo
body: ```suggestion: Put the "why" before the "what":
<1> To enable eBPF flow filtering, you must set `spec.agent.ebpf.flowFilter.enable` to `true`.
```
created_at: 2025-05-13T21:11:09Z
author_association: CONTRIBUTOR
diff_hunk: @@ -57,18 +70,23 @@ spec:
   deploymentModel: Direct
   agent:
     type: eBPF
-    ebpf:        
+    ebpf:
+      privileged: true <1>
+      features:
+        - PacketDrop <2>
       flowFilter:
-        action: Accept  <1>
-        cidr: 0.0.0.0/0 <2>
-        protocol: TCP
-        direction: Egress
-        sourcePort: 100
-        peerIP: 192.168.127.12 <3>
-        enable: true    <4>
-----       
-<1> You can `Accept` flows based on the criteria in the `flowFilter` specification.
-<2> The `cidr` value of `0.0.0.0/0` matches against any IP address.
-<3> See flows after `peerIP` is configured with `192.168.127.12`. 
-<4> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable the feature.
-====
\ No newline at end of file
+        enable: true <3>
+        rules:
+        - action: Accept <4>
+          cidr: 172.30.0.0/16
+          pktDrops: true <5>
+----
+<1> You must set `spec.agent.ebpf.privileged` to `true` for the packet drop feature.
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: lpettyjo
body: Same comment as above.
created_at: 2025-05-13T21:11:50Z
author_association: CONTRIBUTOR
diff_hunk: @@ -57,18 +70,23 @@ spec:
   deploymentModel: Direct
   agent:
     type: eBPF
-    ebpf:        
+    ebpf:
+      privileged: true <1>
+      features:
+        - PacketDrop <2>
       flowFilter:
-        action: Accept  <1>
-        cidr: 0.0.0.0/0 <2>
-        protocol: TCP
-        direction: Egress
-        sourcePort: 100
-        peerIP: 192.168.127.12 <3>
-        enable: true    <4>
-----       
-<1> You can `Accept` flows based on the criteria in the `flowFilter` specification.
-<2> The `cidr` value of `0.0.0.0/0` matches against any IP address.
-<3> See flows after `peerIP` is configured with `192.168.127.12`. 
-<4> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable the feature.
-====
\ No newline at end of file
+        enable: true <3>
+        rules:
+        - action: Accept <4>
+          cidr: 172.30.0.0/16
+          pktDrops: true <5>
+----
+<1> You must set `spec.agent.ebpf.privileged` to `true` for the packet drop feature.
+<2> You can start reporting the packet drops of each network flow by listing the `PacketDrop` parameter in the `spec.agent.ebpf.features` specification list.
+<3> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable eBPF flow filtering.
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: lpettyjo
body: Same comment as above.
created_at: 2025-05-13T21:12:08Z
author_association: CONTRIBUTOR
diff_hunk: @@ -4,8 +4,14 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="network-observability-filtering-ebpf-rule_{context}"]
-= Filtering eBPF flow data using a global rule
-You can configure the `FlowCollector` to filter eBPF flows using a global rule to control the flow of packets cached in the eBPF flow table.
+= Filtering eBPF flow data using multiple rules
+You can configure the `FlowCollector` to filter eBPF flows using multiple rules to control the flow of packets cached in the eBPF flow table.
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: jeana-redhat
body: I think that's a CR? needs a noun following the backticked string
```suggestion
You can configure the `FlowCollector` custom resource to filter eBPF flows using multiple rules to control the flow of packets cached in the eBPF flow table.
```
created_at: 2025-05-14T14:39:19Z
author_association: CONTRIBUTOR
diff_hunk: @@ -30,21 +35,29 @@ spec:
     type: eBPF
     ebpf:
       flowFilter:
-        action: Accept  <1>
-        cidr: 172.210.150.1/24 <2>
-        protocol: SCTP
-        direction: Ingress
-        destPortRange: 80-100
-        peerIP: 10.10.10.10
-        enable: true    <3>
+        enable: true <1>
+        rules:
+         - action: Accept <2>
+           cidr: 0.0.0.0/0 <3>
+           sampling: 1 <4>
+         - action: Accept
+           cidr: 10.128.0.0/14
+           peerCIDR: 10.128.0.0/14 <5>
+         - action: Accept
+           cidr: 172.30.0.0/16
+           peerCIDR: 10.128.0.0/14
+           sampling: 50
 ----
-<1> The required `action` parameter describes the action that is taken for the flow filter rule. Possible values are `Accept` or `Reject`. 
-<2> The required `cidr` parameter provides the IP address and CIDR mask for the flow filter rule and supports IPv4 and IPv6 address formats. If you want to match against any IP address, you can use `0.0.0.0/0` for IPv4 or `::/0` for IPv6.
-<3> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable this feature.
+<1> To enable eBPF flow filtering, you must set `spec.agent.ebpf.flowFilter.enable` to `true`.
+<2> The required `action` parameter specifies the action that is taken for the flow filter rule. Possible values are `Accept` or `Reject`.
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: jeana-redhat
body: If these are the only valid values:
```suggestion
<2> The required `action` parameter specifies the action that is taken for the flow filter rule. Valid values are `Accept` or `Reject`.
```
created_at: 2025-05-14T14:40:38Z
author_association: CONTRIBUTOR
diff_hunk: @@ -30,21 +35,29 @@ spec:
     type: eBPF
     ebpf:
       flowFilter:
-        action: Accept  <1>
-        cidr: 172.210.150.1/24 <2>
-        protocol: SCTP
-        direction: Ingress
-        destPortRange: 80-100
-        peerIP: 10.10.10.10
-        enable: true    <3>
+        enable: true <1>
+        rules:
+         - action: Accept <2>
+           cidr: 0.0.0.0/0 <3>
+           sampling: 1 <4>
+         - action: Accept
+           cidr: 10.128.0.0/14
+           peerCIDR: 10.128.0.0/14 <5>
+         - action: Accept
+           cidr: 172.30.0.0/16
+           peerCIDR: 10.128.0.0/14
+           sampling: 50
 ----
-<1> The required `action` parameter describes the action that is taken for the flow filter rule. Possible values are `Accept` or `Reject`. 
-<2> The required `cidr` parameter provides the IP address and CIDR mask for the flow filter rule and supports IPv4 and IPv6 address formats. If you want to match against any IP address, you can use `0.0.0.0/0` for IPv4 or `::/0` for IPv6.
-<3> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable this feature.
+<1> To enable eBPF flow filtering, you must set `spec.agent.ebpf.flowFilter.enable` to `true`.
+<2> The required `action` parameter specifies the action that is taken for the flow filter rule. Possible values are `Accept` or `Reject`.
+<3> The required `cidr` parameter provides the IP address and CIDR mask for the flow filter rule and supports IPv4 and IPv6 address formats. If you want to match against any IP address, you can use `0.0.0.0/0` for IPv4 or `::/0` for IPv6.
+<4> Sampling rate for the matched flows, overriding the global sampling defined at `spec.agent.ebpf.sampling`.
+<5> The Peer IP CIDR to filter flows by.
++
+By default, all other flows are rejected.
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: jeana-redhat
body: Is this a new line intentionally? Other param explanations aren't split this way
created_at: 2025-05-14T14:41:46Z
author_association: CONTRIBUTOR
diff_hunk: @@ -14,8 +20,7 @@ You can configure the `FlowCollector` to filter eBPF flows using a global rule t
 . Configure the `FlowCollector` custom resource, similar to the following sample configurations:
 +
 
-[%collapsible]
-.Filter Kubernetes service traffic to a specific Pod IP endpoint
+.Example YAML to sample all North-South traffic, and 1:50 East-West traffic
 ====
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: jeana-redhat
body: Any place you remove the `[%collapsible]` line, you want to get rid of the `====` lines that were there to define the collapsible block start and end
created_at: 2025-05-14T14:42:40Z
author_association: CONTRIBUTOR
diff_hunk: @@ -30,21 +35,29 @@ spec:
     type: eBPF
     ebpf:
       flowFilter:
-        action: Accept  <1>
-        cidr: 172.210.150.1/24 <2>
-        protocol: SCTP
-        direction: Ingress
-        destPortRange: 80-100
-        peerIP: 10.10.10.10
-        enable: true    <3>
+        enable: true <1>
+        rules:
+         - action: Accept <2>
+           cidr: 0.0.0.0/0 <3>
+           sampling: 1 <4>
+         - action: Accept
+           cidr: 10.128.0.0/14
+           peerCIDR: 10.128.0.0/14 <5>
+         - action: Accept
+           cidr: 172.30.0.0/16
+           peerCIDR: 10.128.0.0/14
+           sampling: 50
 ----
-<1> The required `action` parameter describes the action that is taken for the flow filter rule. Possible values are `Accept` or `Reject`. 
-<2> The required `cidr` parameter provides the IP address and CIDR mask for the flow filter rule and supports IPv4 and IPv6 address formats. If you want to match against any IP address, you can use `0.0.0.0/0` for IPv4 or `::/0` for IPv6.
-<3> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable this feature.
+<1> To enable eBPF flow filtering, you must set `spec.agent.ebpf.flowFilter.enable` to `true`.
+<2> The required `action` parameter specifies the action that is taken for the flow filter rule. Possible values are `Accept` or `Reject`.
+<3> The required `cidr` parameter provides the IP address and CIDR mask for the flow filter rule and supports IPv4 and IPv6 address formats. If you want to match against any IP address, you can use `0.0.0.0/0` for IPv4 or `::/0` for IPv6.
+<4> Sampling rate for the matched flows, overriding the global sampling defined at `spec.agent.ebpf.sampling`.
+<5> The Peer IP CIDR to filter flows by.
++
+By default, all other flows are rejected.
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: jeana-redhat
body: If possible, the items in this list of callouts should have more parallel phrasing. Right now we have:
* To enable...
* The [XYZ] parameter specifies...
* The [ABC] parameter provides...
* Sampling rate... (sentence fragment)
* The [description of parameter function]...
created_at: 2025-05-14T14:45:55Z
author_association: CONTRIBUTOR
diff_hunk: @@ -57,18 +70,23 @@ spec:
   deploymentModel: Direct
   agent:
     type: eBPF
-    ebpf:        
+    ebpf:
+      privileged: true <1>
+      features:
+        - PacketDrop <2>
       flowFilter:
-        action: Accept  <1>
-        cidr: 0.0.0.0/0 <2>
-        protocol: TCP
-        direction: Egress
-        sourcePort: 100
-        peerIP: 192.168.127.12 <3>
-        enable: true    <4>
-----       
-<1> You can `Accept` flows based on the criteria in the `flowFilter` specification.
-<2> The `cidr` value of `0.0.0.0/0` matches against any IP address.
-<3> See flows after `peerIP` is configured with `192.168.127.12`. 
-<4> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable the feature.
-====
\ No newline at end of file
+        enable: true <3>
+        rules:
+        - action: Accept <4>
+          cidr: 172.30.0.0/16
+          pktDrops: true <5>
+----
+<1> To enable packet drops, you must set `spec.agent.ebpf.privileged` to `true`.
+<2> You can start reporting the packet drops of each network flow by listing the `PacketDrop` parameter in the `spec.agent.ebpf.features` specification list.
+<3> To enable eBPF flow filtering, you must set `spec.agent.ebpf.flowFilter.enable` to `true`.
+<4> The required `action` parameter specifies the action that is taken for the flow filter rule. Possible values are `Accept` or `Reject`.
+<5> Set `pktDrops` to `true` to filter flows containing drops.
+
+By default, all other flows are rejected.
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: jeana-redhat
body: Same comments on this one for the most part. List items could be more parallel, "By default, all other flows are rejected." on a new line stands out. 

In this case, the "By default, all other flows are rejected." bit is also formatted differently than the one above - not sure which is more correct. Does that statement mean to apply to the last callout, or to the YAML config as a whole?
created_at: 2025-05-14T14:48:37Z
author_association: CONTRIBUTOR
diff_hunk: @@ -57,18 +70,23 @@ spec:
   deploymentModel: Direct
   agent:
     type: eBPF
-    ebpf:        
+    ebpf:
+      privileged: true <1>
+      features:
+        - PacketDrop <2>
       flowFilter:
-        action: Accept  <1>
-        cidr: 0.0.0.0/0 <2>
-        protocol: TCP
-        direction: Egress
-        sourcePort: 100
-        peerIP: 192.168.127.12 <3>
-        enable: true    <4>
-----       
-<1> You can `Accept` flows based on the criteria in the `flowFilter` specification.
-<2> The `cidr` value of `0.0.0.0/0` matches against any IP address.
-<3> See flows after `peerIP` is configured with `192.168.127.12`. 
-<4> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable the feature.
-====
\ No newline at end of file
+        enable: true <3>
+        rules:
+        - action: Accept <4>
+          cidr: 172.30.0.0/16
+          pktDrops: true <5>
+----
+<1> To enable packet drops, you must set `spec.agent.ebpf.privileged` to `true`.
+<2> You can start reporting the packet drops of each network flow by listing the `PacketDrop` parameter in the `spec.agent.ebpf.features` specification list.
+<3> To enable eBPF flow filtering, you must set `spec.agent.ebpf.flowFilter.enable` to `true`.
+<4> The required `action` parameter specifies the action that is taken for the flow filter rule. Possible values are `Accept` or `Reject`.
+<5> Set `pktDrops` to `true` to filter flows containing drops.
+
+By default, all other flows are rejected.
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: gwynnemonahan
body: Applies to the YAML configs as a whole.
created_at: 2025-05-14T16:12:57Z
author_association: CONTRIBUTOR
diff_hunk: @@ -30,22 +37,30 @@ spec:
     type: eBPF
     ebpf:
       flowFilter:
-        action: Accept  <1>
-        cidr: 172.210.150.1/24 <2>
-        protocol: SCTP
-        direction: Ingress
-        destPortRange: 80-100
-        peerIP: 10.10.10.10
-        enable: true    <3>
+        enable: true <1>
+        rules:
+         - action: Accept <2>
+           cidr: 0.0.0.0/0 <3>
+           sampling: 1 <4>
+         - action: Accept
+           cidr: 10.128.0.0/14
+           peerCIDR: 10.128.0.0/14 <5>
+         - action: Accept
+           cidr: 172.30.0.0/16
+           peerCIDR: 10.128.0.0/14
+           sampling: 50
 ----
-<1> The required `action` parameter describes the action that is taken for the flow filter rule. Possible values are `Accept` or `Reject`. 
-<2> The required `cidr` parameter provides the IP address and CIDR mask for the flow filter rule and supports IPv4 and IPv6 address formats. If you want to match against any IP address, you can use `0.0.0.0/0` for IPv4 or `::/0` for IPv6.
-<3> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable this feature.
-====
+<1> To enable eBPF flow filtering, set `spec.agent.ebpf.flowFilter.enable` to `true`.
+<2> To define the action for the flow filter rule, set the required `action` parameter. Valid values are `Accept` or `Reject`.
+<3> To define the IP address and CIDR mask for the flow filter rule, set the required `cidr` parameter. This parameter supports both IPv4 and IPv6 address formats. To match any IP address, use 0.0.0.0/0 for IPv4 or ::/0 for IPv6.
+<4> To define the sampling rate for matched flows and override the global sampling setting `spec.agent.ebpf.sampling`, set the `sampling` parameter.
+<5> To filter flows by Peer IP CIDR, set the `peerCIDR` parameter.
 +
path: modules/network-observability-filtering-ebpf-rule.adoc
user: login: jeana-redhat
body: get rid of this line with the `+` and it should realign right
```suggestion
```
created_at: 2025-05-14T18:13:43Z
author_association: CONTRIBUTOR

PR comments:
user: login: ocpdocs-previewbot
created_at: 2025-04-21T20:41:09Z
body: 🤖 Wed May 14 18:30:13 - Prow CI generated the docs preview:

https://92375--ocpdocs-pr.netlify.app/openshift-enterprise/latest/observability/network_observability/flowcollector-api.html
https://92375--ocpdocs-pr.netlify.app/openshift-enterprise/latest/observability/network_observability/observing-network-traffic.html
author_association: NONE
user: login: Amoghrd
created_at: 2025-05-06T17:20:03Z
body: LGTM from my side
author_association: NONE
user: login: Amoghrd
created_at: 2025-05-08T21:23:10Z
body: /label qe-approved
author_association: NONE
user: login: gwynnemonahan
created_at: 2025-05-12T16:46:04Z
body: /label peer-review-needed
author_association: CONTRIBUTOR
user: login: gwynnemonahan
created_at: 2025-05-14T14:23:19Z
body: /label merge-review-needed
author_association: CONTRIBUTOR
user: login: openshift-ci[bot]
created_at: 2025-05-14T18:31:53Z
body: @gwynnemonahan: all tests **passed!**


[Full PR test history](https://prow.ci.openshift.org/pr-history?org=openshift&repo=openshift-docs&pr=92375). [Your PR dashboard](https://prow.ci.openshift.org/pr?query=is:pr+state:open+author:gwynnemonahan).

<details>

Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md).  If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes-sigs/prow](https://github.com/kubernetes-sigs/prow/issues/new?title=Prow%20issue:) repository. I understand the commands that are listed [here](https://go.k8s.io/bot-commands).
</details>
<!-- test report -->
author_association: NONE