Blog

Putting a Thermometer on Your Switches: SNMP Monitoring

February 15, 2026 5 min read
MonitoringSNMPOps
SNMP monitoring of network switches

The edge firewall logs are thorough, but the access switches were a black box for years — until an aging uplink optical module made business crawl for half a day. What I added was SNMP monitoring: not a grand NMS replacement, but a way for the critical links to call for help when they're saturated or erroring out.

Monitoring priority

  1. Core / distribution CPU, memory, temperature
  2. Uplink traffic, error counters, optical power (if available)
  3. The links heading to the edge firewall
  4. Wireless controllers and key APs (if reachable via SNMP or vendor APIs)

Don't try to map every port of the access layer in phase one; start with the topology skeleton.

SNMPv2c or v3

For a lab, a v2c community string is acceptable; for an office network I lean v3 with auth and encryption — a community string is a password that travels in cleartext. Read-only privileges only; never give the monitoring station write access.

ACL: allow only the monitoring server's IP to reach switch UDP 161.

Collection stack

I've used Zabbix templates and also Prometheus + snmp_exporter. Pick the one your team will actually look at, which matters more than what's trendy. At minimum, collect:

  • ifHCInOctets / ifHCOutOctets (for rates)
  • ifInErrors / ifOutErrors
  • CPU/memory vendor OIDs or HOST-RESOURCES
  • Optical module DOM (when available)
# snmp_exporter approach: modules + target list
# the key is the target list and labels: site, role, vendor

Alert de-noising

A bad alert is worse than no alert:

  • Port down: watch only uplinks and server ports; don't SMS-bomb on desktop-port flapping
  • Utilization: alert on the 95th percentile, or sustained 5 minutes above 80%, not one-second blips
  • Error counters: use the rate, not the cumulative value
  • Suppress during maintenance windows

After being woken three times by "Gi0/37 down" in one night, you'll fall in love with the network admin's restraint.

One real hit

Uplink error frames crept up slowly; the traffic graph still looked unsaturated, yet users reported "large files randomly fail." After swapping the optical module and cleaning the flange, errors went to zero. Without an error-counter curve, that problem would've been blamed on "the server disk is slow."

Docs and handoff

  • Device inventory and SNMP credentials in the vault
  • OID / template versions
  • Topology diagram and "whose uplink is this" labels

Wrap-up

A network engineer's monitoring isn't just "ping works." SNMP makes link errors and capacity visible, and together with host monitoring it's the two legs you stand on. On a resume, write out the toolchain, the device scale, and whether optical power and de-noising strategy are included — that reads closer to daily ops than "have used Wireshark."

← Back to Blog