Configuration C: External SPAN Monitoring
Copy link

In this configuration, a dedicated physical NIC on the AHV host receives mirrored traffic from an external source, such as a core switch SPAN port or a TAP device. That NIC must be made accessible to the sensor VM.

ℹ️

How this configuration differs

This is a distinct problem from Configurations A and B. Those use Traffic Mirroring to copy traffic that already exists inside AHV, whereas this configuration is about first getting external traffic onto the AHV host at all. If you use the dedicated virtual switch approach (Option 2 below) instead of PCI passthrough, you can optionally use the same acli net.create_traffic_mirror approach from Configuration A, with the dedicated NIC as the kHostNic source, instead of directly attaching that network to the sensor VM.

There are two approaches to get the external traffic onto the host and to the sensor.

Option 1: PCI Passthrough
Copy link

PCI passthrough assigns the physical NIC directly to the sensor VM at the hardware level, bypassing the virtual switch entirely. This provides the most reliable capture at high throughput and is the recommended approach.

⚠️

NIC passthrough is configured through Prism Central

Unlike GPU passthrough, which has a documented acli vm.gpu_assign command, raw NIC passthrough has no equivalent self-service aCLI command. The current supported mechanism is SR-IOV / Network Offload NIC Profiles, configured through Prism Central rather than aCLI, and it has real version requirements.

Version Requirements
Copy link

SR-IOV NIC Profile support requires all of the following:

  • AOS 7.3 and later
  • AHV 10.3 and later
  • Prism Central pc.7.3 and later
  • An SR-IOV-capable physical NIC (a smartNIC), not already assigned to any virtual switch or uplink

Configure via Prism Central
Copy link

  1. In Prism Central, create a NIC Profile with the SR-IOV capability enabled, under Network Profiles / NIC and NIC Profile Management.
  2. Add the dedicated physical NIC port to that NIC Profile, either while creating the profile or by updating it afterward.
  3. Using the Update VM workflow for the sensor VM, attach the SR-IOV NIC Profile and NIC port as the sensor’s capture vNIC.
  4. Power cycle the sensor VM. The capture NIC will be enumerated within the guest operating system with direct hardware access to the physical port.
ℹ️

If you cannot meet the SR-IOV requirements

If your environment does not meet the version requirements above, or your NIC does not support SR-IOV, true 1:1 NIC passthrough is possible in principle but is not a self-service, publicly documented aCLI procedure. Engage Nutanix Support for guidance, or use Option 2 below instead.

Option 2: Dedicated Virtual Switch
Copy link

This approach creates a Nutanix-managed virtual switch tied to the dedicated physical NIC, then connects the sensor VM’s capture interface to it. This avoids PCI passthrough configuration, but does not offer the same throughput and reliability.

⚠️

Do not create the bridge manually

Do not create the bridge manually with ovs-vsctl add-br. The net.create_virtual_switch command does not accept a bridge name parameter — AOS assigns its own internal bridge name, such as br1, regardless of the virtual switch name you choose. A manually created bridge will not be the one actually carrying the traffic, and any OVS-level changes applied to it will have no effect.

Create the Virtual Switch
Copy link

Get the UUID of the AHV host that contains the dedicated SPAN NIC:

acli host.list

The sensor VM must run on this host, because it can only receive traffic that enters through this host’s SPAN NIC. Check which host the sensor VM is running on:

acli vm.get <sensor-vm-name>

If the host_uuid value does not match the SPAN host, migrate the sensor VM to it. If you already configured the sensor VM as an agent VM in Prepare the Network Sensor VM, clear that setting before you migrate, and then set it again so the VM stays on the SPAN host:

acli vm.update <sensor-vm-name> agent_vm=false acli vm.migrate <sensor-vm-name> host=<host-uuid> acli vm.update <sensor-vm-name> agent_vm=true

Create a virtual switch with the dedicated NIC as its only uplink. No bonding is needed for a single-NIC SPAN feed:

acli net.create_virtual_switch vs-span bond_type=kNoBond \ host_uplink_config={<host-uuid>:[eth1]}

host_ip_addr_config and gateway_ip_address are deliberately omitted. This bridge only needs to carry mirrored L2 traffic to the sensor, not host IP connectivity.

Identify the Real Underlying Bridge
Copy link

AOS assigns its own bridge name to the virtual switch. Find it before making any OVS-level changes:

acli net.get_virtual_switch vs-span

Note the internal_bridge value under host_configuration_list. This is referred to as <real-bridge> below. Cross-check against the AHV host directly:

ovs-vsctl show

Confirm that the same bridge name lists your dedicated NIC as a port.

Disable MAC Learning on the Bridge
Copy link

ℹ️

Why MAC learning must be disabled

OVS bridges learn MAC-to-port associations by default. Mirrored SPAN traffic contains both sides of conversations happening elsewhere, all arriving on the same port. Once OVS learns those MACs as living on that port, it stops forwarding them anywhere else — traffic appears briefly, then silently stops. Overriding the bridge to always flood avoids this.

ovs-vsctl set-fail-mode <real-bridge> secure ovs-ofctl del-flows <real-bridge> ovs-ofctl add-flow <real-bridge> actions=flood

Create the VM Network
Copy link

Create an unmanaged, untagged network bound to the virtual switch:

acli net.create span-network virtual_switch=vs-span vlan=0

Attach the Sensor VM’s Capture NIC
Copy link

acli vm.nic_create <sensor-vm-name> network=span-network

Verify
Copy link

acli net.get_virtual_switch vs-span acli vm.nic_list <sensor-vm-name>

Confirm that vs-span shows the dedicated NIC in its uplink_list, and that the sensor VM’s NIC list shows the new vNIC on span-network.

Verify Guest-Level Interface State
Copy link

After attaching the NIC with either option, SSH into the sensor VM and confirm that the capture interface is visible:

sudo ip addr list

A new interface corresponding to the attached NIC should be listed. If it is in a DOWN state, bring it up before completing the network sensor configuration in the Insight platform:

sudo ip link set <interface-name> up
✅

Next steps

After completing the configuration above, return to Step 4: Download and Install the Network Sensor Software to assign the capture NIC in the Insight platform and complete your sensor setup.