[ Bottom of Page | Previous Page | Next Page | Contents | Index | Library Home | Legal | Search ]

System Management Guide: Communications and Networks

SNMP Daemon Processing

The Simple Network Management Protocol (SNMP) daemon processes SNMP requests from manager applications. Read Simple Network Management Protocol (SNMP), How a Manager Functions, and How an Agent Functions in AIX 5L Version 5.2 Communications Programming Concepts for more detailed information on agent and manager functions.

Message Processing and Authentication

All requests, traps, and responses are transmitted in the form of ASN.1-encoded messages. A message, as defined by RFC 1157, has the following structure:

Version Community PDU

where Version is the SNMP version (currently version 1), Community is the community name, and PDU is the protocol data unit that contains the SNMP request, response, or trap data. A PDU is also encoded according to ASN.1 rules.

Figure 28. The primary parts of the SNMPv1 architecture. This illustration shows and example of the SNMPv1 architecture. The DPI2 subagent, smux peer, SNMP manager, and SNMP agent are shown. In addition, how they communicate with each other is shown.

The SNMP daemon receives and transmits all SNMP protocol messages through the Transmission Control Protocol/Internet Protocol (TCP/IP) User Datagram Protocol (UDP). Requests are accepted on well-known port 161. Traps are transmitted to the hosts listed in the trap entries in the /etc/snmpd.conf file that are listening on well-known port 162.

When a request is received, the source IP address and the community name are checked against a list containing the IP addresses, community names, permissions, and views as specified in the community and view entries in the /etc/snmpd.conf file. The snmpd agent reads this file at startup and on a refresh command or a kill -1 signal. If no matching entry is found, the request is ignored. If a matching entry is found, access is allowed according to the permissions specified in the community and view entries for that IP address, community, and view name association in the /etc/snmpd.conf file. Both the message and the PDU must be encoded according to the ASN.1 rules.

This authentication scheme is not intended to provide full security. If the SNMP daemon is used only for get and get-next requests, security might not be a problem. If set requests are allowed, the set privilege can be restricted.

See the /etc/snmpd.conf file for further information. See Management Information Base (MIB) for further information.

Request Processing

There are three types of request PDUs that can be received by the SNMP daemon. The request types are defined in RFC 1157, and the PDUs all have the following format:

Request PDU format
request-ID error-status error-index variable-bindings
GET 0 0 VarBindList
GET-NEXT 0 0 VarBindList
SET 0 0 VarBindList

The request-ID field identifies the nature of the request; the error-status field and error-index field are unused and must be set to 0 (zero); and the variable-bindings field contains a variable-length list of numeric-format instance IDs whose values are being requested. If the value of the request-ID field is SET, the variable-bindings field is a list of pairs of instance IDs and values.

Read Using the Management Information Base (MIB) Database for a discussion of the three request types.

Response Processing

Response PDUs have nearly the same format as request PDUs:

Response PDU format
request-ID error-status error-index variable-bindings
GET-RESPONSE ErrorStatus ErrorIndex VarBindList

If the request was successfully processed, the value for both the error-status and error-index field is 0 (zero), and the variable-bindings field contains a complete list of pairs of instance IDs and values.

If any instance ID in the variable-bindings field of the request PDU was not successfully processed, the SNMP agent stops processing, writes the index of the failing instance ID into the error-index field, records an error code in the error-status field, and copies the partially completed result list into the variable-bindings field.

RFC 1157 defines the following values for the error-status field:

Values for the error-staus field
Value Value Explanation
noError 0 Processing successfully completed (error-index is 0).
tooBig 1 The size of the response PDU would exceed an implementation-defined limit (error-index is 0).
noSuchName 2 An instance ID does not exist in the relevant MIB view for GET and SET request types or has no successor in the MIB tree in the relevant MIB view for GET-NEXT requests (nonzero error-index).
badValue 3 For SET requests only, a specified value is syntactically incompatible with the type attribute of the corresponding instance ID (nonzero error-index).
readOnly 4 Not defined.
genErr 5 An implementation-defined error occurred (nonzero error- index); for example, an attempt to assign a value that exceeds implementation limits.

Trap Processing

Trap PDUs are defined by RFC 1157 to have the following format:

Trap PDU format
enterprise agent-address generic-trap specific-trap time-stamp variable-bindings
Object ID Integer Integer Integer TimeTicks VarBindList

The fields are used as follows:

enterprise The object identifier assigned to the vendor implementing the agent. This is the value of the sysObjectID variable, and it is unique for each implementer of an SNMP agent. The value assigned to this implementation of the agent is 1.3.6.1.4.1.2.3.1.2.1.1.3, or risc6000snmpd.3.
agent-address IP address of the object generating the trap.
generic-trap Integer, as follows:
0
coldStart
1
warmStart
2
linkDown
3
linkUp
4
authenticationFailure
5
egpNeighborLoss
6
enterpriseSpecific
specific-trap Unused, reserved for future development.
time-stamp Elapsed time, in hundredths of a second, from the last reinitialization of the agent to the event generating the trap.
variable-bindings Extra information, dependent on generic-trap type.

The following generic-trap values indicate that certain system events have been detected:

coldStart The agent is reinitializing. Configuration data or MIB variable values, or both, might have changed. Restart the measurement epochs.
warmStart The agent is reinitializing but configuration data or MIB variable values have not changed. In this implementation of the SNMP agent, a warmStart trap is generated when the /etc/snmpd.conf file is reread. The configuration information in the /etc/snmpd.conf file is for agent configuration that has no side effects on SNMP manager databases. Measurement epochs should not be restarted.
linkDown The agent has detected that a known communications interface has been disabled.
linkUp The agent has detected that a known communications interface has been enabled.
authenticationFailure A message was received that could not be authenticated.
egpNeighborLoss An Exterior Gateway Protocol (EGP) neighbor was lost. This value is only generated when the agent is running on a host that runs the gated daemon using EGP.
enterpriseSpecific Not implemented; reserved for future use.

The linkDown and linkUp traps contain a single instance ID/value pair in the variable-bindings list. The instance ID identifies the ifIndex of the adapter that was disabled or enabled, and the value is the ifIndex value. The trap for egpNeighborLoss also contains a binding consisting of the instance ID and value of egpNeighAddr for the lost neighbor.

[ Top of Page | Previous Page | Next Page | Contents | Index | Library Home | Legal | Search ]