---
title: Observing the network traffic
---

# Observing the network traffic {#nw-observe-network-traffic}

As an administrator, you can observe the network traffic in the OpenShift Container Platform web console for detailed troubleshooting and analysis. This feature helps you get insights from different graphical representations of traffic flow.

## Observing the network traffic from the Overview view {#network-observability-network-traffic-overview-view_nw-observe-network-traffic}

The Network Traffic **Overview** view provides aggregated flow metrics and visual insights into application communications. Administrators can use the metrics to monitor data volume, troubleshoot connectivity, and detect unusual traffic patterns across the cluster.

The **Overview** view shows aggregate network traffic in your OpenShift Container Platform cluster, allowing you to see which applications are communicating and the volume of data being transferred. It provides detailed insights by source, destination, and flow type, along with the top traffic flows and average byte rates.

As an administrator, you can troubleshoot connectivity issues, detect unusual traffic patterns, and optimize application performance. It provides a quick overview of network behavior, making it easier to prioritize actions and ensure efficient resource usage.

### Working with the Overview view {#network-observability-working-with-overview_nw-observe-network-traffic}

Navigate to the network traffic **Overview** view in the OpenShift Container Platform console to see graphical representations of flow rate statistics and configure the display scope using available options.

**Prerequisite**

- Access to the cluster with administrator rights.

**Procedure**

1. Navigate to **Observe** → **Network Traffic**.
2. In the **Network Traffic** page, click the **Overview** tab.
3. Click the menu icon to configure the scope of each flow rate data.

### Configuring advanced options for the Overview view {#network-observability-configuring-options-overview_nw-observe-network-traffic}

Customize the network traffic **Overview** view by configuring advanced options, such as graph scope, label truncation, and panel management, to refine the display of flow rate statistics and traffic data.

To access the advanced options, click **Show advanced options**. You can configure the details in the graph by using the **Display options** drop-down menu. The options available are as follows:

- **Scope**: Select to view the components that network traffic flows between. You can set the scope to **Node**, **Namespace**, **Owner**, **Zones**, **Cluster** or **Resource**. **Owner** is an aggregation of resources. **Resource** can be a pod, service, node, in case of host-network traffic, or an unknown IP address. The default value is **Namespace**.
- **Truncate labels**: Select the required width of the label from the drop-down list. The default value is **M**.

#### Managing panels and display {#network-observability-cao-managing-panels-overview_nw-observe-network-traffic}

You can select the required panels to be displayed, reorder them, and focus on a specific panel. To add or remove panels, click **Manage panels**.

The following panels are shown by default:

- **Top X average bytes rates**
- **Top X bytes rates stacked with total**

Other panels can be added in **Manage panels**:

- **Top X average packets rates**
- **Top X packets rates stacked with total**

**Query options** allows you to choose whether to show the **Top 5**, **Top 10**, or **Top 15** rates.

### Packet drop tracking {#network-observability-pktdrop-overview_nw-observe-network-traffic}

Monitor and analyze network packet loss by using eBPF-based packet drop tracking, which identifies drop locations, detects host or OVS-specific drop reasons, and provides dedicated graphical panels in the **Overview** view.

You can configure graphical representation of network flow records with packet loss in the **Overview** view. By employing eBPF tracepoint hooks, you can gain valuable insights into packet drops for TCP, UDP, SCTP, ICMPv4, and ICMPv6 protocols, which can result in the following actions:

- Identification: Pinpoint the exact locations and network paths where packet drops are occurring. Determine whether specific devices, interfaces, or routes are more prone to drops.
- Root cause analysis: Examine the data collected by the eBPF program to understand the causes of packet drops. For example, are they a result of congestion, buffer issues, or specific network events?
- Performance optimization: With a clearer picture of packet drops, you can take steps to optimize network performance, such as adjust buffer sizes, reconfigure routing paths, or implement Quality of Service (QoS) measures.

When packet drop tracking is enabled, you can see the following panels in the **Overview** by default:

- **Top X packet dropped state stacked with total**
- **Top X packet dropped cause stacked with total**
- **Top X average dropped packets rates**
- **Top X dropped packets rates stacked with total**

Other packet drop panels are available to add in **Manage panels**:

- **Top X average dropped bytes rates**
- **Top X dropped bytes rates stacked with total**

#### Types of packet drops {#_types_of_packet_drops}

Two kinds of packet drops are detected by network observability: host drops and OVS drops. Host drops are prefixed with `SKB_DROP` and OVS drops are prefixed with `OVS_DROP`. Dropped flows are shown in the side panel of the **Traffic flows** table along with a link to a description of each drop type. Examples of host drop reasons are as follows:

- `SKB_DROP_REASON_NO_SOCKET`: the packet dropped due to a missing socket.
- `SKB_DROP_REASON_TCP_CSUM`: the packet dropped due to a TCP checksum error.

Examples of OVS drops reasons are as follows:

- `OVS_DROP_LAST_ACTION`: OVS packets dropped due to an implicit drop action, for example due to a configured network policy.
- `OVS_DROP_IP_TTL`: OVS packets dropped due to an expired IP TTL.

See the *Additional resources* of this section for more information about enabling and working with packet drop tracking.

### Working with packet drops {#network-observability-packet-drops_nw-observe-network-traffic}

Enable packet drop tracking in the Network Observability Operator by configuring the `FlowCollector` resource to monitor and visualize network data loss in the web console.

Packet loss occurs when one or more packets of network flow data fail to reach their destination. You can track these drops by editing the `FlowCollector` to the specifications in the following YAML example.

> [!IMPORTANT]
> CPU and memory usage increases when this feature is enabled.

**Procedure**

