Determine your network data collection architecture

Install the Splunk add-on for Stream Forwarder on your network where you want to capture network data. Before you deploy Splunk Stream determine the best location for your Stream forwarders:

• Review the network or network segments that contain the hosts you want to monitor.
• Review the network collection architectures in this topic to determine the best method to capture data.

Once you determine the data you want to collect, determine the network collection method.

• Local collection that collects data on each machine that you monitor
• Switched Port Analyzer (SPAN) collection
• Test Access Port (TAP) collection

Configure Local collection

Local collection is useful, for example, to help capture data from individual network nodes in a subnet environment such as a multi-tier web site.

To use local collection, install a universal forwarder and the Splunk Add-on for Stream Forwarder on each host on the network or network segment that you want to monitor.

You can configure local collection manually or use the Splunk deployment server.

Configure SPAN or TAP collection

Switched Port Analyzer (SPAN) and Test Access Port (TAP) collection require that you have an existing collection node that listens to all traffic on a network or network segment using a SPAN port or network TAP.

install Splunk Add-on for Stream Forwarder on a universal forwarder or deploy an Independent Stream Forwarder (ISF), then configure that forwarder as the listener on the SPAN or TAP interface.

This diagram illustrates a distributed Splunk Stream deployment with a SPAN collection architecture:

Considerations for local, SPAN, and TAP collection

This table highlights pros and cons of local, SPAN, and TAP collection architectures.

Collection type	Pros	Cons
Local	Fast implementation (using deployment server) More selective data collection (subnet) Works on public cloud VMs where SPAN or TAP is not available	Resources are limited on individual machines. See Hardware performance test summary.
SPAN	Efficiently captures everything on the network. Single point of capture makes data collection easy to set up. SPAN causes no performance impact on individual machines.	Requires configuration in switch hardware. Captures everything on the network, which may raise security considerations. Single point of capture creates a risk of single point of failure. Can be challenging to collect data from Cloud virtual machines. May experience resource limitations on network switches. Dropped packets are more common than with TAP.
TAP	Efficiently captures everything on the network. Single point of capture makes data collection easy to set up. No performance impact on individual machines. No performance impact on network switches. Higher data capture fidelity than with SPAN.	Requires a physical hardware device. Captures everything on the network, which may lead to security considerations. Single point of capture creates a risk of single point of failure. Can be challenging to collect from Cloud virtual machines.

Additional considerations for SPAN collection

SPAN collection requires a few additional considerations.

• Can the Network Interface Card (NIC) that receives the mirror data handle the influx of traffic? For example, a 1GB NIC can not handle the data volume from a 10GB port.
• Does the SPAN mirror port contain both ingress and egress traffic from all of the ports they are spanning? If yes, then the capacity of the NIC itself is even more important.
• Does the mirror device generate NATed data (in which case the data contains both internal and external (Internet) representations of traffic)?
• What is the volume of source traffic? Depending on the volume of traffic, you might need to make some performance adjustments to ensure that the system behaves as expected.