Skip to main content
There are two scan modules for SNMP. The difference lies in the protocol version and therefore in the access data a target requires: Both modules can be operated side by side: the older devices over SNMP v1 and v2, the ones switched to v3 over SNMPv3. In both cases a connected gateway is required. The wizard shows four steps for both; only the middle part differs from the standard path in Creating a Scan Job.

​
Prerequisites

Both modules capture active network components such as switches, routers and printers through predefined MIBs, such as the Printer MIB and RFC1213-MIB, and also which system is connected to which switch, port and VLAN.

​
Ports and protocols

​
Permissions

  • SNMP v1 and v2 needs a read community, by default public.
  • SNMPv3 needs the device’s access data: user name, algorithm and password for authentication and encryption, and a context name where applicable. At the security level without encryption (authNoPriv), the encryption algorithm and encryption password stay empty, and without a configured context the context name does too.
  • The gateway’s computer is allowed to send SNMP queries to the devices, through an access list or allowlist.
  • Depending on the device, access to the OID tree must also be granted—through the community or the group.

​
Network requirements

  • SNMP v1, v2c or v3 is enabled on the device.
  • The firewall allows the port. Flooding protection (ICMP, UDP) and intrusion protection do not block the queries.
  • The devices respond to ping.
  • For the topology, switches, routers and firewalls speak a neighbor discovery protocol: CDP or LLDP, as uniformly as possible, preferably LLDP.
  • Cisco devices with SNMPv3 need the matching SNMPv3 contexts for the VLAN and Bridge MIB so that learned MAC addresses and VLAN assignments are read completely.
  • The device name comes from the SNMP system name (OID 1.3.6.1.2.1.1.5). If it is not set, the IP address appears as the name.

​
Entering the targets

The Targets step carries a table with one row per target. The columns are almost the same for both modules: Into the target column may go a single address, a range, a network in CIDR notation (e.g. /24) or a hostname. A whole network therefore fits into one row.
The column is called Credentials with both modules, even though with SNMP v1 and v2 a community stands in it and no account. The entry in the Credentials for All Targets field above the table applies to all rows without their own assignment. With SNMP v1 and v2 the cell per row stays a picker with free text—so a community can be typed straight into the row.
Timeout (ms) is limited silently to 100 to 60000 when you leave the field, with no message. Check the value once more after entering it.
Some Cisco devices respond late. If the scan does not find all devices, increase Timeout (ms).

​
The access data

An entry of the type SNMP v1 and v2 carries a single field: the Community. An entry of the type SNMPv3 carries Username, Authentication Algorithm (None, MD5 or SHA-1), Authentication Password, Encryption Algorithm (None, AES, AES-128, AES-192, AES-256, DES or TDES), Encryption Password and Context Name.
If the authentication stands at None, the encryption jumps back to None automatically: encryption without authentication does not exist in SNMPv3 and cannot be created here either.
You can create both under Scan › Credentials or directly in the wizard through the New Credentials… row in the picker.
Enter the entry above the table first and deviate from it per row only afterwards. The summary later shows how many targets deviate from the default—that way you can check whether a row was forgotten.

​
Common issues

​
Checking devices that are not scanned

If a device is not scanned, check in this order:
  1. Does the device support SNMP? If not, capture it manually.
  2. Is SNMP enabled on the device?
  3. Does the device respond to ping from the gateway? If not, check the network connection.
  4. Is there a firewall in between? Check its log.
  5. Are the community or the SNMPv3 access data correct?
  6. Do the community, user name or password contain a backslash (\) or an @? Many devices have problems with these—change the value.
  7. Is the gateway’s computer allowed to send SNMP queries to the device?
  8. Is access to the OID tree granted?
  9. Do monitoring, the firewall or security solutions (flooding protection, intrusion protection) block the query? If so, set up exceptions.
  10. Is the device within the specified address range?
  11. Does another tool, such as Paessler SNMP Tester, read values like uptime or description? If so, contact support.
  12. Is the firmware up to date?
Which types these scans produce is under Network and Devices. What Docusnap365 finds in the network but cannot assign to a type is in Unknown Systems.