How can we help?

How does Auvik discover network topology and device information?

Follow

Once the Auvik collector is successfully installed on your network, it automatically searches on its local subnet to find more networks. When new networks are discovered, you can choose whether to have Auvik scan them or not.

Refining the topology

During the network scan, Auvik looks for network devices that expose the following information:

  • ARP tables
  • Forwarding tables (Layer 2)
  • IP assignments
  • VLAN associations
  • Layer 1 discovery protocols, such as Link Layer Discovery Protocol (LLDP), Cisco Discovery Protocol (CDP), and Foundry Discovery Protocol (FDP)

This information is pulled from SNMP through various management information bases (MIBs), and by issuing "show" commands through the CLI on network elements.

From there, Auvik uses logic to determine connections and model your network. Where definitive connection information is unavailable, the system uses a set of proprietary algorithms to infer the remaining connections.

On your map, you can see:

  • Wired and wireless connections when we have strong evidence of a physical connection
  • Inferred wired and inferred wireless connections when Auvik knows the connection must exist but doesn’t have the exact port mapping

For example, there may be an unmanaged switch between a router and a set of PCs. The system will realize this and add an unmanaged device to your map.

Refining Device Information

Once a device is discovered, Auvik looks for open services so it can identify the class of device, such as printer, switch, firewall, access point, laptop, or phone. The system uses a number of tools and services to refine device information. They include:

  • SNMP v1/2c, and v3
  • Generic credentials (public, private) are tried to identify the device using System-MIB
  • SSH, Telnet, and CLI
  • Multicast Domain Name System (mDNS)
  • SMB / Samba
  • Windows Management Instrumentation (WMI)

How Auvik determines device hostnames

Auvik primarily obtains device hostnames through SNMP using the sysName.0 value from SNMPv2-MIB:

1.3.6.1.2.1.1.5.0

Some devices may also provide names through other identification fields or data sources.

FortiGate hostname behavior

FortiGate devices commonly report sysName.0 as a fully qualified domain name (FQDN), combining the configured hostname with the DNS domain.

For example:

hostname.domain

This is expected behavior. The name displayed in Auvik may include the domain even if the local FortiGate prompt displays only the short hostname.

How to align the displayed name

You can align the displayed name in either of the following ways:

  • Update the FortiGate hostname and domain settings so the value reported through SNMP matches your naming standard.
  • Set a custom device name on the device details page in Auvik.

A custom device name changes the display name in Auvik only. It does not change the sysName.0 value reported by the device.

FortiGate configuration changes should be performed by an authorized FortiGate administrator.

Device availability and cached hostnames

The device must be online and reachable over SNMP to confirm the current sysName.0 value.

If the device is offline, Auvik may continue to display a previously collected hostname in alerts, dashboards, or device details until the next successful poll.

Identifying devices without SNMP

SNMP is the primary method Auvik uses to identify and monitor network devices. When SNMP is unavailable, Auvik may use other data sources to make a best-effort identification.

Alternative data sources

Depending on the device and environment, Auvik may use:

  • Neighbor discovery: CDP, LLDP, and ARP information learned from other devices
  • Service banners and fingerprints: Information exposed through services such as HTTP, HTTPS, or SSH
  • Operating system and platform credentials: WMI or WinRM for Windows devices, SSH for Linux and Unix devices, and applicable hypervisor or controller APIs
  • Naming services: DHCP, DNS, NetBIOS, or mDNS information

These sources may provide useful context, but they do not consistently provide the same depth or accuracy as SNMP.

Limitations without SNMP

When SNMP is unavailable:

  • The device type or vendor may remain unknown or appear as Generic.
  • Hardware model, serial number, module information, and other inventory details may be unavailable.
  • Interface status, sensor data, hardware health, and performance metrics may be limited.
  • Device filters and reports based on precise vendor or device classifications may be less accurate.

For the best identification and monitoring coverage, enable SNMP and provide valid credentials whenever the device supports it. If SNMP cannot be used, alternative credentials, controller integrations, and neighbor-discovery protocols may improve the available device information, but they cannot guarantee full device identification or monitoring depth.

Why does rediscovery keep showing old device information?

Rediscovery does not necessarily replace information supplied by a vendor controller or cloud integration.

When a device is associated with a controller integration, details such as the device name, model, serial number, or site assignment may be supplied by that integration. If the controller continues to report the old value, rediscovery may appear to restore the outdated information.

Auvik may use multiple data sources, including SNMP, CLI, and cloud-controller integrations, when refining device information.

How to identify the source of the information

Check the device details and the applicable integration configuration to determine whether the device is associated with a vendor controller or cloud integration.

For example, Auvik’s cloud-controller integrations can add information about discovered devices, while the devices must still be reachable from the collector for discovery and management.

How to correct outdated information

  1. Review the device in the vendor controller and correct the device name, model, serial number, or site/organization assignment.
  2. Confirm that the controller integration is connected and that the device is assigned to the intended Auvik site.
  3. Verify that the device remains reachable from the assigned collector.
  4. Confirm that the required SNMP or other monitoring credentials are valid.
  5. Allow the integration and discovery data time to update, then review the device again.

If the information remains incorrect, collect:

  • The device name and identifiers.
  • Serial number, MAC address, and management IP address.
  • The value shown in the vendor controller.
  • The value shown in Auvik.
  • Screenshots or exports from the controller.
  • The time the controller data was corrected and the next rediscovery or synchronization occurred.

Provide these details to Auvik Support so they can determine which data source is supplying the value and reconcile the information.
 

SNMP OIDs used for device identification

Auvik uses standard SNMP system OIDs and vendor MIB information to identify devices and refine their inventory details.

The device should return values for:

  • sysObjectID.0 — 1.3.6.1.2.1.1.2.0
  • sysDescr.0 — 1.3.6.1.2.1.1.1.0
  • sysName.0 — 1.3.6.1.2.1.1.5.0

If device identity or model information appears incorrect, verify that:

  • The SNMP agent is enabled and reachable from the Auvik collector.
  • The correct SNMPv2c community string or SNMPv3 credentials are configured in Auvik.
  • The device returns consistent values for the standard system OIDs.
  • Only the intended device responds to SNMP at the monitored IP address. Shared IPs, proxy responders, or NAT configurations can return identity information from another device.

If the returned identity information is incorrect, provide Auvik Support with:

  • Device make, model, and firmware.
  • Returned sysObjectID, sysDescr, and sysName values.
  • Relevant vendor MIB details.
  • Device IP address and Auvik site.
  • Approximate time the values were collected.

Changes to SNMP settings, access policies, IP addressing, or proxy behavior may require assistance from a network or device administrator.

Was this article helpful?
28 out of 44 found this helpful
Have more questions? Submit a request