CHECK-MIB :: checkRuleOperation

MIB Reference — IPNetwork Monitor · Updated October 05, 2026

All MIBs › CHECK-MIB › checkRuleOperation

checkRuleOperation

Module: CHECK-MIB

OID (symbolic): CHECK-MIB::checkRuleOperation

OID (numeric): 1.3.6.1.2.1.7777.1.4.1.5

Node type: OBJECT-TYPE

Type: INTEGER

Access: read-write

Description: The value of this object specifies the comparison operation to be performed between the value of the managed object indicated by checkRuleOid and the value indicated by checkRuleValue. Some operations cannot be applied to all the types of object. If the value of the checkRuleOperation is inconsistent with the type of the object indicated by checkRuleOid, then an attempt to activate the row results in an inconsistentValue error.

The value 0 can be configured for all the object types and means that no operation is performed and the rule never fails.

When the type of the object indicated by checkRuleOid is IpAddress, BITS, OBJECT IDENTIFIER then only the value equal(2) can be configured. For the IpAddress, the value of the object indicated by checkRuleOid is compared byte by byte with the value of checkRuleValue and the rule doesn't fail if all the bytes are matched. For the OBJECT IDENTIFIER, the rule doesn't fail if checkRuleValue encodes an OID of the same dimension of the value of the object indicated by checkRuleOid and the two OIDs are equal. For the BITS, the rule doesn't fail if the checkRuleValue encodes a bitstring long at least as the number of the named bits and all the named bits are matched with that bitstring.

When the type of the object indicated by checkRuleOid is INTEGER, Integer32, Unsigned32, Counter32, Counter64, TimeTicks, Gauge32, all the values from 1 to 6 can be configured. These values define simple mathematical operations: the rule doesn't fail if the the value of the object indicated by checkRuleOid is, respectively, !=, =, <, <=, >, >= than the value of checkRuleValue.

A value of of delta(7) can be configured only for Counter32, Counter64, Gauge32; moreover it is permitted only if the check including the rule is performed automatically and thus its value of checkResultInterval greater than 0, otherwise an inconsistentValue error is returned. For a delta operation, each time the rule is performed, the difference between the actual value of the managed object and its value at the last performance is considered and the rule doesn't fail if the difference is <= than the value of the checkRuleValue. If the actual value is less than the previous one, then the difference is augmented with the value 4294967295, like as the managed object reached its maximum value and it has been resetted.

Each time the new value of the managed object must be stored by the device in an internal buffer. The buffer must be handled so that when a new managed object is controlled, a new entry is allocated for it. If no more entries are available, then the rule fails with severity 4294967294. If a managed object for which an entry was previously allocated, doesn't exist when a new execution of the delta operation is performed, its entry should be removed. When a new entry is allocated for a new managed object, its value is stored in the entry, but the operation is not computed and the rule doesn't fail; the delta operation is normally computed only from the second time.

What is checkRuleOperation?

This object specifies which comparison, equal, unequal, less, less-or-equal, greater, greater-or-equal, or none, is performed between the live value of the object at checkRuleOid and the configured checkRuleValue, and the description notes some operations don't apply to all object types, causing an activation error if mismatched. An admin building a CPU-above-90%-alert would choose greater(5) paired with a checkRuleValue of 90, whereas checking that an interface must be exactly up would use equal(2); picking an operation incompatible with the target object's type, for example greater against a DisplayString, would fail row activation rather than silently misbehaving. Configuring this object as greaterOrEqual(6) against a memory-utilization gauge with checkRuleValue of 85 would flag a failure any time utilization reaches 85% or higher.

Examples

Walk all instances (SNMPv2c):

snmpwalk -v2c -c public <target> 1.3.6.1.2.1.7777.1.4.1.5
snmpwalk -v2c -c public <target> CHECK-MIB::checkRuleOperation

Get a specific instance (index 1):

snmpget -v2c -c public <target> 1.3.6.1.2.1.7777.1.4.1.5.1
snmpget -v2c -c public <target> CHECK-MIB::checkRuleOperation.1

Set instance 1 (SNMPv2c):

snmpset -v2c -c private <target> 1.3.6.1.2.1.7777.1.4.1.5.1 i <value>

Start monitoring SNMP-managed network equipment (any vendor) with a free 30-day trial of IPNetwork Monitor. Create custom SNMP monitor using the CHECK-MIB::checkRuleOperation OID value, configure state conditions and alerts, and monitor any SNMP-managed network equipment (any vendor) from a single console.

OID Breakdown

Upper-level ancestors (10 from the standard OID tree / other modules)
Numeric OIDNameModule
1isoLANART-AGENT
1.3orgAirPair-MIB
1.3.6dodAirPair-MIB
1.3.6.1internetAirPair-MIB
1.3.6.1.2mgmtAPERTUS-NPG-MIB
1.3.6.1.2.1mib_2AXON-MIB
1.3.6.1.2.1.7777ahcfMIBAHCF-MIB
1.3.6.1.2.1.7777.1ahcfObjectsAHCF-MIB
1.3.6.1.2.1.7777.1.4ahcfSysInfoAHCF-MIB
1.3.6.1.2.1.7777.1.4.1ahcfSysTimeAHCF-MIB
Numeric OIDNameModule
1.3.6.1.2.1.7777.1.4.1.5checkRuleOperationCHECK-MIB