---
title: "Testing traffic"
slug: "testing-traffic"
updated: 2026-07-24T19:53:14Z
published: 2026-07-24T19:53:14Z
canonical: "docs.swxtch.io/testing-traffic"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.swxtch.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Testing traffic

> [!NOTE]
> **WHAT TO EXPECT**
> 
> In this article, users will learn how to test simple multicast traffic creation/consumption using provided tools.

## Provided tools

groundSwXtch provides a set of tools so users can test simple multicast traffic production/consumption. The tools are in a Docker container. Users should check [How to Install Docker on RHEL and Ubuntu](/v2/docs/how-to-install-docker-on-rhel-and-ubuntu).

To help test the groundSwXtch, swx tools can be installed on the groundSwXtch or any other VM using this command:

```shell
sudo ./install-groundswxtch.sh tools
```

This installs the tools as a Docker container. To run the tools, Docker is needed in the commands; see examples below:

```shell
sudo docker exec swx-tools swx-perf producer --nic enp0s5 --sendto 239.1.1.1:5555 --pps 1000 --seconds 30
sudo docker exec swx-tools swx-perf consumer --nic enp0s5 --recvfrom 239.1.1.1:5555
```

You can also log into an interactive bash shell in the container and execute the swx-perf command directly, by doing the following:

```shell
docker exec -it swx-tools bash
```

## Running swx-perf

swx-perf has two roles: a **producer** that sends multicast traffic and a **consumer** that receives it. Run them through `docker exec`:

```shell
sudo docker exec swx-tools swx-perf producer --nic gswx-lan --sendto 239.1.1.1:5555 --pps 1000 --seconds 30
sudo docker exec swx-tools swx-perf consumer --nic gswx-lan --recvfrom 239.1.1.1:5555 --json-report
```

The key flags:

- `--nic` — the interface to send on or receive from (see the note below on which one to use).
- `--sendto` **/** `--recvfrom` — the multicast group and port (`group:port`).
- `--pps` — packets per second for the producer.
- `--seconds` — how long the run lasts. Always set this so the producer self-terminates.
- `--json-report` — prints a structured packet and loss summary at the end of the run.

You can also log into an interactive bash shell in the container and run swx-perf directly:

```shell
docker exec -it swx-tools bash
```

For the full list of swx tools, refer to [Tools and Testing](https://claude.ai/v2/docs/testing).

## Choosing the network interface

The single most common cause of "0 packets" is the wrong `--nic`. The installer prints the suggested interface at the end of the install.

> **PLEASE NOTE**
> 
> If the user is running the tools in a VM that's also running groundSwXtch, the network interface must be the virtual interface gswx-lan. Only when generating traffic from a separate machine should the physical NIC (for example, enp0s5) be used.

Changing the LAN device between a virtual and a physical interface flushes the multicast subscriptions — they must be re-added afterward.

## Notes

- Ports must be 1024 or higher. Avoid 5000 and 6000 (reserved by spp) and 9999 (reserved by the swxtch ecosystem); 5555 is a safe choice.
- A `docker exec` started **without** `-it` does not forward `Ctrl+C` to swx-perf inside the container, so the producer keeps running as an orphan. Always bound the run with `--seconds`, or use `docker exec -it`. To stop a stray producer: `docker exec swx-tools pkill -INT -f swx-perf`.
- The `swx-tools` image is published for `linux/amd64` only.

Now the swx-tools can be run as normal; for swx-tools commands, refer to [Tools and Testing](/v2/docs/testing).

> [!NOTE]
> PLEASE NOTE
> 
> If the user is using the tools in a VM that’s running groundSwXtch, the network interface must be the virtual interface gswx-lan.

A software-based network switch that adds multicast to your physical networks as a softwared defined overlay. Link your facilities into a reliable multicast fabric.