SNMP Agent Administration Guide

Using the BEA SNMP Agent Integrator for Polling

The following sections describe how to use the BEA SNMP Agent Integrator as a proxy for the management station to poll locally on the managed node:

Overview of Polling

Polling is the activity of checking the value of an attribute of a managed resource at a specific interval. To track faults in critical system components or applications, management systems use polling to determine whether attributes of the managed resource have crossed a significant threshold. However, direct polling by a management station becomes increasingly inefficient as the number of components being polled increases—the load on network bandwidth increases as does the load on the management station itself.

The BEA SNMP Agent Integrator can be configured to act as a proxy for the manager and do the polling locally on the managed node. The load on the management station is reduced and less network bandwidth is consumed by off-loading polling to distributed integrator agents.

You can specify the threshold to check, and polling can be activated during BEA SNMP Agent Integrator startup or by an SNMP Set request from the management station. The BEA SNMP Agent Integrator sends an enterprise-specific SNMP trap when the threshold is crossed. To indicate the cause of the alarm, you can configure a specific-trap type number to be sent in the trap generated when a given threshold is crossed. Communication between the manager and BEA SNMP Agent Integrator occurs only when the manager sends a Set request to de-activate (or re-activate) the polling, or when the BEA SNMP Agent Integrator sends an SNMP trap if it detects the specified event in the managed resource. The BEA SNMP Agent Integrator can also be configured to execute a script or program when a threshold is crossed.

Procedure for Setting Up Local Polling

The steps in using the BEA SNMP Agent Integrator for local polling can be summarized as follows:

Decide which resources you want to monitor.

The attributes of the resource that you want to monitor must be defined as MIB objects. These MIB objects must be supported by an agent or subagent that has been installed on the managed node.

Make the managed resource accessible to the BEA SNMP Agent Integrator.

The BEA SNMP Agent Integrator must know how to access the managed object. This means the object identifier for that object must lie within branches of the OID tree that are known to the BEA SNMP Agent Integrator.
If the managed object you want to monitor is supported by a SMUX subagent that has been installed on the managed node, the subagent automatically registers its section of the OID tree with the BEA SNMP Agent Integrator when the subagent is started. This can be modified using OID_CLASS entries in the BEA SNMP Agent configuration file, as described in Configuration Files.
For peer SNMP agents (or DPI or SMUX master agents), you must define the segments of the OID tree supported by those agents in NON_SMUX_PEER entries in the BEA SNMP Agent configuration file. This is described in Configuring the BEA SNMP Agent Integrator for Use with Multiple SNMP Agents.
The BEA SNMP Agent Integrator directly supports the following MIB groups: MIB-II system and snmp groups, the SMUX MIB, and the BEA SNMP Agent beaintAgtTable in the SNMP agent MIB.

Define polling instructions for the BEA SNMP Agent Integrator

This task consists of two main subtasks:

Define the desired threshold.
Specify the action to take if the threshold is crossed.

Each polling instruction for the SNMP Integrator is called a rule. Rules are defined under the RULE_ACTION entry in the BEA SNMP Agent beamgr.conf configuration file. You can use your favorite text editor to modify this file. (For information on how to create rules, see Creating New Polling Rules.) Rules are explained in BEA SNMP Agent Integrator Rules, while Configuration Files provides the complete syntax for the RULE_ACTION entries.

Configure your SNMP management system for BEA SNMP Agent Integrator traps

When a polling threshold is crossed, the BEA SNMP Agent Integrator sends an enterprise-specific SNMP trap notification to the destinations specified by the TRAP_HOST entries in the BEA SNMP Agent configuration file. Some configuration is required on your SNMP-compliant management system to make use of the traps that are thus generated. The exact set of steps you need to perform varies, depending upon which management system you are using. Typically, some configuration or mapping is required to get the management system to perform a desired action when a trap is received. For example, you might want the management system to turn an icon red when a trap is received. Consult your management system documentation for specific instructions.

Start the BEA SNMP Agent Integrator polling.

The BEA SNMP Agent Integrator begins executing all valid polling rules when it is started. For more information, see Starting BEA SNMP Agent Integrator Polling Activity.

De-activate or re-activate BEA SNMP Agent Integrator polling, when desired.

Polling rules are available as MIB objects; thus you can de-activate or re-activate polling from the management station by means of an SNMP Set request. This topic is described in Starting BEA SNMP Agent Integrator Polling Activity.

