# Asset Visibility Forwarding ## 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)](/configuration/coverage/encapsulation-endpoints-gre-erspan-geneve-vxlan.md) 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. {% hint style="warning" %} **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. {% endhint %} #### 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 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 origin ip address ``` #### 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 source 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 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 ``` --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.vectra.ai/deployment/traffic-engineering-and-validation/asset-visibility-forwarding.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.