1. In the web console, navigate to **Ecosystem** → **Installed Operators**.
2. Under the **Provided APIs** heading for the **NetObserv Operator**, select **Flow Collector**.
3. Select **cluster**, and then select the **YAML** tab.
4. Configure the `FlowCollector` custom resource for packet drops, for example: <a name="network-observability-flowcollector-configuring-pkt-drop_nw-observe-network-traffic"></a>

   ```yaml {title="Example FlowCollector configuration"}
   apiVersion: flows.netobserv.io/v1beta2
   kind: FlowCollector
   metadata:
     name: cluster
   spec:
     namespace: netobserv
     agent:
       type: eBPF
       ebpf:
         features:
          - PacketDrop
         privileged: true
   ```

   where:

   `spec.agent.ebpf.features`
   :   Specifies the features to enable. Include `PacketDrop` to start reporting packet drops for each network flow.

   `spec.agent.ebpf.privileged`
   :   Specifies whether privileged mode is enabled. Must be set to `true` for packet drop tracking.

**Verification**

- When you refresh the **Network Traffic** page, the **Overview**, **Traffic Flow**, and **Topology** views display new information about packet drops:

  1. Select new choices in **Manage panels** to choose which graphical visualizations of packet drops to display in the **Overview**.
  2. Select new choices in **Manage columns** to choose which packet drop information to display in the **Traffic flows** table.

     1. In the **Traffic Flows** view, you can also expand the side panel to view more information about packet drops. Host drops are prefixed with `SKB_DROP` and OVS drops are prefixed with `OVS_DROP`.
  3. In the **Topology** view, red lines are displayed where drops are present.

**Additional resources**
{._additional-resources}

