Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Asset Visibility Forwarding

Forward DHCP, mDNS, and NetBIOS traffic over ERSPAN or GRE to improve asset identity coverage for Sensors and Asset Inventory.

Overview

Asset Visibility Forwarding is a deployment technique that allows Vectra to observe network asset identity-related artifacts even when your current Sensor placement does not provide full visibility. It uses standard network capabilities (such as ERSPAN or GRE) to forward selected traffic from switches or network devices to a Vectra Sensor.

By forwarding selected network traffic (such as DHCP, mDNS, and NetBIOS) from remote parts of your network, you can significantly improve:

  • Asset Inventory coverage

  • HostID accuracy

  • Detection fidelity

  • Metadata available for investigations

Asset Visibility Forwarding is most useful when:

  • Your sensors do not see DHCP, mDNS, or NetBIOS traffic.

    • It is critical when you are not seeing all DHCP traffic.

  • You have limited Layer 2 visibility.

  • Devices communicate locally within access networks.

  • You observe gaps in Asset Inventory or HostID coverage.

Configuration Guidance

Two common approaches both involve forwarding traffic over ERSPAN or GRE tunnels to your Vectra Sensors:

  • Forwarding only network asset identity-related traffic.

    • Only DHCP, mDNS, and NetBIOS are forwarded.

  • Forwarding all traffic from remote network segments.

Some customers may opt to dedicate Vectra Sensors for this purpose when there are bandwidth related concerns for the network or the expected load on existing Sensors would be too high.

Option 1: Forward Asset Identity-Related Traffic Only

Forward a targeted set of protocols:

  • DHCP (UDP 67/68)

  • mDNS (UDP 5353)

  • NetBIOS (UDP 137/138)

Benefits

  • Minimal impact on network bandwidth.

  • Simple to deploy.

  • Focused on improving identity and asset visibility.

Considerations

  • Does not provide full traffic visibility.

  • Primarily enhances identity and inventory, not full detection coverage.

Option 2: Forward All Traffic from Remote Segments

Mirror all traffic from selected interfaces or switches to Vectra Sensors.

Benefits

  • Provides complete visibility for detection and investigation.

  • Useful in environments where hosts are otherwise not visible (for example, OT or remote sites).

Considerations

  • Higher bandwidth requirements.

  • May require careful planning and filtering.

Deployment Guidance and Example Configurations

As a general best practice:

  • Mirror traffic from distribution or core layers where multiple access networks aggregate.

  • Ensure the Vectra sensor can receive and process forwarded traffic.

  • Start with targeted forwarding (Option 1) and expand if needed.

Please see Encapsulation Endpoints (GRE, ERSPAN, GENEVE, VXLAN) for an article detailing how to configure IP addresses for your Vectra Sensor capture interfaces to allow GRE and ERSPAN tunnels to be terminated by your Sensor.

Please Note:

  • These configuration examples below are intended as starting points and may need to be adapted.

  • Vectra has not validated all possible configurations or platforms.

  • Customers should work with their networking teams to:

    • Validate configurations.

    • Assess performance and bandwidth impact.

    • Ensure proper routing and reachability.

Juniper EX / QFX (Selective Forwarding)

Cisco (ERSPAN – Selective Forwarding)

Arista EOS (Selective Forwarding)

Aruba CX (Selective Forwarding)

PreviousEncapsulation Endpoints (GRE, ERSPAN, GENEVE, VXLAN)NextMatch

Last updated

Was this helpful?