Set up traffic collection

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.

To function correctly, each sensor must receive a copy of production traffic using one of the mirroring methods described below.

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.

Traffic mirroring is required; the sensor must observe real packets 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 the required packet feed (SPAN, RSPAN/ERSPAN, network TAPs, and packet brokers). 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 copy of network traffic. Each of these methods has different costs, fidelity, and operational characteristics. The table below compares the four primary methods: SPAN, RSPAN/ERSPAN, network TAPs, and packet brokers.

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.

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

Do not mirror traffic after it has been encrypted

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)