Setting up SNMPv3 on switches and routers for monitoring

A common finding when auditing a small office network before putting it under monitoring is that every switch still answers to the community string public, and a couple of them accept private for writes. Usually nobody did anything malicious with it; SNMPv2c was simply left on its factory defaults for years. That is the usual starting point, and it is a good reason to refuse to point a poller at anything that is not running SNMPv3 with authentication and encryption.

This guide walks through a recommended setup for production networks: a read-only SNMPv3 user in authPriv mode (SHA for authentication, AES for privacy), restricted to the monitoring server’s address. It covers Cisco IOS / IOS XE, a Linux host running net-snmp, command-line tests, and adding the result to a poller such as LibreNMS. Only configure devices you own or are authorized to manage.

What authPriv actually buys you

SNMPv3 has three security levels:

• noAuthNoPriv — a username, nothing else. Barely better than a community string.
• authNoPriv — messages are signed with an HMAC (MD5 or SHA), so they cannot be forged or replayed, but the payload still travels in clear text.
• authPriv — signed and encrypted (DES or AES). Interface descriptions, ARP tables and routing data are no longer readable by anyone on the path.

Use authPriv with SHA and AES-128. MD5 and DES still appear in vendor examples, but there is no reason to pick them on anything built in the last decade. Some platforms offer SHA-2 variants (SHA-256 and up) and AES-192/256; they are worth using where both the device and your poller support them, but AES-192/256 in particular has had interoperability problems between vendors, so test before rolling it out fleet-wide.

Step 1: plan the names and secrets

Before touching a device, decide on:

1. A username the monitoring system will use, e.g. nms-ro.
2. An auth passphrase and a separate privacy passphrase. net-snmp rejects anything shorter than 8 characters; we use 20+ random characters and keep them in the team’s password manager.
3. The poller’s source addresses — the monitoring server and any distributed pollers or proxies.
4. A read-only view. Monitoring never needs write access.

Keep one credential set per trust zone rather than one per device. Per-device secrets sound safer, but in practice they end up in a spreadsheet, which defeats the point.

Step 2: Cisco IOS / IOS XE

On a Catalyst switch or ISR, the configuration is three layers: an ACL, a group bound to a view, and a user in that group.

conf t
 ip access-list standard SNMP-POLLERS
  permit host 10.20.0.15
  permit host 10.20.0.16
  deny any log
 exit
 snmp-server view NMS-VIEW iso included
 snmp-server group NMS-RO v3 priv read NMS-VIEW access SNMP-POLLERS
 snmp-server user nms-ro NMS-RO v3 auth sha AuthPassphrase-Here priv aes 128 PrivPassphrase-Here access SNMP-POLLERS
 no snmp-server community public
 no snmp-server community private
end
write memory

A few things that trip people up on IOS:

• snmp-server user lines do not appear in show running-config. That is by design; the localized keys are stored separately. Confirm with show snmp user and show snmp group.
• Users are tied to the engine ID. If you change snmp-server engineID local, every v3 user has to be recreated.
• The priv keyword on the group matters. A group defined as v3 auth will let an authPriv user in but will not enforce encryption; define the group as v3 priv so a misconfigured poller fails loudly instead of silently falling back.
• On newer IOS XE releases you may be able to use auth sha-2 256; check your release notes before standardizing on it.

Step 3: a Linux host with net-snmp

For servers, firewalls built on Linux, or a jump host you want to graph, install the snmpd package from your distribution’s repository. The cleanest way to create a v3 user is with the daemon stopped:

sudo systemctl stop snmpd
sudo net-snmp-create-v3-user -ro -a SHA -A 'AuthPassphrase-Here' -x AES -X 'PrivPassphrase-Here' nms-ro
sudo systemctl start snmpd

The helper writes a createUser line into the persistent file (/var/lib/snmp/snmpd.conf on Debian/Ubuntu, /var/lib/net-snmp/snmpd.conf on RHEL-family). When snmpd starts, it converts that line into localized keys and removes the plain-text passphrase. The -ro flag adds a rouser line to /etc/snmp/snmpd.conf. A minimal main config looks like this:

# /etc/snmp/snmpd.conf
agentaddress udp:161
rouser nms-ro priv
sysLocation Rack B2, Lab
sysContact NOC on-call, ext 4410

Two defaults to watch: Debian and Ubuntu ship with agentaddress 127.0.0.1,[::1], so the daemon ignores the network until you change it; and many distributions ship a restrictive view systemonly that limits what v2c communities can see. The rouser nms-ro priv line without an OID grants the whole tree to that user at authPriv only. Open UDP 161 in the host firewall for the poller addresses and nothing else.

Step 4: test from the monitoring server

Never add a device to a monitoring system until snmpwalk works from the poller itself. Walk the system subtree first:

snmpwalk -v3 -l authPriv -u nms-ro \
  -a SHA -A 'AuthPassphrase-Here' \
  -x AES -X 'PrivPassphrase-Here' \
  10.20.1.1 1.3.6.1.2.1.1

You should see sysDescr, sysObjectID, sysUpTime and friends. Then walk IF-MIB::ifName (1.3.6.1.2.1.31.1.1.1.1) to confirm interfaces are visible. Errors map to causes fairly reliably:

If a walk times out and each team insists its side is fine, capture the exchange on the poller and read it in Wireshark: a request with no reply, or a reply from an unexpected address, points straight at the culprit.

Keep the passphrases out of your shell history: prefix the command with a space if HISTCONTROL=ignorespace is set, or put defaults in ~/.snmp/snmp.conf on the poller with 600 permissions.

Step 5: add the device to your poller

In LibreNMS, go to Devices → Add Device, choose SNMP version v3, auth level authPriv, fill in the username, set auth algorithm to SHA and crypto algorithm to AES, and paste both passphrases. The CLI equivalent is lnms device:add — run lnms device:add --help to see the v3 flags for your installed version. Better still, add the credential set under the global SNMP settings so auto-discovery (via LLDP/CDP neighbors) can use it for every new device it finds.

In Zabbix, create an SNMP interface on the host, pick SNMPv3 and authPriv, and store the passphrases in secret user macros (for example {$SNMPV3_AUTHPASS}) at template or host-group level so they are not visible in the host form. Checkmk handles this with the “SNMP credentials of monitored hosts” rule, which you can scope by folder or host tag.

Common mistakes

• Leaving v2c enabled “just in case”. If v3 works, remove the communities. Otherwise the weak path stays open forever.
• Swapping the two passphrases. It happens more than anyone admits, and the error message points at the wrong half.
• Forgetting distributed pollers. A new poller in a branch office needs to be in every device ACL, or polls from that site time out.
• Polling too aggressively. Small switches have weak control-plane CPUs. A 60-second interval on a 48-port access switch with full interface tables is fine; 10 seconds is not. See our guide to cutting alert noise for why tighter intervals rarely help.

Where to go next

To find switches that never made it into monitoring in the first place, see the network discovery and troubleshooting tools. If you are still choosing a platform for network gear, our SNMP and network device monitoring category compares the options side by side, and LibreNMS vs PRTG looks at the open-source versus paid-subscription decision specifically. Packages for all of these should come from the vendor’s own repositories; our where to get it page explains how to verify signing keys.