- [Network Observability metrics](/openshift-docs-markdown/observability/network_observability/metrics-alerts-dashboards#network-observability-metrics_metrics-dashboards-alerts)

### DNS tracking {#network-observability-dns-overview_nw-observe-network-traffic}

Monitor DNS activity by using eBPF-based DNS tracking to gain insights into query patterns, detect security threats, and troubleshoot latency issues through dedicated graphical panels in the **Overview** view.

You can configure graphical representation of Domain Name System (DNS) tracking of network flows in the **Overview** view. Using DNS tracking with extended Berkeley Packet Filter (eBPF) tracepoint hooks can serve various purposes:

- Network Monitoring: Gain insights into DNS queries and responses, helping network administrators identify unusual patterns, potential bottlenecks, or performance issues.
- Security Analysis: Detect suspicious DNS activities, such as domain name generation algorithms (DGA) used by malware, or identify unauthorized DNS resolutions that might indicate a security breach.
- Troubleshooting: Debug DNS-related issues by tracing DNS resolution steps, tracking latency, and identifying misconfigurations.

By default, when DNS tracking is enabled, you can see the following non-empty metrics represented in a donut or line chart in the **Overview**:

- Top X DNS Response Code
- Top X average DNS latencies with overall
- Top X 90th percentile DNS latencies

Other DNS tracking panels can be added in **Manage panels**:

- Bottom X minimum DNS latencies
- Top X maximum DNS latencies
- Top X 99th percentile DNS latencies

This feature is supported for IPv4 and IPv6 UDP and TCP protocols.

See the *Additional resources* in this section for more information about enabling and working with this view.

### Working with DNS tracking {#network-observability-dns-tracking_nw-observe-network-traffic}

Configure the `FlowCollector` custom resource to enable DNS tracking for monitoring network performance, security analysis, and DNS troubleshooting in the web console.

You can track DNS by editing the `FlowCollector` to the specifications in the following YAML example.

> [!IMPORTANT]
> CPU and memory usage increases are observed in the eBPF agent when this feature is enabled.

**Procedure**

1. In the web console, navigate to **Ecosystem** → **Installed Operators**.
2. Under the **Provided APIs** heading for **Network Observability**, select **Flow Collector**.
3. Select **cluster** then select the **YAML** tab.
4. Configure the `FlowCollector` custom resource. A sample configuration is as follows: <a name="network-observability-flowcollector-configuring-dns_nw-observe-network-traffic"></a>

   ```yaml {title="Configure FlowCollector for DNS tracking"}
   apiVersion: flows.netobserv.io/v1beta2
   kind: FlowCollector
   metadata:
     name: cluster
   spec:
     namespace: netobserv
     agent:
       type: eBPF
       ebpf:
         features:
          - DNSTracking
         sampling: 1
   ```

   - You can set the `spec.agent.ebpf.features` parameter list to enable DNS tracking of each network flow in the web console.
   - You can set `sampling` to a value of `1` for more accurate metrics and to capture **DNS latency**. For a `sampling` value greater than 1, you can observe flows with **DNS Response Code** and **DNS Id**, and it is unlikely that **DNS Latency** can be observed.
5. When you refresh the **Network Traffic** page, there are new DNS representations you can choose to view in the **Overview** and **Traffic Flow** views and new filters you can apply.

   1. Select new DNS choices in **Manage panels** to display graphical visualizations and DNS metrics in the **Overview**.
   2. Select new choices in **Manage columns** to add DNS columns to the **Traffic Flows** view.
   3. Filter on specific DNS metrics, such as **DNS Id**, **DNS Error** **DNS Latency** and **DNS Response Code**, and see more information from the side panel. The **DNS Latency** and **DNS Response Code** columns are shown by default.

      > [!NOTE]
      > TCP handshake packets do not have DNS headers. TCP protocol flows without DNS headers are shown in the traffic flow data with **DNS Latency**, **ID**, and **Response code** values of "n/a". You can filter out flow data to view only flows that have DNS headers using the **Common** filter "DNSError" equal to "0".

**Additional resources**
{._additional-resources}

- [Network Observability metrics](/openshift-docs-markdown/observability/network_observability/metrics-alerts-dashboards#network-observability-metrics_metrics-dashboards-alerts)

### Round-Trip Time {#network-observability-RTT-overview_nw-observe-network-traffic}

Analyze network flow latencies by using TCP Round-Trip Time (RTT) metrics, which use eBPF hookpoints to identify performance bottlenecks and troubleshoot TCP-related issues through dedicated panels in the Overview view.

You can use TCP smoothed Round-Trip Time (sRTT) to analyze network flow latencies. You can use RTT captured from the `fentry/tcp_rcv_established` eBPF hookpoint to read sRTT from the TCP socket to help with the following:

- Network Monitoring: Gain insights into TCP latencies, helping network administrators identify unusual patterns, potential bottlenecks, or performance issues.
- Troubleshooting: Debug TCP-related issues by tracking latency and identifying misconfigurations.

By default, when RTT is enabled, you can see the following TCP RTT metrics represented in the **Overview**:

- Top X 90th percentile TCP Round Trip Time with overall
- Top X average TCP Round Trip Time with overall
- Bottom X minimum TCP Round Trip Time with overall

Other RTT panels can be added in **Manage panels**:

- Top X maximum TCP Round Trip Time with overall
- Top X 99th percentile TCP Round Trip Time with overall

See the *Additional resources* in this section for more information about enabling and working with this view.

### Working with RTT tracing {#network-observability-RTT_nw-observe-network-traffic}

Enable Round Trip Time (RTT) tracing by configuring the `FlowCollector` custom resource to monitor and analyze network latency across your cluster by using the web console.

You can track RTT by editing the `FlowCollector` to the specifications in the following YAML example.

**Procedure**

1. In the web console, navigate to **Ecosystem** → **Installed Operators**.
2. In the **Provided APIs** heading for the **NetObserv Operator**, select **Flow Collector**.
3. Select **cluster**, and then select the **YAML** tab.
4. Configure the `FlowCollector` custom resource for RTT tracing, for example: <a name="network-observability-flowcollector-configuring-RTT_nw-observe-network-traffic"></a>

   ```yaml {title="Example FlowCollector configuration"}
   apiVersion: flows.netobserv.io/v1beta2
   kind: FlowCollector
   metadata:
     name: cluster
   spec:
     namespace: netobserv
     agent:
       type: eBPF
       ebpf:
         features:
          - FlowRTT
   ```

   where:

   `spec.agent.ebpf.features`
   :   Specifies the list of eBPF features to enable. Add `FlowRTT` to this list to start tracing Round-trip time (RTT) network flows.

**Verification**

After the **Network Traffic** page is refreshed, the **Overview**, **Traffic flows**, and **Topology** views display RTT information.

1. In the **Overview** view, click **Manage panels** to select the RTT graphical visualizations to display.
2. In the **Traffic flows** table, verify that the **Flow RTT** column is visible by default. To manage columns, click **Manage columns**.
3. In the **Traffic flows** view, expand the side panel to view RTT metadata:

   1. Filter the flow data for the **TCP** protocol by entering `protocol=TCP` in the filter search bar.
   2. Verify that all TCP filtered flows have **FlowRTT** values greater than `0`.
   3. Filter for **FlowRTT** values greater than `10,000,000` nanoseconds (10 ms) by entering `time_flow_rtt>=10000000` in the filter search bar.
   4. Remove the filters.
4. In the **Topology** view, click the **Display** option drop-down menu. In the **Edge labels** list, select **RTT**.

### eBPF flow rule filter {#network-observability-ebpf-flow-rule-filter_nw-observe-network-traffic}

Control packet capture volume by using eBPF flow rule filtering to specify capture criteria based on ports and CIDR notation, while monitoring filter performance through dedicated health dashboards and Prometheus metrics.

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.

#### Ingress and egress traffic filtering {#ingress-and-egress-traffic-filtering_nw-observe-network-traffic}

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.

#### Dashboard and metrics integrations {#dashboard-and-metrics-integrations_nw-observe-network-traffic}

When this option is enabled, the **Netobserv/Health** dashboard for **eBPF agent statistics** now has the **Filtered flows rate** view. Additionally, in **Observe** → **Metrics** you can query `netobserv_agent_filtered_flows_total` to observe metrics with the reason in **FlowFilterAcceptCounter**, **FlowFilterNoMatchCounter** or **FlowFilterRecjectCounter**.

#### Flow filter configuration parameters {#network-observability-flowcollector-flowfilter-parameters_nw-observe-network-traffic}

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.

**Required configuration parameters**

<table>
<thead>
<tr>
  <th>Parameter</th>
  <th>Description</th>
</tr>
</thead>
<tbody>
<tr>
  <td><code>enable</code></td>
  <td>Set <code>enable</code> to <code>true</code> to enable the eBPF flow filtering feature.</td>
</tr>
<tr>
  <td><code>cidr</code></td>
  <td>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 <code>0.0.0.0/0</code> for IPv4 or <code>::/0</code> for IPv6.</td>
</tr>
<tr>
  <td><code>action</code></td>
  <td>Describes the action that is taken for the flow filter rule. The possible values are <code>Accept</code> or <code>Reject</code>.<br><br><ul><li>For the <code>Accept</code> action matching rule, the flow data is cached in the eBPF table and updated with the global metric, <code>FlowFilterAcceptCounter</code>.</li><li>For the <code>Reject</code> action matching rule, the flow data is dropped and not cached in the eBPF table. The flow data is updated with the global metric, <code>FlowFilterRejectCounter</code>.</li><li>If the rule is not matched, the flow is cached in the eBPF table and updated with the global metric, <code>FlowFilterNoMatchCounter</code>.</li></ul></td>
</tr>
</tbody>
</table>

**Optional configuration parameters**

<table>
<thead>
<tr>
  <th>Parameter</th>
  <th>Description</th>
</tr>
</thead>
<tbody>
<tr>
  <td><code>direction</code></td>
  <td>Defines the direction of the flow filter rule. Possible values are <code>Ingress</code> or <code>Egress</code>.</td>
</tr>
<tr>
  <td><code>protocol</code></td>
  <td>Defines the protocol of the flow filter rule. Possible values are <code>TCP</code>, <code>UDP</code>, <code>SCTP</code>, <code>ICMP</code>, and <code>ICMPv6</code>.</td>
</tr>
<tr>
  <td><code>tcpFlags</code></td>
  <td>Defines the TCP flags to filter flows. Possible values are <code>SYN</code>, <code>SYN-ACK</code>, <code>ACK</code>, <code>FIN</code>, <code>RST</code>, <code>PSH</code>, <code>URG</code>, <code>ECE</code>, <code>CWR</code>, <code>FIN-ACK</code>, and <code>RST-ACK</code>.</td>
</tr>
<tr>
  <td><code>ports</code></td>
  <td>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 <code>ports: 80</code>. To filter a range of ports, use a "start-end" range in string format. For example <code>ports: "80-100"</code></td>
</tr>
<tr>
  <td><code>sourcePorts</code></td>
  <td>Defines the source port to use for filtering flows. To filter a single port, set a single port as an integer value, for example <code>sourcePorts: 80</code>. To filter a range of ports, use a "start-end" range, string format, for example <code>sourcePorts: "80-100"</code>.</td>
</tr>
<tr>
  <td><code>destPorts</code></td>
  <td>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 <code>destPorts: 80</code>. To filter a range of ports, use a "start-end" range in string format, for example <code>destPorts: "80-100"</code>.</td>
</tr>
<tr>
  <td><code>icmpType</code></td>
  <td>Defines the ICMP type to use for filtering flows.</td>
</tr>
<tr>
  <td><code>icmpCode</code></td>
  <td>Defines the ICMP code to use for filtering flows.</td>
</tr>
<tr>
  <td><code>peerIP</code></td>
  <td>Defines the IP address to use for filtering flows, for example: <code>10.10.10.10</code>.</td>
</tr>
</tbody>
</table>

### Filtering eBPF flow data using multiple rules {#network-observability-filtering-ebpf-rule_nw-observe-network-traffic}

Configure multiple filtering rules in the `FlowCollector` custom resource to refine network traffic data collection by accepting or rejecting specific eBPF flows based on IP addresses and packet conditions.

> [!IMPORTANT]
> - You cannot use duplicate Classless Inter-Domain Routing (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**

1. In the web console, navigate to **Ecosystem** → **Installed Operators**.
2. Under the **Provided APIs** heading for **Network Observability**, select **Flow Collector**.
3. Select **cluster**, then select the **YAML** tab.
4. Configure the `FlowCollector` custom resource.

### eBPF flow data filtering examples {#network-observability-ebpf-flow-data-filtering-examples_nw-observe-network-traffic}

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 {#example-yaml-sample-all-north-south-traffic_nw-observe-network-traffic}

By default, all other flows are rejected.

```yaml
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 {#example-yaml-filter-flows-with-packet-drops_nw-observe-network-traffic}

By default, all other flows are rejected.

```yaml
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.

**Additional resources**
{._additional-resources}

- [Network Observability metrics](/openshift-docs-markdown/observability/network_observability/metrics-alerts-dashboards#network-observability-metrics_metrics-dashboards-alerts)
- [Health dashboards](/openshift-docs-markdown/observability/network_observability/network-observability-operator-monitoring#network-observability-health-dashboard-overview_network_observability)

### User-defined networks {#network-observability-user-defined-networks_nw-observe-network-traffic}

Understand how you can use user-defined networks (UDN) for flexible network segmentation and leverage the Network Observability Operator to monitor these segments through dedicated labels and name filters in the traffic flow table.

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.

UDNs enable a wide range of network architectures and topologies, enhancing network flexibility, security, and performance.

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**.

### Working with user-defined networks {#network-observability-working-with-udn_nw-observe-network-traffic}

Configure the `FlowCollector` custom resource to enable user-defined network (UDN) mapping, providing visibility into traffic across custom network interfaces within the web console.

You can enable user-defined networks (UDN) in network observability resources. The following example shows the configuration for the `FlowCollector` resource.

**Prerequisite**

- You have configured UDN in Red Hat OpenShift Networking. For more information, see "Creating a UserDefinedNetwork by using the CLI" or "Creating a UserDefinedNetwork by using the web console."

**Procedure**

1. Edit the network observability `FlowCollector` resource by running the following command:

   ```terminal
   $ oc edit flowcollector
   ```
2. Configure the `ebpf` section of the `FlowCollector` resource:

   ```yaml
   apiVersion: flows.netobserv.io/v1beta2
   kind: FlowCollector
   metadata:
     name: cluster
   spec:
     agent:
       ebpf:
         sampling: 1
         privileged: true
         features:
         - UDNMapping
   ```

   where:

   `spec.agent.ebpf.sampling`
   :   Specifies sampling rate for network events. Set to a value of `1` to capture all network events. If sampling `1` is too resource heavy, set sampling to something more appropriate for your needs.

   `spec.agent.ebpf.privileged`
   :   Specifies whether privileged mode is enabled. Must be set to `true` for user-defined network mapping.

**Verification**

- Refresh the **Network Traffic** page to view updated UDN information in the **Traffic Flow** and **Topology** views:

  - In **Network Traffic** > **Traffic flows**, you can view UDNs under the `SrcK8S_NetworkName` and `DstK8S_NetworkName` fields.
  - In the **Topology** view, you can set **Network** as **Scope** or **Group**.

**Additional resources**
{._additional-resources}

- [About user-defined networks](/openshift-docs-markdown/networking/multiple_networks/primary_networks/about-user-defined-networks#about-user-defined-networks)
- [Creating a UserDefinedNetwork by using the CLI](/openshift-docs-markdown/networking/multiple_networks/primary_networks/about-user-defined-networks#nw-udn-cr_about-user-defined-networks)
- [Creating a UserDefinedNetwork by using the web console](/openshift-docs-markdown/networking/multiple_networks/primary_networks/about-user-defined-networks#nw-udn-cr-ui_about-user-defined-networks)

### OVN-Kubernetes networking events {#network-observability-networking-events-overview_nw-observe-network-traffic}

Use OVN-Kubernetes network event tracking to monitor and audit network policies, admin network policies, and egress firewall rules in your cluster.

> [!IMPORTANT]
> OVN-Kubernetes networking events tracking is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
>
> For more information about the support scope of Red Hat Technology Preview features, see [Technology Preview Features Support Scope](https://access.redhat.com/support/offerings/techpreview/).

You can use the insights from tracking network events to help with the following tasks:

- Network monitoring: Monitor allowed and blocked traffic, detecting whether packets are allowed or blocked based on network policies and admin network policies.
- Network security: You can track outbound traffic and see whether it adheres to egress firewall rules. Detect unauthorized outbound connections and flag outbound traffic that violates egress rules.

See the *Additional resources* in this section for more information about enabling and working with this view.

### Viewing network events {#network-observability-viewing-network-events_nw-observe-network-traffic}

Configure the `FlowCollector` custom resource to enable network event tracking for auditing how security policies, firewalls, and isolation rules affect traffic flows in the web console.

> [!IMPORTANT]
> OVN-Kubernetes networking events tracking is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
>
> For more information about the support scope of Red Hat Technology Preview features, see [Technology Preview Features Support Scope](https://access.redhat.com/support/offerings/techpreview/).

You can edit the `FlowCollector` to view information about network traffic events, such as network flows that are dropped or allowed by the following resources:

- `NetworkPolicy`
- `AdminNetworkPolicy`
- `BaselineNetworkPolicy`
- `EgressFirewall`
- `UserDefinedNetwork` isolation
- Multicast ACLs

**Prerequisites**

- You must have `OVNObservability` enabled by setting the `TechPreviewNoUpgrade` feature set in the `FeatureGate` custom resource (CR) named `cluster`. For more information, see "Enabling feature sets using the CLI" and "Checking OVN-Kubernetes network traffic with OVS sampling using the CLI".
- You have created at least one of the following network APIs: `NetworkPolicy`, `AdminNetworkPolicy`, `BaselineNetworkPolicy`, `UserDefinedNetwork` isolation, multicast, or `EgressFirewall`.

**Procedure**

1. In the web console, navigate to **Ecosystem** → **Installed Operators**.
2. In the **Provided APIs** heading for the **NetObserv Operator**, select **Flow Collector**.
3. Select **cluster**, and then select the **YAML** tab.
4. Configure the `FlowCollector` CR to enable viewing `NetworkEvents`, for example: <a name="network-observability-flowcollector-configuring-networkevents_nw-observe-network-traffic"></a>

   ```yaml {title="Example FlowCollector configuration"}
   apiVersion: flows.netobserv.io/v1beta2
   kind: FlowCollector
   metadata:
     name: cluster
   spec:
      agent:
       type: eBPF
       ebpf:
     #   sampling: 1
         privileged: true
         features:
          - "NetworkEvents"
   ```

   where:

   `spec.agent.ebpf.sampling`
   :   Specifies the sampling rate for network events. Set to a value of `1` to capture all network events. If the sampling `1` is too resource heavy, set sampling to something more appropriate for your needs. This value is optional.

   `spec.agent.ebpf.privileged`
   :   Specifies whether the eBPF agent runs in privileged mode. Set to `true` because the OVN observability library needs to access local Open vSwitch (OVS) socket and Open Virtual Network (OVN) databases.

**Verification**

1. Navigate to the **Network Traffic** view and select the **Traffic flows** table.
2. You should see the new column, **Network Events**, where you can view information about impacts of one of the following network APIs you have enabled: `NetworkPolicy`, `AdminNetworkPolicy`, `BaselineNetworkPolicy`, `UserDefinedNetwork` isolation, multicast, or egress firewalls.

   An example of the kind of events you could see in this column is as follows:

   ```text {title="Example of Network Events output"}
   <Dropped_or_Allowed> by <network_event_and_event_name>, direction <Ingress_or_Egress>
   ```

**Additional resources**
{._additional-resources}

- [Enabling feature sets using the CLI](/openshift-docs-markdown/nodes/clusters/nodes-cluster-enabling-features#nodes-cluster-enabling-features-cli_nodes-cluster-enabling-features)
- [Checking OVN-Kubernetes network traffic with OVS sampling using the CLI](/openshift-docs-markdown/networking/ovn_kubernetes_network_provider/ovn-kubernetes-troubleshooting-sources#nw-ovn-kubernetes-observability_ovn-kubernetes-sources-of-troubleshooting-information)

## Observing the network traffic from the Traffic flows view {#network-observability-trafficflow_nw-observe-network-traffic}

Use the **Traffic flows** view to monitor real-time and historical network communication between cluster components. By analyzing granular flow data collected via eBPF, you can audit network traffic, validate network policies, and export data for external reporting and analysis.

The **Traffic flows** view in the Network Observability Operator provides a granular, tabular representation of network activity across a OpenShift Container Platform cluster. By leveraging eBPF technology to collect flow data, this view allows administrators to monitor real-time and historical communication between pods, services, and nodes. This visibility is essential for auditing network traffic, validating network policies, and identifying unexpected communication patterns within the cluster infrastructure.

In the **Traffic flows** interface, you can analyze specific connection details by interacting with individual rows to retrieve detailed flow information. The view supports advanced customization through the **Display options** menu, where you can adjust row density and manage columns. By selecting and reordering specific columns, you can tailor the table to highlight the most relevant data points for your environment, such as source and destination endpoints or traffic volume.

To support external analysis and reporting, the **Traffic flows** view includes data export capabilities. You can export the entire dataset or select specific fields to generate a targeted report of network activity. This functionality ensures that network flow data is accessible for long-term auditing or for use in third-party monitoring tools, providing a flexible way to document and analyze the network health of your OpenShift Container Platform environment.

### Working with the Traffic flows view {#network-observability-working-with-trafficflow_nw-observe-network-traffic}

View and analyze detailed network flow information by using the **Traffic flows** table.

As an administrator, you can navigate to **Traffic flows** table to see network flow information.

**Prerequisite**

- You have administrator access.

**Procedure**

1. Navigate to **Observe** → **Network Traffic**.
2. In the **Network Traffic** page, click the **Traffic flows** tab.
3. Click on each row to get the corresponding flow information.

### Traffic flow display settings {#network-observability-configuring-options-trafficflow_nw-observe-network-traffic}

The **Traffic flows** view contains settings to customize the display density, data columns, and data export options.

#### Display options {#display-options_nw-observe-network-traffic}

The following elements are available in the **Traffic flows** view:

**Show advanced options**
:   Specifies a menu to customize and export the current view.

**Display options** drop-down
:   Specifies the row size for the data table. The default value is **Normal**.

**Manage columns**
:   Specifies a dialog to select and reorder the columns displayed in the **Traffic flows** table.

### Exporting traffic flow data {#network-observability-exporting-traffic-flow-data_nw-observe-network-traffic}

Export network flow data from the **Traffic flows** view to a CSV file for external analysis or reporting.

**Procedure**

1. Click **Export data**.
2. In the window, select the **Export all data** checkbox to export all the data, and clear the checkbox to select the required fields to be exported.
3. Click **Export**.

### Configuring IPsec with the FlowCollector custom resource {#network-observability-configuring-ipsec-with-flow-collector-resource_nw-observe-network-traffic}

Enable IPsec tracking in the `FlowCollector` resource to monitor encrypted traffic, adding an IPsec status column to the traffic flow view and generating a dedicated encryption dashboard.

In OpenShift Container Platform, IPsec is disabled by default. You can enable IPsec by following the instructions in "Configuring IPsec encryption".

**Prerequisite**

- You have enabled IPsec encryption on OpenShift Container Platform.

**Procedure**

1. In the web console, navigate to **Ecosystem** → **Installed Operators**.
2. Under the **Provided APIs** heading for the **NetObserv Operator**, select **Flow Collector**.
3. Select **cluster** then select the **YAML** tab.
4. Configure the `FlowCollector` custom resource for IPsec:

   ```yaml {title="Example configuration of FlowCollector for IPsec"}
   apiVersion: flows.netobserv.io/v1beta2
   kind: FlowCollector
   metadata:
     name: cluster
   spec:
     namespace: netobserv
     agent:
       type: eBPF
       ebpf:
         features:
         - "IPSec"
   ```

**Verification**

When IPsec is enabled:

- A new column named **IPsec Status** is displayed in the network observability **Traffic flows** view to show whether a flow was successfully IPsec-encrypted or if there was an error during encryption/decryption.
- A new dashboard showing the percent of encrypted traffic is generated.

**Additional resources**
{._additional-resources}

- [Configuring IPsec encryption](/openshift-docs-markdown/networking/network_security/configuring-ipsec-ovn#configuring-ipsec-ovn)

### Working with conversation tracking {#network-observability-working-with-conversations_nw-observe-network-traffic}

Configure the `FlowCollector` custom resource to enable conversation tracking for grouping and analyzing related network flows in the web console.

As an administrator, you can group network flows that are part of the same conversation. A conversation is defined as a grouping of peers that are identified by their IP addresses, ports, and protocols, resulting in an unique **Conversation Id**. You can query conversation events in the web console. These events are represented in the web console as follows:

- **Conversation start**: This event happens when a connection is starting or TCP flag intercepted
- **Conversation tick**: This event happens at each specified interval defined in the `FlowCollector` `spec.processor.conversationHeartbeatInterval` parameter while the connection is active.
- **Conversation end**: This event happens when the `FlowCollector` `spec.processor.conversationEndTimeout` parameter is reached or  the TCP flag is intercepted.
- **Flow**: This is the network traffic flow that occurs within the specified interval.

**Procedure**

1. In the web console, navigate to **Ecosystem** → **Installed Operators**.
2. Under the **Provided APIs** heading for the **NetObserv Operator**, select **Flow Collector**.
3. Select **cluster** then select the **YAML** tab.
4. Configure the `FlowCollector` custom resource so that `spec.processor.logTypes`, `conversationEndTimeout`, and `conversationHeartbeatInterval` parameters are set according to your observation needs. A sample configuration is as follows:

   ```yaml {title="Configure FlowCollector for conversation tracking"}
   apiVersion: flows.netobserv.io/v1beta2
   kind: FlowCollector
   metadata:
     name: cluster
   spec:
    processor:
     logTypes: Flows
     advanced:
      conversationEndTimeout: 10s
      conversationHeartbeatInterval: 30s
   ```

   where:

   `spec.processor.logTypes`
   :   Specifies the types of events to export. When set to `Flows`, only the Flow event is exported. When set to `All`, both conversation and flow events are exported and visible in the **Network Traffic** page. To focus only on conversation events, specify `Conversations` to export **Conversation start**, **Conversation tick**, and **Conversation end** events. To export only the **Conversation end** events, specify `EndedConversations`. Storage requirements are highest for `All` and lowest for `EndedConversations`.

   `spec.processor.advanced.conversationEndTimeout`
   :   Specifies the duration at which a **Conversation end** event is triggered once the timeout is reached or a TCP flag is intercepted.

   `spec.processor.advanced.conversationHeartbeatInterval`
   :   Specifies the interval for the **Conversation tick** event while the network connection is active.

   > [!NOTE]
   > If you update the `logType` option, the flows from the previous selection do not clear from the console plugin. For example, if you initially set `logType` to `Conversations` for a span of time until 10 AM and then move to `EndedConversations`, the console plugin shows all conversation events before 10 AM and only ended conversations after 10 AM.
5. Refresh the **Network Traffic** page on the **Traffic flows** tab. Notice there are two new columns, **Event/Type** and **Conversation Id**. All the **Event/Type** fields are `Flow` when **Flow** is the selected query option.
6. Select **Query Options** and choose the **Log Type**, **Conversation**. Now the **Event/Type** shows all of the desired conversation events.
7. Next you can filter on a specific conversation ID or switch between the **Conversation** and **Flow** log type options from the side panel.

### Working with the eBPF Manager Operator {#network-observability-ebpf-manager-operator_nw-observe-network-traffic}

Integrate the eBPF Manager Operator with Network Observability to manage eBPF programs and reduce the need for privileged agent permissions.

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.

> [!IMPORTANT]
> eBPF Manager Operator with network observability is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
>
> For more information about the support scope of Red Hat Technology Preview features, see [Technology Preview Features Support Scope](https://access.redhat.com/support/offerings/techpreview/).

**Procedure**

1. In the web console, navigate to **Ecosystem** → **Operator Hub**.
2. Install **eBPF Manager**.
3. Check **Workloads** → **Pods** in the `bpfman` namespace to make sure they are all up and running.
4. Configure the `FlowCollector` custom resource to use the eBPF Manager Operator:

   ```yaml {title="Example FlowCollector configuration"}
   apiVersion: flows.netobserv.io/v1beta2
   kind: FlowCollector
   metadata:
     name: cluster
   spec:
     agent:
       ebpf:
         features:
           - EbpfManager
   ```

**Verification**

1. In the web console, navigate to **Ecosystem** → **Installed Operators**.
2. Click **eBPF Manager Operator** → **All instances** tab.

   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.

**Additional resources**
{._additional-resources}

- [Installing the eBPF Manager Operator](/openshift-docs-markdown/networking/networking_operators/ebpf_manager/ebpf-manager-operator-install)

### Using the histogram {#network-observability-histogram-trafficflow_nw-observe-network-traffic}

The histogram provides a visualization of network flow logs that you can use to analyze traffic volume trends and filter flow data by specific time intervals.

You can click **Show histogram** to display a toolbar view for visualizing the history of flows as a bar chart. The histogram shows the number of logs over time. You can select a part of the histogram to filter the network flow data in the table that follows the toolbar.

### Working with availability zones {#network-observability-zones_nw-observe-network-traffic}

Configure the `FlowCollector` custom resource to collect availability zone data, enabling the visualization and analysis of network traffic across different cluster zones in the web console.

You can configure the `FlowCollector` to collect information about the cluster availability zones. This allows you to enrich network flow data with the [`topology.kubernetes.io/zone`](https://kubernetes.io/docs/reference/labels-annotations-taints/#topologykubernetesiozone) label value applied to the nodes.

**Procedure**

1. In the web console, go to **Ecosystem** → **Installed Operators**.
2. Under the **Provided APIs** heading for the **NetObserv Operator**, select **Flow Collector**.
3. Select **cluster** then select the **YAML** tab.
4. Configure the `FlowCollector` custom resource so that the `spec.processor.addZone` parameter is set to `true`. A sample configuration is as follows:

   ```yaml {title="Configure FlowCollector for availability zones collection"}
   apiVersion: flows.netobserv.io/v1beta2
   kind: FlowCollector
   metadata:
     name: cluster
   spec:
   # ...
    processor:
      addZone: true
   # ...
   ```

**Verification**

When you refresh the **Network Traffic** page, the **Overview**, **Traffic Flow**, and **Topology** views display new information about availability zones:

1. In the **Overview** tab, you can see **Zones** as an available **Scope**.
2. In **Network Traffic** → **Traffic flows**, **Zones** are viewable under the SrcK8S_Zone and DstK8S_Zone fields.
3. In the **Topology** view, you can set **Zones** as **Scope** or **Group**.

**Additional resources**
{._additional-resources}

- [Conntrack Zone ID](https://lwn.net/Articles/370152/#:~:text=A%20zone%20is%20simply%20a,to%20seperate%20conntrack%20defragmentation%20queues.)

### Endpoint translation (xlat) {#network-observability-packet-translation-overview_nw-observe-network-traffic}

Endpoint translation (xlat) uses eBPF to enrich network flow logs with translated pod-level metadata, providing visibility into the specific backend pods serving traffic behind services or load balancers.

You can gain visibility into the endpoints serving traffic in a consolidated view using network observability and extended Berkeley Packet Filter (eBPF). Typically, when traffic flows through a service, egressIP, or load balancer, the traffic flow information is abstracted as it is routed to one of the available pods. If you try to get information about the traffic, you can only view service related info, such as service IP and port, and not information about the specific pod that is serving the request. Often the information for both the service traffic and the virtual service endpoint is captured as two separate flows, which complicates troubleshooting.

To solve this, endpoint xlat can help in the following ways:

- Capture the network flows at the kernel level, which has a minimal impact on performance.
- Enrich the network flows with translated endpoint information, showing not only the service but also the specific backend pod, so you can see which pod served a request.

As network packets are processed, the eBPF hook enriches flow logs with metadata about the translated endpoint that includes the following pieces of information that you can view in the **Network Traffic** page in a single row:

- Source Pod IP
- Source Port
- Destination Pod IP
- Destination Port
- Conntrack Zone ID

### Working with endpoint translation (xlat) {#network-observability-packet-translation_nw-observe-network-traffic}

Enable endpoint translation (xlat) in the `FlowCollector` resource to enrich network flows with translated packet information. You can use this information to identify the specific pods and objects serving service traffic through dedicated xlat columns.

You can use network observability and eBPF to enrich network flows from a Kubernetes service with translated endpoint information, gaining insight into the endpoints serving traffic.

**Procedure**

1. In the web console, navigate to **Ecosystem** → **Installed Operators**.
2. In the **Provided APIs** heading for the **NetObserv Operator**, select **Flow Collector**.
3. Select **cluster**, and then select the **YAML** tab.
4. Configure the `FlowCollector` custom resource for `PacketTranslation`, for example: <a name="network-observability-flowcollector-configuring-packet-translation_nw-observe-network-traffic"></a>

   ```yaml {title="Example FlowCollector configuration"}
   apiVersion: flows.netobserv.io/v1beta2
   kind: FlowCollector
   metadata:
     name: cluster
   spec:
     namespace: netobserv
     agent:
       type: eBPF
       ebpf:
         features:
          - PacketTranslation
   ```

   - You can start enriching network flows with translated packet information by listing the `PacketTranslation` parameter in the `spec.agent.ebpf.features` specification list.
5. Refresh the **Network Traffic** page to filter for information about translated packets:

   1. Filter the network flow data based on **Destination kind: Service**.
   2. You can see the **xlat** column, which distinguishes where translated information is displayed, and the following default columns:

      - **Xlat Zone ID**
      - **Xlat Src Kubernetes Object**
      - **Xlat Dst Kubernetes Object**
   3. You can manage the display of additional **xlat** columns in **Manage columns**.

## Observing the network traffic from the Topology view {#network-observability-topology_nw-observe-network-traffic}

The **Topology** view in the **Network Traffic** page provides a graphical representation of network flows and traffic volume across your OpenShift Container Platform cluster. As an administrator, you can use this view to monitor application traffic data and visualize the relationships between various network components.

The visualization represents network entities as nodes and traffic flows as edges. By selecting individual components within the graph, you can access a side panel containing specific metrics and health details for that resource. This interactive approach allows for rapid identification of traffic patterns and connectivity issues within the cluster.

To manage complex environments, the **Topology** view includes advanced configuration options that allow you to customize the layout and data density. You can adjust the **Scope** of the view, apply **Groups** to represent resource ownership, and choose different **Layout** algorithms to optimize the graphical display. Additionally, you can enable **Edge labels** to show real-time measurements, such as the average byte rate, directly on the flow lines.

For reporting or external analysis, the **Topology** view provides an export feature. You can download the current graphical representation as a PNG image or generate a direct link to the specific view configuration to share with other administrators. These tools ensure that network insights are both accessible and easily documented.

### Working with the Topology view {#network-observability-working-with-topology_nw-observe-network-traffic}

Access the **Topology** view to visually inspect cluster network relationships and select individual components to view detailed traffic metrics and metadata.

As an administrator, you can navigate to the **Topology** view to see the details and metrics of the component.

**Prerequisites**

- You have administrator access.

**Procedure**

1. Navigate to **Observe** → **Network Traffic**.
2. In the **Network Traffic** page, click the **Topology** tab.
3. Click each component in the **Topology** tab to view its details and metrics.

### Configuring the advanced options for the Topology view {#network-observability-configuring-options-topology_nw-observe-network-traffic}

Review the available advanced options in the **Topology** view to customize display settings, configure component grouping and layouts, and export the network graph as an image.

You can customize and export the view by using **Show advanced options**. The advanced options view has the following features:

- **Find in view**: To search the required components in the view.
- **Display options**: To configure the following options:

  - **Edge labels**: To show the specified measurements as edge labels. The default is to show the **Average rate** in **Bytes**.
  - **Scope**: To select the scope of components between which the network traffic flows. The default value is **Namespace**.
  - **Groups**: To enhance the understanding of ownership by grouping the components. The default value is **None**.
  - **Layout**: To select the layout of the graphical representation. The default value is **ColaNoForce**.
  - **Show**: To select the details that need to be displayed. All the options are checked by default. The options available are: **Edges**, **Edges label**, and **Badges**.
  - **Truncate labels**: To select the required width of the label from the drop-down list. The default value is **M**.
  - **Collapse groups**: To expand or collapse the groups. The groups are expanded by default. This option is disabled if **Groups** has the value of **None**.

#### Exporting the topology view {#network-observability-cao-export-topology_nw-observe-network-traffic}

To export the view, click **Export topology view**. The view is downloaded in PNG format.

## Filtering the network traffic {#network-observability-quickfilter_nw-observe-network-traffic}

Review the available query options and filtering parameters in the **Network Traffic** view to optimize data searches, analyze specific log types, and manage directional traffic visibility.

By default, the **Network Traffic** page displays the traffic flow data in the cluster based on the default filters configured in the `FlowCollector` instance. You can use the filter options to observe the required data by changing the preset filter.

Alternatively, you can access the traffic flow data in the **Network Traffic** tab of the **Namespaces**, **Services**, **Routes**, **Nodes**, and **Workloads** pages which provide the filtered data of the corresponding aggregations.

Query Options
:   You can use **Query Options** to optimize the search results, as listed below:

    - **Log Type**: The available options **Conversation** and **Flows** provide the ability to query flows by log type, such as flow log, new conversation, completed conversation, and a heartbeat, which is a periodic record with updates for long conversations. A conversation is an aggregation of flows between the same peers.
    - **Match filters**: You can determine the relation between different filter parameters selected in the advanced filter. The available options are **Match all** and **Match any**. **Match all**  provides results that match all the values, and **Match any** provides results that match any of the values entered. The default value is **Match all**.
    - **Datasource**: You can choose the datasource to use for queries: **Loki**, **Prometheus**, or **Auto**. Notable performance improvements can be realized when using Prometheus as a datasource rather than Loki, but Prometheus supports a limited set of filters and aggregations. The default datasource is **Auto**, which uses Prometheus on supported queries or uses Loki if the query does not support Prometheus.
    - **Drops filter**: You can view different levels of dropped packets with the following query options:

      - **Fully dropped** shows flow records with fully dropped packets.
      - **Containing drops** shows flow records that contain drops but can be sent.
      - **Without drops** shows records that contain sent packets.
      - **All** shows all the aforementioned records.

- **Limit**: The data limit for internal backend queries. Depending upon the matching and the filter settings, the number of traffic flow data is displayed within the specified limit.

Quick filters
:   The default values in **Quick filters** drop-down menu are defined in the `FlowCollector` configuration. You can modify the options from console.

Advanced filters
:   You can set the advanced filters, **Common**, **Source**, or **Destination**, by selecting the parameter to be filtered from the dropdown list. The flow data is filtered based on the selection. To enable or disable the applied filter, you can click on the applied filter listed below the filter options.

You can toggle between <img src="/images/arrow-up-long-solid.png" alt="arrow-up-long-solid" width="10"> **One way** and <img src="/images/arrow-up-long-solid.png" alt="arrow-up-long-solid" width="10"> <img src="/images/arrow-down-long-solid.png" alt="arrow-down-long-solid" width="10"> **Back and forth** filtering. The <img src="/images/arrow-up-long-solid.png" alt="arrow-up-long-solid" width="10"> **One way** filter shows only **Source** and **Destination** traffic according to your filter selections. You can use **Swap** to change the directional view of the **Source** and **Destination** traffic. The <img src="/images/arrow-up-long-solid.png" alt="arrow-up-long-solid" width="10"> <img src="/images/arrow-down-long-solid.png" alt="arrow-down-long-solid" width="10"> **Back and forth** filter includes return traffic with the **Source** and **Destination** filters. The directional flow of network traffic is shown in the **Direction** column in the Traffic flows table as `Ingress`or `Egress` for inter-node traffic and `Inner`for traffic inside a single node.

You can click **Reset defaults** to remove the existing filters, and apply the filter defined in `FlowCollector` configuration.

> [!NOTE]
> To understand the rules of specifying the text value, click **Learn More**.

**Additional resources**
{._additional-resources}

- [Configuring Quick Filters](/openshift-docs-markdown/observability/network_observability/configuring-operator#network-observability-config-quick-filters_network_observability)
- [Flow Collector sample resource](/openshift-docs-markdown/observability/network_observability/configuring-operator#network-observability-flowcollector-view_network_observability)