OpenShift Container Platform

Configure flow sampling and filtering rules

Configure flow sampling rates and filtering rules to control which network flows the eBPF agent collects, so you can balance observability detail against resource usage.

Update the FlowCollector resource

As an alternative to using the web console, use the oc patch command with the flowcollector custom resource to quickly update specific specifications, such as eBPF sampling

Procedure

Run the following command to patch the flowcollector CR and update the spec.agent.ebpf.sampling value:

$ oc patch flowcollector cluster --type=json -p "[{"op": "replace", "path": "/spec/agent/ebpf/sampling", "value": <new value>}] -n netobserv"

Filter network flows at ingestion

Create filters to reduce the number of generated network flows. Filtering network flows can reduce the resource usage of the network observability components.

You can configure two kinds of filters:

eBPF agent filters
Flowlogs-pipeline filters

eBPF agent filters

eBPF agent filters maximize performance because they take effect at the earliest stage of the network flows collection process.

To configure eBPF agent filters with the Network Observability Operator, see "Filtering eBPF flow data using multiple rules".

Flowlogs-pipeline filters

Flowlogs-pipeline filters provide greater control over traffic selection because they take effect later in the network flows collection process. They are primarily used to improve data storage.

Flowlogs-pipeline filters use a simple query language to filter network flow, as shown in the following example:

(srcnamespace="netobserv" OR (srcnamespace="ingress" AND dstnamespace="netobserv")) AND srckind!="service"

The query language uses the following syntax:

Table 13. Query language syntax
Category	Operators
Logical boolean operators (not case-sensitive)	`and`, `or`
Comparison operators	`=` (equals), `!=` (not equals), `=~` (matches regexp), `!~` (not matches regexp), `<` / `<=` (less than or equal to), `>` / `>=` (greater than or equal to)
Unary operations	`with(field)` (field is present), `without(field)` (field is absent)

You can configure flowlogs-pipeline filters in the spec.processor.filters section of the FlowCollector resource. For example:

Example YAML Flowlogs-pipeline filter

apiVersion: flows.netobserv.io/v1beta2
kind: FlowCollector
metadata:
  name: cluster
spec:
  namespace: netobserv
  agent:
  processor:
    filters:
      - query: |
          (SrcK8S_Namespace="netobserv" OR (SrcK8S_Namespace="openshift-ingress" AND DstK8S_Namespace="netobserv"))
        outputTarget: Loki
        sampling: 10

where:

spec.processor.filters.outputTarget: Specifies the output destination for matching flows, such as Loki, Prometheus, or an external system. If you omit this parameter, the system sends the flows to all configured outputs.
spec.processor.filters.sampling: Specifies an optional sampling interval to limit the number of matching flows stored or exported. For example, a value of 10 means there is a 1 in 10 chance that a flow is kept.

Flow filter configuration parameters

Reference the required and optional parameters for configuring flow filter rules in the FlowCollector resource, including CIDR ranges, filter actions, protocols, and specific port configurations.

Table 14. Required configuration parameters
Parameter	Description
`enable`	Set `enable` to `true` to enable the eBPF flow filtering feature.
`cidr`	Provides the IP address and CIDR mask for the flow filter rule. Supports both IPv4 and IPv6 address format. If you want to match against any IP, you can use `0.0.0.0/0` for IPv4 or `::/0` for IPv6.
`action`	Describes the action that is taken for the flow filter rule. The possible values are `Accept` or `Reject`. For the `Accept` action matching rule, the flow data is cached in the eBPF table and updated with the global metric, `FlowFilterAcceptCounter`. For the `Reject` action matching rule, the flow data is dropped and not cached in the eBPF table. The flow data is updated with the global metric, `FlowFilterRejectCounter`. If the rule is not matched, the flow is cached in the eBPF table and updated with the global metric, `FlowFilterNoMatchCounter`.

