SNMP SET

SET is the one core SNMP operation that changes something on the device, rather than just reading its current state. Where GET and the walking operations only observe, SET actually writes a new value to a specific OID - and if that OID controls something real (an interface's admin status, a threshold, a configuration flag), the device's behavior changes as a direct result.

snmpset -v2c -c private 192.168.1.1 1.3.6.1.2.1.2.2.1.7.1 i 2

That example sets ifAdminStatus for interface 1 to 2 (down) - a real, consequential change, not a query. The i in the command tells the tool the value being sent is an integer; SET requires you to specify the correct data type for whatever you're writing, matching what the MIB defines for that object.

Not every object can be set

Whether an object accepts SET at all is defined in the MIB itself, in the MAX-ACCESS clause of its OBJECT-TYPE definition - typically read-only, read-write, or occasionally read-create (used specifically for creating new rows in a table, closely tied to RowStatus). Attempting to SET a read-only object fails with an error regardless of your access permissions - the restriction is defined by the object itself, not just by what you're authorized to do.

Access control matters more here than anywhere else

Because SET can actually reconfigure a device, write access is something to hand out far more carefully than read access. In SNMPv1/v2c, this means a separate, ideally much more tightly held read-write community string - many environments deliberately configure only a read-only community and skip read-write entirely, preferring a dedicated configuration management system for actual changes. In SNMPv3, write access is granted per-user through view-based access control, which allows much finer-grained control - a user could be permitted to SET within one specific subtree while having no write access anywhere else.

A common, specific use: creating and deleting table rows

Beyond changing a scalar value, SET is also how new rows get created in - or existing rows removed from - certain kinds of SNMP tables, by writing to that row's RowStatus column. This is a more involved, multi-step process than a simple value change, and is common enough to have its own dedicated page.

If a SET request fails

A failed SET usually comes back with a specific error - noAccess or notWritable if the object genuinely can't be written to or you lack permission, or wrongType/wrongValue if the data type or value you sent doesn't match what the object expects. These are generally much more informative than a plain timeout, and worth reading carefully rather than just retrying.