Beruflich Dokumente
Kultur Dokumente
February 2000
Contents
SNMP an Introduction
ii
iii
SNMP an Introduction
SNMP was born out of the U.S> Department of Defenses Advanced Research Projects
Agencys efforts to manage their expanding network of systems from different vendors. Three
solutions were proposed:
CMIP was chosen as the preferred solution, but SNMP evolved out of CMIP as a short-term
solution.
SNMP has been very successful because it is light and flexible. Since SNMP is a light-weight
communications protocol, it adds very little traffic to a network that it is managing.
Additionally, SNMPs simple design allows users to expand the applications that are
monitored by SNMP very easily.
The original specification for SNMP (V1) caught on quickly but exposed a few deficiencies:
bugs
security
To address these deficiencies SNMP V2 was introduced, but disagreements about security
methods led to V2 dropping its security solution. However, V2 did manage to fix some bugs
and introduce new data types and message formats. Recently, V3 has been proposed and
provides a security solution.
This paper address SNMP V1 with little reference to V2 tolerance.
Four types of SNMP messages are defined that allow you to get values from the managed
object, set values on the managed object, and allow the managed object to communicate with
the network manager:
get request
get next request
set request
trap message
PDU
SNMP works very simply. It exchanges network information through messages (technically
known as protocol data units (or PDUs)). From a high-level perspective, the message (PDU)
can be looked at as an object that contains variables that have both titles and values.
There are four basic PDUs that SNMP employs to monitor a network: two deal with reading
terminal data, one deals with setting terminal data, and one is used for monitoring network
events such as terminal start-ups or shut-downs.
Therefore, if you want to see if a terminal is attached to the network, you would use SNMP to
send out a read PDU to that terminal. If the terminal was attached to the network, you would
receive back the PDU, its value being yes, the terminal is attached. If the terminal was shut
off, you would receive a packet sent out by the terminal being shut off informing you of the
shutdown. In this instance a trap PDU would have been dispatched by the terminal.
Get Request
Specific vales can be obtained from a device using the get request. Typically, many different
values can be obtained from a device using SNMP without the overhead associated with
logging into the device, or establishing a TCP connection with the device.
Get Next Request
With the get next request, SNMP managers can walk through all the SNMP values of a
device to discover all the names and values that the device supports. This is accomplished by
starting with the value of the first SNMP object and then using the get net request until there
are no more SNMP objects to get. The process of using the get next request to obtain the
values of all the SNMP objects is referred to as walking the objects.
Set Request
The set request provides a mechanism by which devices can managed using SNMP. With the
set request, SNMP can be used to accomplish activities such as disabling interfaces,
disconnecting users, clearing registers, and more on the managed device.
Trap Message
The trap message allows the SNMP managed device to communicate with the manager. This
allows the device to notify the manager of specific problems. Typically, the use of traps
requires each device on the network to be configured to issue SNMP traps to one or more
network devices that are awaiting or listening for the traps.
sysUpTime
1.3.6.1.2.1.1.3.0
Usually, the tendency is to use the name of the MIB object instead of the numerical identifier.
much like the way host names are used instead of IP addresses on the Web.
See MIB Structure and Objects on page 5 for more information on the description of MIB
objects.
mgmtthis branch contains the standard SNMP objects that are supported by most
network devices.
privatethis branch contains the extended SNMP objects that are defined by network
equipment vendors.
experimentalthis branch usually contains no meaningful data or objects.
directorythis branch usually contains no meaningful data or objects.
The MIB is a tree structure much like a file directory structure. The top five levels of the MIB
tree are constant, and all other MIBs are added to those branches. Figure 3 on page 6 shows
the top of the MIB object tree:
Figure 3
The tree structure is an integral part of the SNMP standard. and the most important parts of
the tree are the leaf objects that provide actual management data regarding the devices.
Generally, the leaf objects are divided into two groups that reflect the organization of the tree
structure.
Discrete and table objects are identified by their extensions. Discrete objects have a .0
(dot-zero) extension added to their name indicating that they are discrete objects, and table
objects have a .instance (dot-instance) extension where the instance is a number greater
than zero that represents the index into the SNMP table for this value.
Table Objects
SNMP tables are special types of SNMP objects that allow parallel arrays of information to
be supported. Tables are distinguished from discrete objects because they can grow without
bounds. For example, SNMP defines the ifDescr object (a standard SNMP object) that
indicates the text description of each interface supported by a particular device. Since network
devices can be configured with more than one interface, this object must be represented as an
array to accommodate multiple and expanding values.
SNMP objects are always grouped in a Entry directory within an object with a Table suffix.
The ifDescr object residues in the iEntry directory contained in the ifTable directory. Several
constraints are placed on SNMP objects:
Each object in the Entry directory of a table must contain the same number of elements as
other objects in the same Entry directory where the instance numbers of all entries are the
same. Table objects are always regarded as parallel arrays of data.
When creating a new Entry object, SNMP requires that a value is associated with each
table entry in a single SNMP message (PDU). This means that to create a row in a table,
using the SNMP set command, a value must be specified for each element in the row.
If a table row can be deleted, SNMP requires that at least one object in the entry has a
control element that is documented to perform the table deletion. (This applies only if the
row can be deleted, which is not necessarily required of an SNMP table.)
MIB tables are access by using the OID that represents an index into the table. Figure 4 shows
how the PSL snmp_walk() function would access the MIB table using the OID as an index
into the table:
Figure 4
Type
Description
Text
A DisplayString type that can contain textual information (usually limited to 256 characters). The text must
contain only printable characters.
Counter
Gauge
A numeric value that can increase or decrease. While this value is not very common in the standard MIB is
widely used in private MIBs.
Integer
A basic integer value that can contain either positive or negatives values. Usually, this value is supplanted
by Counter or Gauge values.
EnumVal
A enumerated value that associates a textual label with a numeric value. This type is common in the
standard MIB.
Time
A TimeTicks type that represents an elapsed time. This time always has a resolution of one hundredth of a
second, even if it is not used. Network managers frequently format this time as HH:MM:SS:ss for display.
The time value is always an elapsed time value. For example, sysUpTime indicates the elapsed time since
the device was booted.
Object
A value that an contain the identifier for another SNMP object. If the named object is compiled into the
MIB, the name is usually displayed as the name of the SNMP object.
IPAddr
A value that contains an IP address of a network device. This type of object is often displayed in the type
as an IP address in conventional dot notation.
PhysAd
A value that contains the physical address of a network device. Managers often display this value as a
series of hexadecimal values, prefixed by the hex keyword and separated by colons.
String
A value that contains arbitrary byte strings. If the byte string contains only ASCII characters, managers
display the value as a text string. Otherwise the managers display this type as a sequence of hexadecimal
values prefixed by the hex keyword and separated by colons. Tis value is not common in the standard MIB
objects but it is occasionally found in private MIBs.
Table
A value that is a branch object containing table entries. This object is always an intermediate name that
contains an Entry directory that contains various table objects.
Branch
A value that defines an SNMP branch that contains additional SNMP objects.
SNMP Architecture
SNMP architecture consists of the following components:
SNMP manager
SNMP master agent
SNMP sub-agents
SNMP instrumenting applications
SNMP Managers
The SNMP manager is an application that provides some basic components for working with
SNMP and ANMP objects. Typically, an SNMP manager will provide the following
functionality:
MIB Compiler
SNMP managers must also have the ability to add new MIB objects that are provided by
network equipment. MIB objects are added using a MIB compiler.
Management Tools
SNMP managers provide tools for inspecting raw MIB objects and setting SNMP values of an
agent. This is usually in the form of a MIB browser.
Trap Reception
All SNMP managers provide some ability to receive and filter SNMP traps issued by network
devices. SNMP traps are an important part of the SNMP standard because they allow devices
to report their own problems.
Alarm Polling
Most substantial SNMP managers provide some ability to set thresholds on SNMP MIB
objects, and respond with some type of notification when these thresholds are violated. This
provides a means of constantly testing a networks integrity against a baseline. The alarm
polling functionality will also determine what devices are responding and which devices are
not responding.
10
Trend Monitoring
Most SNMP managers provide some ability to continuously watch an SNMP value over time
and view trends in the network. Trend monitoring can be used to determine load of a network
over time by watching bandwidth. Typically a management system will plot network
utilization versus time.
SNMP Sub-agents
A subagent may be a stand alone process or part of the application to be managed. The
process supports the sub protocol of the master agent and responds to requests for information
from the master agent.
11
SNMP manager
SNMP master agent
SNMP sub-agents
SNMP instrumenting applications
12
13
MIB to KM Wizard
The MIB to KM Wizard is a tool that reads a MIB definition and creates a KM that includes
parameters, infoboxes, and applications based on the object definitions in a MIB. You can edit
the KM to add functionality, or the KM can then be loaded and PATROL can manage the
SNMP devices along with other applications. You can obtain the PATROL MIB to KM
Wizard from the BMC Software Developer Connection (DevCon) Web Site at
http:\\devcon.bmc.com.
14
When you are using a third-party SNMP Manager. You can manage PATROL objects in the
PATROL MIB after you compile the PATROL MIB into your SNMP management
application. MIB supports V1 syntax. Some MIB compilers will generate errors so MIBs may
need to be edited to ensure the correct V1 syntax is used.
Dynamic OIDs
The PATROL MIB is a little unique because it has dynamic OIDs. Normally, an SNMP MIB
is fairly static, and the OIDs remain constant. However, in PATROL the many of the OIDs
correspond to application instances and the corresponding elements of the application. So
when you are dealing with the PATROL MIB, you must be aware that it will probably look
very different every time you access it.
It is very important to note that since PATROL OIDs are dynamic, an instance may be present
one moment and then gone the next moment if the instance disappears.
Configuring SNMP Management Consoles to Recognize PATROL Traps
SNMP trap notification requires configuration on two ends: the PATROL Agent sending the
traps, and the non-PATROL SNMP management console receiving the traps. The Agent needs
to know where to send the traps. The SNMP management console needs to know how to
recognize PATROL traps, and what to do about them. Also, the SNMP manager must be
added to the PATROL Agents list of interested managers in the config.default configuration
file.
15
The PATROL Agent communicates with both SNMP Managers and SNMP Agents. It
communicates with the SNMP Managers through the SNMP Master Agent. The same is not
true for the SNMP Agents, but SNMP support must be active for this communication to take
place. Configuring PATROL for SNMP consists of the following steps:
set the port number and community name for the PATROL SNMP Master Agent
The PATROL SNMP Master Agent/Sub-Agent model is based on an industry standard
known as SMUX that allows one or more SNMP Sub-Agents to connect to a single
SNMP Master Agent using a TCP SMUX port (TCP port 199 by default).
For more information on configuring the PATROL SNMP Master Agent see Configuring
the PATROL SNMP Master Agent on page 17.
The SNMP management console needs to know how to recognize PATROL traps, and
what to do about them. On some consoles it involves configuration of internal rules and
tables. In others it may involve configuring the "trapd.conf" configuration file.
16
Figure 10 shows the process for configuring the PATROL Agent to run with SNMP:
Figure 10
On Unix, it is $PATROL_HOME/lib/snmpmagt.cfg.
The PATROL SNMP Master Agent configuration file lists the community name and SNMP
listening port. This configuration file is in ASCII text format, which means you can use any
text editor to effect changes.
An SNMP manager is an application that controls an SNMP Agent by making SNMP
requests of it and setting variables in it. An SNMP Agent is an application that builds internal
SNMP structures and provides SNMP information to SNMP Managers in the form of SNMP
traps and responses to SNMP queries.
17
The configuration of the PATROL SNMP Master Agent is controlled by the values contained
in the PATROL SNMP Master Agent configuration file. The SNMP Master Agent
configuration file is found in the following locations:
Unix$PATROL_HOME/lib/snmpmagt.cfg
Windows NT%PATROL_HOME%\lib\snmpmagt.cfg
18
Variable
Description
/snmp/agent_auto_start
/snmp/masteragent_auto_start
Whether the SNMPStart parameter should automatically start the SNMP Master Agent.
The SNMPStart parameter is defined within each platform.km the parameter checks to see if
the SNMP Master Agent is running, and if it is not, it attempts to start it.
The NT.KM executes the following PSL script for the SNMPStart parameter:
requires SNMP_lib;
#
# Attempt to start the SNMP subagent.
# If it fails, attempt to start the
# SNMP master agent.
#
if (snmp_agent_start() == "ERR") {
master_agent_start();
}
The master_agent_start() function is a function in the SNMP_lib PSL library that starts the
SNMP Master Agent.
A value of no prevents the SNMP Master Agent from starting. If the variable has any other value or
does not exist, the SNMP Master Agent starts when it is started by the SNMPStart parameter.
For more information on the PATROL Agent configuration variables see PATROL Agent
SNMP Configuration Variables on page 46.
19
The List of Interested Managers for SNMP Traps with the PATROL Agent
Variable
Description
/snmp/piV1m_list
The list of SNMPV1 managers that are interested in getting automatic SNMP traps from the Agent
Each SNMP manager listed here is entered in the piV1mTable in the Management Information
Base (MIB). The piV1mTable is the dynamic register of interested SNMP managers. Changes made
to this variable take effect without having to restart the Agent.
The default is that no managers get SNMP traps. Managers are entered in the form
hostname/port/
community. If port or community is omitted, the defaults are 162 and public, respectively.
Entries must be separated by commas.
For more information on the PATROL Agent configuration variables see PATROL Agent
SNMP Configuration Variables on page 46.
20
You Want to
Changing SNMPV1 Managers That Get SNMP Traps from the Agent on
page 52
/snmp/PiV1m_list
Operating
System
Unix
All non-Unix
Changes made to the PATROL SNMP Master Agent configuration file are permanent; that is,
the changes remain in effect regardless of how many times the PATROL SNMP Master Agent
is shut down and restarted.
21
Agent self-testingrun a PSL script in the Agent to receive its own traps and print them.
The logic involving SNMP trap receiving can be used in this way, such as PSL
snmp_trap_listen() and snmp_trap_receive(). Essentially, this procedure sets
up the PATROL Agent as an SNMP Agent.
22
objects table
variables table
applications table
trap table
23
24
25
26
The PATROL MIB application tables can be accessed to find out what applications are loaded
on the PATROL Agent. Figure 19 shows how the PSL snmp_walk() function can be used to
print the entries in the PATROL MIB applications table:
Figure 19
27
28
The PATROL MIB instance table can be accessed to find out what instances of an application
have been discovered by the PATROL Agent. Figure 21 shows how the PSL snmp_walk()
function can be used to print the instances of an application in the PATROL MIB instance
table (all the instances for the PRINTER application):
Figure 21
29
30
31
32
25
This section tells you how you can use PSL to control how the PATROL SNMP Master Agent
and the Agent interact with SNMP.
The following are the primary groups of PSL functions for SNMP:
PSL functions allow you to manage a number of processes, including starting and stopping
the PATROL SNMP Sub-Agent and changing the list of registered SNMP managers.
Some of these PSL functions are briefly described in this section. Refer to the PATROL Script
Language Reference Manual for detailed information about all PSL functions for SNMP.
There is a sample PATROL Knowledge Module SNMP_test.km that demonstrates how to use
PSL with PATROL and SNMP. It is available on the BMC Software Developer Connection
(DevCon) Web Site at http://devcon.bmc.com.
33
Task to be Performed
snmp_trap_ignore()
snmp_trap_receive()
snmp_trap_listen()
snmp_trap_send()
snmp_trap_raise_std_trap(text)
snmp_agent_config()
snmp_agent_start()
snmp_agent_stop()
34
snmp_close()
snmp_config()
snmp_open()
snmp_set()
You can also use snmp_h_* functions. The snmp_h_*
functions accept host name instead of session and
automatically open and close the session.
Note
snmp_h_* functions use port 161 and cannot be configured to use a
different port.
35
snmp_agent_register_im()
snmp_agent_register_im()
snmp_agent_register_im()
snmp_dump_packet (1)
snmp_report_error (2)
36
Error Message
Description
E_PSL_BAD_FUNCTION_PARAMETER
E_PSL_SNMP_ERROR
E_PSL_SNMP_NOT_SUPPORTED
NULL
When an error occurs, the user does not see any of the error messages in Table 32. A user sees
nothing since all SNMP PSL functions return the NULL string after encountering an error. A
user can determine which error occurred most recently by displaying or printing the value of
the PATROL PSL error variable. This variable holds an integer that corresponds to one of the
error messages above.
The PATROL Script Language Reference Manual provides more information on working with
error messages.
37
33
This section discusses several methods of using the SNMP support in a PATROL environment
to send traps and problem notification to other SNMP management consoles, to receive and
handle traps within the PATROL Agent, and to gather PATROL data from the PATROL MIB
static tables.
using the agent to send a SNMP trap based on TRAP_SEND and NO_TRAP settings in
event definitions
Table 34 compares the differences between the SNMP trap sending methods.
Table 34
PEM Traps
PSL Traps
yes
yes
no
yes
no
yes
no
yes
no
yes
two
unlimited
38
39
Event Class
Meaning
RegApp
New KM class is now registered and running in the agent (e.g. When a new console connects
requesting the KMs that it is interested in viewing).
UpdAppState
WorstApp
This application now has the worst state of all applications in the agent.
UpdParState
UpdInstState
UnregAllApp
UpdMachineState
new or updated state for the entire agent (due to some change in the state of an application).
Diag
Diagnosis event.
RemPsl
Result
PslSet
RemProcess
EventArchive
Disconnect
Unload
R3FilterData
Worst application class name is provided in this event, when the agents state has changed.
Worst application instance name is provided in this event, when the agents state has changed.
Successful connection to the agent by a user. (i.e. A normal console connection or one involving the
API or PSL remote functions).
Alarm is cancelled because the condition regarding the parameters violating its thresholds has
disappeared. In other words, the parameters value is no longer a bad value that causes an alarm, and
the parameter is going back to the OK state.
10
11
Parameter value has exceeded the alarm range thresholds. This will raise a warning or alarm state for
this parameter.
12
All recovery actions have executed and failed to resolve the problem. The parameter will stay in its
current state. Agent will not execute any more recovery actions for this parameter.
40
Table 35
Event Class
Meaning
13
14 or 15
16
Parameter description has been modified (i.e. KM editing) and the parameter state is reset to OK.
17 or 18
19
20
Parameter had bad output. For example, PSL set on value did not provide an integer to a graph or
gauge parameter.
21
22 or 23
24
25
26 or 27
28
Username/password were invalid to connect to the Agent (e.g. through the API or PSL remote
functions).
29
38
39
40
PSL response-related event. Created when a PSL response function is launched by the agent.
41, 42, or 43
Information event. Placeholder for user-defined events. Not generated internally by the agent.
41
Event Class
Description
UpdParState
UpdInstState
UpdAppState
11
By knowing under which circumstances various events are generated, you can choose when
SNMP traps are sent. Table 37 maps common situations to the events that the agent creates.
Table 37
UpdParState and 11
UpdInstState
UpdInstState
UpdAppState
Note
Some exceptions exist. For example, if a PSL set() directly changes the
status variable of a parameter to ALARM, this causes an UpdParState for
the state change, but not an alarm range threshold exceeded event of type
11.
42
Event Class
Purpose
UpdParState
NO_TRAP
UpdInstState
NO_TRAP
UpdAppState
NO_TRAP
UpdMachineState
NO_TRAP
SEND_TRAP
11
SEND_TRAP
This list of trap destinations does not affect the recipients of SNMP traps
sent by PSL snmp_trap_send().
43
Purpose
/snmp/masterAgentStartLine
/snmp/masterAgentWorkingDir
/snmp/agent_auto_start
starts the SNMP sub-agent support when the PATROL Agent starts
It requires that the PATROL SNMP Master Agent be running in order to
successfully complete.
/snmp/masteragent_auto_start
/snmp/agent_r_community
/snmp/agent_w_community
/snmp/sysName
/snmp/sysContact
/snmp/sysLocation
/snmp/trapConfTable
/snmp/trapMibTable
/snmp/masterAgentName
/snmp/masterAgentDir
/snmp/masterAgentConfigName
/snmp/masterAgentConfigDir
/snmp/masterAgentParamName
/snmp/masterAgentParamDir
directory containing the PATROL SNMP Master Agent nonvolatile information file
/AgentSetup/localPortForRemoteOpen
/AgentSetup/pemPFSnmpNode
/AgentSetup/pemPFSnmpNSeverity
/AgentSetup/pemPFSnmpOrigin
/AgentSetup/pemPFSnmpEidRange
/AgentSetup/pemPFSnmpEvClass
/AgentSetup/pemPFSnmpStartTime
start time
/AgentSetup/pemPFSnmpEndTime
end time
44
Table 39
Purpose
/AgentSetup/pemPFSnmpPattern
/AgentSetup/pemPFSnmpTypeMask
type tags
/AgentSetup/pemSnmpSupport
/AgentSetup/pemPFSnmpStatusMask
status tags
/AgentSetup/pemIssueV31traps
/AgentSetup/pemIssueV30traps
/AgentSetup/snmpConfigAccess
/snmp/accessControlList
/snmp/support
/snmp/piV1m_list
/snmp/mibFileName
MIB file that the PATROL Agent loads for PSL SNMP management functions
/snmp/trap_port
/snmp/default_r_community
default community name for SNMP get and getnext operations in PSL
/snmp/default_w_community
/snmp/default_retries
/snmp/default_timeout
Note
Pay special attention to the SNMP listening port that controls access to
the PATROL SNMP Sub-Agent from an external SNMP Manager(s).
This port is not set by the snmp/master_agent_port variable or, for that
matter, any agent configuration variable. Instead it is defined in the
SNMP Master Agent configuration file,
$PATROL_HOME/lib/snmpmagt.cfg.
For more information on the variables contained in the agent configuration, see PATROL
Agent SNMP Configuration Variables on page 46 for more information on changing the
agent configuration see the PATROL Agent Reference Manual.
45
40
The PATROL Agent configuration variables are set in the PATROL configuration file
(config.default). The PATROL Agent configuration file is located in the following directories:
Unix$PATROL_HOME/lib/config.default
The config.default file is a text file that lists and defines the PATROL Agent configuration
values. The Figure 41 shows the format for setting values in the PATROL configuration file:
Figure 41
"/snmp/support"
"/snmp/support" == {{ REPLACE="yes"
REPLACE="yes" },
},
"/snmp/agent_auto_start"
"/snmp/agent_auto_start" == {{ REPLACE="yes"
REPLACE="yes" },
},
"/snmp/default_port"
"/snmp/default_port"
== {{ REPLACE="161"
REPLACE="161" },
},
"/snmp/master_agent_port"
"/snmp/master_agent_port" == {{ REPLACE="1161"
REPLACE="1161" },
},
"/snmp/trap_port"
"/snmp/trap_port" == {{ REPLACE="162"
REPLACE="162" },
},
"/snmp/sysName"
"/snmp/sysName" == {{ REPLACE
REPLACE == "unknown"
"unknown" },
},
"/snmp/sysContact"
"/snmp/sysContact" == {{ REPLACE
REPLACE == "http://www.bmc.com"
"http://www.bmc.com" },
},
"/snmp/sysLocation"
"/snmp/sysLocation" == {{ REPLACE
REPLACE == "BMC
"BMC Software
Software Inc."
Inc." },
},
"/snmp/piV1m_list"
"/snmp/piV1m_list" == {{ REPLACE=""
REPLACE="" },
},
46
Table 42 lists some of the more important PATROL Agent configuration variables for SNMP
support:
Table 42
Variable
Description
Page
/snmp/support
1-51
/snmp/agent_auto_start
1-55
/snmp/default_port
the default port number that the PATROL Agent uses to open sessions with SNMP
agents
1-54
/snmp/master_agent_port
1-48
/snmp/trap_port
1-52
/snmp/sysName
1-48
/snmp/sysContact
1-48
/snmp/sysLocation
1-48
/snmp/piV1m_list
the list of SNMPV1 managers that are interested in getting automatic SNMP traps
from the Agent
1-52
Item
Variables
/AgentSetup/_name_
/AgentSetup/_type_
AgentSetup/AgentTuning/_name_
AgentSetup/AgentTuning/_type_
SNMP name
/snmp/_name_
SNMP type
/snmp/_type_
47
Changing the PATROL SNMP Master Agent and Start Line (Part 1 of 2)
Variable to Change
Additional Information
/snmp/masterAgentStartLine
/snmp/masterAgentWorkingDir
/snmp/agent_auto_start
/snmp/agent_r_community
Default: public
/snmp/agent_w_community
Default: private
/snmp/master_agent_port
Default: 1161
/snmp/sysName
Default: unknown
/snmp/sysContact
Default: http://www.bmc.com
/snmp/sysLocation
/snmp/trapConfTable
Default: no
/snmp/trapMibTable
Default: yes
/snmp/masterAgentName
/snmp/masterAgentDir
48
Table 44
Changing the PATROL SNMP Master Agent and Start Line (Part 2 of 2)
Variable to Change
Additional Information
/snmp/masterAgentConfigName
/snmp/masterAgentConfigDir
/snmp/masterAgentParamName
/snmp/masterAgentParamDir
49
Variable to Change
Additional Information
/AgentSetup/pemPFSnmpNode
/AgentSetup/pemPFSnmpNseverity
/AgentSetup/pemPFSnmpOrigin
/AgentSetup/pemPFSnmpEidRange
/AgentSetup/pemPFSnmpEvClass
Start time
/AgentSetup/pemPFSnmpStartTime
End time
/AgentSetup/pemPFSnmpEndTime
/AgentSetup/pemPFSnmpPattern
Type tags
/AgentSetup/pemPFSnmpTypeMask
/AgentSetup/pemPF
SnmpTypeMask =
{REPLACE=A,W}
Whether PEM triggers
SNMP events
/AgentSetup/pemSnmpSupport
50
Table 45
Variable to Change
Additional Information
Status tags
/AgentSetup/pemPFSnmpStatusMask
Whether PATROL
uses PATROL Version
3.1 formats to issue
SNMP traps
/AgentSetup/pemIssueV31traps
Whether PATROL
uses PATROL Version
3.0 formats to issue
SNMP traps
/AgentSetup/pemIssueV30traps
Variable to Change
Additional Information
/snmp/support
51
Variable to Change
Additional Information
/snmp/piV1m_list
Changing the MIB File That the Agent Uses for SNMP
Use Table 48 to find the variable for the item you want to change.
Table 48
Variable to Change
Additional Information
/snmp/mibFileName
Variable to Change
Additional Information
/snmp/trap_port
52
Variable to Change
Additional Information
/snmp/agent_r_community
/snmp/agent_w_community
/snmp/default_r_community
/snmp/default_w_community
53
Variable to Change
Additional Information
/snmp/default_retries
/snmp/default_timeout
/snmp/default_port
Variable to Change
Additional Information
/snmp/agent_auto_start
/snmp/masteragent_auto_start
54
Appendix A: ASN.1
53
Abstract Syntax Notation One (ASN.1) standard syntax is a type declaration language,
adopted by SNMP to define MIB objects. To explore the SNMP MIB, a user can examine the
ASN.1 definitions to see the object type, access, and descriptions of MIB objects.
SNMP administrators study the ASN.1 files to determine the capabilities provided by private
MIB objects. While ASN.1 is a complex language, SNMP only uses a simple subset of the
ASN.1 syntax. SNMP uses ASN.1 to define the following objects:
branches
leaf objects
Description
myBranch
OBJECT IDENTIFIER
parentBranch
100
the unique object identifier (OID) for the branch under the parent branch
Since each branch reference its parent branch, you can trace back through the ASN.1 file to
determine the parent of each branch until you reach the root internet branch.
55
Leaf Objects
With a branch the user can define more branches or leaf objects that have specific values. In
the object definitions the white space is ignored, but the definitions usually conform to a
particular style to make them more readable. The following syntax defines an SNMP object
with a specific value:
(objectname) OBJECT-TYPE
SYNTAX (syntax)
ACCESS (access)
DESCRIPTION (description)
::= { (parent) (number) }
Description
(objectname)
OBJECT-TYPE
SYNTAX
a required keyword that indicates the following token is the type of object
being defined
The SYNTAX defines the type of object which should not be confused with
the OBJECT-TYPE keyword that defines the type of ASN.1 declaration.
(syntax)
ACCESS
a required keyword that indicates the following token defines the access to
the object
(access)
DESCRIPTION
(description)
the text description of the object that is used as commentary in the file
The description is a quoted string that can span multiple lines of the
ASN.1 file. The description is supplied by the designer of the SNMP
agent, and the description documents the MIB value supported by the
agent.
56
Element
Description
(parent)
(number)
a numerical identifier that uniquely identifies the object under the parent
Throughout the MIB the (parent) (number) combinations must be unique.
In addition to these required object definitions, an object can also have other keywords such
as STATUS, UNITS, or INDEX. These optional fields may or may not be used by a network
manager, depending on the network management software.
These ASN.1 definitions reflect the characteristics of values supported by the SNMP agent.
The SNMP agent characteristics are not changed by changes to the objects definition. For
example, you could change the name of the object without affecting the agent operation, and
it is common for a network administrator to make changes to an objects ASN.1 definition and
compile these changes into the management software.
Note
When making changes to a MIB object, the location of the object in the
MIB, that is defined with the ::= operator, cannot be changed. If you
make such a change to the ASN.1 file the network management software
will no longer be able to access the SNMP object.
Counters
Gauges
INTEGERS
DisplayStrings
IpAddress
TimeTicks
and a few others
There are also some other special considerations that apply to the SYNTAX definition:
integer syntax
derived object types
tables
57
Integer Syntax
The INTEGER type can be either a basic integer over a range of values, or an enumerated
type. For example, the following example associates specific enumerated values with an
SNMP INTEGER object:
myEnumObject OBJECT-TYPE
SYNTAX INTEGER
{
first(1),
second(2),
third(3),
fourth(4)
}
ACCESS read-only
DESCRIPTION An enumerated value
::= { parentObject 22 }
In this example, the value of myEnumObject can be an integer ranging from 1 to 4, where
each of these numbers has a tag that labels the specific value. This provides a way of
specifying an integer value by a more descriptive name. The management software than can
interpret the integer value as the tag that is assigned to the value which can provide more
meaningful information.
The INTEGER type can also be a raw integer representing a unit value of some type. In this
case, the integer is interpreted as a number rather than a label by the management software.
Derived Object Types
ASN.1 syntax allows you to define new types based on existing predefined types. For
example, the following statement derives a new type (NetworkAddress) from an existing type
(IpAddress):
NetworkAddress ::= IpAddress
After making such a declaration, anywhere that NetworkAddress is defined in the ASN.1 file,
the MIB compiler immediately substitutes the IpAddress type in its place. Types are often
derived from enumerated types to simplify the readability and programming of the ASN.1
file. For example, the following definition could be used:
MY EnumValue ::= INTEGER
{
first(1),
second(2),
third(3),
fourth(4)
}
58
After this definition, anywhere the MyEnumValue is found in the ASN.1 file the enumerated
value is substituted. Enumerated values are common, and these derived data type make
creating and reading the ASN.1 file easier.
Tables
SNMP tables have a special type statement. SNMP tables are identical to SNMP branches,
except that the objects contained in the table can be considered columns rather than scalar
objects. They also have a rigorous set of syntactical requirements. The following syntax
defines a table:
(tablename) OBJECT-TYPE
SYNTAX SEQUENCE OF (tabletype)
ACCESS not-accessible
DESCRIPTION (description)
::= { (parent) (number) }
(entryname) OBJECT-TYPE
SYNTAX (tabletype)
ACCESS not-accessible
DESCRIPTION (description)
::= { (tablename) 1 }
(tabletype) ::= SEQUENCE {
(column1) (column1type),
(column2) (column2type),
(columnN) (columnNtype), }
Fortunately, the syntax of the table can usually be ignored and a table definition can be
thought of as an idiosyncrasy of ASN.1 syntax. The following basic rules summarize ASN.1
tables:
By convention, each SNMP table contains a name incorporating the Table keyword. This
convention is almost universal. For example, the object myTable indicates that it is a
tabletype object.
Under each table is a single branch object with a name incorporating the Entry keyword.
Again, this convention is almost universal. For example, under myTable their will always
be a single branch containing table data with the name myEntry.
Within myEntry is a series of SNMP objects that are identical to the OBJECT-TYPE
definitions presented earlier, except the suffix of these objects will not necessarily be .0,
but may be simple or complex indexes to the table rows in dot notation.
59
These rules are not strictly enforced and cannot be counted on by the MIB compiler, but they
do give you a sound foundation to use when you are reading a MIB ASN.1 file.
Note
60