gtpc1m2lTransmission Control Protocol/Internet Protocol

Processing SNMP Requests

You communicate between the SNMP manager and SNMP agent through the exchange of messages, each within a single UDP packet. The TPF system supports a maximum SNMP packet size of 548 bytes (excluding the IP and UDP headers). One SNMP agent server can be started per processor in a loosely coupled TPF complex by using the Internet daemon to monitor the network for SNMP packets.

As shown in the following table, an SNMP message consists of a version identifier, an SNMP community name, and a PDU.

Table 5. SNMP Network Management Protocol Packet

SNMP version Community name PDU=PDU type, MIB variable 1, MIB variable 2, MIB variable 3, ....MIB variable n

All units of data in an SNMP message are encoded using a subset of the basic encoding rules (BER). See ISO 8825 Part 1: Basic Encoding Rules for more information. Go to http://www.iso.ch/ to view ISO 8825.

Message Processing

The processing of an SNMP message begins when TPF receives an SNMP packet on well-known port 161. Message processing then continues as follows:

  1. The Internet daemon activates the SNMP agent when a packet is received from the network.
  2. The SNMP agent parser examines the SNMP packet for required fields. Each SNMP packet that the TPF system receives must contain the SNMP version, community name, and PDU. If the message that is received cannot be parsed because it is not in the correct format, the message is discarded.
  3. The version field of the SNMP packet is validated for SNMP Version 1. Any packet that is not from SNMP Version 1 is discarded by the TPF system.
  4. The TPF system passes the community name received in the SNMP message and the remote IP address of the SNMP manager that sent the SNMP request to the UCOM user exit. The UCOM user exit validates the SNMP manager from which the message was received. If an SNMP agent receives a request from an SNMP manager that is not authorized, the request from that manager is rejected and one of the following actions occurs:

    You can select one of these actions by specifying the appropriate return code when coding the UCOM user exit. See Coding the UCOM and UMIB User Exits and TPF System Installation Support Reference for more information about coding the UCOM user exit.

  5. Once the community name is validated, the PDU section of the packet is parsed to determine the type of PDU request that was received and which MIB variables are being requested.
  6. If the PDU is a GETREQUEST or GETNEXTREQUEST PDU, the TPF system extracts the object identifiers from the PDU to determine which MIB variables to retrieve. The TPF system then attempts to retrieve the values for each requested variable from the MIB. Multiple variables may be requested in a single PDU.
    Note:
    If the PDU is a SETREQUEST PDU, the TPF system rejects SETREQUEST by sending a GETRESPONSE PDU with an error status code of NOSUCHNAME.
  7. If it is determined that the requested object identifier is not part of the system-controlled MIB, the request is sent to the UMIB user exit to retrieve your own enterprise-specific MIB variables. The object identifier is provided as input to the UMIB user exit, so the user exit can do Step 1 or Step 2.

    Step 1:

    Step 2:

    See User MIB Variables for more information.

  8. For each variable (object identifier) requested, its value is retrieved from either the system-controlled MIB or from the UMIB user exit and a variable binding is built. A variable binding is the unique object identifier of an encoded variable followed by its encoded value.

The following example shows a variable binding requesting variable ifNumber from the TPF system.

300B          06072B06010201020100               0500
  |
Variable      Encoded object ID for ifNumber     NULL Value
Binding
Length encoded
as type
SEQUENCE_OF
 

The following example shows a variable binding response of variable ifNumber.

300D          06072B06010201020100               020104
  |
Variable      Encoded object ID for ifNumber     4 interfaces encoded
Binding                                          as an integer
Length encoded
as type
SEQUENCE_OF
 

An SNMP manager can make a request for the value of more than one MIB variable in an SNMP packet. The TPF system retrieves the value for each requested MIB variable and builds a variable binding. All the variable bindings are then packaged together by encoding them as a variable binding list, which is a simple list of variable names and their corresponding values. The variable binding list is included in the PDU section of the SNMP response packet and sent to the SNMP manager.

Note:
If any variables cannot be retrieved by either the TPF system or by the UMIB user exit, the entire variable binding list is rejected.

User MIB Variables

As stated previously, the SNMP architecture allows you to have your own enterprise-specific MIB variables through the use of the UMIB user exit. When an SNMP request is received by the TPF system and the requested MIB variable is not one of the SNMP system MIB variables, the UMIB user exit is called to provide the value for the specified variable or to indicate that the specified variable is not an enterprise-specific MIB variable. If you or the TPF system could not retrieve any of the requested MIB variables, the SNMP request is rejected.

Each MIB variable has an object identifier, which is BER-encoded and passed as input to the UMIB user exit. If the specified object identifier is known to you and is coded in the UMIB user exit, the UMIB user exit returns the BER-encoded object identifier and value for the requested MIB variable. The tpf_snmp_BER_encode C/C++ function allows you to encode a subset of the MIB variable types. See the TPF C/C++ Language Support User's Guide for more information about the tpf_snmp_BER_encode C/C++ function. See ISO 8825 Part 1: Basic Encoding Rules for more information about BER encoding. Go to http://www.iso.ch/ to view ISO 8825.

The UMIB user exit retrieves enterprise-specific MIB variables. You must maintain these variables and allocate and maintain your own storage for them. The SNMP architecture has created the iso.org.dod.internet.private.enterprises (1.3.6.1.4.1) portion of the SNMP hierarchical tree specifically for enterprise-specific MIB variables. Object identifiers that the SNMP architecture has set aside for the various system-controlled SNMP groups cannot be used for enterprise-specific purposes.

See Coding the UCOM and UMIB User Exits and TPF System Installation Support Reference for more information about the UMIB user exit.