Netis cloud-probe moves captured packets off the box they were taken on

The problem is having no tap and no SPAN port

Cloud-probe solves a specific gap. The README frames it as capturing packets on device A and then using them for analysis on device B, which matters in two situations. The first is physical: there are no TAP or SPAN devices in the environment. The second is virtual: the virtual switch flow table does not support the SPAN function, so a virtual switch cannot mirror traffic the way a physical switch port analyser can. In both cases the usual answer is to run tcpdump on the box and copy files around, which does not scale past a couple of hosts and does not give you live analysis. The project's answer is a set of low overhead but high performance packet capture tools. The topic list on the repository names the environments it was designed for: cloud, docker, kubernetes, vxlan, gre, pcap, sniffer, and traffic.

cpworker does the capturing, cpdaemon manages it, CPM draws the graphs

Three pieces make up the system, and the split matters for what you can build yourself. cpworker is the data plane. It captures packets on the network card and sends them to a remote device through different output methods, which is what enables monitoring and analysis somewhere else. cpdaemon is the management program for cpworker: it can start and stop the worker. That module needs to work with CPM, the Cloud Probe Manager, which provides a user interface for configuring cpworker policies and for graphically displaying the statistical data that cpdaemon reports. The README states that CPM is not part of this open source project: you can contact Netis for support on CPM, or you can develop your own. The repository also holds cpctl, cpgolib, cptools, and a build directory, so the open source part covers the agents and their shared libraries, not the dashboard.

A JSON task file defines the capturer and the outputs

The worker is driven by a JSON configuration file. The example named libpcap_gre.json sets a log level, a control channel over a unix socket at /var/run/cloud-probe/cpworker.sock, and a task list. Each task pairs a request pattern with a capturer and a list of outputs. The capturer in the example is of type libpcap, pointed at interface eth0 with a snaplen of 2048 and a buffer size of 256 megabytes. The output is of type gre, aimed at host 172.16.1.201 and bound to device eth1. The file runs to more lines than are comfortable in one place, so here it is in three consecutive parts, starting with the control section and the start of the task:

{
    "log_level": "INFO",
    "control": {
        "type": "unix",
        "unix": {
            "path": "/var/run/cloud-probe/cpworker.sock"
        }
    },
    "tasks": [
        {
            "req_pattern": {
                "type": "auto"
            },
            "capturer": {
                "type": "libpcap",
                "libpcap": {

The capture settings follow, still inside the same file:

                    "interface": "eth0",
                    "snaplen": 2048,
                    "buffer_size_mb": 256
                }
            },
            "outputs": [
                {
                    "type": "gre",
                    "gre": {
                        "host": "172.16.1.201",
                        "bind_device": "eth1"
                    }
                }

And the file closes with the output list and the task and task list terminators:

            ]
        }
    ]
}

Two design choices stand out. The outputs are an array, so a single capture can fan out to several destinations. And the request pattern has a type of auto, which suggests the worker decides for itself what to pick up rather than being told a filter expression in this file.

Running cpworker with the GRE output

Starting the worker takes a single command with the config file as an argument. The reader should see the process take over the capture and forward traffic to the remote host described in the file:

cpworker -c libpcap_gre.json

The README attaches an important warning to this particular configuration: you must ensure the firewall allows sending GRE packets to the target, and it points to a reference on GRE tunnels as a way to verify whether sending GRE packets is allowed. The bind_device field exists for the same reason. Gre is convenient because it is a normal IP protocol and needs no extra kernel module, but many cloud security groups and firewalls treat it differently from ordinary TCP and UDP, so a capture that works locally can silently fail in production. That check belongs before you rely on the data, not after.

Three output types, with wire formats documented for each

