|
|
Cisco Info Center works with a variety of Information Mediators (Info Mediators) and data sources. This chapter describes the Info Mediators and data sources used with Cisco Info Center.
This chapter contains the following sections:
Cisco Info Center manages trap data and Syslog messages produced by many network management systems. The most important event sources for Cisco Info Center are the following:
In addition to using these data sources, Cisco Info Center can receive events from many additional network management systems when used with additional Info Mediators. For a complete list of the Info Mediators that you can use with Cisco Info Center, see "Additional Info Mediators."
The Syslog Trap Generator (STG) is a software module that receives Syslog messages from IOS devices and converts them into SNMP traps. The traps are then sent to the nco_p_rttrapd mediator (reliable trap mediator). The Info Server monitors events forwarded to it by the nco_p_rttrapd mediator and processes them according to rules specified in the cisco.rules file.
Using the STG as an event source, the Cisco Info Server can manage routers and other IOS devices, such as digital subscriber line (DSL) equipment, by processing layer-3 routing events. Using the router processing module (RPM) feature, the STG and CIC can process events generated by Cisco 7200 router blades in MGX 8500 devices and generated by Cisco 3180 multiservice access concentrators.
In order to use the Policy Manager component of Cisco Info Center, you must install the STG on either the host where the Cisco Info Server is running or on another host.
 |
