Network devices

Network device monitoring brings the unmanaged kit on your clients' networks — printers, switches, routers, access points, UPS units, firewalls — into OpsMerge alongside your agents. It speaks SNMP, so anything that exposes a standard MIB shows up with its identity, uptime, and reachability.

There are two ways a device gets polled, and you pick per device:

• Proxy — an OpsMerge agent on the same LAN polls the device and reports back. This is the right choice for anything behind a firewall (i.e. almost everything).
• Direct — the OpsMerge server polls the device itself over a public interface. Use this only for devices that are genuinely reachable from the internet (rare, and think twice about exposing SNMP that way).

What it monitors

For each device, OpsMerge reads the standard MIB-2 system group:

Field	What it tells you
System name	The device's configured hostname (sysName)
Description	Vendor/model/firmware string (sysDescr) — used to auto-classify the device type
Object ID	Vendor enterprise OID (sysObjectID)
Uptime	Time since last reboot (sysUpTime)
Contact	The sysContact set on the device
Location	The sysLocation set on the device
Reachability	Online / offline, with last-seen timestamp

Devices are classified automatically from their description and object ID into a type — printer, switch, router, AP, UPS, firewall, camera, phone, storage, or other — which drives the icon and lets you filter the list.

SNMP versions

Version	Auth	When to use
v1	Community string	Legacy gear that doesn't support v2c
v2c	Community string	The common case for most SMB network kit
v3	Username + auth/privacy (USM)	Where the device and your security posture require authenticated, optionally encrypted SNMP

For v3, you configure a security level:

• noAuthNoPriv — username only, no authentication or encryption.
• authNoPriv — authenticated (MD5/SHA/SHA-224/256/384/512) but not encrypted.
• authPriv — authenticated and privacy-encrypted (DES/AES/AES-192/256).

Credentials are encrypted at rest

Community strings and v3 passphrases are encrypted in the database (AES-256-GCM) and are never returned by the API or shown back in the console — you'll see "Configured", not the secret. When editing a device you can leave secret fields blank to keep the stored value; only type into them to replace it.

Adding a device

Monitoring → Network devices → Add device.

1. Pick the site the device belongs to.
2. Enter its IP address and (optionally) a hostname, manufacturer, model, serial.
3. Choose the monitoring mode — Proxy (and the agent that will poll it) or Direct.
4. Choose the SNMP version and enter the credential:
   • v1/v2c → the community string (defaults to public).
   • v3 → the username, security level, protocols, and passphrases.
5. Set the poll interval (default 300 seconds).
6. Save.

The device is polled on the next cycle; its system fields and online status populate on the device page.

Discovering a subnet

Rather than add devices one by one, point an agent at a subnet and let it find them.

Monitoring → Network devices → Discover.

1. Choose the agent that will run the scan (it scans from its own network position).
2. Enter the subnet in CIDR notation (e.g. 192.168.10.0/24).
3. Choose the SNMP version and credential the scan should try.
4. Run it.

The agent probes each host, and anything that answers SNMP is added to the device list — pre-classified, with the working credential stored against it so future polls just work.

Agents can also discover their local subnets automatically on a schedule when that's enabled in the agent's configuration; those autonomous scans use the agent's configured community.

Discovery never clobbers your choices

If you've set a specific version or credential on a device (say, moved it to v3), a routine automatic scan won't downgrade it back to v2c/public. Only a discovery you run by hand — with an explicit credential — replaces the stored one.

Polling on demand

From a device's page, Poll now runs an immediate read instead of waiting for the next interval — handy after a config change or to confirm a credential works. Proxy devices are polled through their agent; direct devices from the server.

Common patterns

"Add a new client's whole network at once"

Get an agent onto the LAN, then run a Discover against each of the client's subnets with the community string they use. Everything that answers lands in the list classified and ready; tidy up names and types afterwards.

"Monitor a UPS so I know before the batteries die"

Add the UPS as a network device (most expose SNMP). You'll get reachability and uptime out of the box; for battery/runtime OIDs specifically, pair it with an SNMP check in Monitoring & alerts.

"This device only allows authenticated SNMP"

Set it to v3 with the username and passphrases the device requires. Match the auth and privacy protocols exactly to the device's configuration — a mismatch reads as a failed poll, not a partial one.

Common issues

A device shows offline but it's clearly up. The poll isn't getting an answer. Check, in order: the community string / v3 credential is exactly right; SNMP is actually enabled on the device and bound to the interface the agent can reach; no ACL or firewall is blocking UDP 161 between the polling agent and the device; the SNMP version matches.

Discovery found nothing on a subnet I know has SNMP devices. The scan tries one credential. If your devices use a non-default community, enter it in the discover dialog rather than relying on public. Also confirm the agent is actually on (or routable to) that subnet.

v3 device won't poll. v3 is strict: the username, security level, auth protocol, privacy protocol, and both passphrases must all match the device. The most common cause is an auth/priv protocol mismatch (e.g. the device is on SHA/AES but the credential says MD5/DES).

Direct-mode device is offline. Direct polling only works for devices reachable from OpsMerge's servers. If the device is behind NAT or a firewall (it usually is), switch it to Proxy and assign a LAN agent.

I changed the version from v3 to v2c and now it wants a community. Switching versions requires the credential the new version needs — a v3 device has no community string, so you have to supply one when moving it to v1/v2c.

Next

• Monitoring & alerts — add SNMP-OID checks and alert rules on top of device reachability
• Domain monitoring — the other agentless/external monitoring surface