SNMP – devices without an agent
Monitor a switch, NAS, UPS or printer without installing software on it.
What this is for #
A switch, a NAS, a UPS or a printer cannot run an agent. But they sit on the same network as your servers and fail just as readily – often with worse consequences, because everything else hangs off the switch.
SNMP is the smallest common denominator practically all of these devices speak. NODE64 uses it to include them: an agent on one of your servers queries them, and afterwards they appear in the dashboard like any other device – with state, findings and history.
Why the query comes from the agent #
SNMP is a protocol for the local network. If our server wanted to query a device behind your firewall, you would have to open a port for it – exactly what this tool advises against.
The agent on your server already has access. It receives the target addresses over the same channel as everything else, runs the queries, and sends the results along with the next upload.
Setting up #
Under Settings › SNMP targets:
- Address of the device and, if it differs, the port (default 161).
- Querying device – one of your servers with an agent that can reach the target over the network.
- Version and credentials (see below).
- Interval – how often to query. Fifteen minutes is a good start.
SNMP targets count against your plan limit like any other device.
v3 or v1/v2c #
This is the most important decision on the page.
With v1 and v2c the community string travels unencrypted across the network – on every single query. Anyone listening on the same network knows it within seconds. And there is no access control beyond it: the string is the password, and it is the same for everyone who knows it.
v3 brings user identities, a checksum over every message and optional encryption. NODE64 supports SHA and MD5 for authentication, AES and DES for encryption.
| Method | Recommendation |
|---|---|
| v3 with SHA + AES | The right choice if the device can do it. |
| v3 with MD5 or DES | Take it if nothing better is available – still far better than v2c. |
| v1 / v2c | Only if the device cannot do anything else. Then the management network belongs separated. |
If a target runs over v1 or v2c, NODE64 reports it as a finding. That is not pedantry: it is a state you should know about.
Encryption without authentication is not permitted by NODE64. That is not a formality – without a checksum the encrypted part could be swapped out unnoticed in transit.
Credentials #
Community strings and v3 passwords are stored encrypted (with the installation's key, exactly like the two-factor secret) and never shown again – like an API key. To change them, create the target anew.
They are decrypted at exactly one point: when delivering them to the agent, over the same authenticated channel everything else uses. They appear in no view, no report and no log entry.
Read-only – and compiled in that way #
SNMP has a writing command (SET) that can reconfigure devices. NODE64 cannot do it. Not "it is switched off", but: there is no function in the agent that executes it. What is not compiled in cannot be triggered by a configuration mistake either.
What gets queried is also a closed list of values – system data, port table, storage usage, processor load. No walk over the entire tree, no vendor branches. That is deliberate: a switch often holds its complete configuration, credentials included, under its private identifier.
What is collected #
- System: description, vendor (from the identifier), name, location, uptime.
- Ports: number, name, alias, speed, administrative and operational state, error and discard counters and – if the device provides them – the traffic volume.
- Storage: usage of disks, flash and memory.
- Processor load, if the device reports it.
64-bit counters #
There is a catch with traffic volume that often goes unnoticed: the old 32-bit counters wrap around on a gigabit port after about 34 seconds. Any measurement at a wider interval would be guesswork.
NODE64 therefore prefers the 64-bit counters (ifHCInOctets). If a device does not provide them, the traffic volume stays empty – and the device view says why. A wrong number would be worse than none.
Findings #
| Finding | Meaning |
|---|---|
| v1/v2c in use | The community string travels in clear text across the network. |
| Default community | public, private and their like – every scanning script tries them first. |
| Not answering | Device off, firewall in between, or credentials changed. |
| Transmission errors | Almost always cabling: cable, connector, transceiver, duplex mismatch. |
| Port up but no link | Enabled and without a link. Deliberately disabled ports are not reported. |
Limits #
- Traps are not received. NODE64 queries on its own schedule; a device that reports on its own initiative is not heard. Receiving traps would mean an open port on your server.
- No vendor extensions. Only the standardised tables. The temperature sensor of a particular switch model is not read out.
- No vulnerability matching. For network devices there is no package inventory to compare against. The firmware is in the device description; whether it is current you have to check with the vendor.
Several probes per target #
A target can be queried by several devices running an agent, in a defined order. The highest-ranked probe that is currently reporting does the querying; if it goes silent for more than ten minutes, the next one takes over.
Exactly one probe queries at a time. Two at once would mean double the load on the switch, two collections racing each other on write, and two truths at the slightest difference.
The measure for "still reporting" is the probe's own heartbeat, not its SNMP success. A probe that is running but cannot reach the target has made a statement — namely "it does not work from here". That statement must not be lost because someone else immediately takes over. The target list therefore shows, per probe, when it last reached the target and what else went wrong.
The last probe of a target cannot be removed. A target without a probe is never queried again and would look like one where nothing is happening.
Querying your own device over SNMP #
If a server running an agent also runs an SNMP service, it is not read without being asked. The switch for it sits in the device settings and is off by default.
The reason is not caution but sense: the agent knows more about its own system than SNMP could ever deliver — packages with versions, services with state, files with checksums. Reading the same system over SNMP as well would produce duplicate data of lower quality.
What is actually read #
The list of queried objects is closed. There is no walk across the whole tree and no vendor branches under 1.3.6.1.4.1.* — that is where many devices keep their configuration, including credentials.
| Table | What it becomes |
|---|---|
ifTable, ifXTable | ports, state, errors, traffic volume |
ipAddrTable, ipAddressTable | the device's addresses, IPv4 and IPv6 |
hrStorageTable | usage of disks, flash, memory |
hrFSTable | mounted filesystems |
hrDeviceTable | components with state and error counter |
hrSWRunTable | the count only of running programs |
tcpCurrEstab, udpTable | numbers only, never connection lists |
entPhysicalTable | components, model, hardware and firmware revision |
dot1dBaseTable | bridge ports, bridge address |
ipForwarding, sysServices | whether the device routes, which services it reports |
lldpRemTable | neighbours — the cabling can be read from these |
Three things are missing on purpose:
- Serial numbers (
entPhysicalSerialNum). They identify a device to third parties and do not help monitoring in the slightest. - Connection lists from
tcpConnTable. Seeing who a router is talking to right now is more than monitoring needs to know. - Program names from
hrSWRunTable. Which programs run on someone else's device is their business; that there are two hundred rather than twenty is an operational fact.
What your device really delivers #
Not every device knows every table. The device view shows, under "What this device answers", what came back for each table at the last query — four possible answers:
| Answer | Meaning |
|---|---|
| delivers | The table was answered and has rows. |
| empty | Answered, but with no content — a switch with no neighbours, say. |
| does not know it | The device does not keep this table. |
| query failed | Timeout or abort. |
The difference between the middle two is the point: a switch with no LLDP neighbours and one without LLDP-MIB both deliver nothing and say entirely different things.
This information lives there rather than in a table in these docs, because such a table would be either incomplete or wrong — and within a year, both. MikroTik, for instance, lists thirteen supported MIBs in the RouterOS manual (MIB-2, HOST-RESOURCES-MIB, IF-MIB, IP-MIB, IP-FORWARD-MIB, IPV6-MIB, BRIDGE-MIB, ENTITY-MIB and others); LLDP-MIB is not among them, even though the manual describes lldpRemTable elsewhere — noting there that only LLDP-discovered neighbours appear, not those found via CDP or MNDP. TCP-MIB and UDP-MIB are absent from the list as well. Netgear publishes no complete list at all; it is only visible in the device's own web menu under "Supported MIBs" and differs by model and firmware.
So your device answers the question itself, for exactly its model and firmware.
MikroTik: agent in a container instead of SNMP? #
RouterOS has been able to run containers since version 7.4, and the NODE64 agent is built for linux/arm, linux/arm64 and linux/amd64 — precisely the architectures RouterOS supports. Technically, nothing stands in the way.
In practice there are three caveats, all from MikroTik's own documentation:
- Containers must be unlocked on the device. `/system/device-mode/update container=yes` then requires a press of the reset button or a cold reboot — that is, physical access. It cannot be done remotely.
- MIPS devices cannot do it. This affects the original hEX and the hAP lite, among others. Devices with an EN7562CT CPU (such as the hEX Refresh) only run
arm32v5images. - MikroTik gives no security assurance. It states verbatim that on a compromised device containers make installing malicious software easy, and that there is "no security guarantee of any kind". An attached disk is also recommended; devices with 16 MB of flash need one.
Our assessment: on a router with enough storage, physical access and an arm64 CPU, the agent delivers considerably more than SNMP — it knows packages, services and files. Everywhere else SNMP remains the right route. Official support for this is not built yet; this section only records what was checked.