Template:FAQ:Coding 25

Contexts are a mechanism within SNMPv3 (and AgentX) whereby an agent can support parallel versions of the same MIB objects, referring to different underlying data sets. By default, a MIB module registrations will use the default empty context of "". But it's also possible to provide MIB information using a different (non-default) context.

There are three aspects involved in doing this. Firsly, it's necessary to register the MIB module in this non-default context. With the v4 API, this uses the call 'register_mib_context()' rather than the REGISTER_MIB macro. This is significantly more detailed, but most of the additional parameters can take fixed values, if all that's needed is to change the registration context.

Instead of the macro call:

       REGISTER_MIB("my_token", my_variables, variable1, my_variables_oid);

use the function call:

       register_mib_context( "my_token",
                              my_variables, sizeof(variable1),
                              sizeof(my_variables)/sizeof(variable1),
                              my_variables_oid,
                              sizeof(my_variables_oid)/sizeof(oid),
                              DEFAULT_MIB_PRIORITY, 0, 0, NULL,
                              "my_context", -1, 0);

Things are much easier with the v5 helper-based API. Having created the registration structure, this just requires setting the 'contextName' field before actually registering the MIB module:

       netsnmp_handler_registration *reg;
       reg = netsnmp_create_handler_registration(.....);
       reg->contextName = strdup("my_context");
       netsnmp_register_handler(reg);

Secondly, it is necessary to configure the access control settings to allow access to information in the new context. This is handled automatically when using the simple "rouser" or "rwuser" directives. But if access control is configured using the fuller com2sec/group/view/access mechanism, then the "access" line must specify the appropriate context(s), either explicitly:

       access {group} "my_context" any noauth exact  ......

or using a single entry to cover all possible contexts:

       access {group} ""           any noauth prefix ......

Finally, the SNMP request used to retrieve (or update) the information must also specify the required context. With SNMPv3 requests, the context is part of the protocol, so this can be done using a command-line option:

     snmpwalk -v 3 -n my_context .....

With community-based requests (SNMPv1 and SNMPv2c), things aren't so simple. Although the "rocommunity" and "rwcommunity" settings also configure access for all possible contexts, there's no way to specify a non-default context as part of the request.

The only way to handle non-default contexts with community-based SNMP requests is to set up a mapping from the community string to the desired context. This uses the "com2sec" directive, with an additional "-Cn" parameter. Note that this also means that the access control must be configured using the full com2sec/group/view/access mechanism. The short-form access control directives do not handle the mapping of community strings to non-default contexts.