SNMP Client Walk Rule Edit

From Control Solutions IoTServer Documentation
Jump to navigation Jump to search

SNMP Client Walk Rules are where you configure the device to query other SNMP devices for data by walking a table in that device, and store that data in local data objects. This page is where you set up a table walk rule. The "table walk" will consist of a series of SNMP Get-Next requests resulting in retrieving multiple data values with one walk rule.

Snmp client walk rule edit 1.jpg

Rule Number – Used as a reference in the rule list for ordering the rules. Polling is done in round robin fashion in the order of rule number.

Snmp client walk rule edit 2.jpg

OID – A dot field character string specifying the starting OID for the table walk. The table is walked using GetNext requests, therefore the OID must specify an OID preceeding the first OID that one wishes to read.

The table OID is different than OIDs for read and write maps. The table OID includes optional wildcard fields when the walk method is Index or Mask. For example, to walk the alarm table of a UPS using RFC 1628, the OID would be 1.3.6.1.2.1.33.1.6.2.1.*(2).*. The *(2) means allow any value in the second to last field but only act on the value when this field is 2. The last asterisk means disregard the last field entirely (which for RFC 1628 increments with each new alarm until reaching some rollover point, then starts back at 1 again).

Device – Identifies which device from the device list this rule applies to, i.e., determines which IP address to try to establish a connection with.

Snmp client walk rule edit 3.jpg

Method – Defines the method of table walk to be used with values as follows:

  • Normal (0)
  • Sparse (1)
  • Wildcard (2)
  • Index (3)
  • Mask (4)

The table walking process can become complicated by the fact that tables are allowed to have missing rows, or rows may have intermittent missing columns. In some applications, rows will be populated only temporarily and then they will disappear. The table walk method identified as "Normal" expects the given column to exist in all rows through the range of rows defined by the starting OID and the count. The remaining methods accommodate the other complications permitted by SNMP.

Method "Normal" will simply produce a 1 to 1 correlation between table entries and object numbers, placing successive values in successive objects. Data will be interpreted according to the data hint if an octet string is returned, otherwise the ASN encoding will take precedence. If the Get-Next sequence fails to return enough OIDs to fill the 'count' criteria, an error code is set for the device indicating that the table came up short on data.

Method "Sparse" is the same as Normal, except missing OIDs in the sequence is anticipated, and the corresponding local objects in the sequence are skipped over if the respective OID is not included in the Get-Next sequence. No error is flagged for table being short on data.

Method "Wildcard" allows wildcard fields in the table OID. The walk does not care about order of OIDs returned by Get-Next as long as they match the OID given after discounting wildcard fields. No attempt is made to sequentially pair OIDs with objects. The next 'count' OIDs that successfully match the OID with wildcards will fill the next 'count' of objects beginning with the starting local object number. The OID sent out in the first Get-Next request will have zero in any wildcard fields, and each successive Get-Next will send out the OID from the response to the previous Get-Next.

Method "Index" will walk the table, but expect to find that values are OIDs. In other words, the table name is an OID, but the contents of the variable at that name will be another OID. The result is that the OID index (last field of OID) from the value will be used as the offset to calculate which object number is to be affected, and that object will be set to 1 indicating this OID is present in the table. This seemingly odd means of table walking is required in order to translate the alarm table from RFC 1628 for UPS systems into indexable local objects that indicate the presence or absence of alarms defined in RFC 1628. (Note that the alarm table in RFC 1628 is "sparse" meaning its table entries are only present if an alarm is present, and the table is empty if there are no alarms. One cannot simply query OIDs to determine presence of an alarm. Alarms are implied by presence of a table entry that only exists while the alarm is present. Furthermore, the alarm table is simply a circular buffer of alarm entries, and the table index means nothing.)

The object set to 1 by the Index method will not be reset to zero by anything in the table walk rule. Use the timeout feature available in the definition of the object itself to set it to a default value after some amount of time, typically a time longer than the rate at which this table is walked. The result will be a object that is set to 1 when the corresponding alarm exists, and automatically reset to zero sometime after the alarm no longer is found in the alarm table.

Method "Mask" is a modified version of "Index". It will walk the table in the same manner, but set bits within the same single object corresponding to the OID index field. OID index .1 will be bit 0, index .2 will be bit 1, and so on. In this case, starting object is the only object number affected, and "count" is the number of bits that will be affected in that one object. If the Index method is used and one wishes to recognize the full range of alarms known to RFC 1628, then 24 objects will be consumed. Using the Mask method, only one 32-bit object is used. Furthermore, non-present alarms will have their corresponding bits cleared without any timeout default value. (Timeout and default should not be used in this case since the single object represents as many as 24 individual states.)

Hint – Provides direction on how to interpret data in the event the value type is Octet String. All ASN data types are interpreted according to their type; however, Octet String will default to being interpreted as a character string unless this hint says otherwise. The exceptions are hint=”1” to interpret 4-octet Octet Strings as 32-bit floating point per RFC 6340, and hint=”2” to interpret 8-octet Octet Strings as 64-bit floating point per RFC 6340. If the hint is non-zero but the Octet String length is not 4 or 8, then it will still be treated as a character string.

Snmp client walk rule edit 4.jpg

Poll Time - Real poll time in seconds, can be fractional. The sets the rate at which the table in the remote SNMP device will be walked. This poll time is not guaranteed to be met. Polling is done in round-robin fashion. In a very busy system, more than this time may expire before the next poll. If less than this time has expired, then the system will wait this amount of time until polling again.

Snmp client walk rule edit 5.jpg

Start Object – Specifies the first local object number that may be filled by this table walk, used in conjunction with count (below).

Snmp client walk rule edit 6.jpg

Count – Specifies the number of local objects, starting at startObject, that may be filled by this table walk. Most table walks are going to result in filling multiple objects with data.

Snmp client walk rule edit 7.jpg

Index Object – Optional, allows for selectively enabling this table walk. If an index object (local object number) is given, and its value matches the index value, then this table walk will take place. If an index object is given but the local object’s value does not match the index value, then this table walk will be skipped.

Index Value – Optional, used in conjunction with Index Object (see note above).