Asset Visibility Forwarding

How to forward DHCP, mDNS, and NetBIOS traffic over ERSPAN or GRE tunnels to Vectra Sensors to increase coverage of network asset identity-related artifacts for Asset Inventory, HostID, etc.

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

• Host-ID 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 Host-ID 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 DCHP, 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)

set firewall family inet filter IDENTITY-MIRROR term DHCP from protocol udp
set firewall family inet filter IDENTITY-MIRROR term DHCP from port 67
set firewall family inet filter IDENTITY-MIRROR term DHCP from port 68
set firewall family inet filter IDENTITY-MIRROR term DHCP then port-mirror
set firewall family inet filter IDENTITY-MIRROR term DHCP then accept

set firewall family inet filter IDENTITY-MIRROR term MDNS from protocol udp
set firewall family inet filter IDENTITY-MIRROR term MDNS from port 5353
set firewall family inet filter IDENTITY-MIRROR term MDNS then port-mirror
set firewall family inet filter IDENTITY-MIRROR term MDNS then accept

set firewall family inet filter IDENTITY-MIRROR term NETBIOS from protocol udp
set firewall family inet filter IDENTITY-MIRROR term NETBIOS from port 137
set firewall family inet filter IDENTITY-MIRROR term NETBIOS from port 138
set firewall family inet filter IDENTITY-MIRROR term NETBIOS then port-mirror
set firewall family inet filter IDENTITY-MIRROR term NETBIOS then accept

set interfaces ge-0/0/1 unit 0 family inet filter input IDENTITY-MIRROR

set forwarding-options analyzer VECTRA-MONITOR input ingress interface ge-0/0/1
set forwarding-options analyzer VECTRA-MONITOR output remote-ip <sensor-ip>
set forwarding-options analyzer VECTRA-MONITOR output gre

Cisco (ERSPAN – Selective Forwarding)

ip access-list IDENTITY-MIRROR
  permit udp any any eq bootps
  permit udp any any eq bootpc
  permit udp any any eq 5353
  permit udp any any eq 137
  permit udp any any eq 138

monitor session 10 type erspan-source
 source interface Ethernet1/1 rx
 filter ip access-group IDENTITY-MIRROR
 destination
   erspan-id 10
   ip address <sensor-ip>
   origin ip address <source-ip>

Arista EOS (Selective Forwarding)

ip access-list IDENTITY-MIRROR
   10 permit udp any any eq bootps
   20 permit udp any any eq bootpc
   30 permit udp any any eq 5353
   40 permit udp any any eq 137
   50 permit udp any any eq 138

monitor session 1 source Ethernet1 rx
monitor session 1 destination gre <sensor-ip> source <source-ip>
no monitor session 1 shutdown

Aruba CX (Selective Forwarding)

class ip IDENTITY
    10 match udp any any eq 67
    20 match udp any any eq 68
    30 match udp any any eq 5353
    40 match udp any any eq 137
    50 match udp any any eq 138

mirror-session 1
    destination erspan
    ip-address <sensor-ip>
    source-ip <source-ip>
    no shutdown

policy MIRROR-IDENTITY
    10 class ip IDENTITY action mirror 1
    20 class ip any action permit

interface 1/1/1
    apply policy MIRROR-IDENTITY in