Set up SNMP discovery

Without SNMP, a discovered host has only what port scanning and DNS provide — addresses, open ports, detected services, and a reverse DNS name. SNMP adds what the device says about itself.

What gets discovered

• System identity — sysName, sysDescr, sysLocation, sysContact
• Interface table — every interface with its name, speed, MAC address, IP assignments, and operational status
• LLDP/CDP neighbors — the directly connected devices the host itself reports

Neighbor data is what makes accurate physical topology possible: it's the source for the links drawn in L2 Physical. Interface and IP data also improve host deduplication, since a MAC address gives Scanopy a second way to recognize a device whose address has changed.

For the full list of queried MIBs and OIDs, see the SNMP reference.

Prerequisites

• SNMP enabled on the target devices
• UDP port 161 reachable from the daemon host to those devices
• A community string for v1/v2c, or USM credentials for v3

Choosing a credential type

Each SNMP version is its own credential type. Pick the highest one your devices support.

Versions can be mixed freely across a network. Each host resolves its own credential, so v3 on the core switches alongside v2c on older access gear works fine.

SNMP v1

A single shared community string, sent in cleartext. Use this only for devices that support nothing newer — v2c takes the same field and is otherwise identical from Scanopy's side.

SNMP v2c

A single shared community string, sent in cleartext. The common choice for gear that predates v3.

SNMP v3

Authenticated and encrypted on the wire, and the version to prefer wherever a device supports it. Scanopy always uses AuthPriv — authentication and privacy together — which is why both protocol pairs are required rather than optional. AuthNoPriv and NoAuthNoPriv are not supported, and MD5 authentication is not available.

Leave Context Name blank unless your device puts interface and LLDP data in a named context; the default context is what almost every device uses.

Verifying it works

1. Go to Discover > Scan > Scheduled and run a discovery, or wait for the next scheduled run
2. Open a host that should have SNMP data
3. Check for:
   • sysName and sysDescr in the host's SNMP tab
   • Interfaces in the ifEntry tab — names, speeds, and IP assignments
   • Neighbors in the L2 Physical topology

You can confirm a network-wide assignment from Discover > Daemons — hover the Network chip to see whether an SNMP credential is configured.

Troubleshooting

The usual symptom is a scan that completes and detects port 161, but leaves the host's SNMP and ifEntry tabs empty.

No SNMP data on any host

The credential exists but isn't assigned. Creating a credential doesn't activate SNMP — see Where a credential applies.

No SNMP data on one host

Test the device directly from the daemon's host to separate a credential problem from a device problem:

# v1 / v2c — try the default community, then yours
snmpwalk -v2c -c public DEVICE_IP 1.3.6.1.2.1.2.2.1.2
snmpwalk -v2c -c YOUR_COMMUNITY_STRING DEVICE_IP 1.3.6.1.2.1.2.2.1.2

# v3
snmpwalk -v3 -l authPriv -u SECURITY_NAME \
  -a SHA -A AUTH_PASSWORD -x AES -X PRIV_PASSWORD \
  DEVICE_IP 1.3.6.1.2.1.2.2.1.2

If public works but your own string doesn't, the credential is wrong or isn't reaching this host — a per-host credential overrides the network default. If neither works, SNMP isn't enabled on the device or it refuses that version.

A device that enforces v3 will not answer a community string at all. Note that Scanopy's v3 is AuthPriv only, so a device configured for AuthNoPriv won't connect either.

System data appears but no neighbors

The device isn't reporting an LLDP or CDP neighbor table. Some managed switches collect neighbor data internally without exposing the LLDP MIB over SNMP, in which case a walk returns nothing and the neighbors have to come from that vendor's own management API instead.

Interfaces missing or incomplete

Fewer interfaces than the device has — or interfaces with no neighbor, VLAN or learned-MAC data — means the table walk was cut short. A walk is capped at 10,000 rows and each query at 30 seconds, so a very large table or a device that stalls partway through returns a partial result. Truncation is reported as a warning on the discovery session, not just in the daemon logs.

Interfaces are saved before the neighbor and VLAN queries run, so bare interfaces with no neighbor data mean the device hung later in collection.

Check how long a full snmpwalk of the interface table takes from the daemon host, whether the device is rate-limiting SNMP, and whether its interface count is genuinely near the cap — stacked chassis and large modular switches can be.

Reading the daemon logs

With debug logging enabled, these messages appear during a scan of the target host:

For credential loading problems — unreadable files, PEM errors, and the per-session assignment summary — see Credential troubleshooting.