SNMP Daemon RFC Conformance

RFC 1157 requires that each set request variable assignment "should be effected as if simultaneously set with respect to all other assignments specified in the same message" (on pages 25 and 26 of the RFC). This means that a set request with multiple instance ID/value pairs should be processed in an all-or-none fashion. That is, either all the new values are assigned without error, or else none of the variables in the request have modified values. This requirement is also known as "atomic commit with rollback."

Note: RFC 1157 does not address the problems of order dependency or consistency. Ordering dependencies may exist, such as in:

snmpinfo -m set -h host1 ipNetToMediaPhysAddress.f.1.n.n.n=hh:hh:hh:hh:hh:hh\
ifAdminStatus.f=1
 
snmpinfo -m set -h host1 iproutenexthop.n.n.n.n=m.m.m.m ifAdminStatus.f=1

The adapter with ifIndex f must be enabled before an address table entry can be associated with it or before a route can be established that reaches a gateway by using that adapter. In these cases, the order of the variables is significant and must be the reverse of that shown above. If the RFC 1157 atomic commit policy were followed exactly, ordered set requests would have undefined effects.

For the Management Information Base (MIB) variables supported, the snmpd agent prechecks the specified values for the MIB variables in the set request. If a specified value does not meet the precheck requirements, the set request is rejected. The actual implementation for the set request is technically a best effort, not a true atomic commit and rollback.

During the set process when the snmpd agent is actually modifying MIB variable values, if a failure occurs, the original values of the MIB variables already set are not restored.

RFC 1213 describes all variables in the ipRouteEntry table as read-write. As described above, set support is only implemented for ipRouteDest, ipRouteType, and ipRouteNextHop (see note). To accept set requests that may specify several unsupported route attributes (such as the ipRouteMetric1 or the ipRouteProto attributes), set requests for these unsupported variables are accepted. No error response is returned to the request originator, but a subsequent get request will show that the original values have been retained.