|
|
This chapter describes the Mediators provided with the Cisco Info Center product.
This chapter contains the following sections:
This section provides information about the HP Network Node Manager (NNM) Info Mediator.
Info Mediator Target | HP Network Node Manager |
Info Mediator Executable Name | nco_p_nnm5 for NNM Version 5.x |
Info Mediator Supported on | NNM Version 3: Solaris 2 NNM Version 4: Solaris 2 NNM Version 5: Solaris 2 |
Properties file | $OMNIHOME/probes/solaris2/nnm5.props for nco_p_nnm5 |
Rules file | $OMNIHOME/probes/solaris2/nnm5.rules for nco_p_nnm5 |
Requirements | HP NNM trapd process. |
The HP NNM Info Mediator acquires event data by connecting to a running HP NNM system and capturing traps to form alerts.
The HP NNM Info Mediator connects to the trapd process which HP NNM uses. It acquires its events directly from that process. The HP NNM Info Mediator does not work when the trapd process does not exist.
The HP NNM Info Mediator requires that the HP NNM is running to generate a real-time stream of events.
This subsection provides information about the HP NNM Info Mediator command line option.
The command line option specific to the HP NNM Info Mediators is:
nco_p_nnmn -<manager-string>
where <manager-string> is the management application name.
See Appendix A, "Generic Info Mediator Properties", and Appendix B "Default Info Mediator Command Line Options", for the properties and command line options available with all Info Mediators.
This subsection provides information about the HP NNM Info Mediator elements.
The HP NNM Info Mediator uses the static elements listed in Table 3-2.
| Element Name | Element Description |
$Node | Node name or IP address. |
$community | SNMP community string. |
$enterprise | SNMP enterprise string. |
$generic-trap | SNMP generic trap integer value. |
$specific-trap | SNMP specific trap integer value. |
$IPaddress | IP address of the device. |
$Sequence | Indicates the number of times the Info Mediator has been run. |
The other elements are created on-the-fly and are entirely dependent on the traps sent by the network elements. They are mapped into $<n> and $OID<n> elements, where <n> is a sequence number.
The generic traps are handled at the end of the rules file. The handling of each is detailed below.
Summary field set to Cold Start, AlertGroup field set to Generic, Severity field set to 4.
Summary field set to Warm Start, AlertGroup field set to Generic, Severity field set to 4.
Summary field set to Link Down, AlertKey field set to the $1 varbind (which is <ifIndex>), AlertGroup field set to Generic, Severity field set to 5, Identifier field set to <Nodename> plus <Agent> plus <generic-trap> plus <specific trap> plus <ifIndex>.
Summary field set to Link Up, AlertKey field set to the $1 varbind (which is ifIndex), AlertGroup field set to Generic, Severity field set to 2, Identifier field set to <Nodename> plus <Agent> plus <generic-trap> plus <specific trap> plus <ifIndex>.
By default, Authentication traps are discarded
Summary field set to EGP Neighbor Loss, AlertGroup field set to Generic, Severity field set to 3.
See Appendix E, "Error Messages", for details of the generic error messages produced by all Info Mediators.
Refer to your support contract for more information about contacting the help desk.
See Appendix E, "Error Messages", for details of the generic error messages produced by all Info Mediators.
Refer to your support contract for more information about contacting the help desk.
See Appendix E, "Error Messages", for details of the generic error messages produced by all Info Mediators.
Refer to your support contract for more information about contacting the help desk.
The Info Mediator cannot save the sequence number.
Check that the file /var/adm/.nnm_seqno exists and the permissions are set correctly.
This section provides information about the Cisco Syslog Info Mediator.
Mediator Target | None - Info Mediator for UNIX syslogd |
Mediator Executable Name | nco_p_syslog |
Mediator Supported on | Solaris 2 |
Properties file | $OMNIHOME/probes/solaris2/syslog.props |
Rules file | $OMNIHOME/probes/solaris2/syslog.rules |
Requirements | The Syslog Info Mediator requires that a FIFO can be created and syslogd is configured to write to that FIFO. |
The Cisco Syslog Info Mediator acquires event data from syslogd, the UNIX system message logger, by reading from a FIFO into which syslogd has been configured to write its messages.
The /etc/syslog.conf file needs to be modified to send all messages to the FIFO. By default, with no FIFO settings in the properties or on the command line, the Cisco Syslog Info Mediator creates and reads a FIFO called /var/adm/nco. To set syslogd to write to this file, add the following line to the /etc/syslog.conf file:
*.debug /var/adm/nco
The line specified writes all syslog messages to the FIFO. It is also possible to configure syslog to only write particular messages to the file. Refer to the UNIX online manual pages for syslog.conf for more details. The syslogd process does not need to be restarted; when the Cisco Syslog Info Mediator is started, it automatically triggers a re-reading of the syslog.conf file.
When the Cisco Syslog Info Mediator starts, it attempts to open (or create) the FIFO specified in the properties or command line. It is recommended you do not set this property so the Cisco Syslog Info Mediator defaults to its standard /var/adm/nco FIFO location. When, for some reason (for example, /var/adm does not exist or a FIFO has been incorrectly specified), the Cisco Syslog Info Mediator falls back to using /tmp/nco as its emergency FIFO.
The Cisco Syslog Info Mediator then locates the syslogd process and sends it a signal, prompting it to re-read its configuration file. This allows you to make changes to the syslog.conf file. Any changes you do make only come into effect when the Cisco Syslog Info Mediator is restarted.
Once it is reading the FIFO, the Cisco Syslog Info Mediator detects any messages written to the FIFO and processes them, one line at a time, as events.
This subsection describes the properties and command line options associated with the Cisco Syslog Info Mediator.
The following command line options are associated with the Cisco Syslog Info Mediator:
nco_p_syslog -fifo <string> -offset0 <numeric> -offset1 <numeric> -offset2 <numeric>
Table 3-4 describes the Cisco Syslog Info Mediator properties and command line options.
| Property Name | Property Parameter | Command Line Option | Description |
FifoName | string | -fifo <string> | Filename of FIFO to create and read syslog messages from. |
OffsetZero | numeric | -offset0 <numeric> | Parse from character position. |
OffsetOne | numeric | -offset1 <numeric> | Number of token elements to create. |
OffsetTwo | numeric | -offset2 <numeric> | Number of tokens into string to create Details element. |
See Appendix A, "Generic Info Mediator Properties", and Appendix B, "Default Info Mediator Command Line Options", for the properties and command line options available with all Info Mediators.
See Appendix E, "Error Messages", for details of the generic error messages produced by all Info Mediators.
The properties or command line options for the FIFO file are pointing to a file which cannot be opened.
Check the command line options and properties and set them to refer to the correct FIFO file that has been created.
See Appendix E, "Error Messages", for details of the generic error messages produced by all Info Mediators.
The Cisco Syslog Info Mediator is unable to create the specified FIFO.
Check that the file specified can be created, then check the properties and command line options.
See Appendix E, "Error Messages", for details of the generic error messages produced by all Info Mediators.
The Cisco Syslog Info Mediator did not find the specified FIFO.
The Cisco Syslog Info Mediator has fallen back to using the temporary named FIFO.
Check the properties, command line options, and that the file can be written to.
The named FIFO has been created.
The file specified as a FIFO already exists and is not a FIFO.
Check the properties and command line options.
This section provides information about the Trapd Info Mediator.
Mediator Target | SNMP Events |
Mediator Executable Name | nco_p_trapd |
Mediator Supported on | Solaris 2 |
Properties file | $OMNIHOME/probes/solaris2/trapd.props |
Rules file | $OMNIHOME/probes/solaris2/trapd.rules |
Requirements | See Section "Other Requirements" on next page. |
The Trapd Info Mediator is a direct SNMP monitoring Info Mediator. The Trapd Info Mediator acquires event data by acting as a trap daemon and monitoring SNMP traps and events.
The Trapd Info Mediator must not be run on a machine where another trapd process (for example, HP NNM or SunNet Manager) is running, unless a different SNMP port is specified on the command line or in the properties.
The Trapd Info Mediator must be run by a root user or by a user with write access to the /var/adm directory and the SNMP port.
This subsection describes the properties and command line options associated with the Trapd Info Mediator.
The following command line options are associated with the Trapd Info Mediator:
nco_p_trapd -mibfile <string> -port <numeric> -socketsize <numeric>
Table 3-6 describes the Trapd Info Mediator properties and command line options.
| Property Name | Property Parameter | Command Line Option | Description |
MIBFile | string | -mibfile <string> | Set the name of the MIB file. The default is: $OMNIHOME/probes/arch/mib.txt |
Port | numeric | -port <numeric> | Sets the port to listen for SNMP traffic. Defaults to the standard SNMP port. |
SocketSize | numeric | -socketsize <numeric> | The input buffer size in bytes. The default is 4096. See note below. |
See Appendix A, "Generic Info Mediator Properties", and Appendix B, "Default Info Mediator Command Line Options", for properties and command line options available with all Info Mediators.
128 bytes, the default is 4096 bytes. In the majority of cases, the default size is the best size to use. You should only change it when you are instructed to do so by technical support. When you do increase the size, the Trapd Info Mediator is less likely to miss traps when there is a sudden burst of them, however, you do use up RAM needlessly the rest of the time. When you decrease the size, the Trapd Info Mediator may lose events.
This subsection provides information about the Trapd Info Mediator elements.
The Trapd Info Mediator uses the static elements listed in Table 3-7.
| Element Name | Element Description |
$Node | Node name or IP address when the name can not be resolved. |
$IPaddress | IP address. |
$community | SNMP community string. |
$enterprise | SNMP enterprise string. |
$generic-trap | SNMP generic trap integer value. |
$specific-trap | SNMP specific trap integer value. |
$UpTime | SNMP Uptime. |
$ReqId | SNMP request ID. |
$EventCount | The number of traps processed during the current execution of the Trapd Info Mediator. |
$Sequence | A value unique to each execution of the Trapd Info Mediator. The first time the Trapd Info Mediator is run, this value is set to 1, it is then incremented by one each time the Trapd Info Mediator is run. |
The other elements are created on-the-fly and are entirely dependent on the network devices.
The varbinds that are generated by SNMP are mapped to elements called $1, $2, $3, and so on up to $9.
For each varbind, the object ID is placed in a corresponding element called $OID1, $OID2, $OID3, and so on up to the number of varbind elements.
The generic traps are handled at the end of the rules file. The handling of each is detailed below.
As the Trapd Info Mediator exits, a ProbeWatch event message is generated that contains the unique sequence number of the Trapd Info Mediator and the number of traps processed during its execution.
See Appendix E, "Error Messages", of the ProbeWatch events produced by all Info Mediators.
The Cisco StrataView+ (SV+) 8.4 and/or 9.1 management application that manages the Cisco WAN equipment, forwards the traps received from the network element to two destinations as shown in Figure 3-1.
The Cisco SV+ Info Mediator consists of the HP NNM and Trapd Info Mediators. These two Info Mediators form the Cisco SV+ Info Mediator and collect events passed by
Cisco SV+ to the HP NNM and the Service View Agent.
The Trapd Info Mediator for the Cisco SV+ Info Mediator, registers with the Robust Trap Mechanism (RTM) Proxy Agent by passing the IP address of the machine on which the Info Mediator runs, which is the Cisco SV+ machine, and the port it is running on. By default, the Trapd Info Mediator runs on port 162, however, as this port is used by HP NNM Trapd, the Trapd Info Mediator is configured to run on port 4000. The registration process registers the Trapd Info Mediator with the Service View Agent and monitors the registration. When for any reason, the RTMProxy process is not running, or the Trapd Info Mediator is unable to register, the registration process sends an SNMP trap to the Trapd Info Mediator. The registration script is started in the Process Control as follows:
$OMNIHOME/utils/trapd/start_trapd <IP Address> <Port>
See Appendix G, Section "Micromuse Specific Traps", for more information.
As both the HP NNM and Trapd Info Mediators receive traps, the elements created by both of these Info Mediators are the same (see the Static and Dynamic Elements Sections for NNM and Trapd Info Mediators). Both of these Info Mediators use a common rules file, /opt/Omnibus/probes/solaris2 called cisco.rules. The installation and configuration script on installing the Cisco SV+ Info Mediators, configures the properties for the HP NNM and Trapd Info Mediators to include the cisco.rules file.
It is likely the HP NNM and Trapd Info Mediators may receive identical traps from
Cisco SV+ and therefore, a discard functionality has been implemented whereby duplicate traps are discarded from the HP NNM.
Manager Address | Enterprise ID | Agent Address | Generic Trap | Specific Trap | TimeStamp | VarBind1 | VarBind2 | Other VarBinds. |
where the VarBinds consist of a group of Object Identifier, Type, and Value and the number of VarBinds depends upon the trap. For example:
171.22.24.67 | .1.3.6.1.4.1.9 | 171.22.24.88 | 2 | 0 | 133333 | .1.3.6.1.1.2.5, integer 11 |
When this trap is received by either the HP NNM or Trapd Info Mediator, the following elements are generated:
| Element Name | Element Description |
$Node | 171.22.24.88 |
$enterprise | .1.3.6.1.4.1.9 |
$generic-trap | 2 |
$specific-trap | 0 |
$OID1 | .1.3.6.1.1.2.5 |
$1 | 11 |
The VarBind elements are assigned to elements $OID[<n>] and $[<n>] where <n> is the position of the VarBind in the SNMP PDU, as shown in the above example.
$OID1 = .1.3.6.1.1.2.5 $1 = 11
This section describes the skeleton of the rules file for the HP NNM and Trapd Info Mediators. See Appendix G, "Cisco StrataView Plus Mediator Rules File", for more information.
The first section must have any settings for lookups when defined. For example:
table discards = "/opt/Omnibus/probes/solaris2/discards.lookup" table NEAddress = "/opt/Omnibus/probes/solaris2/node_ip_addr.lookup"
The next section is the body of the rules file that deals with the Info Mediator Watch and Event mappings.
The Probe Watch messages are generated by the Info Mediators and is an internal property of the Info Mediators. These messages are usually generated during start-up and shutdown. The following section deals with the Info Mediator Watch messages within the main loop of the rules file.
switch(@Manager)
{
@Summary = @Agent + " on " + @Node + " "+ @Summary The defaults start here for main rules section (non ProbeWatch alerts).
case ".1.3.6.1.4.1.351.1":
switch($specific-trap)
{
case "25000":
case "25001":
case "25002":
default:
case ".1.3.6.1.4.1.351.100":
Map Traps for the StrataView Switch Software
switch($specific-trap)
{
case "1000":
case "1001":
case "1002":
default:
}
case ".1.3.6.1.4.1.351.110":
Map traps for the StrataCom Axis Enterprise
switch($specific-trap)
{
case "50000":
case "50001":
case "50002":
default:
}
case ".1.3.6.1.4.1.351.200.1":
Map traps for the StrataCom Switch Software
case ".1.3.6.1.4.1.351.200.1":
Map traps for the VNS DNS enterprise
switch ($specific-trap)
{
case "6000":
case "6001":
default:
}
}
This section deals with SNMP traps 0 - 5:
5 - EGP Loss
4 - Authentication
3 - Link Up
2 - Link Down
1 - Warm Start
0 - Cold Start
case "5":
switch($enterprise)
{
case ".1.3.6.1.6.3.1.1.5":# SNMP_EGP_DownMappings here...default:Mappings here }
case "4":
switch($enterprise)
{
case ".1.3.6.1.6.3.1.1.5":
# SNMP_Authen_Failure
Mappings here
...
default:
Mappings here
}
case "3":
switch($enterprise)
{
case ".1.3.6.1.6.3.1.1.5":
# SNMP_Link_Up
Mappings here
default:
Mappings here
}
case "2":
switch($enterprise)
{
case ".1.3.6.1.6.3.1.1.5":
# SNMP_Link_Down
Mappings here
default:
Mappings here
}
case "1":
switch($enterprise)
{
case ".1.3.6.1.6.3.1.1.5":
# SNMP_Warm_Start
Mappings here
default:
Mappings here
}
case "0":
switch($enterprise)
{
case ".1.3.6.1.6.3.1.1.5":
# SNMP_Cold_Start
Mappings here... default:
Mappings here... }
This handles the default if none of the above rules match.
default:
@Summary = "Unknown generic trap number " + $generic-trap + " from enterprise " + $enterprise-name@AlertGroup = "unknown"@Severity = "1" }
}
This section describes the process of adding a new, specific trap to an existing enterprise.
You must add the trap definition, within a case statement, in the portion of the rules file defined for the enterprise. For example, to add trap 25010 to the .1.3.6.1.4.1.351.1 enterprise in the above example, add the case "25010" anywhere before the default condition that matches the case statement, for the enterprise within the specific trap switch, within the enterprise.
case ".1.3.6.1.4.1.351.1":
switch($specific-trap){case "25000":Mappings here for this case....case "25010":Mappings here and so on.....default: catch all if none of the above matches.}This section describes the process of adding a new enterprise definition, with its specific traps, to the rules file.
You must add the specific traps for a new enterprise, in the loop of the switch on generic trap 6, and within the switch for the enterprise, as follows.
For example, to add the traps for vendor Micromuse (.1.3.6.1.4.1.1279) into the above rules skeleton:
#Micromuse Specific Traps
case ".1.3.6.1.4.1.1279":
switch($specific-trap){case "1":Mappings for Case 1...case "2":Mappings for Case 2...default:Mappings for Default} Traps specific to a new enterprise must be added under the switch statement for the $generic-trap and under case "6". A new switch statement must be added anywhere under the case "6" and before the SNMP Generic traps:
Configure traps for the enterprise (vendor) specific traps.
switch ($generic-trap)
{
case "6"
switch($enterprise)
{
Map Traps for the StrataViewPlus Enterprise
case ".1.3.6.1.4.1.351.1":
switch($specific-trap)
{
case "25000":
Mappings here for this case..
}
case ".1.3.6.1.4.1.1279":
Micromuse Specific Traps
switch($specific-trap)
{
case "1":
Mappings for Case 1
case "2":
Mappings for Case 2
default:
Catch all if none of the above cases match for this specific enterprise
}
Posted: Thu Apr 1 10:51:45 PST 1999
Copyright 1989-1999©Cisco Systems Inc.