Rules for walking tables are defined on this page. Rule number simply tells you where you're at on the list of table walk rules. Click "next" and "prev" to scroll through the list. To advance directly to a specific rule, enter the desired number in the "Rule #" box, then click Update.

The walk will begin at the variable name or OID given. It is not necessary to start at the beginning of a table. To walk a section of the table, enter an OID whose last field is the desired first index, minus one. The count will limit the scope of the walk.

The table name 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).

The method determines how the table walker will operate.

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 requiired in order to translate the alarm table from RFC 1628 for UPS systems into indexable 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. Use the optional timeout feature to reset the object to zero after some amount of time, typically a time longer than the rate at which this table is walked. The result will be an object that is set to 1 when the corresponding alarm exists in an RFC 1628 alarm table (for example), and automatically reset to zero sometime after the alarm no longer is found in the alarm table.

The "local objects starting at" is the first local object to be filled by this table walk, and "count" is the number of objects in the sequence that are to be affected. The count also determines how many OIDs in the table will be read since there is a 1 to 1 correspondence between table entries and local object values saved.

Select the location or device that this table should be read from. The names in the device list are defined in the Devices page.

Data hint provides instruction for interpretation of data in the event the value is an Octet String. If the data is an ASN type that is clearly recognizable, the ASN encoding will take precedence.

Poll Rate, noted as "repeat this process every... seconds", sets the rate at which the table should be walked. The amount of time to wait between table walks is entered. Be prudent with poll rate - this will generate a lot of network traffic.

If the local object written to by the table walk should be automatically reset to zero after some period of time, enter the optional timeout in seconds. Enter zero for timeout if this feature should be disabled.

You have the option of enabling this rule only when a selected object contains a given value. Any local object may be used as the index object. As the name implies, you could have the same local objects contain different values based on different rules as indexed by the index object.

Click Update when all entries have been made. After all configuration has been entered, be sure to go to the Config File page and click Save so that changes are retained through power cycles.

Delete will remove the rule number shown in the "Rule #" box. Insert will insert a new rule before the rule number shown, and is used for placing rules between existing rules. It is not necessary to use Insert to add rules to the bottom of the list or to define any rule presently having zero for a local object or an empty string for OID.

The number of rules enabled simply limits the scope of rule review so that you do not have to review a lot of unused rules. If the displayed rules are used up and you need more, increase the enabled number.