The output mechanism is the part of the design with the most reach, because it decides where the analysis happens. The README names ZMQ, GRE, and VXLAN as output types, and the repository documents two of the wire formats directly, in docs/ZMQ-WIRE-FORMAT.md and docs/VXLAN-WIRE-FORMAT.md. That documentation matters more than it might appear: when you forward captured packets to another host, the receiving side needs to know the exact framing, and a format you cannot describe cannot be consumed by a third party decoder. GRE and VXLAN are the two that fit a network path, since both encapsulate the traffic so it can travel across an ordinary routed link to the analysis machine. ZMQ is the in-process and messaging style option. The topic list confirms the vxlan and gre emphasis. The documentation also links INSTALL, USAGE-CPWORKER, and BUILD, so the operational detail sits outside the README.

The forwarding table shows what changed between 0.8.7 and 0.9.0

The README includes a forwarding rate comparison table with columns for forwarding BPS, forwarding PPS, and CPU utilization, comparing version 0.8.7 against 0.9.0 for the three output types. For ZMQ the table shows 1560Mbps and 241K packets per second at 110 percent CPU in 0.8.7, against 2680Mbps and 409K packets per second at 49 percent CPU in 0.9.0, with the listed increase columns reading plus 71.8 percent, plus 69.7 percent, and minus 55.4 percent. For GRE the same table shows 786Mbps and 120K at 90 percent against 883Mbps and 135K at 58 percent, and for VXLAN 820Mbps and 125K at 96 percent against 883Mbps and 135K at 52 percent. The shape of the numbers is the interesting part. ZMQ is the fastest path and costs the most CPU in the older version, while GRE and VXLAN land on similar throughput with lower CPU. These are the project's own figures on unspecified hardware, so treat them as a guide to which output to choose rather than as a performance guarantee for your environment.

Building it needs a C toolchain, an SDK root, and a Go module proxy

The repository is mostly C for the worker, with a Go layer for the tooling, and the build environment file shows how much of that is assumed. The file is named .env.example, and the instructions in it say to copy it to .env.local and edit, with .env.local gitignored. The build backend is selected through BUILD_MODE, which can be left unset to auto-detect, and the three documented choices are local, which runs mage directly in the working directory, ssh, which rsyncs the project to BUILD_SSH_HOST and runs mage there, and orb, which runs inside an OrbStack Linux VM. The SDK root is pointed at by CPWORKER_LIBRARY_ROOT and is described as containing include and lib directories with pcap.h, zmq.h, libpcap.so, and libzmq.a, and the file notes that just remote setup creates that skeleton from distro packages. A GOPROXY variable is there for environments where the default Go module proxy is blocked. The justfile acts as a router, with recipes such as just dev build, just dev test, just remote setup, and just env init, and it declares that the build targets are cpworker, cpctl, cpdaemon, dockerpid, or all. A note in the same file warns that BUILD_SSH_ROOT_PASSWORD exists for a one time setup when the SSH user lacks passwordless sudo, and that the file must never be committed with a real password.

Support is explicitly not a product feature

The licence is BSD-3-Clause, with copyright stated as 2018 to 2020 Netis, which is the permissive three clause BSD form that allows commercial use and redistribution with the notice retained. The README is equally direct about support: the project is provided to teams with development capabilities, and there is no official commitment to provide support. Issues and suggestions can go through GitHub issues using the provided issue template, and the contact address is [email protected]. That combination, an open agent with a closed manager, is the shape of the project. The last push to the repository was on 2026-10-14, and the recent releases are v0.9.5 on 2026-10-14, v0.9.4 on 2026-06-30, and v0.9.3 on 2026-06-12, with the default branch named 0.9.x. There is a stale version badge in the README that still reads 0.3.6, so the release list rather than the badge is the source to trust about what is current.

Editorial conclusion

Cloud-probe fits network teams that need packet visibility in an environment with no physical tap and no SPAN support, and that already operate their own management front end. It does not fit teams looking for a product with a supported user interface, since the README states there is no official commitment to provide support and CPM is not in the repository. Before deploying cpworker, verify that the firewall permits GRE traffic to the analysis host, confirm your capture interface and snaplen settings match what you need to analyse, and read the output wire format documents for VXLAN or ZMQ before pointing a decoder at the stream.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-3-Clause
3. Netis/cloud-probe on GitHub
4. README
5. Releases