You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
You can create filters to reduce the number of generated network flows. Filtering network flows can reduce the resource usage of the Network Observability components.
10
+
11
+
You can configure two kinds of filters:
12
+
13
+
* eBPF agent filters
14
+
* Flowlogs-pipeline filters
15
+
16
+
[id="ebpf-agent-filters_{context}"]
17
+
== eBPF agent filters
18
+
19
+
eBPF agent filters maximize performance because they take effect at the earliest stage of the network flows collection process.
20
+
21
+
To configure eBPF agent filters with the Network Observability Operator, see "Filtering eBPF flow data using multiple rules".
22
+
23
+
[id="flowlogs-pipeline-filters_{context}"]
24
+
== Flowlogs-pipeline filters
25
+
26
+
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.
27
+
28
+
Flowlogs-pipeline filters use a simple query language to filter network flow, as shown in the following example:
29
+
30
+
[source,terminal]
31
+
----
32
+
(srcnamespace="netobserv" OR (srcnamespace="ingress" AND dstnamespace="netobserv")) AND srckind!="service"
33
+
----
34
+
35
+
The query language uses the following syntax:
36
+
37
+
.Query language syntax
38
+
[cols="1,3", options="header"]
39
+
|===
40
+
| Category
41
+
| Operators
42
+
43
+
| Logical boolean operators (not case-sensitive)
44
+
| `and`, `or`
45
+
46
+
| Comparison operators
47
+
| `=` (equals), +
48
+
`!=` (not equals), +
49
+
`=~` (matches regexp), +
50
+
`!~` (not matches regexp), +
51
+
`<` / `\<=` (less than or equal to), +
52
+
`>` / `>=` (greater than or equal to)
53
+
54
+
| Unary operations
55
+
| `with(field)` (field is present), +
56
+
`without(field)` (field is absent)
57
+
58
+
| Parenthesis-based priority
59
+
|===
60
+
61
+
You can configure flowlogs-pipeline filters in the `spec.processor.filters` section of the `FlowCollector` resource. For example:
62
+
63
+
.Example YAML Flowlogs-pipeline filter
64
+
[source,yaml]
65
+
----
66
+
apiVersion: flows.netobserv.io/v1beta2
67
+
kind: FlowCollector
68
+
metadata:
69
+
name: cluster
70
+
spec:
71
+
namespace: netobserv
72
+
agent:
73
+
processor:
74
+
filters:
75
+
- query: |
76
+
(SrcK8S_Namespace="netobserv" OR (SrcK8S_Namespace="openshift-ingress" AND DstK8S_Namespace="netobserv"))
77
+
outputTarget: Loki <1>
78
+
sampling: 10 <2>
79
+
----
80
+
<1> Sends matching flows to a specific output, such as Loki, Prometheus, or an external system. When omitted, sends to all configured outputs.
81
+
<2> Optional. Applies a sampling ratio to limit the number of matching flows to be stored or exported. For example, `sampling: 10` means 1/10 of the flows are kept.
User-defined networks (UDN) improve the flexibility and segmentation capabilities of the default Layer 3 topology for a Kubernetes pod network by enabling custom Layer 2 and Layer 3 network segments, where all these segments are isolated by default. These segments act as primary or secondary networks for container pods and virtual machines that use the default OVN-Kubernetes CNI plugin.
10
+
11
+
UDNs enable a wide range of network architectures and topologies, enhancing network flexibility, security, and performance.
12
+
13
+
When the `UDNMapping` feature is enabled with Network Observability, the *Traffic* flow table has a *UDN labels* column. You can filter on *Source Network Name* and *Destination Network Name*.
The eBPF Manager Operator reduces the attack surface and ensures compliance, security, and conflict prevention by managing all eBPF programs. Network observability can use the eBPF Manager Operator to load hooks. As a result, you no longer need to provide the eBPF Agent with privileged mode or additional Linux capabilities such as `CAP_BPF` and `CAP_PERFMON`. The eBPF Manager Operator with network observability is only supported on 64-bit AMD architecture.
10
+
11
+
:FeatureName: eBPF Manager Operator with network observability
12
+
include::snippets/technology-preview.adoc[]
13
+
14
+
.Procedure
15
+
. In the web console, navigate to *Operators*->*Operator Hub*.
16
+
. Install *eBPF Manager*.
17
+
. Check *Workloads*->*Pods* in the `bpfman` namespace to make sure they are all up and running.
18
+
. Configure the `FlowCollector` custom resource to use the eBPF Manager Operator:
19
+
+
20
+
.Example `FlowCollector` configuration
21
+
[source,yaml]
22
+
----
23
+
apiVersion: flows.netobserv.io/v1beta2
24
+
kind: FlowCollector
25
+
metadata:
26
+
name: cluster
27
+
spec:
28
+
agent:
29
+
ebpf:
30
+
features:
31
+
- EbpfManager
32
+
----
33
+
34
+
.Verification
35
+
. In the web console, navigate to *Operators*->*Installed Operators*.
For each node, verify that a `BpfApplication` named `netobserv` and a pair of `BpfProgram` objects, one for Traffic Control (TCx) ingress and another for TCx egress, exist. If you enable other eBPF Agent features, you might have more objects.
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.
8
+
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.
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.
14
+
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.
13
15
14
-
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.
16
+
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.
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.
6
+
= Filtering eBPF flow data using multiple rules
7
+
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.
8
+
9
+
[IMPORTANT]
10
+
====
11
+
* You cannot use duplicate Classless Inter-Domain Routing (CIDRs) in filter rules.
12
+
* When an IP address matches multiple filter rules, the rule with the most specific CIDR prefix (longest prefix) takes precedence.
13
+
====
9
14
10
15
.Procedure
11
16
. In the web console, navigate to *Operators*->*Installed Operators*.
12
17
. Under the *Provided APIs* heading for *Network Observability*, select *Flow Collector*.
13
18
. Select *cluster*, then select the *YAML* tab.
14
19
. Configure the `FlowCollector` custom resource, similar to the following sample configurations:
15
-
+
16
20
17
-
[%collapsible]
18
-
.Filter Kubernetes service traffic to a specific Pod IP endpoint
19
-
====
21
+
22
+
.Example YAML to sample all North-South traffic, and 1:50 East-West traffic
23
+
24
+
By default, all other flows are rejected.
25
+
20
26
[source, yaml]
21
27
----
22
28
apiVersion: flows.netobserv.io/v1beta2
@@ -30,22 +36,29 @@ spec:
30
36
type: eBPF
31
37
ebpf:
32
38
flowFilter:
33
-
action: Accept <1>
34
-
cidr: 172.210.150.1/24 <2>
35
-
protocol: SCTP
36
-
direction: Ingress
37
-
destPortRange: 80-100
38
-
peerIP: 10.10.10.10
39
-
enable: true <3>
39
+
enable: true <1>
40
+
rules:
41
+
- action: Accept <2>
42
+
cidr: 0.0.0.0/0 <3>
43
+
sampling: 1 <4>
44
+
- action: Accept
45
+
cidr: 10.128.0.0/14
46
+
peerCIDR: 10.128.0.0/14 <5>
47
+
- action: Accept
48
+
cidr: 172.30.0.0/16
49
+
peerCIDR: 10.128.0.0/14
50
+
sampling: 50
40
51
----
41
-
<1> The required `action` parameter describes the action that is taken for the flow filter rule. Possible values are `Accept` or `Reject`.
42
-
<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.
43
-
<3> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable this feature.
44
-
====
45
-
+
46
-
[%collapsible]
47
-
.See flows to any addresses outside the cluster
48
-
====
52
+
<1> To enable eBPF flow filtering, set `spec.agent.ebpf.flowFilter.enable` to `true`.
53
+
<2> To define the action for the flow filter rule, set the required `action` parameter. Valid values are `Accept` or `Reject`.
54
+
<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.
55
+
<4> To define the sampling rate for matched flows and override the global sampling setting `spec.agent.ebpf.sampling`, set the `sampling` parameter.
56
+
<5> To filter flows by Peer IP CIDR, set the `peerCIDR` parameter.
57
+
58
+
.Example YAML to filter flows with packet drops
59
+
60
+
By default, all other flows are rejected.
61
+
49
62
[source, yaml]
50
63
----
51
64
apiVersion: flows.netobserv.io/v1beta2
@@ -57,18 +70,19 @@ spec:
57
70
deploymentModel: Direct
58
71
agent:
59
72
type: eBPF
60
-
ebpf:
73
+
ebpf:
74
+
privileged: true <1>
75
+
features:
76
+
- PacketDrop <2>
61
77
flowFilter:
62
-
action: Accept <1>
63
-
cidr: 0.0.0.0/0 <2>
64
-
protocol: TCP
65
-
direction: Egress
66
-
sourcePort: 100
67
-
peerIP: 192.168.127.12 <3>
68
-
enable: true <4>
69
-
----
70
-
<1> You can `Accept` flows based on the criteria in the `flowFilter` specification.
71
-
<2> The `cidr` value of `0.0.0.0/0` matches against any IP address.
72
-
<3> See flows after `peerIP` is configured with `192.168.127.12`.
73
-
<4> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable the feature.
74
-
====
78
+
enable: true <3>
79
+
rules:
80
+
- action: Accept <4>
81
+
cidr: 172.30.0.0/16
82
+
pktDrops: true <5>
83
+
----
84
+
<1> To enable packet drops, set `spec.agent.ebpf.privileged` to `true`.
85
+
<2> To report packet drops for each network flow, add the `PacketDrop` value to the `spec.agent.ebpf.features` list.
86
+
<3> To enable eBPF flow filtering, set `spec.agent.ebpf.flowFilter.enable` to `true`.
87
+
<4> To define the action for the flow filter rule, set the required `action` parameter. Valid values are `Accept` or `Reject`.
88
+
<5> To filter flows containing drops, set `pktDrops` to `true`.
0 commit comments