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 Communications Programming Concepts for more detailed information on agent and manager functions.
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:
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.
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 may not be a problem. If set requests are allowed, the set privilege may be restricted.
See the /etc/snmpd.conf file for further information. See "Management Information Base (MIB)" in AIX Communications Programming Concepts for further information.
There are three types of request PDUs that may 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" in AIX Communications Programming Concepts for a discussion of the three request types.
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-Status 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 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:
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, may have changed. Measurement epochs should be restarted. |
| 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.
Note: In the following sections, interfaces applies to both a TCP/IP interface and a Common Data Link Interface (CDLI) token-ring, Ethernet, or Fiber Distributed Data Interface (FDDI) device. CDLI allows snmpd to monitor the Ethernet, token-ring, and FDDI devices even if they are not running TCP/IP. The SNMP daemon stills needs TCP/IP loopback to run, but it is no longer a requirement on interfaces.
The linkUp and linkDown traps are generated when the snmpd agent determines there is a change in the state for a known interface. If the current state of a known interface is down and the interface state changes to up, a linkUp trap will be generated. Likewise, if the current state of a known interface is up and the interface changes to down, a linkDown trap is generated.
There is no concept of up or down to a CDLI device if there is not a TCP/IP interface running on that device. CDLI devices with a TCP/IP interface layer attached is always considered to be up unless the device is removed from the system. The other values of the interfaces table are also effected by whether or not a CDLI device has a TCP/IP interface or not. If a CDLI device has a TCP/IP interface, then all the statistics in the interfaces table pertain to the TCP/IP interface and the device specific MIB should be used to retrieve statistics about the device. If there is not a TCP/IP interface layer running on the CDLI device, the iftable entries for the device are retrieved from the CDLI device itself.
If an interface is known to the snmpd agent, there is an entry for that interface in the snmpd interfaces table. When an interface is attached or detached by the ifconfig command, the entries in the snmpd agent's interfaces table change. A coldStart trap is generated to indicate the configuration change. The purpose of generating a coldStart trap is to guarantee the receiving host understands that crucial MIB variable values may have changed. In particular, measurement epochs should be restarted. Even though links may be enabled or disabled, no linkUp or linkDown traps are generated.
For instance, a netstat -in command may provide the following information for a host's network configuration:
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll lo0 1536 127 127.0.0.1 6228 0 6228 0 0 en0 1500 192.100.154 192.100.154.7 585287 0 666636 0 0 tr0 1500 129.35.32 129.35.42.141 3976323 0 2414030 0 0
In this example, network configuration, the snmpd agent has three entries in its interface table from TCP/IP interfaces: one for lo0, one for en0, and one for tr0. In the interface index table, ifIndex.1 might refer to lo0, ifIndex.2 might refer to en0, and ifIndex.3 might refer to tr0. The term "might refer to" implies that since interfaces are dynamic, the actual entry number may vary. In the example, there is an additional token-ring adapter in the workstation that the TCP/IP kernel does not know about; the interface for this adapter is named tr1. Since, the token-ring adapter is a CDLI device, there is an entry in the interfaces table, for example, ifIndex.4. The workstation has a serial optical device. The serial optical device has not been configured for TCP/IP and it is not a CDLI device. So, neither TCP/IP nor snmpd recognize this device. Its interface name is so0.
If you issue the ifconfig tr1 command, TCP/IP attaches tr1, but does not mark the interface as up. The snmpd agent changes the method for reporting interface table statistics to the TCP/IP interface layer from the CDLI device level statistics. The snmpd agent then generates a coldStart trap. This action has not added a new entry, because an entry for tr1 already existed.
If you issue the ifconfig so0 command, TCP/IP attaches so1, but does not mark the interface as up. The snmpd agent then adds a fifth entry for this new interface to its interfaces table and sets ifIndex.5 to refer to so0. The SNMP agent then generates a coldStart trap. Since, so0 is not a CDLI device, it was not in the interface table as a result of device configuration, so it had to be added when the TCP/IP interface layer was configured.
The crucial interface index (ifIndex) values that an SNMP manager may have stored for the four original entries will not change. But the coldStart trap is a signal to SNMP managers that their MIB databases need to be updated. Upon refreshing its database, an SNMP manager learns about this new entry in the snmpd agent's interface table.
If the system administrator issued an ifconfig tr1 up command, the new interface is marked up and the method of obtaining statistics is changed. The snmpd agent would send a coldStart trap; a linkUp trap would not be sent because the state of the device did not change. A CDLI device is always considered up, until it gets a TCP/IP interface.
The coldStart trap indicates to the SNMP managers that the snmpd agent configuration had changed, so the managers should update their MIB databases. A linkUp trap generated after the coldStart trap is meaningless to the SNMP manager because the manager's database already has the information from its database refresh.
The system administrator elected to detach the en0 interface from the above network configuration. Once detached, the snmpd agent updates its statistics gathering method to use the CDLI device statistics (Ethernet is a CDLI device). The agent generates a coldStart trap to inform the SNMP managers that something in the interfaces is different. In this case, the crucial ifIndex values have not changed, just the method of statistic retrieval.
The system administrator has elected to detach the so0 interface from the above network configuration. Upon the detachment of an interface, the snmpd agent updates its interfaces table. In this example, all the indices remain the same except that the fifth entry has been removed. If the third entry had been removed, the fourth and fifth entry would have been renumbered to be the third and fourth entries. In either case, the snmpd agent generates a coldStart trap.
In this case, the crucial ifIndex values that an SNMP manager may have stored for the original entries will change. The SNMP manager needs to refresh its MIB database to reflect the changes in the snmpd agent's interfaces table. In this situation, a linkDown trap is not generated. An SNMP manager cannot take immediate action upon receipt of a linkDown trap because the ifIndex values in its database are no longer valid.
In order for the snmpd agent to catch all interface status changes, the snmpd agent periodically checks the TCP/IP kernel and CDLI device list to determine the status of the interfaces. The time interval at which these checks are run is user-configurable.
In the event that the snmpd agent has received a request for a MIB variable in the interfaces table and the snmpd agent determines that an interface has changed state to the degree that a coldStart should be generated, the snmpd agent returns a genErr and issues the coldStart trap.
Refer to "User Datagram Protocol (UDP)", "Exterior Gateway Protocol (EGP)", and "TCP/IP Addressing" for more information on protocols and Internet addresses.