This chapter covers the following topics:
SNMPv2 is the second version of the Simple Network Management Protocol. SNMP lets you manage multiple network devices (agents) from a central location (manager) using a simple common protocol supported by many different manufacturers.
QNX 4 support for SNMP consists of the following:
There are five configuration files required to use these applications:
These files reside under your /etc directory. For more information, refer to the ``Architecture'' and the ``Administrative model'' sections below and to the TCP/IP Utilities chapter.
Here's a brief description of each of the config files:
The following programs are available with QNX SNMPv2. For more information, refer to the TCP/IP Utilities chapter in this guide.
The snmpd daemon (/usr/ucb/snmpd) is a server that receives and responds to SNMP messages sent to the SNMP port on the local machine.
SNMPv2 includes the following utilities:
There's also an SNMPv2 C lib available to write your own SNMPv2 applications. For information on writing SNMP apps, please refer to the API Functions (snmp_*()) in the TCP/IP Programmer's Guide.
The SNMP MIB (Management Information Base) describes the data that can be queried or modified via the SNMP protocol. This information allows agents on a network to be managed. This data includes configuration, performance, faults, accounting, and security. The MIB defines its managed objects using a structure of management information (SMI). The SMI defines the syntax for the MIB. For an example of an MIB, please see the /etc/mib.txt file. This is the MIB used by the QNX SNMP programs.
Objects in the MIB are identified using a unique object identifier (OID). The object identifier is made up of a sequence of nonnegative integers separated by a dot (for example: .1.3.6.1). You can also use a textual name to represent each component of the OID (e.g. the equivalent of .1.3.6.1 is .iso.org.dod.internet).
The chain of values is organized into a structure that's similar to a filesystem. In the example above, .1 (iso) is like a directory at the root of the filesystem.
For example, data that is common to all systems can be found under .1.3.6.1.2 (.iso.org.dod.internet.mgmt), while data that is proprietary for a particular device can be found under .1.3.6.1.4 (.iso.org.do.internet.private). To query the syscontact variable on a SNMP agent you would use the object identifier .1.3.6.1.2.1.1.4, which is equivalent to:
.iso.org.dod.internet.mgmt.mib-2.system.sysContact
The MIB definition (/etc/mib.txt) contains the names of all the objects that can be queried or modified on the system.
In SNMPv1, authentication was done with a cleartext password referred to as the ``community.'' A common value for this would be ``public.''
SNMPv2 uses a more complex configuration to implement its authentication. It replaces the community value with a concept involving contexts, parties, and views.
The authentication is configured with four files found in the /etc directory:
Each file contains a brief description telling you how to configure it; you should also see the reference describing each file in the TCP/IP Utilities chapter in this guide.
Here are the different components of this authentication concept:
The SNMPv2 party is a conceptual, virtual execution environment. When an agent or manager performs an action, it does so as a defined party, using the party's environment as described in the configuration files.
By using the party concept, an agent can permit one manager to do a certain set of operations, and another manager to do a different set of operations. Each communication session with a different manager can have its own environment. Here are two entries from a party config file (/etc/party.conf) for an agent and a manager.
/etc/party.conf agent_party .1.3.6.1.6.3.3.1.3.10.0.0.59.5 snmpUDPDomain 10.0.0.59 161 noAuth noPriv 300 484 29F660EA 00000000000000000000000000000000 Null 00000000000000000000000000000000 Null manager_party .1.3.6.1.6.3.3.1.3.10.0.0.59.6 snmpUDPDomain 0.0.0.0 0 noAuth noPriv 300 484 29F660EA 00000000000000000000000000000000 Null 00000000000000000000000000000000 Null
The agent and manager definition use the same format. It starts with the name of the party (agent_party and manager_party) and follows with the unique party identity value. This value starts with:
.1.3.6.1.6.3.3.1.3
which resolves to:
.iso.org.dod.internet.snmpv2.snmpModules.partyMIB.partyAdmin.initialPartyID
in the MIB. (Please refer to the /etc/mib.txt file for more information on the ``InitialPartyID'' value.)
The next line of values are the transport domain, the IP address that the party exists on, and a port to listen to. The manager_party just specifies 0.0.0.0 0 to signify that it's a remote machine. The agent_party entry specifies 10.0.0.59 161 which is the IP address of one of its interfaces and a port to listen to. These two example parties will communicate with no authentication (noAuth) and no privacy (noPriv) and are listed as the fifth and sixth parties defined under ``InitialPartyID.''
The /etc/view.conf file contains view configurations. Each view definition is a list of objects that are are part of the view. You can include or exclude objects from the view. When a party attempts to access the agent MIB, they will see only the objects contained in the view.
/etc/view.conf 3 .iso.org.dod.internet.mgmt included Null
This creates a view number 3, which includes all of the objects under the MIB subtree .iso.org.dod.internet.mgmt.
The context.conf file contains the definitions made up of a collection of object resources accessible by a network entity.
/etc/context.conf agent_context .1.3.6.1.6.3.3.1.4.10.0.0.59.3 3 Null CurrentTime 0 0 0
The context definition starts with the name of the context (in this case agent_context) and is followed by the unique object identifier that represents this context. It starts with the value:
.1.3.6.1.3.3.1.4
which resolves to:
.iso.org.dod.internet.snmpv2.snmpModules.partyMIB.partyAdmin.initialContextID
For more information on the initialContextID, please refer to the /etc/mib.txt file. This agent_context will represent the collection of object resources that the manager will be able to access. You can define different contexts for different agent/manager pairs. This is demonstrated in the acl.conf file.
The access control list is where you define what context will be available to an agent and manager. You can also define what operations will be permitted on the collection of object resources.
/etc/acl.conf agent_party manager_party agent_context GSUBN
In this example, the manager can perform operations on the objects defined in agent_context. These operations are limited to the following:
The other operations that can be specified are:
Now that we have all the files (/etc/party.conf, /etc/view.conf, /etc/context.conf, and /etc/acl.conf) configured, we can access some data on the server.
Let's now take a look at a few examples of using the agent and utilities. Please refer to the TCP/IP Utilities chapter in this guide for more information on the options that can be passed to the agent and utilities mentioned here.
These examples assume that the configuration files and mib.txt are located in the /etc directory and that the utilities are in the /usr/ucb directory.
The first thing we need is an agent to query. For this example, we'll use the agent supplied with your software:
snmpd &
If you run into any problems with the agent, you could try specifying the -d option, which dumps all sent and received packets to the screen. This option is available to several of the utilities also.
Once the SNMPv2 agent is running, we could use the snmpget utility to query an object resource:
snmpget host manager_party agent_party agent_context system.syscontact.0
The output would look something like this:
system.sysContact.0 = "John Doe"
Using the snmpset command, we can change the string value of sysContact:
snmpset host manager_party agent_party agent_context system.syscontact.0 s "Not me"
The output would look something like this:
system.sysContact.0 = "Not me"
Now when someone uses an SNMP utility to query system.syscontact, the string value ``Not me'' will be returned.
Let's now take a look at the snmptrap and snmptrapd utilities. The first thing we'll want to do is start the snmptrapd utility. It will receive the trap PDU messages from snmptrap.
snmptrapd -p
The -p option tells snmptrapd to print log information regarding trap messages received to the screen. We can now use snmptrap to send a trap message.
snmptrap host manager_party agent_party agent_context 0 0 "device_description"
The snmptrapd server would log a message something like this:
------------------------------- Notification ------------------------------- 10.0.0.59: Cold Start Trap (0) Uptime: 2 days, 20:27:21 system.sysDescr.0 = "device_description"
For more information on SNMP, refer to the following RFCs:
You may also find the following useful: