snmpget & snmpset Guide: Read and Write SNMP Values

By the SNMP Monitoring team · Reviewed July 2026

Where snmpwalk sweeps a whole subtree, snmpget reads exactly one object — the right tool when you already know the OID and just want its current value. Its sibling snmpset does the opposite: it writes a value to the device. That write capability is powerful and genuinely risky, so this guide treats it with the caution it deserves. You'll get the exact syntax for reading and writing, why scalar OIDs end in .0, the type specifiers snmpset needs, and a clear-eyed look at why most agents should stay read-only.

Parent: tools. Siblings: snmpwalk, Net-SNMP.

snmpget syntax & examples

The form mirrors snmpwalk but returns a single object instead of a subtree:

snmpget -v2c -c <community> <host> <OID>.0

Read the system uptime:

snmpget -v2c -c S3cr3tR0str1ng 10.0.0.20 sysUpTime.0

SNMPv2-MIB::sysUpTime.0 = Timeticks: (45678901) 5 days, 6:53:09.01

Read one storage row's description by its index:

snmpget -v2c -c S3cr3tR0str1ng 10.0.0.20 hrStorageDescr.31

HOST-RESOURCES-MIB::hrStorageDescr.31 = STRING: /

The flags you'll use:

You can pass several OIDs in one call — snmpget reads them all in a single request, which is efficient when you want a fixed set of metrics.

Scalar instances and the .0 suffix

The .0 trips up newcomers. In SNMP, a scalar object — one that has a single value, like sysUpTime or sysContact — is addressed with an instance suffix of .0. The base OID names the object type; the .0 names the single instance of it. Leave it off and you're asking for the object itself, not its value, and the agent returns noSuchInstance. Table objects are different: their instance suffix is the row index (like .31 above), not .0. So the rule is: scalars end in .0, table cells end in their row index. More on OID structure at what is an OID.

snmpget vs snmpwalk

They answer different questions. Use snmpget when you know the exact OID and want one value — a monitoring poll for a specific metric, or a scripted check. Use snmpwalk when you want to discover what's there, or dump a whole table whose indices you don't yet know. A common pattern is to walk once to learn the index numbers, then get repeatedly against the specific instances in production — the walk is exploration, the get is the steady-state query.

There's a performance angle too. A monitoring platform polling thousands of devices doesn't walk them every cycle — it walks once at discovery to build a picture of each device, then gets exactly the OIDs it cares about on every subsequent poll. A targeted get for five known OIDs is a fraction of the load of walking a whole subtree, and it returns instantly. So the mental model is: snmpwalk answers "what's here?", snmpget answers "what's the value of this specific thing right now?" — and once you've answered the first question, you almost always want the second one for ongoing monitoring. Getting this distinction right is the difference between a poller that scales and one that melts the agent under load. It's also why well-written monitoring templates ship with an explicit list of OIDs to get, rather than a subtree to walk — the authors already did the discovery for you.

snmpset syntax & type specifiers

snmpset writes a value, and unlike a read it must declare the value's type:

snmpset -v2c -c <rwcommunity> <host> <OID> <type> <value>

The type specifier tells the agent how to interpret your value:

For example, setting a writable sysContact (string type):

snmpset -v2c -c RwStr1ng 10.0.0.20 sysContact.0 s "netops@example.com"

SNMPv2-MIB::sysContact.0 = STRING: netops@example.com

The value comes back echoed on success. Get the type wrong — say i for a string — and the agent rejects the SetRequest with a wrongType error.

The risk of SNMP writes

Here's the part to take seriously. snmpset needs read-write access, which on v2c means an rwcommunity — and a read-write community is a cleartext password that can change your device: reset interfaces, alter config, flip a PDU outlet. A leaked rwcommunity is a far worse incident than a leaked read-only one. Sensible rules:

1. Keep agents read-only by default; enable writes only where a real workflow needs them.
2. Never use v2c rwcommunity for writes on anything untrusted — use SNMPv3 with scoped write access.
3. Bind any write access to a narrow VACM view, so a compromised credential can set only what you intended.
4. Prefer the device's own management API over SNMP writes when one exists.

Most monitoring is pure reads. If you're reaching for snmpset, pause and confirm there isn't a safer path — see hardening.

v3 examples

For an authenticated, encrypted read, snmpget takes the same v3 flags as the rest of the suite:

snmpget -v3 -l authPriv -u monitor -a SHA -A "AuthPass" -x AES -X "PrivPass" 10.0.0.20 sysUpTime.0

The credential handling matches SNMPv3 setup; the OID argument and output are identical to v2c. For writes over v3, the same user must have been granted read-write access rather than read-only.

Frequently asked questions

How do I use snmpget?

Run snmpget -v2c -c <community> <host> <OID>.0 to read a single object — for example snmpget -v2c -c public 10.0.0.20 sysUpTime.0. You can list several OIDs in one command to read them together. For v3, use -u <user> -l authPriv -a SHA -A <authpass> -x AES -X <privpass> instead of -c.

Why do I append .0 to the OID?

Because scalar objects — those with a single value, like sysUpTime or sysContact — are addressed with the instance suffix .0. The base OID names the object type; .0 names its one instance. Table cells use their row index instead (e.g. .31). Omit the suffix on a scalar and you'll get noSuchInstance.

What is snmpset?

snmpset writes a value to a device: snmpset -v2c -c <rwcommunity> <host> <OID> <type> <value>, where type is a specifier like i (integer), s (string), or u (unsigned). It requires read-write access, so it can change device configuration — which makes it far riskier than read-only queries.

Is SNMP write access safe?

Not by default. A read-write community on v2c is a cleartext password that can alter your device, and a leak is a serious incident. Keep agents read-only wherever possible, and if you must allow writes, use SNMPv3 with a narrowly scoped view rather than a v2c rwcommunity. Most monitoring never needs writes at all.

Key takeaways

• snmpget reads one object: snmpget -v2c -c <community> <host> <OID>.0.
• Scalars end in .0; table cells use their row index.
• Use snmpget for known OIDs, snmpwalk for discovery.
• snmpset writes — snmpset … <OID> <type> <value> with type specifiers i/u/s/x/a/t.
• Writes need read-write access and are risky — keep agents read-only; use SNMPv3 if you must.
• v3 works with the standard -u/-l/-a/-A/-x/-X flags.