1
0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-07 00:48:01 +01:00
Files
openshift-docs/modules/support-collecting-network-trace.adoc
2023-12-06 19:17:24 +00:00

133 lines
6.5 KiB
Plaintext

// Module included in the following assemblies:
//
// * support/gathering-cluster-data.adoc
:_mod-docs-content-type: PROCEDURE
[id="support-collecting-network-trace_{context}"]
= Collecting a network trace from an {product-title} node or container
When investigating potential network-related {product-title} issues, Red Hat Support might request a network packet trace from a specific {product-title} cluster node or from a specific container. The recommended method to capture a network trace in {product-title} is through a debug pod.
.Prerequisites
ifndef::openshift-rosa,openshift-dedicated[]
* You have access to the cluster as a user with the `cluster-admin` role.
endif::openshift-rosa,openshift-dedicated[]
ifdef::openshift-rosa,openshift-dedicated[]
* You have access to the cluster as a user with the `dedicated-admin` role.
endif::openshift-rosa,openshift-dedicated[]
* You have installed the OpenShift CLI (`oc`).
* You have a Red Hat standard or premium Subscription.
* You have a Red Hat Customer Portal account.
* You have an existing Red Hat Support case ID.
* You have SSH access to your hosts.
.Procedure
. Obtain a list of cluster nodes:
+
[source,terminal]
----
$ oc get nodes
----
. Enter into a debug session on the target node. This step instantiates a debug pod called `<node_name>-debug`:
+
[source,terminal]
----
$ oc debug node/my-cluster-node
----
. Set `/host` as the root directory within the debug shell. The debug pod mounts the host's root file system in `/host` within the pod. By changing the root directory to `/host`, you can run binaries contained in the host's executable paths:
+
[source,terminal]
----
# chroot /host
----
+
[NOTE]
====
{product-title} {product-version} cluster nodes running {op-system-first} are immutable and rely on Operators to apply cluster changes. Accessing cluster nodes by using SSH is not recommended. However, if the {product-title} API is not available, or the kubelet is not properly functioning on the target node, `oc` operations will be impacted. In such situations, it is possible to access nodes using `ssh core@<node>.<cluster_name>.<base_domain>` instead.
====
+
. From within the `chroot` environment console, obtain the node's interface names:
+
[source,terminal]
----
# ip ad
----
. Start a `toolbox` container, which includes the required binaries and plugins to run `sosreport`:
+
[source,terminal]
----
# toolbox
----
+
[NOTE]
====
If an existing `toolbox` pod is already running, the `toolbox` command outputs `'toolbox-' already exists. Trying to start...`. To avoid `tcpdump` issues, remove the running toolbox container with `podman rm toolbox-` and spawn a new toolbox container.
====
+
. Initiate a `tcpdump` session on the cluster node and redirect output to a capture file. This example uses `ens5` as the interface name:
+
[source,terminal]
----
$ tcpdump -nn -s 0 -i ens5 -w /host/var/tmp/my-cluster-node_$(date +%d_%m_%Y-%H_%M_%S-%Z).pcap <1>
----
<1> The `tcpdump` capture file's path is outside of the `chroot` environment because the toolbox container mounts the host's root directory at `/host`.
. If a `tcpdump` capture is required for a specific container on the node, follow these steps.
.. Determine the target container ID. The `chroot host` command precedes the `crictl` command in this step because the toolbox container mounts the host's root directory at `/host`:
+
[source,terminal]
----
# chroot /host crictl ps
----
+
.. Determine the container's process ID. In this example, the container ID is `a7fe32346b120`:
+
[source,terminal]
----
# chroot /host crictl inspect --output yaml a7fe32346b120 | grep 'pid' | awk '{print $2}'
----
+
.. Initiate a `tcpdump` session on the container and redirect output to a capture file. This example uses `49628` as the container's process ID and `ens5` as the interface name. The `nsenter` command enters the namespace of a target process and runs a command in its namespace. because the target process in this example is a container's process ID, the `tcpdump` command is run in the container's namespace from the host:
+
[source,terminal]
----
# nsenter -n -t 49628 -- tcpdump -nn -i ens5 -w /host/var/tmp/my-cluster-node-my-container_$(date +%d_%m_%Y-%H_%M_%S-%Z).pcap <1>
----
<1> The `tcpdump` capture file's path is outside of the `chroot` environment because the toolbox container mounts the host's root directory at `/host`.
. Provide the `tcpdump` capture file to Red Hat Support for analysis, using one of the following methods.
+
* Upload the file to an existing Red Hat support case directly from an {product-title} cluster.
.. From within the toolbox container, run `redhat-support-tool` to attach the file directly to an existing Red Hat Support case. This example uses support case ID `01234567`:
+
[source,terminal]
----
# redhat-support-tool addattachment -c 01234567 /host/var/tmp/my-tcpdump-capture-file.pcap <1>
----
<1> The toolbox container mounts the host's root directory at `/host`. Reference the absolute path from the toolbox container's root directory, including `/host/`, when specifying files to upload through the `redhat-support-tool` command.
+
* Upload the file to an existing Red Hat support case.
.. Concatenate the `sosreport` archive by running the `oc debug node/<node_name>` command and redirect the output to a file. This command assumes you have exited the previous `oc debug` session:
+
[source,terminal]
----
$ oc debug node/my-cluster-node -- bash -c 'cat /host/var/tmp/my-tcpdump-capture-file.pcap' > /tmp/my-tcpdump-capture-file.pcap <1>
----
<1> The debug container mounts the host's root directory at `/host`. Reference the absolute path from the debug container's root directory, including `/host`, when specifying target files for concatenation.
+
[NOTE]
====
{product-title} {product-version} cluster nodes running {op-system-first} are immutable and rely on Operators to apply cluster changes. Transferring a `tcpdump` capture file from a cluster node by using `scp` is not recommended. However, if the {product-title} API is not available, or the kubelet is not properly functioning on the target node, `oc` operations will be impacted. In such situations, it is possible to copy a `tcpdump` capture file from a node by running `scp core@<node>.<cluster_name>.<base_domain>:<file_path> <local_path>`.
====
+
.. Navigate to an existing support case within link:https://access.redhat.com/support/cases/#/case/list[the *Customer Support* page] of the Red Hat Customer Portal.
+
.. Select *Attach files* and follow the prompts to upload the file.
// TODO - Add details relating to https://github.com/openshift/must-gather/pull/156 within the procedure.