Dell OS10: Configure SNMPv3 on PowerSwitch Switches

2026年8月28日 LOG admin

SNMPv3 is the only SNMP version that provides real security — message integrity, authentication, and encryption — which makes it the right choice for monitoring production Dell PowerSwitch infrastructure. Dell's official knowledge base documents a complete SNMPv3 configuration for SmartFabric OS10 that combines a restricted view, an authenticated user with SHA/AES, and host notifications. This article walks through the full configuration and shows how to verify it end to end with the snmpwalk tool on a Linux host, so you can be sure monitoring works before you rely on it.

Sample SNMPv3 Configuration on OS10

The following configuration is a working sample for an OS10 switch running firmware 10.5.2.6. It creates a group with privacy (encryption), a view restricted to a single OID subtree, a user with SHA authentication and AES privacy, and an SNMP host for informs:

snmp-server group mysnmpgroup 3 priv read snmpview
snmp-server host 100.127.X.X informs version 3 priv user1
snmp-server location SNMP-TEAM-PA
snmp-server user user1 mysnmpgroup 3 auth sha myshaP@ssw0rd priv aes Myencryptedkey
snmp-server view snmpview 1.3.6.1 included

Note how the view snmpview limits the group to OID 1.3.6.1 — a read-only, scoped view is a security best practice for any monitoring account.

Decoding the Four SNMPv3 Objects on OS10

OS10 follows the standard SNMPv3 architecture, but the CLI hides the relationships behind four separate commands. Understanding what each one actually does saves a lot of debugging time, because a mistake in any one of them produces the same symptom — an empty or timed-out walk.

The view defines which OIDs are visible. It is a name plus a list of subtrees, each marked included or excluded. A view is not attached to anything by itself; it is only a named filter.

The group binds a security level to a view. The security level is one of noauth (no authentication or encryption), auth (MD5 or SHA authentication, cleartext payload), or priv (authentication plus encryption). In the sample above the group is declared as version 3 priv read snmpview, which means: SNMPv3 only, authentication and encryption required, and read access filtered through the snmpview view.

The user binds a username to a group and carries the actual authentication and privacy secrets. This is where the algorithm choices live. On OS10 you can choose md5 or sha for authentication and des, aes (128-bit) or aes-256 for privacy, depending on release. MD5 and DES are legacy and should not be used on new deployments.

The host entry tells the switch where to send notifications that it originates — link up/down, BGP state changes, temperature threshold crossings. The informs keyword means the switch expects an acknowledgement and will retry; traps are fire-and-forget. For anything you intend to alert on, informs are the better choice.

Finally, the engine ID is the identity of the SNMP engine. It is generated automatically on OS10, usually from the chassis MAC or the management IP, and it is part of every authenticated message. If you replace a switch and reuse the old management IP with a different engine ID, monitoring systems that cached the old engine ID will report authentication failures until the cache is purged. That single behaviour explains a large share of "it worked yesterday" SNMPv3 incidents.

Installing the SNMP Tools on Ubuntu

To test the configuration you need the SNMP command-line tools. On Ubuntu (the example uses 18.04) install them with:

sudo apt update
sudo apt install snmp snmpd libsnmp-dev

On modern Ubuntu LTS releases the same package set works unchanged. If you only need the client utilities and do not intend to run an SNMP agent on the Linux box, you can drop snmpd and install snmp plus libsnmp-dev alone. The -dev package is only required if you plan to compile or script against the Net-SNMP libraries.

Verifying SNMPv3 with snmpwalk

snmpwalk issues SNMP GETNEXT requests to walk a subtree. Assuming the switch IP is 192.168.0.10 and the OID to query is 1.3.6.1.2.1.1 (system group), run:

snmpwalk -v3 -l authPriv -u user1 -a sha -A myshaP@ssw0rd -x aes -X Myencryptedkey 192.168.0.10 1.3.6.1.2.1.1

A successful response looks like:

iso.3.6.1.2.1.1.1.0 = STRING: "Dell EMC Networking OS10 Enterprise.
Copyright (c) 1999-2021 by Dell Inc. All Rights Reserved.
System Description: OS10 Enterprise.
OS Version: 10.5.2.6."

If all variables in the subtree are displayed, the switch is correctly configured for SNMPv3 monitoring. If the query fails, check that the username, auth passphrase, and privacy passphrase exactly match the snmp-server user line, and that the management network allows UDP 161 between the NMS and the switch. Also confirm the -l authPriv level matches the group level — asking for authentication with a noauth group is a common copy-paste error.

The flags are worth memorising because they map one-to-one onto the CLI objects: -v3 selects the protocol version, -l is the security level, -u is the username that must exist in the snmp-server user line, -a and -A are the authentication protocol and passphrase, and -x and -X are the privacy protocol and passphrase. If you have configured authentication but no privacy, use -l authNoPriv and omit -x and -X.

Querying Individual OIDs with snmpget

A full walk of the wrong subtree is a slow way to find out whether credentials work. For a fast credential and connectivity test, query a single scalar from the system group:

snmpget -v3 -l authPriv -u user1 -a sha -A myshaP@ssw0rd -x aes -X Myencryptedkey 192.168.0.10 1.3.6.1.2.1.1.5.0

