Network collection architectures

Splunk Stream requires installation of universal forwarders and Splunk_TA_stream on your network at the location(s) where you want to capture network data. To determine the best location for these components, consider the topology and organization of your network and the tools available.

Before you deploy Stream:

• Review the network (or network segment) that contains the hosts you want to monitor.
• Review the network collection architectures (below) and determine the best method to capture data.

There are three types of network collection architectures that fit most use cases: local, SPAN, and TAP.

Local collection

A local collection architecture requires installation of a universal forwarder and Splunk_TA_stream on each host on the network or network segment that you want to monitor. Local collection is useful, for example, in a subnet environment (such as a multi-tier web site) for capturing data from individual network nodes.

You can deploy Splunk_TA_Stream to forwarders manually or use the Splunk deployment server.

SPAN or TAP collection

A SPAN or TAP collection architecture requires a collection node that listens to all traffic on a network or network segment using a SPAN port or network TAP. The collection node requires installation of a universal forwarder and Splunk_TA_stream, and is configured as the listener on the SPAN or TAP interface.

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

SPAN architecture considerations

If you are deploying Stream in a SPAN collection architecture, consider the following:

• Can the NIC (network interface card) that receives the mirror data handle the influx of traffic? For example, a 1GB NIC cannot handle the volume of data that comes 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 tweaks to ensure that the system behaves as expected.

Pros and Cons of collection architectures

This table shows 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/TAP not available	Resource limitations on individual machines. See Hardware performance test summary.
SPAN	Captures everything on network (efficient) Ease of collection (single point of capture) No performance impact on individual machines	Requires configuration in switch hardware Captures everything on network (security considerations) Ease of collection (single point of failure) Challenge collecting from cloud VMs Resource limitations on network switches Dropped packets more common vs using TAP
TAP	Captures everything on network (efficient) Ease of collection (single point of capture) No performance impact on individual machines No performance impact on network switches High fidelity of data capture vs using SPAN	Requires physical hardware device Captures everything on network (security considerations) Ease of collection (single point of failure) Challenge collecting from cloud VMs

For more information on network collection methods, see Everything you always wanted to know about span ports and stream.