Note If you are using the STG feature, do not use the syslogd mediator. |
You can use the STG in two ways:
In order to monitor a particular router, you must enable message forwarding to the STG on the router. For information on installing and configuring the STG module during Cisco Info Center installation, see the "Configuring the STG" section in chapter 3 of the Cisco Info Center Installation and Configuration Guide.
The following figure shows the STG acting as a data source for CIC 2.0.
Currently the STG supports the categories of IOS facility shown in Table 3-1.
| IOS Facility | Definition |
|---|---|
CONTROLLER | Controller |
AAA | TACACS+ Authentication, Authorization, and Accounting security |
FR | Frame Relay |
FR_LMI | Frame Relay Local Management Interface |
FR_ELMI | Frame Relay Enhanced Local Management Interface |
ATM | Asynchronous Transfer Mode |
ATM_SIG | ATM Signalling Subsystem |
ATMSSCOP | ATM Service-Specific Connection Oriented Protocol |
IP | Internet Protocol |
IPFAST | IP Fast Switching |
IP_SNMP | SNMP specific to SNMP |
SYS | Operating System |
SUBSYS | Software Subsystem |
SCHED | Scheduler |
DSX1 | Channelized E1 and T1 telephony standard |
ENT_API | Entity MIB API |
|
Note Because Cisco Info Center release 2.0 primarily supports traps sent from Route Processor Module (RPMs) in Cisco wide-area switches and from the Cisco 3810 multiservice access concentrator, messages that do not have direct mappings to 3810 trap definitions are sent directly as traps to the RTM Proxy module. |
Table 3-2 shows the general mapping of STG trap fields to Cisco Info Server fields.
| Info Center Field | STG Field |
|---|---|
NEName | stgNodeName |
NEAddress | stgRouteIpAddr |
ObjectType | IOS stgTrapFacility and stgTrapMnemonic |
SubObectType | For traps that have interface information, mapped to the interface information; otherwise, blank |
AlertKey | stgRouterIpAddr + stgFacility + stgMnemonic + stgSeverity + stgTrapReason. |
DedupKey | AlertKey + AlertGroup |
ObjectStatus | stgState or stgState + stgResult |
Summary | If the trap has TrapMessage information, this is mapped to stgTrapMessage. |
AdminDomain | stgTrapReason |
PSAP (Physical Service Access Point) | If the STG trap has Controller and SubControllerID information, this is mapped to ControllerID and SubControllerID; otherwise blank. |
DSAP (Destination Service Access Point) | If the STG message has DLCI information, this is mapped to DSAP; otherwise, blank. |
Cisco IOS Syslog messages have eight severity levels. In contrast, Cisco Info Center events have five possible severity levels. Table 3-3 indicates the mapping of IOS severity levels to Cisco Info Center severity levels.
| IOS Severity | Cisco Info Center Severity | Description |
|---|---|---|
0 - Emergency | 5 - Critical | System unusable |
1 - Alert | 5 - Critical | Immediate action needed |
2 - Critical | 4 - Major | Critical condition |
3 - Error | 3 - Minor | Error condition |
4 - Warning | 2 - Warning | Warning condition |
5 - Notification | 2 - Warning | Normal but significant condition |
6 - Informational | 1 - Indeterminate | Informational only |
7 - Debugging | 1 - Indeterminate | Appears during debugging only |
The STG forwards layer-3 router events to Cisco Info Center through the RTtrapd mediator. The cisco.rules file for Cisco Info Center 2.0 provides rules that allow processing of the following types of IOS events:
The following sections summarize the types of events for these types of IOS event. For complete information on the event processing rules for Cisco Info Center 2.0, refer to the Cisco Rules File Reference.
The STG receives and forwards general router event messages that indicate the severity level of events, changes in router configuration, changes in controller state and ATM faults related to virtual circuit creation. For a complete list of these types of event, refer to the 26000 series trap rule documentation in the Cisco Rule File Reference.
RPM events are generated by RPM cards in the MGX 8850. The RPM cards function as a Cisco 7200 router. These events are used to monitor MPLS provisioning and are useful in evaluating the results of provisioning enabled through the Cisco MPLS VPN Solution product.
The following types of events are monitored by the STG and relayed to Cisco Info Center.
For information on the event mappings for MPLS events, refer to the Cisco Rules File Reference.
Cisco Info Center 2.0 includes an option called Policy Manager that acts as a data proxy or mediator for Cisco Info Center. When Cisco Info Center receives an event indicating that an interface on a router managed by Cisco's MPLS VPN Solution product has gone down, Policy Manager queries MPLS VPN Solution to obtain additional information about the event.
Cisco MPLS VPN Solution is an application that allows service providers to define and monitor virtual private networks (VPNs). A VPN is a network in which two sites communicate over the service provider's network in a private manner---no site outside of the VPN can receive or transmit packets on the "private" route. This allows service providers to provide specialized, secure intranet and extranet services to customers.
Service Providers use Cisco MPLS VPN Solution to configure two types of routers that enable deployment of VPNs:
By establishing and maintaining unique routes between CEs and PEs, service providers can provide hundreds of thousands of VPNs to their customers.
When a serial or main interface on a PE router goes down, all of the VPNs connected through that PE are affected. Policy Manager receives an event indicating that the router is down and relays fault information to Cisco Info Center.
Figure 3-2 shows the general network topology for VPNs created using PEs and CEs.
Policy Manager receives event information on PE router interfaces from two sources:
The STG converts serial interface up and down IOS messages received from PEs into traps. In addition, the STG reads a text file that contains a list of the main PE interfaces used by the organization (this file must be created manually during STG installation and configuration).The STG polls the PE interfaces at 5-minute intervals to check whether they are reachable. When the interface is unreachable, a trap is generated.
The generated traps are forwarded to the RTM Proxy module and then to the RTtrapd Info Mediator. Cisco Info Center receives the traps from the RTtrapd Info Mediator. The Policy Manager component of Cisco Info Center then queries Cisco MPLS VPN Solution to obtain additional information about the alarm, such as the number of CEs and VPNs that are affected by the PE interface failure. Policy Manager then updates the original PE event, generates new events for the affected CEs and VPN s, and forwards the events to the Cisco Info Server.
Policy Manager runs as a separate process, and includes a Common Object Request Broker Architecture (CORBA) Data Source Adapter (DSA) that acts as an object adapter that collects events from Cisco MPLS VPN Solution.
Figure 3-3 shows the flow of events between the STG, the CIC Info Server, Policy Manager, and Cisco MPLS VPN Solution.
This section describes the MPLS PE event, which is generated by the STG when a PE or a specified interface on a PE goes down, and the events that Policy Manager generates based on the MPLS PE event.
When the RTtrapd Info Mediator receives a node unreachable or link state changed Syslog trap, it performs a table lookup on a table that contains a list of all of the PEs provisioned by Cisco MPLS VPN Solution. If the value contained in the trap's nodeName varbind ($2) is listed in the lookup table, an event is forwarded to the Info Server with a flag set indicating that Policy Manager should process it.
This type of event is an MPLS PE event.
Table 3-4 describes the traps that are processed by Policy Manager.
| Trap Name | STG State | Specific Trap | When Sent |
|---|---|---|---|
stgSyslogNodeUnreachable | NA | 26301 | Generated by STG when a node being polled becomes unreachable. |
stgSyslogNodeReachable | NA | 26302 | Generated by STG when a node being polled becomes reachable. |
stgSyslogLinkStateChanged | Up or Down | 26111 | LINK-5-PDOWN Syslog message LINK-5-CHANGED Syslog message |
When Policy Manager receives an event that is flagged for Policy Manager processing, it queries Cisco MPLS VPN Solution for additional information relating to the event, such as the affected CEs and VPNs, customer names, and site names. Policy Manager updates the original PE event with information on the affected VPN by adding the following information:
Policy Manager generates an MPLS CE event for each Customer Edge router (CE router) that is serviced by an interface that has gone down on a PE router.
Table 3-5 describes the fields in the MPLS CE Event.
| Field | Description |
|---|---|
CEName | Name of an affected CE. |
Customer Name | Name of the customer using the CE. |
Customer Site | Name of the affected customer site. |
VPNs | List of VPNs connected to the CE. |
PEName | Name of the PE that services the CE. |
PE Interface | The down PE interface. |
Policy Manager generates an MPLS VPN event for each VPN that is affected by an MPLS PE event. Table 3-6 describes the fields in the MPLS VPN event. This event is generated when a PE interface either goes up or comes down.
| Field | Description |
|---|---|
Customer | Name of the customer for the VPN. |
VPNName | Name of the affected VPN. |
NumCEs Down | Number of CE routers affected in the VPN. |
totalNumCEs | Total number of CEs in the VPN. |
Summary | Percentage of CEs affected in the VPN. |
When a PE interface that has gone down comes back up, the original interface down events are cleared and all associated MPLS events are cleared by an automation process running on the Cisco Info Server. Policy Manager determines the number of cleared CEs in the affected VPN and updates the NumCE Down and Summary (percentage of CEs down) fields.
Cisco WAN Manager is a network management product that monitors Cisco's wide-area switch equipment. You can use CWM to manage the following types of Cisco device:
Cisco WAN Manager primarily monitors layer-2 (data link layer) switching events. However, you can use CWM with the STG feature to manage routers by processing layer-3 routing events.
Cisco WAN Manager acts as a data source proxy for Cisco Info Center and uses two Info Mediators: the nco_p_rttrapd Info Mediator and one of two versions of the HP NNM Info Mediators, the nco_p_nnm5 mediator or the nco_p_nnm6 mediator.
Figure 3-4 shows how Cisco Info Center interacts with Cisco WAN Manager and its associated Info Mediators.
Cisco WAN Manager primarily monitors Cisco wide-area switches and concentrators. For a detailed list of all of the traps that Cisco Info Center receives from Cisco switch equipment, refer to the Cisco Rules File Reference.
Some of the common event types that Cisco Info Center receives through CWM are the following:
|
Note Events generated by Route Processor Module (RPM) cards on MGX 8850 wide-area switches are processed using the STG as a data source. |
Using the nco_p_nnm5 and nco_p_nnm6 Info Mediators, Cisco Info Center can receive events from the industry standard HP Network Node Manager (HP NNM) network management system.
Cisco Info Center uses the following Info Mediators to receive event data from the network:
The following sections describe each of these Info Mediators.
This section provides information about the Cisco Syslog Info Mediator.
Mediator Target | IOS messages from Syslog daemon (syslogd) |
Mediator Executable Name | nco_p_syslog |
Mediator Supported on | Solaris 2.6, Solaris 2.7 |
Properties file | $OMNIHOME/probes/solaris2/syslog.props |
Rules file | $OMNIHOME/probes/solaris2/syslog.rules
/opt/Omnibus/utils/install/rules |
Requirements | The Syslog Info Mediator requires that syslogd is configured to a named pipe, or optionally, to a log file. |
The Cisco Syslog Info Mediator acquires event data from syslogd, the UNIX system message logger, by reading from a FIFO that syslogd has been configured to write messages to.
|
Note A First In First Out (FIFO), also known as a named pipe, allows a program to write to a file and another process to read what has been written without the file expanding. |
The /etc/syslog.conf file must be edited during CIC configuration to send specific messages to the named pipe or log file. By default, with no named pipe settings in the properties or on the command line, the Cisco Syslog Info Mediator creates and reads a named pipe called /var/adm/nco. To set syslogd to write to this file and enable monitoring of routers, add the following line to the /etc/syslog.conf file:
local7.debug
|
Note This line must not be the first line of the /etc/syslog.conf file. When it is, it activates a bug in syslogd, where it attempts a check on the first file in the first entry in the /etc/syslog.conf file, and this makes the syslog system unstable. Also note, some implementations of syslogd are limited to twenty entries in the /etc/syslog.conf file. |
The line specified writes Local7 Facility level syslog messages to the named pipe (this is the default Facility level for Cisco routers). It is also possible to configure syslogd to write other Facility and severity level messages to the named pipe or 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 by the syslogd process.
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 Syslog Info Mediator does not find the FIFO, 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-8 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 "Generic Info Mediator Properties," and "Default Info Mediator Command Line Options," for the properties and command line options available with all Info Mediators.
See "Error Messages," for details of the generic error messages produced by all Info Mediators.
Failed to open FIFO <FIFO file name>
Explanation The properties or command line options for the FIFO file are pointing to a file which cannot be opened.
Action Check the command line options and properties and set them to refer to the correct FIFO file that has been created.
See "Error Messages," for details on the generic error messages produced by all Info Mediators.
Can't create <FIFO file name>
Explanation The Cisco Syslog Info Mediator is unable to create the specified FIFO.
Action Check that the file specified can be created, then check the properties and command line options.
See "Error Messages," for details of the generic error messages produced by all Info Mediators.
Not found: <FIFO file name>
Explanation The Cisco Syslog Info Mediator did not find the specified FIFO.
Temporary FIFO created: <FIFO file name>
Using temporary FIFO: <FIFO file name>
Explanation The Cisco Syslog Info Mediator has fallen back to using the temporary named FIFO.
Action Check the properties, command line options, and that the file can be written to.
FIFO created: <FIFO file name>
Explanation The named FIFO has been created.
Not a FIFO: <file name>
Explanation The file specified as a FIFO already exists and is not a FIFO.
Action Check the properties and command line options.
This section provides information about the RTtrapd Info Mediator.
Mediator Target | SNMP events from Cisco WAN Manager or the Syslog Trap Generator |
Mediator Executable Name | nco_p_rttrapd |
Mediator Supported on | Solaris 2.6, Solaris 2.7 |
Properties file | $OMNIHOME/probes/solaris2/rttrapd.props |
Rules file | $OMNIHOME/probes/solaris2/cisco.rules |
Requirements | Requires that you have Cisco WAN Manager or the Syslog Trap Generator installed. |
The RTtrapd Info Mediator acquires data from Cisco WAN Manager or from the Syslog Trap Generator.
This subsection describes the properties and command line options associated with the RTtrapd Info Mediator.
The following command line options are associated with the RTtrapd Info Mediator:
nco_p_rttrapdThe following command line options are associated with the Cisco Syslog Info Mediator:
nco_p_rttrapd -rtmmanagerhostaddr <IP_address> -rtmmanagerport <port_number> -rtagenthostname <hostname> -server<server_name> -manager <hostname@SV+> | <hostname@SV+> -rulesfile <rules_filename>Table 3-10 describes the Cisco Syslog Info Mediator properties and command line options.
| Property Name | Property Parameter | Command Line Option | Description |
RTMManagerHostaddr | string | -rtmmanagerhostaddr <IP_address> | IP address of the host that is running the RTTrapd Info Mediator. |
RTMManagerPort | numeric | -rtmmanagerport <port_number> | Port that the Rttrapd Info Mediator uses to listen for reliable traps |
RTAgentHostname | string | -rtagenthostname <hostname> | Host name of the host that is running Cisco WAN Manager |
Server | string | -server <server_name> | Name of the Info Server that will receive the traps |
Manager | string | -manager <hostname@SV+> | <hostname@SV+> | Name of the host running the RTTrapd Info Mediator. This can be in either of two forms: hostname@SV+ or hostname@STG. |
RulesFile | string | -rulesfile <rules_filename> | The path to the rules file used by the RTtrapd Info Mediator. Normally this path is the following: /opt/Omnibus/probes/solaris2/ |
|
Note These parameters are written to the rttrapd.props properties files and are used by the process control agent when the RTTrapd Info Mediator is started automatically. Do not change the other parameters in the properties file, as this will cause the Info Mediator to cease functioning. |
As the RTtrapd Info Mediator exits, a ProbeWatch event message is generated that contains the unique sequence number of the RTtrapd Info Mediator and the number of traps processed during its execution.
See "Error Messages," for a list of the ProbeWatch events produced by all Info Mediators.
This section provide information about the HP Network Node Manager (NNM) Info Mediator. This Info Mediator allows Cisco Info Center to receive alerts from the HP NNM application.
Table 3-11 summarizes essential information about the HP NNM mediator.
Info Mediator Target | SNMP traps generated by the HP OpenView component of HP NNM |
Info Mediator Executable Name | nco_p_nnm5 for NNM Versions 3.x, 4.x, or 5.x nco_p_nnm6 for NNM Version 6 |
Info Mediator Supported on | NNM Version 5: Solaris 2.7 NNM Version 6: Solaris 2.7 |
Properties file | $OMNIHOME/probes/solaris2/nnm5.props for nco_p_nnm5 $OMNIHOME/probes/solaris2/nnm6.props for nco_p_nnm5 |
Rules file | $OMNIHOME/probes/solaris2/nnm5.rules for nco_p_nnm5 $OMNIHOME/probes/solaris2/nnm6.rules for nco_p_nnm5 |
Requirements | HP NNM |
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 ovtrapd process that HP NNM uses. It acquires its events directly from that process. The HP NNM Info Mediator does not work when the ovtrapd 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 n is the NNM version that the mediator will communicate with (NNM 3, 4, o4 5) and <manager-string> is the management application name.
See "Generic Info Mediator Properties,"and "Default Info Mediator Command Line Options," for the properties and command line options available with all Info Mediators.
The command line syntax for the nco_p_nnm6 Info Mediator is as follows:
nco_p_nnm6 -ovhostname <hostname> -ovfilter <filter>where <hostname> is the hostname of the host running HP Open View and <filter> is the name of the OpenView trap filter.
This subsection provides information about the HP NNM Info Mediator elements.
The HP NNM Info Mediator uses the static elements listed in Table 3-12.
With the NNM 6 Info Mediator (nco_p_nnm6) the following additional dynamic element is used:
$eventID
This element represents the unique identifier that is generated for an Event Correlation System (ECS) event.
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 "Error Messages," for details on the generic error messages produced by all Info Mediators.
Select(): <reason>
Dstrval(&DS)
Action Refer to your support contract for more information about contacting the help desk.
See "Error Messages," for details on the generic error messages produced by all Info Mediators.
Cannot malloc memory for enterprise oid
Action Refer to your support contract for more information about contacting the help desk.
See "Error Messages," for details of the generic error messages produced by all Info Mediators.
Dstrval(&DS)
Action Refer to your support contract for more information about contacting the help desk.
Overror - An unexpected msg/condition - ignored
Could not get the sequence number: err code <number>
Explanation The Info Mediator cannot save the sequence number.
Action Check that the file /var/adm/.nnm_seqno exists and the permissions are set correctly.
Cisco WAN Manager is a network management product that monitors Cisco's switch equipment. You can use CWM to manage the following Cisco devices:
Cisco WAN Manager primarily monitors layer-2 (data link layer) switching events. However, you can use CWM with the STG feature to manage routers by processing layer-3 routing events.
Cisco WAN Manager acts as a data source and proxy for Cisco Info Center and uses two Info Mediators: the nco_p_rttrapd Info Mediator and one of two versions of the HP NNM Info Mediators, the nco_p_nnm5 mediator or the nco_p_nnm6 mediator. The nco_p_rttrapd Info Mediator collects events passed by CWM to the RTMProxy module. The HP NNM mediators collect events passed by the network to the HP NNM application.
Note that to use the STG you must use the nco_p_rttrapd mediator provided with Cisco Info Center.
Figure 3-5 shows how Cisco Info Center interacts with Cisco WAN Manager and its associated Info Mediators.
To communicate with CWM, the RTtrapd Info Mediator runs on the host that is running CWM. It 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 CWM machine, and the port it is running on. By default, the RTtrapd Info Mediator runs on port 161, however, as this port is used by the HP ovtrapd process, the RTtrapd Info Mediator is configured to run on port 4000.
The nco_p_nnm5 Info Mediator uses the nnm5.rules file, the nco_p_nnm6, uses the nnm6.rules file, and nco_p_rttrapd Info Mediators uses the cisco.rules. file. These files are located in the /opt/Omnibus/probes/solaris2 directory. When you run the nco_config configuration script to configure the Info Server to communicate with CWM, the script sets the properties for these Info Mediators to include the correct rules files.
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 the RTtrapd 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 RTTrapd Info Mediator. See the Cisco Rules File Reference 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)
{
case "ProbeWatch":
include "/opt/Omnibus/probes/solaris2/cisco.includes/probewatch.r"
When a ProbeWatch event comes in, the Info Mediator reads the include statement and executes the following code in the probewatch.r rules file:
{
@Summary = @Agent + " on " + @Node + " "+ @Summary
@NEName = @Node
@ObjectType = `infocenter.system'
@SubObjectType = `Info Mediator'
@AlertKey = @Agent
switch(@Summary)
{
case "Going Down ...":
@AlertGroup = "ProbeUpDown"
@Type = 1
case "Running ...":
@AlertGroup = "ProbeUpDown"
@Type = 2
default:
}
The defaults start here for the main rules section (non ProbeWatch alerts).
default:
include "/opt/Omnibus/probes/solaris2/cisco.includes/generatediscardtrap.r"
if(match($discardtrap, $Manager) or match($discardtrap, "All"))
{
discard
} #######################################################################
#
# Do not discard traps. Continue with processing the rules file
#
#######################################################################
else
{
include "/opt/Omnibus/probes/solaris2/cisco.includes/nodiscardcommon.r"
switch($generic-trap)
{
case "6":
include "/opt/Omnibus/probes/solaris2/cisco.includes/generictraps/generictrap6.r"
case "5":
include "/opt/Omnibus/probes/solaris2/cisco.includes/generictraps/generictrap5.r"
case "4":
include "/opt/Omnibus/probes/solaris2/cisco.includes/generictraps/generictrap4.r"
case "3":
include "/opt/Omnibus/probes/solaris2/cisco.includes/generictraps/generictrap3.r"
case "2":
include "/opt/Omnibus/probes/solaris2/cisco.includes/generictraps/generictrap2.r"
case "1":
i nclude "/opt/Omnibus/probes/solaris2/cisco.includes/generictraps/generictrap1.r"
case "0":
include "/opt/Omnibus/probes/solaris2/cisco.includes/generictraps/generictrap0.r"
default:
@Summary = "Unknown generic trap number " + $generic-trap + " from enterprise " + $enterprise-name
@AlertGroup = "unknown"
@Severity = "1"
# end of switch($enterprise)
}
include "/opt/Omnibus/probes/solaris2/cisco.includes/endofrules.r"
}
For information on the rules files that are executed for each of the categories of generic traps tested in the example above, refer to the specific rules file for the class of generic traps. For information on specific traps, refer to the Cisco Rules File Reference.
Posted: Tue Jun 13 17:07:02 PDT 2000
Copyright 1989 - 2000©Cisco Systems Inc.