Table 15. Optional configuration parameters
Parameter	Description
`direction`	Defines the direction of the flow filter rule. Possible values are `Ingress` or `Egress`.
`protocol`	Defines the protocol of the flow filter rule. Possible values are `TCP`, `UDP`, `SCTP`, `ICMP`, and `ICMPv6`.
`tcpFlags`	Defines the TCP flags to filter flows. Possible values are `SYN`, `SYN-ACK`, `ACK`, `FIN`, `RST`, `PSH`, `URG`, `ECE`, `CWR`, `FIN-ACK`, and `RST-ACK`.
`ports`	Defines the ports to use for filtering flows. It can be used for either source or destination ports. To filter a single port, set a single port as an integer value. For example `ports: 80`. To filter a range of ports, use a "start-end" range in string format. For example `ports: "80-100"`
`sourcePorts`	Defines the source port to use for filtering flows. To filter a single port, set a single port as an integer value, for example `sourcePorts: 80`. To filter a range of ports, use a "start-end" range, string format, for example `sourcePorts: "80-100"`.
`destPorts`	DestPorts defines the destination ports to use for filtering flows. To filter a single port, set a single port as an integer value, for example `destPorts: 80`. To filter a range of ports, use a "start-end" range in string format, for example `destPorts: "80-100"`.
`icmpType`	Defines the ICMP type to use for filtering flows.
`icmpCode`	Defines the ICMP code to use for filtering flows.
`peerIP`	Defines the IP address to use for filtering flows, for example: `10.10.10.10`.

eBPF flow data filtering examples

Use these FlowCollector custom resource examples to filter eBPF flows using multiple rules to control the flow of packets cached in the eBPF flow table.

Example YAML to sample all North-South traffic, and 1:50 East-West traffic

By default, all other flows are rejected.

apiVersion: flows.netobserv.io/v1beta2
kind: FlowCollector
metadata:
  name: cluster
spec:
  namespace: netobserv
  deploymentModel: Service
  agent:
    type: eBPF
    ebpf:
      flowFilter:
        enable: true
        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
         - action: Accept
           cidr: 172.30.0.0/16
           peerCIDR: 10.128.0.0/14
           sampling: 50

where:

spec.agent.ebpf.flowFilter.enable: Specifies whether to enable eBPF flow filtering. Set to true to enable flow filtering.
spec.agent.ebpf.flowFilter.rules.action: Specifies the action for the flow filter rule. Valid values are Accept or Reject.
spec.agent.ebpf.flowFilter.rules.cidr: Specifies the IP address and CIDR mask for the flow filter rule. This parameter supports both IPv4 and IPv6 address formats. Use 0.0.0.0/0 for IPv4 or ::/0 for IPv6 to match any IP address.
spec.agent.ebpf.flowFilter.rules.peerCIDR: Specifies the Peer IP CIDR used to filter flows.
spec.agent.ebpf.flowFilter.rules.sampling: Specifies the sampling interval for matched flows. This value overrides the global sampling setting defined in spec.agent.ebpf.sampling.

Example YAML to filter flows with packet drops

By default, all other flows are rejected.

apiVersion: flows.netobserv.io/v1beta2
kind: FlowCollector
metadata:
  name: cluster
spec:
  namespace: netobserv
  deploymentModel: Service
  agent:
    type: eBPF
    ebpf:
      privileged: true
      features:
        - PacketDrop
      flowFilter:
        enable: true
        rules:
        - action: Accept
          cidr: 172.30.0.0/16
          pktDrops: true

where:

spec.agent.ebpf.privileged: Specifies whether to enable privileged mode, which is required for reporting packet drops.
spec.agent.ebpf.features: Specifies the list of eBPF features to enable. Adding the PacketDrop value to this list reports packet drops for each network flow.
spec.agent.ebpf.flowFilter.enable: Specifies whether to enable eBPF flow filtering.
spec.agent.ebpf.flowFilter.rules.action: Specifies the action for the flow filter rule. Valid values are Accept or Reject.
spec.agent.ebpf.flowFilter.rules.pktDrops: Specifies whether to filter for flows that contain packet drops.