Traffic sensors observe real network communications to build an accurate asset inventory and application dependency map. Reliable packet visibility enables improved change management, cybersecurity monitoring, and compliance reporting.
We strongly recommend giving each traffic sensor a copy of production traffic, using one of the mirroring methods described below. Mirroring isn't a hard requirement. Without a dedicated packet feed, though, the sensor processes broadcast traffic only, which covers a limited subset of the assets on the local network.
For placement diagrams, capacity planning, and vendor configuration examples, download the Integrating the Lansweeper traffic sensor into your network white paper (PDF).
What is traffic mirroring?
Port mirroring (Switched Port Analyzer or SPAN), remote port mirroring (Remote Switched Port Analyzer or RSPAN), and encapsulated mirroring (Encapsulated Remote Switched Port Analyzer or ERSPAN) are switch/router features that duplicate packets from selected interfaces, VLANs, or routing points and send them to a dedicated destination interface.
The sensor attaches to this destination interface and passively inspects the mirrored traffic.
Mirroring gives the sensor the real packets it needs to:
- Identify assets communicating on the network
- Build application dependency maps
- Detect lateral movement (east–west traffic)
- Increase overall visibility without introducing risk to production traffic (sensor is receive-only)
There are multiple ways to provide a feed (SPAN, RSPAN/ERSPAN, network TAPs, packet brokers, and NetFlow records). Choose the option that best matches your network design, operational constraints, and fidelity requirements. The next section compares each option in detail.
Methods for providing packet feeds
There are several methods to provide traffic sensor with a reliable feed of network traffic. Each of these methods has different costs, fidelity, and operational characteristics. The table below compares the five primary methods: SPAN, RSPAN/ERSPAN, network TAPs, packet brokers, and NetFlow.
| Method | What it is | When to use | Prerequisites | Pros | Cons |
|---|---|---|---|---|---|
| SPAN | Mirrors traffic from selected ports/VLANs to a monitor port on a switch | - Simple, low-cost option - Fast to pilot - Traffic volumes won’t oversubscribe the switch | - Free SPAN session(s) - Available mirror port - Cable to sensor NIC | - No hardware purchase - Quick to configure and modify | - Limited sessions per switch |
| RSPAN/ERSPAN | Remote mirroring across the network (via VLAN, or via GRE over IP) | - Deploying virtual sensor - Centralizing capture across sites | - Hardware/software support - MTU tuning for ERSPAN - QoS if needed | - No local monitor cabling (ERSPAN) - Consolidates multiple capture sources | - MTU/QoS complexity - ERSPAN overhead |
| Network TAP | Physical device inserted inline to provide full-fidelity traffic copies | - No switch access/permissions - SPAN capacity/limitations are a concern | - TAP matching link type/speed - Physical access and cabling - Maintenance window | - Full line-rate capture - No switch performance impact | - Hardware purchase required - Less flexible than SPAN - Physical installation necessary |
| Packet brokers | Aggregation device that collects SPAN/TAP feeds and forwards filtered traffic to tool | - Broker already exists - Need centralized management of feeds | - None beyond broker availability | - Centralized control - Filtering, load-balancing, deduplication | - Additional cost/licensing - Mis-filters can hide traffic - If sampling is enabled, the traffic sensor will receive an incomplete representation of network traffic |
| NetFlow (early access) | Flow records exported by switches or routers describing observed connections (IPs, ports, byte/packet counts, TCP flags) | - Mirror sessions or capture hardware aren’t available - Remote sites where SPAN/TAP isn’t practical - You already export NetFlow to another collector | - Exporter supports NetFlow v5, v9, or IPFIX (v10) - UDP path from exporter to sensor | - No mirror sessions, cabling, or capture hardware required - Works across routed networks and remote sites - Can complement SPAN/TAP to cover blind spots | - Lower recognition fidelity: no packet payload, so device fingerprinting is limited compared with mirrored traffic - Quality depends on which fields the exporter includes and whether sampling is enabled - sFlow is not supported |
Any capture method can produce incomplete visibility if the capture path is oversubscribed (mirror destination, broker/tool port, WAN transport, or sensor NIC). This affects monitoring data, not production forwarding.
Configure mirroring on common switch vendors
The steps for configuring SPAN, RSPAN, or ERSPAN vary significantly across switch platforms. The most common switch vendors are listed below, along with direct links to their documentation.
Configure NetFlow on common switch vendors
NetFlow collection is currently in early access. Features and requirements are subject to change.
If your switches or routers already export NetFlow, or if you can enable it, point the exporter at the traffic sensor's IP address. The sensor starts processing records as soon as they arrive; no additional sensor-side configuration is required.
The traffic sensor accepts NetFlow v5, NetFlow v9, and IPFIX (NetFlow v10). sFlow is not supported.
NetFlow v5 doesn't support 802.1q VLAN frames or trunks. To monitor 802.1q VLAN traffic, use NetFlow v9 or IPFIX.
The steps for configuring NetFlow vary by platform. The most common vendors are listed below, along with direct links to their documentation.
| Manufacturer | Documentation |
|---|---|
| Cisco (NetFlow / Flexible NetFlow) | https://www.cisco.com/c/en/us/td/docs/switches/lan/c9000/fnf-avc/flexible-netflow-configuration-guide.html |
| Juniper (J-Flow / IPFIX) | https://www.juniper.net/documentation/us/en/software/junos/flow-monitoring/topics/concept/services-ipfix-flow-template-flow-aggregation-configuring.html |
| Extreme Networks | https://extreme-networks.my.site.com/ExtrSearch?q=#q=netflow&t=Knowledge&sort=relevancy |
Recommended exporter settings
For the best results, configure your exporter to include the fields the sensor uses for connection analysis:
- Enable TCP flags in the export template. The sensor uses TCP flags to distinguish scans and partial connections from established sessions.
- Use the lowest sample rate your environment can support, or disable sampling entirely. Aggressive sampling reduces the number of flows the sensor sees and can hide short-lived or low-volume assets.
- Export from the same points you'd otherwise mirror (aggregation/distribution switches, core switches, and inter-VLAN gateways) for the widest asset coverage.
Where to place the traffic sensor?
The sensor should observe as much internal asset traffic as practical, including east–west communications (asset-to-asset within/ across VLANs), and north–south communications (to/from external networks).
Ideal capture points include:
- Aggregation/Distribution switches
- Core switches/routers
- Inter-VLAN gateways
- Data center cores where traffic converges
Mirroring or TAPs must be placed before SD-WAN appliances, IPsec tunnels, VPN gateways, and other encryption points.
Sensor placement guidelines
Effective sensor placement ensures broad visibility into network communications while minimizing blind spots and unnecessary duplication.
East-west coverage
While east–west traffic is often overlooked, it contains a large portion of the internal communications that matter for security and dependency mapping.
When planning capture points, ensure mirrors or TAPs also cover:
- Inter-VLAN routing points
- Lateral movement paths inside campuses, branches, or data centers
Remote sites via ERSPAN
When deploying a physical sensor at a remote site isn't practical, ERSPAN provides an effective way to forward mirrored traffic to a central location.
Because ERSPAN encapsulates packets, a few additional considerations are important:
- Account for ERSPAN overhead in MTU calculations
- Ensure the WAN links have sufficient capacity, as multiple ERSPAN feeds can be bandwidth heavy
- Use separate NICs on the sensor when using multiple ERSPAN sources
Distributed vs centralized networks
In highly distributed networks, you may need multiple sensors or capture points to maintain visibility across independent sites or segments.
Centralized networks on the other hand often allow you to capture the majority of traffic at core or aggregation layers, reducing the number of sensors required.
Reliability and capacity
Reliable capture depends on both the network and the sensor host.
To ensure predictable capture quality:
- Avoid oversubscribing SPAN sessions
- Confirm the sensor NIC can handle the expected bandwidth
- Adjust mirror scope (VLANs/ports/direction) if drops occur
- Ensure the NIC is in promiscuous mode so all mirrored traffic is collected.
For virtual deployments, you may also need to enable promiscuous mode on the hypervisor vSwitch/port group. - Confirm NIC receive buffers are sized appropriately for high-rate traffic
- Validate traffic delivery after deployment (packet counters, SPAN/TAP health checks)
Frequently asked questions (FAQ)
Is the packet capture feed a hard requirement?
No, but it does guarantee the best results. There are multiple ways to provide a feed to the traffic sensor: SPAN, RSPAN/ERSPAN, network TAPs, packet brokers, or NetFlow records exported by your switches or routers. For a full comparison of your options, see Methods for providing packet feeds earlier in this article.
Can the traffic sensor be hosted in the cloud (Azure, AWS, and so on)?
Yes, though we recommend deploying the traffic sensor as close to the assets you want to monitor as possible. Depending on your network configuration, you can also deploy it remotely.
Keep in mind that the bandwidth sent to the sensor may increase depending on the volume of traffic data being mirrored.
Can I run the traffic sensor on a virtual machine?
Yes. On virtualized hardware such as VMware, we recommend using PCI Express passthrough from the host hardware to the virtual machine.
Passthrough gives the virtual machine ownership of the physical network card and its acceleration features. This increases capture performance and reduces the chance of missing network traffic in demanding environments.
Passthrough has a trade-off: it can prevent you from migrating the virtual machine to another host server.
How many network interfaces does the traffic sensor need?
We recommend running each traffic sensor with a minimum of two network interfaces:
- Management interface: the traffic sensor and its host operating system use this interface to receive patches and updates, and to communicate with the hub and Lansweeper cloud services.
- Monitor interface: this interface processes mirror port traffic only.
Which network cards does Lansweeper recommend?
The traffic sensor works with most network cards and drivers, but some perform better than others. Use these cards as a starting point for the monitor interface:
| Interface speed | Recommended network cards |
|---|---|
| 1 Gbit | Intel X550 or newer |
| 10 Gbit | Intel X550 or newer |
| 25 Gbit | Intel X710 or E810 or newer, or NVIDIA/Mellanox ConnectX-5 or newer. We suggest the ConnectX-6, because it's still a supported platform. |
| 100 Gbit | Intel E810 or newer, or NVIDIA/Mellanox ConnectX-6 or newer. Requires PCI Express 3.0 x16; we recommend PCI Express 4.0 x16. |
For interface speeds over 100 Gbit, contact the Lansweeper support or sales team.
Does the traffic sensor support VLAN-tagged (802.1Q) traffic?
Yes. The traffic sensor processes network traffic including 802.1Q-tagged frames, and needs no additional configuration to do so. Configure the switch port that the sensor's monitor interface connects to so that it allows the tagged frames you want to capture.
Don't configure VLANs on the sensor interfaces
We strongly recommend against configuring any VLAN information on the traffic sensor's Ethernet interfaces. Most network cards then drop all other tagged and untagged frames.
Does the traffic sensor support jumbo frames?
Yes. Most modern enterprise network cards and ports support large frame receive and process jumbo frames.
We recommend configuring the traffic sensor's monitor interface to match the jumbo frame size used on your network. Supported jumbo frame settings differ per network card and driver, so consult your network card manufacturer's documentation for the exact values.
How can I validate if traffic is flowing for SPAN?
After you've configured the SPAN session and connected the mirror port to the sensor NIC, log in to the sensor host and:
- Identify the capture interface (for example
ens192):ip link show - Run a short packet capture test (requires root):
tcpdump -i <INTERFACE> -c 20 -nn
If you see packets scrolling by, the SPAN feed is working.
If no packets are captured, the sensor is not receiving mirrored traffic: recheck the source ports/VLANs, direction (ingress/egress/both), and that the correct physical port is cabled to the sensor.
How can I validate if traffic is flowing from a TAP?
Once the TAP is inserted and the monitor ports are connected to the sensor NIC(s):
- Confirm at the network layer that the TAP and sensor links are up (link light/switch port status if applicable).
- On the sensor host, identify the capture interface:
ip link show - Run a short packet capture test (requires root):
tcpdump -i <INTERFACE> -c 20 -nn
If you see packets scrolling by, the TAP is correctly delivering traffic.
If no packets are captured, verify that:
- The TAP type matches link speed/media (1G/10G copper/fiber)
- You're using the correct monitor ports
- For bi-directional links, both directions are actually presented to the sensor (some TAPs output two one-way feeds that must both be connected/aggregated)
How can I validate if traffic is flowing for RSPAN/ERSPAN?
After configuring RSPAN or ERSPAN on the switches/routers and connecting/attaching the sensor endpoint:
- On the sensor host, identify the interface or tunnel that should receive the mirrored traffic:
ip link show - Run a short packet capture test (requires root):
tcpdump -i <INTERFACE> -c 20 -nn. For RSPAN, you should see mirrored packets directly. For ERSPAN over GRE, you may first see GRE-encapsulated ERSPAN packets.
If tcpdump shows no packets, re-check:
- Verify MTU settings along the path to avoid silent drops due to fragmentation.
- The destination endpoint (correct NIC, tunnel, or vSwitch port group).
- The RSPAN VLAN/ERSPAN tunnel configuration and ACLs.
- That the source session is actually active on the switch.
How can I validate if traffic is flowing through a packet broker to the sensor?
Validation is done in two places: on the broker and on the sensor.
-
On the packet broker:
- Check the statistics/counters on the tool-port feeding the sensor (ingress/egress packet/byte counters).
- Confirm that any filters or ACLs applied to that tool-port are not excluding the VLANs, IP ranges, or protocols you expect to see.
- If you are load-balancing across multiple sensor NICs, verify the hash/load-balancing policy and per-port counters.
-
On the sensor host:
- Identify the interface(s) connected to the broker:
ip link show - Run a short packet capture test (requires root):
tcpdump -i <INTERFACE> -c 20 -nn
- Identify the interface(s) connected to the broker:
If you see packets, the broker is successfully delivering a feed to that NIC.
If no packets are showing, revisit broker filters, output mapping, and cabling, and verify that the correct tool-port is assigned to the sensor.
Which NetFlow versions does the traffic sensor support?
NetFlow v5, NetFlow v9, and IPFIX (NetFlow v10). sFlow is not supported.
Do I still need SPAN or a TAP if I already export NetFlow?
No, NetFlow on its own is enough to get assets into your inventory. Recognition quality is typically higher when the sensor sees mirrored packets, because full packets carry the payload details used for device fingerprinting. If you can, combine both: mirror the segments where you need the best recognition, and use NetFlow to cover remote sites or segments you can't mirror.
How can I validate if NetFlow records are reaching the sensor?
On the sensor host:
- Identify the interface receiving NetFlow (usually the sensor's management NIC):
ip link show - Run a short capture filtered to the NetFlow port (requires root):
tcpdump -i <INTERFACE> -c 20 -nn udp port 2055
If you see UDP packets from your switch or router, the exporter is reaching the sensor.
If nothing arrives, check that:
- The exporter is configured with the sensor's IP as the collector and port 2055
- No firewall or ACL between the exporter and the sensor is dropping UDP 2055
- The exporter is actually sending flows (some switches only export after a flow ages out, so generate traffic and wait for the active/inactive timeout)
Why do assets discovered only via NetFlow look less detailed than assets seen via mirrored traffic?
NetFlow records describe connections but don't carry packet payloads, so the sensor can't extract the fingerprint information it would normally pull from mirrored packets.