Skip to content

Troubleshooting

Devices from other VLANs appear in scan results

Each multi-VLAN discovery job targets a single VLAN. If devices from other VLANs appear in the results, this is most likely caused by device or network configuration issues rather than a problem with the discovery job itself. This applies to both VXLAN and trunk port mode.

Common causes include:

  • Improper VLAN segmentation on the switch. If VLAN boundaries are not correctly enforced, traffic can leak between VLANs and cause devices from neighboring VLANs to respond to probes they should never have received.
  • Multi-homed devices. Switches, routers, Industrial Edge devices, and any host with more than one active network interface may be reachable through multiple VLANs. When such a device receives a discovery probe on one interface, the operating system may reply using the address of a different interface. For example, an Industrial Edge device with one interface at 192.168.20.5 (in VLAN 20) and another at 192.168.10.42 (in VLAN 10) may receive a probe on its 192.168.10.42 interface and reply with 192.168.20.5 as the source address, making it appear as a VLAN 20 device in a VLAN 10 scan.

This behavior is a consequence of the Linux weak host model, where the kernel may send and receive packets on any interface regardless of which interface holds the matching IP address. The two sysctl settings that together address ARP flux on multi-homed Linux hosts are arp_ignore and arp_announce. Set both to their strict values on each interface that should not advertise foreign addresses:

sysctl -w net.ipv4.conf.<interface>.arp_ignore=1
sysctl -w net.ipv4.conf.<interface>.arp_announce=2

arp_ignore=1 instructs the kernel to reply to ARP requests only with addresses assigned to the receiving interface. arp_announce=2 ensures that ARP requests sent from that interface use the best local address for that interface rather than any address on the host. Replace <interface> with the interface name, for example eth1. To make the settings persistent across reboots, add them to /etc/sysctl.conf or a file under /etc/sysctl.d/.

Note

These settings apply only to Linux-based devices. Non-Linux devices such as switches or Windows hosts require equivalent configuration through their own network stack settings.

If unexpected devices appear consistently in the results, review the VLAN configuration on the switch and the network interface settings of the affected devices.

Discovery returns no results

Work through the following, in both modes:

  • Check that the host firewall does not drop the required traffic. Blocked packets never reach the Asset Gateway, so the job fails silently. See Host firewall requirements.
  • Check that probeIP belongs to vlanSubnet and is not assigned to any other host in the target VLAN.
  • Check that the parent interface supplied as parentInterfaceName or parentInterfaceIP exists on the host and is the interface that actually reaches the target network.
  • Check that the interface is attached to the container that runs the scan. If the Asset Link delegates the scan to a separate tool, its container name cannot be derived from the assetLinkId and must be supplied in networkScannerName. See Overriding the container name.

In VXLAN mode, additionally check that:

  • segmentId matches the VNI configured on the user-side VXLAN endpoint for the target VLAN.
  • remoteIP is reachable from the host, and vxlanDstPort matches the port used by that endpoint.
  • If a VPN is used as the underlay, the VPN tunnel is up before the job starts. See Securing VXLAN Traffic.

In trunk port mode, additionally check that:

  • segmentId matches the 802.1Q VLAN ID of the target VLAN.
  • The VLAN is allowed and tagged on the trunk port the host is connected to. A VLAN configured as the native, untagged VLAN of the trunk cannot be reached by a tagged sub-interface.

Discovery results are incomplete or vary between runs

When several VPN interfaces exist on the Asset Gateway host and their addresses overlap, the routes used for the VXLAN tunnel may be bound to the wrong interface. See Using multiple WireGuard interfaces.

Any questions left?

Ask the community