User`s manual

RNAS-1200 Series Modify Network Settings
6-10
rnas1200Query
A scalar SNMP object used to query an RNAS-1200 RESOURCE_IDENTIFIER. For a full list of resources
available for queries, refer to the table below, SNMP Resource Identifiers for Moxa’s SNMP Control
Interface.
OID:
1.3.6.1.4.1.8691.12.1200.1.3.0
Input Syntax: [RESOURCE_IDENTIFIER]
Ex:
systemResources.hostname.1
Output Result: [RESOURCE_VALUE]
Ex:
MOXA
Moxa SNMP Control Interface: Usage Examples
There are many SNMP suites, and all may be used more-or-less interchangeably. In the following example, we
use Net-SNMP syntax to demonstrate how to use SNMP to acquire information from and remotely manage a
device.
Moxas proprietary MIB file implements a heavily modified version of Net-SNMP that is not always intuitive. This
is because Moxas SNMP controls are the view layer (i.e., the user interface) of a larger MVC software
framework. The model layer of this framework is a transparent database with which the SNMP controls interact.
Thus, when the proprietary OID
rnas1200Query (1.3.6.1.4.1.8691.12.1200.1.3.0) is called, the
returned resource and its associated value are being read from the relational database which forms the model
layer within the framework. When the
rnas1200Commit (1.3.6.1.4.1.8691.12.1200.1.2.0) object is
called, the related resource and value are not being written directly to the system, but are instead written to the
relational database in which all system information is stored. This database is constantly being monitored by
control layer, so that when a new write to the database is completed the framework’s control layer will
automatically and immediately implement the changes in the root system.
Consequently, when using Moxas proprietary MIB file to control, monitor, and manage system processes, the
syntax used is slightly different than with a stock Net-SNMP implementation. Because the resources available
for management and monitoring are stored in a relational database, SNMP does not call them directly from the
root system. Instead, they are referenced as paired strings of database objects. The following example gives
a basic idea of the modified syntax; notice the data type is
s, for STRING:
#snmpset [COMMAND_OPTIONS] [IP_ADDRESS] [OID] [DATA_TYPE: s, for STRING] /
[RESOURCE_IDENTIFIER=RESOURCE_VALUE]
When considering this example (and the ones below), new users of SNMP should make two notes. First, in
standard Net-SNMP syntax, OID data types are defined by tags; these tags are distinct from the command
options which modify the basic SNMP command. Common command options are delimited by hyphens (
-v, -c,
-x, etc), while OID data types (i for INTEGER, s for STRING, d for DECIMAL_STRING, etc) are not
delimited by hyphens. In the three examples immediately below, the s delimiter is used to indicate that the OID
data type is a
STRING.
Second, when calling an OID, a final number called the instance identifier is sometimes appended to indicate
whether the OID being called is a scalar value or is retrieving a value from within a columnar table. For Moxa’s
current implementation of the RNAS SNMP controls, all values are scalar. Thus, in all the following examples all
the instance identifiers are zero. For instance, the OID for acquiring RNAS-1200 settings is
1.3.6.1.4.1.8691.12.1200.1.1. To indicate that this is a scalar value, the instance identifier of zero may
be appended to the OID, so that the completed OID is written
1.3.6.1.4.1.8691.12.1200.1.1.0. While
the final instance identifier is not always required by NMS systems, for many it remains a required parameter
and so Moxa includes it here as an example of best practices.