gtpc1m2n | Transmission Control Protocol/Internet Protocol |
To install the SNMP agent server, do the following:
TPF SNMP agent support requires TCP/IP native stack support. Ensure that TCP/IP native stack support is defined on your TPF 4.1 system before attempting to use SNMP agent support. See TCP/IP Native Stack Support Internals and Operator Procedures for TCP/IP Native Stack Support for more information about TCP/IP native stack support.
Install SNMP agent support.
The TPF system needs specific information to run correctly as an SNMP agent, including the values needed for the MIB. For example, there is a MIB value for the system name (sysName) that is supplied in the /etc/snmp.cfg SNMP configuration file. Specific keywords for the values are coded, followed by the values. Most of the information in the configuration file is not processor-unique information. However, the system name (sysName) and system object identifier (sysObjectID) are processor-unique. Because the file resides on the TPF file system that is shared by all processors, the TPF system needs a way to distinguish this information between processors. The TPF system does this by appending the processor ID to the keyword for the value. So, if there are three processors in the complex, there can be three statements defining the system names for each processor.
To create the /etc/snmp.cfg SNMP configuration file, do the following:
The following shows an example of an SNMP configuration file.
* SNMP SAMPLE CONFIG FILE * SysDescription: "TPF Test System" SysContact: "TPF Administrator" SysLocation: "Poughkeepsie, NY" * SysNameA: "TPF A" SysNameB: "TPF B" SysObjIDA: 1.3.6.1.4.1.1.1 SysObjIDB: 1.3.6.1.4.1.1.2 * CommName: "public" * TrapIP: 19.17.153.14 * MANAGER 1 * TrapIP: SNMP.MANAGER.COM * MANAGER 2 * TrapIP: 2.26.7.114 * MANAGER 3 *
The SNMP configuration file contains keywords for identifying and describing your SNMP agent. Each keyword must be on its own line and must start at the first column of that line. Lines that do not start with a valid keyword are treated as comments. The keywords are not case-sensitive. The value of a keyword cannot exceed 255 characters in length. The keywords and their descriptions follow:
The information in the SNMP configuration file is read into core storage during system cycle-up or when you enter the ZSNMP command with the REFRESH parameter specified. SNMP agent support does not work unless the SNMP configuration file is loaded into core storage. See TPF Operations for more information about the ZSNMP command.
For an SNMP request to be accepted and processed by the TPF system, the SNMP manager must be verified. You must decide which SNMP managers are allowed to submit requests to your TPF system. The UCOM user exit validates the SNMP manager. You must add the necessary code to the UCOM user exit to determine which SNMP manager is allowed to view information in the TPF MIB database. The default system action is to reject all SNMP requests if the UCOM user exit is not coded.
The UMIB user exit is required for users who want to provide their own enterprise-specific MIB variables. For this, logic has to be added to the UMIB user exit to retrieve and then BER-encode enterprise-specific MIB variables. Input to the UMIB user exit is the unique object identifier of the variable being queried. The UMIB user exit returns the encoded object identifier of the variable returned, followed by the encoded value. Use the tpf_snmp_BER_encode C/C++ function to do this. 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.
For example, if object ID 1.3.6.1.4.1.20 is passed to the UMIB user exit and the value of the user MIB variable is found to be an integer of 20, the following must be returned:
06062B0601040114 020114 Encoded Object ID Encoded Value
The default coding for the UMIB user exit is to not acknowledge any MIB variable it is asked about. See TPF System Installation Support Reference for more information about the UCOM and UMIB user exits.
The SNMP agent must be defined and started by the Internet daemon. The Internet daemon monitors the network for packets destined for the SNMP agent server on well-known port 161. Define the SNMP agent server to the Internet daemon by entering the ZINET command. To define the SNMP agent server to the Internet daemon and then start it, do the following:
ZINET ADD SERVER-SNMP PGM-CNMA PROTOCOL-UDP MODEL-WAIT PORT-161
ZINET START SERVER-SNMP
See TPF Operations for more information about the ZINET commands.
An important consideration when installing your TPF SNMP agent support is to define it in a way that eliminates single points of failure in the network between TPF and the SNMP managers. Do this by using VIPAs or by defining multiple routers to CDLC IP addresses. However, you can set up multiple local IP interfaces to send the trap message across, by setting up routing table entries for the remote manager IP address. You can also use routing table entries when multiple SNMP managers reside on different networks. Routing table entries can be defined to reach managers on different networks by sending out the trap message to different interfaces in the TPF system.
To define routing table entries, enter ZTRTE ADD. See Operator Procedures for TCP/IP Native Stack Support for more information about defining VIPAs and routing table entries and see TPF Operations for more information about the ZTRTE command.
To function as an SNMP agent, the TPF system must be part of an SNMP-managed network. The remote SNMP manager must be configured with the TPF system IP address and community name. To configure the SNMP manager with the IP address and community name, review your SNMP manager product information or see your system administrator.