That returns sysName.0, which is a useful sanity check because it should echo the hostname you configured. For large tables such as ifTable or ifXTable, snmpbulkwalk is dramatically faster than snmpwalk because it uses GETBULK to retrieve many variables per round trip:

snmpbulkwalk -v3 -l authPriv -u user1 -a sha -A myshaP@ssw0rd -x aes -X Myencryptedkey -Cr50 192.168.0.10 1.3.6.1.2.1.2.2.1

When you get output full of numbers like iso.3.6.1.2.1.1.1.0, translate them into names with snmptranslate:

snmptranslate -On SNMPv2-MIB::sysDescr.0
snmptranslate -Td SNMPv2-MIB::sysName

Debugging Failed Walks

Net-SNMP can tell you a great deal about where the failure happens, but only if you enable its diagnostics. Run the same failing command with verbose logging:

snmpwalk -v3 -l authPriv -u user1 -a sha -A myshaP@ssw0rd -x aes -X Myencryptedkey -D authPriv,msgflags 192.168.0.10 1.3.6.1.2.1.1

The log will typically end in one of a small number of places, and each points at a different fix:

Timeout, no response at all — the switch is not reachable on UDP 161, or the engine ID discovery packet never arrived. Verify reachability with ping, then confirm the management VRF is actually routing the reply.
Unknown user name or an authorization error mid-conversation — the username exists but is in a different group, or the group grants the user a view that excludes the OID being queried.
Authentication failure after a successful engine ID discovery — the passphrase does not match. SNMPv3 passphrases are case sensitive and must be at least eight characters.
Decryption error — the privacy passphrase or privacy protocol does not match. Mixing -x aes with a user configured for priv des produces exactly this.
An empty result set that completes without error — the credentials are fine and the walk succeeded, but the view does not include that subtree. Widen the view, or query a subtree that falls under 1.3.6.1.

It also helps to check the switch side. On OS10 you can inspect the running SNMP configuration and confirm what was actually committed:

show running-configuration snmp
show snmp engineID
show snmp user
show snmp group
show snmp view

Comparing the switch's own view of the world against the client's command line is usually enough to spot the mismatch in a single pass.

Passphrases, Protocols and Key Localisation

SNMPv3 does not send the passphrase over the wire. It derives a key through password-to-key localisation, then mixes in the engine ID. Two practical consequences follow. First, the same passphrase produces different keys on different switches, which is expected and not a bug. Second, if a passphrase is changed on the switch but the monitoring system still holds the old one, the derived key no longer matches and every poll fails authentication.

Choose passphrases of at least twelve characters with mixed case, digits and symbols, and avoid the placeholders from documentation. When you move an existing monitoring account from MD5/DES to SHA/AES, plan a maintenance window: you will need to add the new user, update the NMS, verify, and then remove the old user. OS10 will not silently migrate a user between authentication protocols.

Hardening the SNMPv3 Account

A monitoring account should be the least privileged account on the device. Keep the view tightly scoped to the MIB subtrees your NMS actually polls — typically 1.3.6.1.2.1.1 for system information, 1.3.6.1.2.1.2 for interfaces, and any vendor enterprise branch you need. Include those explicitly and add a trailing excluded entry only if you understand the ordering rules; included entries take precedence in Net-SNMP's model, but a confusing view is a future outage.

On the network side, restrict who can reach UDP 161. If OS10 supports management access lists or a dedicated management VRF in your release, put the SNMP listener and the management interface inside it so that data-plane traffic can never reach the SNMP daemon. Set the SNMP source address explicitly if the switch has several routed interfaces, otherwise notifications may arrive from an unexpected address and be discarded by the receiver.

For notifications, prefer informs to traps and make sure the SNMP host line lists only monitoring endpoints you control. Also set snmp-server location and contact details — they appear in sysLocation and sysContact, and they are the first thing an on-call engineer reads at 03:00.

Saving and Restoring the Configuration

SNMP configuration is part of the OS10 running configuration and must be persisted. In transaction-based mode you commit before it survives a reload:

OS10# configure terminal
OS10(config)# snmp-server group mysnmpgroup 3 priv read snmpview
OS10(config)# snmp-server user user1 mysnmpgroup 3 auth sha myshaP@ssw0rd priv aes Myencryptedkey
OS10(config)# snmp-server host 100.127.X.X informs version 3 priv user1
OS10(config)# end
OS10# copy running-configuration startup-configuration

Capture the result for your backup system and, if you automate deployment, treat the SNMP block as a template variable so that passphrases never appear in plain text inside a Git repository. Storing secrets in a network config repo is a common and avoidable exposure; inject them at deploy time instead.

Integrating with a Monitoring Platform

Once snmpwalk returns data, the hard part is done. Point your NMS at the switch with the same credentials and confirm that interface counters, CPU and temperature are collected. Because SNMPv3 hides the payload, packet captures are no longer useful for content inspection, which makes the -D debugging output and the switch-side show commands your primary tools. Build a small health check into your monitoring that polls sysUpTime and alerts if the poll returns nothing for several consecutive cycles — that detects credential drift, engine ID changes and ACL mistakes before an outage does.