GUIDE — 2026-09-18

Monitor Cisco switch interfaces over SNMP, no agent

SNMP is already on every managed switch you own. You do not need to install anything on the device — you enable a read-only community (or an SNMPv3 user), point a poller at it, and read interface status, traffic counters and error counts straight from the switch. This covers turning it on safely, the OIDs that actually matter, and what is worth an alert.

What does the polling? DeviceWatch is the same application on macOS, Windows 10/11, Windows Server 2016 or newer, and 64-bit Linux. It polls over SNMP with no agent on the device, no collector in the middle, and no cloud account. Most people run it on a server. The commands below are for the switch; the poller can be anything that speaks SNMP.

What this covers

Classic IOS (Catalyst 2960, 3560, 3750) and IOS-XE (Catalyst 9000, ISR 4000). SNMPv2c and SNMPv3. The interface OIDs are standard MIB-II, so most of this applies to any SNMP-capable switch, not only Cisco.

Read-only, always

Monitoring never needs write access. A read-only community can list interfaces and counters but cannot change anything, so a leaked read-only string cannot reconfigure the switch. Never give a monitoring tool a read-write community — it does not need it, and it turns a captured string into a way in.

Step 1 — Turn on SNMP (v2c)

The quickest path, fine on a trusted management VLAN:

conf t
snmp-server community M0nitorRO RO 99
access-list 99 permit 10.0.0.5
snmp-server location "Rack 4, Floor 2"
snmp-server contact "netops@example.com"

The RO makes the community read-only. Access-list 99 limits who may query it to the one poller at 10.0.0.5 — without that, anyone who can reach the switch and guesses the string can read your topology. Pick a community string that is not public.

Step 2 — Prefer SNMPv3 where you can

v2c sends the community in clear text. On any network you do not fully trust, use v3 with authentication and privacy instead:

conf t
snmp-server group MONITOR v3 priv
snmp-server user poller MONITOR v3 auth sha AuthPass123 priv aes 128 PrivPass123

That gives one user, SHA for authentication and AES-128 for encryption, read-only through the group. There is no community string to leak. Use v3 for anything crossing a link you share with other traffic.

Step 3 — The OIDs that matter

Interface data lives in two tables. ifTable (MIB-II) has the basics; ifXTable adds 64-bit counters and the human name. A poller reads these by index, one row per interface:

ifDescr — 1.3.6.1.2.1.2.2.1.2 — interface description (GigabitEthernet0/1)
ifOperStatus — 1.3.6.1.2.1.2.2.1.8 — up (1) or down (2), the one you watch
ifHCInOctets / ifHCOutOctets — ...31.1.1.1.6 / .10 — 64-bit byte counters for traffic
ifInErrors / ifOutErrors — ...2.2.1.14 / .20 — error counts
ifHighSpeed — 1.3.6.1.2.1.31.1.1.1.15 — port speed in Mbps, needed to turn bytes into a utilisation percentage

Use the HC (high-capacity, 64-bit) counters. The old 32-bit ifInOctets wraps in seconds on a busy 10G port, and a poller that does not notice the wrap reports a wild spike or a negative rate.

Step 4 — Check it from the poller

Before pointing a tool at the switch, confirm it answers. With net-snmp installed:

snmpwalk -v2c -c M0nitorRO 10.0.0.1 1.3.6.1.2.1.2.2.1.2
snmpwalk -v3 -l authPriv -u poller -a SHA -A AuthPass123 -x AES -X PrivPass123 10.0.0.1 ifOperStatus

If the walk returns the interface list, the switch is configured and reachable. If it times out, work through the next section.

If nothing comes back

UDP 161 is not open to the poller. SNMP is UDP/161; a firewall or VLAN ACL between the poller and the switch will drop it silently.
The access-list excludes the poller. If you set access-list 99, the query source must be on it — and it must match the interface the switch replies from.
Wrong version. Asking a v3-only switch with v2c (or the reverse) just times out; it does not tell you why.
Counters do not move. A single reading is meaningless — traffic and errors are deltas. You need two reads a minute or so apart to get a rate.

What is worth alerting on

Polling produces a lot of numbers. A few are worth waking someone for; most are not:

An access or uplink port going down when it is normally up. A lab port that flaps all day is noise; a core uplink is not.
Error rate, not error count. Ten errors per second is nothing on a 10G port and a failing cable on a 100M one. Watch errors as a share of packets, keyed to the port's speed.
Sustained high utilisation on an uplink — the difference between a busy minute and a saturated hour.
A counter that resets — the switch rebooted, and you may have missed why.

The trap is that a fixed threshold is wrong for most ports: a number that is alarming on one interface is idle on another. This is where a baseline per interface — what normal looks like on this port, this hour, this weekday — beats a single global rule.

Two things that catch people

Interface names differ by vendor. Cisco fills ifDescr with GigabitEthernet0/1; some vendors leave it blank and put the name in ifName or ifAlias. A poller that reads only ifDescr shows blank columns on those devices. Reading ifDescr, then ifName, then ifAlias covers all of them.

SNMP polling adds load, gently. Reading a few interface columns once a minute is negligible. Walking the entire MIB every ten seconds is not — it can push CPU on an older switch. Poll the columns you use, at a sensible interval.

Getting DeviceWatch

DeviceWatch polls switches, routers, firewalls and servers over plain SNMP — interfaces, traffic, errors, CPU, memory, temperature, fans and power — with no agent and no cloud. It reads ifDescr, ifName and ifAlias so port names show up whatever the vendor, uses the 64-bit counters, and learns each interface's baseline per hour and per weekday so the alerts fit the port. macOS, Windows and Linux; everything stays on the machine you run it on.