Skip to main content

SNMP Devices

Prerequisites for network devices — switches, firewalls, access points, NAS — that you'll monitor with a Stratora Collector via SNMP.

SNMP versions supported​

Stratora supports SNMPv2c and SNMPv3 for polling network devices. SNMPv1 is not used. Both v2c and v3 are first-class — choose the one that matches your environment.

  • SNMPv2c — read-only community string
  • SNMPv3 — USM with authentication and privacy (encryption)

What Stratora reads via SNMP​

At discovery time, Stratora queries the standard system objects on each candidate device: sysDescr, sysObjectID, sysName, sysLocation, and sysContact. These identify the device family and let Stratora auto-classify it against a template.

At runtime, the matched template determines which MIB objects Stratora polls — typically standard MIB-II interface and system tables plus vendor-specific MIBs for that device family.

Stratora does not use SNMP-SET in this release — every credential needed is read-only. Stratora also does not receive SNMP traps in this release; monitoring is poll-only.

Device-side ACL configuration​

On each device you intend to monitor:

  • Permit SNMP queries from the Stratora Collector's IP on UDP/161. For single-server deployments where the Server polls devices directly, that's the Server's IP. For multi-collector deployments, repeat for each Collector that will reach the device.
  • A read-only community (for SNMPv2c) is sufficient — Stratora never writes via SNMP.
  • For SNMPv3, configure a read-only user with one of the authentication and privacy protocols Stratora supports. See Credentials for the full protocol list.

Devices supported today​

For the full list — including how each device is recognized during discovery and what alerting applies — see Supported Devices. That page is generated from Stratora's own validation records, so it reflects exactly what ships, per model.

Two things it makes explicit that a flat vendor list cannot:

  • Recognition — whether a device is found automatically on a scan. Most families are auto-recognized, but not all. For example, classic-IOS Cisco Catalyst collection works, yet no discovery fingerprint exists for it yet, so it is added manually rather than found on a scan — a known, closable gap.
  • Validation basis — whether a template was verified against a real physical device (Validated), against a captured firmware replay with no live device (Replay-validated), or is authored from vendor MIB documentation and not yet verified (MIB-derived). Many families are not yet hardware-validated.
ESXi and vCenter

For vSphere, vCenter inventory and per-host/VM utilization come from the vSphere API, not SNMP — see Virtualization prerequisites. SNMP applies to the per-host enrichment layer (each ESXi host onboarded as a VMware Host node for memory overcommit and host-alert attribution); ESXi ships with SNMP disabled, so enable it per host (esxcli system snmp set --enable true) before onboarding.

What the built-in alerts cover​

Every monitored device gets reachability alerting: device unreachable, packet loss, and response time. The network device families above additionally get SNMP interface monitoring — per-interface throughput, plus interface error-rate alerting — and per-family alerts where the platform exposes the data: NAS volume and RAID state on Synology and QNAP, host memory overcommit and datastore capacity on VMware.

Two qualifications in the current release:

  • Palo Alto PA Series — the PA template does not currently collect interface error counters, so interface-error alerting does not apply to PA devices. Reachability alerting and interface throughput monitoring are unaffected.
  • Interface discards — discard counters are collected on a subset of device families; discard-based alerting applies only where a device's template collects those counters.

The built-in alert library lists every alert. Each alert evaluates only on devices whose template collects the underlying metric — seeing an alert in the library does not by itself mean it applies to every device family.

Generic templates​

Stratora ships generic templates for hosts and services that don't fit a vendor template:

  • ping — ICMP-only monitoring for any reachable host
  • http-https — HTTP / HTTPS endpoint monitoring with SSL certificate expiry tracking
  • wan-circuit — latency, jitter, and loss monitoring for WAN links

Vendors on the roadmap​

Additional vendor support is on the roadmap — including first-class support for Cisco Meraki cloud-managed switches, access points, and appliances.

Where to go next​