Network Requirements for Network Sensor Deployment

Now that you’ve reviewed the requirements for physical and virtual Insight Network Sensor hosts, you can explore your options for configuring a network traffic source.

In order for the Insight Network Sensor to monitor your network traffic and generate the metadata that your Insight products will use, it must have a way to receive a copy of the packet stream traversing your network from a converged location. This dedicated packet stream for the network sensor is known as a network traffic source.

Network Traffic Source Configuration Options

The following network infrastructure components can provide your network sensor with the network traffic source it needs to function.

Switched Port Analyzer (SPAN), or Mirror Port

Port mirroring is a network switch feature that pipes a copy of all network traffic to a single output switch port. Port mirroring technology goes by various names depending on the switch manufacturer, but Cisco’s Switched Port Analyzer implementation (also known as SPAN) is one of the most common.

TIP - Understanding SPAN

You can read more about SPAN on this Cisco documentation resource:

https://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/10570-41.html?dtid=osscdc000283

Chances are, your network already uses at least one core switch with this capability. For this reason, configuring a mirror port as your network traffic source is often the ideal choice for network sensor deployments.

Test Access Point (TAP)

In cases where a mirror port configuration is not an option, you can also deploy one or more Test Access Point (TAP) devices as network traffic sources for the network sensor to use.

Unlike a mirror port that copies network traffic on the core switch itself, a TAP is a separate device that you would typically deploy between your firewall and your switch to copy and send network traffic to a monitoring tool. TAPs functionally achieve the same goal that mirror ports do, but are generally only needed in smaller environments where the connection needs of the network do not warrant the scale of a mirror port-equipped core switch.

Network Packet Broker (NPB)

A Network Packet Broker (NPB) is a more intelligent tool that allows your network to send different streams of network traffic to multiple monitoring applications according to your needs. NPBs can ingest network traffic from both mirror ports and TAP sources.

If you intend to deploy the network sensor as an additional or complementary traffic monitoring tool alongside other monitoring devices or applications, an NPB can provide the network sensor with its own dedicated network traffic source without affecting your existing monitoring infrastructure.

Virtual Network Traffic Sources

If you intend to virtualize the network sensor host, you can create your network traffic source by enabling “promiscuous mode” on a virtual switch. Much akin to a mirror port on a physical network, promiscuous mode allows your virtual network sensor host to read all network traffic traveling through the virtual switch of your ESXi hypervisor.

Ultimately, your monitoring intentions will determine how you should configure your virtual traffic source. The deployment category in this documentation set accounts for the following two scenarios in particular.

East-West Virtual Traffic Monitoring

In this scenario, your virtual network sensor would only be responsible for monitoring the network traffic in the virtual environment of your ESXi hypervisor. For this use case, you would configure your virtual network traffic source by enabling promiscuous mode on an ESXi port group composed of the virtual machines that you want to monitor. The network traffic source NIC of your virtual network sensor host would be connected to the same virtual switch as the rest of your instances to see their network traffic.

Virtual and Physical Traffic Monitoring

In this scenario, your virtual network sensor would have the expanded scope of monitoring both your virtual ESXi environment and your physical infrastructure connected through a core switch. For this use case, your virtual network sensor host would need connections to two virtual switches:

  • One connection to the primary virtual switch already providing connectivity to your existing virtual machines.
  • One connection to a secondary virtual switch (which you will have to create) configured in promiscuous mode and dedicated to the network sensor’s use.
    • This new virtual switch serves as your virtual network traffic source.

The secondary virtual switch, which connects your virtual network sensor host to your physical mirror port, functionally creates a traffic convergence zone between your physical and virtual environments.