BEA SNMP Agent Integrator Rules

A BEA SNMP Agent Integrator rule is a polling instruction for the SNMP BEA SNMP Agent Integrator, and it consists of the following parts:

A unique name for the rule (can be a maximum of eight characters long)
A condition (or threshold) for which the integrator is to check. (This is described further in Conditions.)
An action to take if the specified threshold is crossed. (This is described in States and Transitions.)
A polling frequency (specified in seconds), that is, the time delay between each access of the specified object value

Conditions

When the BEA SNMP Agent Integrator polls, it checks to determine if a specified condition holds. A condition is defined as a relationship between an object (specified by its object identifier) and a value.

Relations for Defining Conditions

The condition obtains (the threshold is crossed) if and only if the specified relation holds between the object and the value. For example, the relation "greater than" defines the following condition: "disk capacity in use greater than 90 percent."

In this case, the condition holds (evaluates to true) if the object (percentage of disk capacity in use) has a value that is greater than 90. (In this example, the condition is described in English, not the actual code used to define BEA SNMP Agent Integrator polling rules.)

Any of the relations shown in the following table can be used to define conditions.

Symbol	Meaning
==	Is identical to
!=	Is not identical to
<	Is less than (for numeric values is a substring of (for strings)
>	Is greater than (for numeric values) contains (for strings)
<=	Is less than or equal to
>=	Is greater than or equal to

Polling with a SMUX Subagent

For example, suppose that you want the BEA SNMP Agent Integrator to check if any server group is inactive. The state of the server group is represented by the tuxTgroupState object in the beaSysPerf group. The BEA SNMP Agent component uses SNMP multiplexing (SMUX) protocol to talk to the BEA SNMP Agent Integrator, and to supply the value of the object to the BEA SNMP Agent Integrator on the same machine.object in the beaSysPerf group. This subagent uses SMUX protocol to talk to the BEA SNMP Agent Integrator.

Examples

You can use the following condition to define a polling rule for the BEA SNMP Agent Integrator:

(VAL(.1.3.6.1.4.1.140.300.4.1.1.4.*) !=1)

The expression VAL() is used to obtain the value of the tuxTgroupState object. The specified condition is obtained if any server group is not active (!=1). In this example, the initial dot indicates that this is an absolute OID; that is, the path to the tuxTgroupState object is .1.3.6.1.4.1.140.300.4.1.1.4. The asterisk (*) wildcard for the instance index indicates that the condition is satisfied if any tuxTgroupState is not equal to 1. Use 0 as the instance index for scalar objects. For more information, see Instance Indexes.

The following example is of a BEA SNMP Agent Integrator rule that uses the condition previously specified:

RULE_ACTION grpState 60 if (VAL(140.300.4.1.1.4.*) !=1) {TRAPID_ERR=300}

In this example, grpState is the name of the rule. The BEA SNMP Agent Integrator checks the server group state every 1 minute (60). If any value of tuxTgroupState is not equal to 1, TRAPID_ERR=300 instructs the BEA SNMP Agent Integrator to generate an enterprise-specific trap with a specific-trap type number of 300.

Note: (The MIB objects whose values the BEA SNMP Agent Integrator can obtain depend on the MIB objects supported by the agents or subagents that the BEA SNMP Agent Integrator is managing. In the previous example, the BEA SNMP Agent Integrator can poll for the tuxTgroupState object value only if the tux_snmpd subagent is running on the managed node. The MIB objects that the BEA SNMP Agent Integrator can access through a peer SNMP agent depend on the NON_SMUX_PEER entries in the BEA SNMP Agent configuration file, as explained in Using Multiple SNMP Agents.

Polling with SNMP Peer Agents

The BEA SNMP Agent Integrator can also obtain MIB object values from SNMP peer (non-SMUX peer) agents on either the same machine or other machines in the network. For example, suppose that a peer SNMP agent supports the MIB-II interfaces group. If so, you might want the BEA SNMP Agent Integrator to check if a physical interface is not operational. This feature of the interface is represented by the ifOperStatus object in the ifTable in the MIB-II interfaces group. In this case, you want to know whether the value of ifOperStatus is not equal to 1. (An interface is operational if its ifOperStatus value is 1.) If you want to check the ifOperStatus value for the first interface on the machine, you could use the following condition:

(VAL(.1.3.6.1.2.1.2.2.1.8.1) != 1)

This condition holds if, and only if, the first interface in the ifTable is operational. The last numeral, 1, specifies the instance index—the first interface entry in the table.

If the condition is satisfied, you want the BEA SNMP Agent Integrator to take some action. For example, if the ifOperStatus value for an interface is not 1 (that is, the interface is not up), you might want the BEA SNMP Agent Integrator to notify the management station. To do this, you can specify that the BEA SNMP Agent Integrator send an enterprise-specific SNMP trap to the management station with a special specific-trap value that identifies the cause of the trap to you (the system administrator).

Instead of requesting this notification if a specific interface (such as the first one in the ifTable) is down, you might want to be notified if any of the interfaces is down.

Here is an example of a rule entry that would do this:

RULE_ACTION checkIf 120 if (VAL(.1.3.6.1.2.1.2.2.1.8.*) != 1) {TRAPID_ERR=300}

In this example, checkIf is the name given to this particular rule. The value 120 indicates that the BEA SNMP Agent Integrator should check the interface every two minutes. By using the asterisk wildcard for the instance index, the condition is satisfied if any interface in the ifTable has an ifOperStatus not equal to 1; that is, all instances are checked. If the value of the OID is not equal to 1 (the interface is not up) for any instance, an enterprise-specific trap is sent with a specific trap ID of 300.

Note: This rule only causes a trap to be generated when the BEA SNMP Agent Integrator first detects that an interface is down. If the interface continues to be down, it does not generate additional traps.

Use of Logical Operators in Conditions

Conditions are of two types, simple and complex. A simple condition consists of a relation between a managed object and a value. All of the examples in the previous sections have been simple conditions.

You can use the logical operators AND, OR, and NOT to define complex conditions. For example, if A and B are two simple conditions, you can specify a complex condition where both A and B occur.

The symbols in the following table can be used to define complex conditions.

Symbol	Meaning
`!(condition_A)`	Logical negation. The threshold is crossed if and only if condition_A does not hold.
`(condition_A \|\| condition_B)`	Logical disjunction. The threshold is crossed if and only if either condition_A or condition_B obtain.
`(condition_A && condition_B)`	Logical conjunction. The threshold is crossed if and only if both condition_A and condition_B obtain.

Scenario for Using a Complex Condition

For example, you might not want the BEA SNMP Agent Integrator to send an alarm when ifOperStatus is not up for an interface if you have taken that interface down for repair. In that case, you could define a rule that asks the BEA SNMP Agent Integrator to determine if two conditions hold: ifOperStatus is not up AND ifAdminStatus is up. That is, you want to be notified if the interface should be up but is not.

Note: The MIB objects whose values the BEA SNMP Agent Integrator can obtain depend on the MIB objects supported by the agents or subagents that the BEA SNMP Agent Integrator is managing.

Sample Code for this Scenario

To do this, you might modify your checkIf rule as follows:

RULE_ACTION checkIf 60 if ((VAL(.1.3.6.1.2.1.2.2.1.8.*) != 1) && (VAL(.1.3.6.1.2.1.2.2.1.7.*) == 1)) {TRAPID_ERR=301}

How this Rule Works

In this example, the BEA SNMP Agent Integrator checks the interfaces every minute (60) and generates an enterprise-specific trap, with a specific trap value of 301, if any of the interfaces is not up (ifOperStatus not equal to 1) but has an ifAdminStatus value of up (that is, the interface should be up but it is not).

Note: This rule causes this trap to be generated only when the condition first evaluates to true. As long as the interface continues in the same state, a new trap is not generated.

Data Types for Defining Conditions

The syntax for a simple condition is as follows:

(VAL(oid) relation value)

where

relation; oid; value

Specifying Object Identifiers in Conditions

In defining polling conditions, the object identifier (OID) must be specified numerically, not using textual symbols (other than MIB II [mib-2] or enterprises as indicated in the following list). One of the following formats can be used to specify the object identifier:

An absolute object identifier, that is, the full path to the object is specified from the root of the OID tree. An initial dot is used to indicate that the path starts at root, (for example, .1.3.6.1.2.1.1.1.0). Note that the trailing zero in this example is the instance index.
A relative OID under the MIB-II branch can be specified in the form:

mib-2.number.number ...
When the reserved word mib-2 appears as the leading sub-oid, .1.3.6.1.2.1 is assumed to be prefixed to the rest of OID. For example:
mib-2.1.1.0
represents the absolute OID:
.1.3.6.1.2.1.1.1.0

A relative OID under the enterprises branch can be specified in the form:

enterprises.number.number ...
When the reserved word enterprises appears as the leading sub-oid, .1.3.6.1.4.1 is assumed to be prefixed to the rest of OID. For example:
enterprises.140.1.0
represents the absolute OID:
.1.3.6.1.4.1.140.1.0

A relative OID under the enterprises branch can also be specified in purely numeric form:

number.number.number ... ,
If there is no leading "." and the OID starts with a number, .1.3.6.1.4.1 is assumed to be prefixed to the rest of OID. For example:
140.1.1.0
represents the absolute OID:
.1.3.6.1.4.1.140.1.1.0

Instance Indexes

Columnar objects are used to represent a column of a tabular MIB group. Columnar objects, accordingly, can have multiple instances. To specify an instance, the index is appended to the rest of the OID. If the index is a single attribute, the last number in an OID is used to specify the particular instance. If the more than one attribute is required to uniquely identify an instance, an instance number for each attribute is appended to the OID, separated by a dot, in the order specified by the INDEX definition in the ASN.1 file.

For example, suppose that you want to check for the condition in which the state of a particular server is anything but active. To uniquely specify a server instance, you require both the group number and the server ID. The INDEX entry for tuxTsrvrTbl in the ASN.1 file specifies the following as an INDEX to particular instances.

INDEX (tuxTsrvrGrpNo,tuxTsrvrId)

The relative OID for tuxTsrverState is the following:

140.300.20.1.1.5

Thus, to specify the particular server instance for group 55 and server ID 3, you use the following OID:

140.300.20.1.1.5.55.3

Note that the order of the two attribute instances added to the tuxTsrvrState OID is indicated by the INDEX definition above: tuxTsrvrGrpNo followed by tuxTsrvrId.

You can thus define the condition that you want to check as follows:

VAL(140.300.20.1.1.5.55.3) != 1

This condition evaluates to true whenever this particular server instance is not active.

You can use a specific number to specify a particular instance or the asterisk wildcard to specify all instances. Use zero as the instance index in the case of scalar objects (objects that can have only one instance). Use the asterisk wildcard only to represent all instances of a columnar object. For example:

.1.3.6.1.4.1.140.1.1.0

specifies the single instance of a scalar object while:

.1.3.6.1.4.1.140.2.22.1.2.*

specifies all of the instances of a columnar object. When a wildcard is used to define a condition, the condition is satisfied if any instance satisfies the condition.

Notes:

When you specify multiple OIDs in a complex rule, the OIDs should either all use wildcards or none should. That is, you should not combine an OID that specifies a particular instance with an OID that uses a wildcard in the same rule.
When you use multiple OIDs with wildcards in a single rule, all the OIDs should specify objects only within the same table.
In complex conditions, when you use asterisk (*) as the index for the OIDs, the condition is checked between columns of the same row, for all rows available in that table.
When you use a wildcard to define a condition, the condition is satisfied if any instance satisfies the condition. For example, VAL(.1.3.6.1.2.1.2.1.2.2.1.8.*) == 1 is satisfied if 1 is the value of any instance. Once the condition is satisfied, the rule is in the ERR state. The rule remains in the ERR state as long as any instance satisfies the condition. The rule transitions to the OK state only when no instance satisfies the rule.

States and Transitions

Associated with each active polling rule is a state. There are two possible states for an active rule:

OK—A rule is in the OK state when the specified condition does not hold (threshold is not crossed).
ERR—A rule is in the ERR state when the specified condition does hold (threshold is crossed).

Transitions determine when an action is to be taken in response to a poll. BEA SNMP Agent Integrator polling rules execute an action (such as generating a trap notification) only when a polling rule undergoes a transition from OK to ERR or from ERR to OK.

When the BEA SNMP Agent Integrator begins executing a polling rule, the rule is initially in the OK state. As long as the threshold is not crossed, the rule remains in the OK state. If the threshold is crossed, the rule undergoes a transition from the OK state to the ERR state. As long as the condition continues to evaluate as true, the rule remains in the ERR state. If the condition subsequently evaluates to false, the rule then transitions back to the OK state. Thus, there are two types of transition:

A transition from the OK state to the ERR state
A transition from the ERR state to the OK state

Note: When conditions are defined for all instances of a columnar object using a wildcard ("*"), the rule transitions from the OK state to the ERR state if the column in any row of the table evaluates to true for the defined condition. The rule transitions to OK if the condition evaluates to false for the column in all rows of the table.

Actions

An BEA SNMP Agent Integrator rule can specify two types of action to be taken if the polling rule undergoes a transition:

An enterprise-specific trap with a user-specified specific trap number.
A specified program or script (or batch file).

Both types of action can be specified in the same rule.

Note: The BEA SNMP Agent Integrator carries out an action only when a transition occurs. Continued polling does not result in duplicate actions as long as the rule remains in the same state. This restriction prevents duplicate traps from being generated in response to detection of a single event.

Four keywords are used to define actions:

TRAPID_ERR = specific-trap-number

Indicates that a trap should be sent if the state of the rule transitions from OK to ERR.

TRAPID_OK = specific-trap-number

Indicates that a trap should be sent if the state of the rule transitions from ERR to OK.

COMMAND_ERR = "command"

The program specified by command is executed if the state of the rule transitions from OK to ERR.

COMMAND_OK = "command"

The program specified by command is executed if the state of the rule transitions from ERR to OK.

Note: The string specifying the command to be executed must be in quotes. For example: COMMAND_ERR = "usr/mybin/test.ksh".

If you do not specify the absolute path to the executable or script, the path should be specified in the BEA SNMP Agent Integrator's environment settings.

The statements specifying actions must be placed within curly braces. When multiple commands are specified in a rule, the commands must be separated by spaces and command must be enclosed in quotes.

A string containing the name of the rule and the direction of the state transition (OK to ERR or ERR to OK) is passed as an argument to the script or program called by the COMMAND_ERR or COMMAND_OK actions.

Trap Information

The following information is passed in the enterprise-specific traps generated by BEA SNMP Agent Integrator polling rules:

User-defined specific trap number
Rule name and state change

A TRAPID_ERR action passes a string in the variable bindings of the trap that takes the following form:
Rule id rule-name has triggered from OK to ERR state
A TRAPID_OK action passes a string in the variable bindings of the trap that takes the following form:
Rule id rule-name has triggered from ERR to OK state

Enterprise ID

When a threshold is crossed, the BEA SNMP Agent Integrator generates an SNMP trap packet (PDU) that has the following enterprise OID in its enterprise field:
.1.3.6.1.4.1.140.1.1

Note: BEA SNMP Agent Integrator polling alarms have a different enterprise identifier in the enterprise field of the trap than the BEA SNMP Agent traps that forward Tuxedo system events. BEA SNMP Agent Integrator polling alarms use bea as an enterprise identifier, whereas the BEA Tuxedo SNMP Agent system traps use tuxedo as the enterprise identifier.

Examples

In the following example, the BEA SNMP Agent Integrator polls every ten minutes (600) to determine if disk capacity in use is greater than 90 percent. If any file system has more than 90 percent capacity in use, an enterprise-specific trap with number 102 is generated. If subsequently all the file systems have less than or equal to 90 percent of capacity in use, an enterprise-specific trap with trap number 202 is generated.

RULE_ACTION diskchk 600 if (VAL(140.2.22.1.5.*) > 90) {TRAPID_ERR = 102 TRAPID_OK = 202}

In the next example, a Tuxedo application is checked to determine if the transaction triptime exceeds 36 msec. If the threshold is crossed, an enterprise-specific trap is generated and a user script, logtime, is invoked to log the time of the event. If the triptime is subsequently less than 36 msec after having crossed that threshold on the previous poll, an enterprise-specific trap with a number of 302 is generated.

RULE_ACTION triptime 20 if (VAL(140.150.1.3.*) > 36) {TRAPID_ERR = 301 TRAPID_OK = 302 COMMAND_ERR = "/usr/sbin/logtime"}

Note: The object identifier in this example is not defined in the BEA MIB, which is an example of an object that might be defined in a user-supplied custom MIB.

In the next example, the BEA SNMP Agent Integrator polls every five seconds to check whether the number of requests completed by the Tuxedo server Server1 is greater than six. If it is, an enterprise-specific trap is generated with a specific trap number of 210 and the command C:/etc/srv_reqs.cmd is executed.

RULE_ACTION Server1 5 if ((VAL(140.300.20.2.1.12.*) > 6)) { TRAPID_ERR=210 COMMAND_ERR="C:/etc/srv_reqs.cmd" }

In the next example, the BEA SNMP Agent Integrator is checking a particular server instance in any state other than active. The server that is being checked is uniquely identified by its group number and server ID: group number 55 and server ID 3.

RULE_ACTION srvrUp 60 if (VAL(140.300.20.1.1.5.55.3) != 1 {TRAPID_ERR = 306 TRAPID_OK = 307}

Whenever the server satisfies the condition, the rule transitions to the ERR state and generates an enterprise-specific trap with the specific trap number of 306. Whenever the server becomes active again, it transitions back to the OK state and issues a trap with the specific trap number of 307.

Starting BEA SNMP Agent Integrator Polling Activity

Polling rules are defined as RULE_ACTION entries in the BEA SNMP Agent beamgr.conf configuration file. The default location of this file is C:\etc on Windows systems and /etc on UNIX systems. Individual rules are MIB objects, stored as an entry (row) in the beaIntAgtTable.

The status of each rule entry determines whether the BEA SNMP Agent Integrator executes that rule (that is, whether the BEA SNMP Agent Integrator actively checks the condition specified in the rule). The status of each rule entry is stored in the beaIntAgtStatus object. Polling is active for a rule if the status of that rule is valid (integer value of 1). Polling is inactive for a rule if its status has been set to inactive (integer value of 3). The specific rule can be Set from a management station (such as OpenView or SunNet Manager) by using the unique name of the rule as the key field used to specify the entry instance (row).

Note: The BEA SNMP Agent Integrator must be running in order to successfully Set objects in the beaIntAgtTable.

The BEA SNMP Agent Integrator begins to execute all polling rules defined in RULE_ACTION entries in the BEA SNMP Agent beamgr.conf configuration file when it first starts up. The status of each rule object in the beaIntAgtTable is valid at startup.

Creating New Polling Rules

You can add rules to the configuration file in two ways:

Use a text editor, such as vi, to add a RULE_ACTION entry to file, making sure that you conform to the syntax of the rule, as described in Configuration Files. However, if the BEA SNMP Agent Integrator is already running, the new rule does not take effect until you execute the following command:

reinit_agent snmp_integrator
Executing this command causes the BEA SNMP Agent Integrator to re-read its configuration file.

Since individual rules are MIB objects, stored as an entry (row) in the beaIntAgtTable, you can use an SNMP manager (or the snmptest utility) to create a new entry (row) in the beaIntMgtTable. (The SNMP manager must have the ability to issue SNMP Set requests that contain multiple objects in a single Set request.) To create the new row, issue a Set request after you specify an index value that does not already exist in the table. This Set request causes a new RULE_ACTION entry to be created in the configuration file.

Deleting or Modifying Polling Rules

BEA SNMP Agent Integrator polling rules can be modified in the same two ways they can be created:

Use a text editor to delete (or comment out) or modify a RULE_ACTION entry in the beamgr.conf file. This change does not take effect unless you issue the following command to force the BEA SNMP Agent Integrator to re-read its configuration file:

reinit_agent snmp_integrator

Use SNMP Set commands to delete or modify rules.

Stopping BEA SNMP Agent Integrator Polling Activity

Polling can be de-activated in one of two ways:

Remove the RULE_ACTION entry from the configuration file.

You can turn off a polling rule by commenting out or deleting that RULE_ACTION entry in the BEA SNMP Agent beamgr.conf configuration file. However, for this to take effect, you need to execute reinit_agent snmp_integrator. This execution, in turn, causes the BEA SNMP Agent Integrator to re-read its configuration file.

Use snmptest or an SNMP-compliant manager to Set the value of the rule status to inactive.

Polling for that rule can be de-activated from the management station (or by using the snmptest utility packaged with the BEA SNMP Agent Integrator) by setting the value of that object to inactive (an integer value of 3). Setting the value to 2 (invalid) causes the RULE_ACTION entry to be deleted from the configuration file. The following figure shows the rule diskchk, discussed earlier, being set to inactive. Note that the read/write community string (in this example, iview) is required for set permission. Figure 7-1 Setting a Polling Rule to Inactive

Restarting BEA SNMP Agent Integrator Polling Activity

When a polling rule has been de-activated using a Set request from a management station, the rule can be re-activated using a Set request to set the value of the corresponding beaIntAgtStatus object to valid (integer value of 1).