Use this Knowledge Script to check for SNMP traps forwarded from NetIQ Trap Receiver (Trap Receiver). This script raises an event when an SNMP trap is received and when Trap Receiver is unavailable or subsequently becomes available. In addition, this script generates datastreams for Trap Receiver availability. For more information, see Working with NetIQ Trap Receiver.
Trap Receiver is not installed automatically when you install the AppManager for Microsoft Windows module. You must start Trap Receiver manually by running the following:
\AppManager\bin\NetIQTrapReceiver_Setup.exe
This script supports SNMP v1, v2, and v3. If you use SNMP v3, configure your SNMP permissions in AppManager Security Manager. For more information, see Configuring SNMP Permissions.
Trap Receiver filters SNMP traps based on the criteria you provide in the script parameters: IP address, hostname, or object identifier (OID). This script can translate numerical OIDs to their object descriptor (ODE) counterparts. The translation process requires access to the Management Information Base (MIB) files that reference the OIDs and ODEs. For more information, see Adding MIBs for Use By Trap Receiver.
Windows 2003 Server or later
The default interval for this script is Asynchronous.
Set the following parameters as needed:
|
Parameter |
How to Set It |
|---|---|
|
General Settings |
|
|
Job Error Notification |
|
|
Event severity when an error occurs |
Set the event severity level, from 1 to 40, to indicate the importance of an event in which the SNMPTrap job fails. The default is 15. The default is 15. |
|
Trap Filters |
|
|
Filter by IP source address or hostname |
Provide the IP address or hostname of the SNMP source from which to receive traps. For example: 10.10.10.10 Separate multiple addresses or hostnames with a comma (,). Notes
|
|
Filter by object identifier |
Provide the object identifier of the trap messages you want to receive. The object identifier is defined by the SNMP source agent. You can use OID or ODE notation to specify the object identifier. To filter for more than one object identifier, separate each notation with a comma (,). If you leave this parameter blank, the script does not use the object identifier to filter for events. If you are using ODE notation, use a case-sensitive descriptor. For example: system.sysUptime.0 If you are using OID notation, include the dot (.) at the beginning of the identifier. For example: .1.2.6.1.4.1.1691 NOTE:This script filters for an exact match to the OID you provide. If your OID is .1.2.6.1.4.1.1691, the script will not match all OIDs that begin with .1.2.6. It matches only the OID you specified. |
|
Filter by MIB sub-tree |
Provide the part of the MIB tree (sub-tree) about which you want to receive events. For example: 1.3.6.1.4.1.9 Separate multiple sub-trees with a comma (,). If you leave this parameter blank, the script reports events related to the entire MIB tree. You can use this parameter for any trap; however, this parameter uses SNMP v2 terminology. |
|
Filter by generic trap number |
Specify a generic trap number to filter trap messages that use the same OID for more than one trap message. You usually do not need to filter for generic trap message numbers if the OID is unique. The generic value of the OID is defined by the SNMP source agent. If you leave this parameter blank, the script does not use a generic value to filter for events. |
|
Filter by specific trap number |
Specify a specific trap number to filter trap messages that use the same OID for more than one trap message. You usually do not need to filter for specific trap message numbers if the OID is unique. The specific value of the OID is defined by the SNMP source agent. If you leave this parameter blank, the script does not use a specific value to filter for events. |
|
Filter by enterprise |
Provide the enterprise from which you want to receive events. The enterprise is defined in MIB 1.3.6.1.4.1.9.87.2. Separate multiple enterprises with a comma (,). If you leave this parameter blank, the script reports events related to all enterprises. You can use this parameter for any trap; however, this parameter uses SNMP v1 terminology. |
|
Event Notification |
|
|
Raise event when SNMP trap received? |
Select Yes to raise an event when an SNMP trap matching your filter criteria is received. The default is Yes. |
|
Event severity when SNMP trap received |
Set the event severity level, from 1 to 40, to indicate the importance of an event in which a trap message matches all filter criteria. The default is 15. You can adjust the severity depending on which type of message you are checking for. |
|
Format trap data according to SNMP version |
Select the version of SNMP whose formatting should be used for trap event messages. The data provided by each format is the same; only the layout is different. |
|
Raise event for Trap Receiver availability? |
Select Yes to raise an event when Trap Receiver becomes unavailable and when Trap Receiver becomes available once again. The default is Yes. |
|
Event severity when Trap Receiver is unavailable |
Set the severity level, from 1 to 40, to indicate the importance of an event in which Trap Receiver becomes unavailable. The default is 5. |
|
Event severity when Trap Receiver becomes available |
Set the severity level, from 1 to 40, to indicate the importance of an event in which Trap Receiver becomes available. The default is 25. |
|
Data Collection |
|
|
Collect data for received traps? |
Select Yes to collect data for charts and reports. If enabled, data collection returns information about received traps based on your search criteria. The default is unselected. |
|
Collect data for Trap Receiver availability? |
Select Yes to collect data for charts and reports. If enabled, data collection returns “1” if Trap Receiver is available and “0” if Trap Receiver is unavailable. The default is unselected. |
|
Interval for collecting Trap Receiver availability data |
Specify the frequency with which the script collects Trap Receiver availability data. The default is every 5 minutes. |
In general, a trap receiver is an application that receives traps from SNMP agents. Trap Receiver receives and filters SNMP traps, and then forwards the traps to AppManager. Trap Receiver runs as a service, NetIQTrapReceiver.exe, and may compete for port usage with any other trap receiver installed on the same computer.
At its most basic, a trap receiver is an application that receives traps from SNMP agents. Trap Receiver receives, filters, and forwards SNMP traps to AppManager. When you use Trap Receiver with the AppManager for Microsoft Windows module, the SNMPTrap Knowledge Script raises events when SNMP traps are received.
Simple Network Management Protocol (SNMP) is a protocol-based system used to manage devices on TCP/IP-based networks. From devices on which an SNMP agent resides, such as routers and switches, SNMP sends unsolicited notifications, called traps, to network administrators when thresholds for certain conditions are exceeded. These conditions are defined by the vendor in a device’s Management Information Base (MIB). The network administrator sets the thresholds.
Traps are composed of Protocol Data Units (PDUs). Each PDU contains the following information, organized in various ways depending on the version of SNMP in use:
SNMP version number
Community name of the SNMP agent
PDU type
Enterprise OID (object identifier), a unique number that identifies an enterprise and its system objects in the MIB
IP address of the SNMP agent
Generic trap type: Cold start, Warm start, Link down, Link up, Authentication failure, Egp Neighbor Loss, and Enterprise
Specific trap type. When the Generic trap type is set to “Enterprise,” a specific trap type is included in the PDU. A specific trap is one that is unique or specific to an enterprise.
Time the event occurred
Varbind (variable binding), a sequence of two fields that contain the OID and a value
Trap Receiver operates on a Client-Server architecture: the Server—the stand-alone Trap Receiver application—receives, filters, and forwards SNMP traps to the Client—an application that receives traps, such as AppManager. The Server may receive traps from standard UDP port 162 or from any other configured port. The Client and the Server can reside on the same computer or on separate (proxy) computers.
Communication between Client and Server is implemented as XML messages over a TCP connection. Only one Server is allowed per computer, however, several Clients are allowed per computer. Clients that are registered to the same Server share the same TCP connection. The Server TCP port should be known to all potential Clients.
The configuration file for Trap Receiver, NetIQTrapReceiver.conf, identifies the UDP and TCP ports used by Trap Receiver: the UDP port is used for receiving traps; the TCP port is used for communicating with the Client, such as AppManager or another supported NetIQ application. The configuration file also identifies the level of logging you want to use and whether port forwarding is enabled.
By default, the configuration file is installed in [installation directory]\config, and has the following format:
############################################################## # # NetIQTrapReceiver.conf # # A configuration file for NetIQ Trap Receiver # ############################################################## ######################### # TCP port # Syntax: tcp_port [port] # E.g. : tcp_port 2735 ######################### tcp_port 2735 ######################### # UDP port # Syntax: udp_port [port] # E.g. : udp_port 162 ######################### udp_port 162 ######################### # Forwarding # Syntax: forward [address]:[port] [v1] # E.g. : forward 127.0.0.1:1000 v1 ######################### ######################### # Log level # Syntax: log_level error|warning|info|debug|xml # E.g. : log_level info ######################### log_level debug
If the configuration file cannot be found, cannot be parsed, or does not contain one of the required values, Trap Receiver is initialized with the default configuration as shown above.
When changing values in the configuration file, take into account the following:
If you change the TCP port number, stop all asynchronous Knowledge Script jobs associated with the modules that support Trap Receiver. Run the Discovery_NT Knowledge Script on all monitored devices to enable the devices to recognize the new TCP port number.
If you change the UDP port number, also change the UDP port number configured on the devices that send traps to Trap Receiver.
If another service uses port 2735 or port 162, Trap Receiver will not start. The Trap Receiver log file will contain different levels of messages, based on the log_level you choose. Either change the port numbers in the configuration file, stop the service that is using the default Trap Receiver port numbers, or forward the traps coming in to UDP port 162.
To forward incoming traps to another trap receiver, such as Microsoft SNMP Trap Service, set the Forwarding values as follows: forward [IP address of other trap receiver]:[port number of other trap receiver] [SNMP version]. For example: forward 10.40.40.25:167 v1. By default, incoming traps are not forwarded. For more information, see Coexisting with Microsoft SNMP Trap Service.
Restart Trap Receiver after any change to the configuration file. From Control Panel, double-click Administrative Tools and then double-click Services. Right-click NetIQ Trap Receiver and select Restart.
Two trap receivers cannot be in use on the same computer while using the same standard UDP port (162). If NetIQ Trap Receiver and another trap receiver such as Microsoft SNMP Trap Service are installed on the same computer and both are receiving traps, then configure Trap Receiver to use the standard UDP port and to forward incoming traps (UDP forwarding) to the other trap receiver. For more information, see Understanding the Trap Receiver Configuration File.
Then, configure the other trap receiver to use a different, non-standard, UDP port that is not in use by another application. The following are instructions for configuring Microsoft SNMP Trap Service.
To configure Microsoft SNMP Trap Service to use another port:
Navigate to \system32\drivers\etc.
Open the services file.
In the row for snmptrap, change the value for udp from 162 to another port number that is not in use by any other application. Use the same port number you set as the forwarding port in the Trap Receiver configuration file. For more information, see Understanding the Trap Receiver Configuration File.
Save and close the services file.
Restart Windows SNMP Trap Service. In Control Panel, double-click Administrative Tools and then double-click Services. Right-click SNMP Trap Service and select Restart.
HINT:To see which ports are in use, run netstat.exe from a command prompt. Then select an available port as the port for the other trap receiver service.
For each device you want to monitor for SNMP v3 traps, configure Simple Network Management Protocol (SNMP) information in AppManager Security Manager before you run the SNMPTrap Knowledge Script. You do not need to configure permissions for SNMP v1 or v2.
By configuring SNMP information, you provide AppManager the permission it needs to access the Management Information Bases (MIBs) on SNMP-enabled devices.
The AppManager for Microsoft Windows module supports the following modes for SNMP v3:
No authentication; no privacy
Authentication; no privacy
Authentication and privacy
In addition, the module supports the following protocols for SNMP v3:
MD5 (Message-Digest algorithm 5, an authentication protocol)
SHA (Secure Hash Algorithm, an authentication protocol)
DES (Data Encryption Standard, encryption protocol)
Your SNMP v3 implementation may support one or more combinations of mode and protocol. That combination dictates the type of information you configure in AppManager Security Manager: user name (or entity), context name, protocol name, and protocol passwords.
Configure SNMP information for each device you want to monitor. On the Custom tab in Security Manager, complete the following fields:
|
Field |
Description |
|---|---|
|
Label |
SNMPTrap |
|
Sub-label |
Indicate whether the community string information will be used for a single device or for all devices:
|
|
Value 1 |
SNMP user name, or entity, configured for the device. All SNMP v3 modes require an entry in the Value 1 field. |
|
Value 2 |
Name of the context associated with the user name or entity you entered in the Value 1 field. A context is a collection of SNMP information that is accessible by an entity. If possible, enter a context that provides access to all MIBS for a device. If the device does not support context, type an asterisk (*). All SNMP v3 modes require an entry in the Value 2 field. |
|
Value 3 |
Combination of protocol and password appropriate for the SNMP v3 mode you have implemented.
|
The SNMPTrap Knowledge Script can translate numerical OIDs to their ODE counterparts. The translation process requires access to the Management Information Base (MIB) files that reference the OIDs you specified as filters in the script parameters.
You must copy the necessary MIB files to the default MIBs directory on the computer on which NetIQ Trap Receiver is installed. After installing the MIBs, reload the MIBs directory so the new MIBs can be compiled for use by Trap Receiver.
To add MIBs to the MIB directory and reload the directory:
On the computer on which Trap Receiver is installed, copy all necessary MIB files to the default directory: \Program Files\NetIQ\AppManager\bin\MIBs. Ensure you copy MIB files for all your modules, not only the MIB files for the module with the trap definition.
On that same computer, restart the AppManager agent services: NetIQmc (NetIQ AppManager Client Resource Monitor) and NetIQccm (NetIQ AppManager Client Communication Manager). Restarting the services allows Trap Receiver to load the MIB files.