Traffic sensor requirements

Prev Next

Before installing the hub or traffic sensor, ensure your environment meets the following requirements.

Learn this in the Academy

For a guided walkthrough of deploying the traffic sensor, take the free Achieve total visibility with the Traffic Sensor course in the Lansweeper Customer Academy.

Connection requirements

The hub must be able to reach the Lansweeper cloud services over TLS 1.2 or higher. For the list of outbound URLs and ports, see Discovery hub requirements.

Sensor must reach the hub

If the traffic sensor and hub are installed on different machines, the traffic sensor must be able to reach the hub over the network.

System requirements

Traffic sensors always operate in combination with a hub. The hub manages configuration and receives processed data from one or more sensors, while each sensor focuses on local packet capture and analysis.

You can install the traffic sensor on the same machine as the hub, or link it to an existing hub on another machine.

Hub disk space

The hub's connection, CPU, RAM, and network requirements are the same whichever sensor you install. See Discovery hub requirements.

Disk space is the one hub requirement that depends on which sensors you connect. Traffic sensors upload capture files to the hub, so they need considerably more disk space than IT and OT sensors do. Size the disk to cover the minimum for all connected traffic sensors combined; for example, 2 traffic sensors require 10 GB of total free disk space.

Resource Minimum for up to 2 sensors Recommended for up to 5 sensors Recommended for up to 10 sensors Recommended for up to 100 sensors
Free disk space (SSD) 10 GB 25 GB 50 GB 500 GB
Hubs with IT and OT sensors only need less

A hub running IT and OT sensors alone needs just 1 GB free as a minimum. See IT and OT sensor requirements.

Traffic sensor requirements

Each traffic sensor host (physical or virtual) needs sufficient resources to capture traffic at line rate without drops. Typical internal capture volume for a sensor is around 200 MB every 5 minutes, or roughly 400 GB per week, depending on the mirrored scope and traffic patterns.

Resource Minimum Recommended
CPU x64, dual-core 2 GHz x64, dual-core 2 GHz
RAM 2 GB 4 GB
Free disk space 500 GB 1 TB
Network speed 100 Mbps 1 Gbps

Hardware requirements and performance expectations

The following guidelines are starting points for sizing traffic sensor hosts. Actual requirements depend on your setup.

Line rate CPUs RAM NIC capacity Disk (minimum, ~1 hour buffer)
0-8 Gbit/s 8 32 GB 10 Gbit 25 GB
8-40 Gbit/s 24 64 GB 40 Gbit 80 GB
40-100 Gbit/s 64 512 GB 100 Gbit 250 GB
Per-interface capture limit

A sensor can read up to ~20 Gbit/s of traffic per interface. Higher rates may require multiple capture NICs, or specialized capture cards.

For a step-by-step method to size bandwidth, network cards, and transceivers, download the Integrating the Lansweeper traffic sensor into your network white paper (PDF).

Next steps

Now that you understand the requirements, set up traffic collection on your network, then install the sensor:

Frequently asked questions (FAQ)

How does disk cleanup work on the traffic sensor, and how should I size disk capacity?

The sensor’s disk cleanup process aims to keep local storage at approximately 85% utilization by deleting the oldest capture files first, even if some files failed to upload.
As a rule of thumb, plan your disk size so that 85% of your total disk can hold at least ~2× your hourly capture volume (one hour of data plus one hour of buffer/headroom before cleanup starts deleting). For example, if you generate 25 GB/hour, you should plan for roughly (2 × 25 GB) ÷ 0.85 ≈ 59 GB total disk, which corresponds to ~50 GB usable under the 85% cleanup target and provides ~1 hour of buffer.

What specific information does network traffic data include?

The traffic sensor only captures the connection metadata needed to identify and place devices in your inventory: IP and MAC addresses observed on the network, source and destination IPs and ports of observed connections, the date and time of each connection, and a device identifier so observations can be linked to the right asset