Cisco Element Manager System Installation and Configuration Guide, 3.1 - Northbound Event Interface [Cisco Element Manager System]

Table Of Contents

Northbound Event Interface

Configuration Overview

nbadmin Tool

help

list

register

deregister

check

command

run

exit

Configuration File Format

Required Configuration File Entries

Topological Export

Configuration File Settings

Generic Settings

HP-OEMF Specific Settings

Topological Export Usage

Registering a Filter

Triggering a Dump

Triggering a Delta

Fault Forwarding

Global Configuration Sections and Settings

NbSNMPForwarder

Functionality

Specific Settings

NbAsciiForwarder

Specific Settings

Ancillary Information

HP-OEMF Class Mapping File

Role of the Class Mapping File

File Format

Example File

Trap MIB

Northbound Event Interface

The Northbound Event Interface for the Cisco EMF platform is designed to allow integration with higher level systems such as fault management platforms, for example HP-OEMF.

To provide this integration, the Northbound Event Interface provides two main areas of functionality:

•Configurable topological export, to allow the external system to build its own model of the managed objects within Cisco EMF.

•Configurable Cisco EMF fault forwarding.

The current release of the Northbound Event Interface supports the following topological export and fault forwarding modules:

–ASCII topological export file in a format compatible with HP-OEMF 4.0.

–SNMP traps generated from Cisco EMF faults with information suitable for HP-OEMF 4.0.

–ASCII logs generated from Cisco EMF faults with information similar to that presented by the standard Cisco EMF event browser.

Configuration Overview

This chapter presents an overview of the tool used to configure the Northbound Event Interface and the format of the files used by the configuration tool.

nbadmin Tool

The Northbound Event Interface is configured using the command line tool nbadmin. This tool should always be run within a Cisco EMF shell to ensure that its runtime environment is properly setup.

This tool should always be run on the Cisco EMF server machine and all file pathnames passed to it should be valid on the Cisco EMF server.

The format of a nbadmin invocation is as follows:
nbadmin <operation> <operation-parameters>
The operations that may be used and any parameters appropriate to them are documented in the following sections.

help

Display usage guidelines for nbadmin.

list

List all registered filters.

register

The parameters to this operation are the filenames of configuration files for filters to create. Each of the files specified will be read in turn and the results returned.

Note The filenames must be fully specified UNIX paths. Relative paths are not allowed.

deregister

The parameters to this operation are the names of filters to be removed from the interface. This command will stop both topological change recording and fault forwarding.

Note The names passed to this command are not the same as the filenames passed to the register command but are the names of the filters specified within the configuration file.

check

The parameters to this operation are the names of filters. Their existence will be confirmed or denied by the output of this command.

command

The first parameter to this operation is the name of the command to be invoked. Subsequent parameters will be passed to the implementation of the command. The default commands supported by the Northbound Event Interface are:

•dump—where the parameters passed to it are the names of the topological filters to trigger a topological dump from.

•delta—where the parameters passed to it are the names of the topological filters to trigger a topological delta from.

run

The parameter to this operation is the name of a file containing a sequence of commands and parameters. Each command should be separated by a new line. The script should be terminated by the exit command.

exit

If nbadmin is in script reading mode, it will exit back to the first run command reached, either back to the nbadmin command line, back to the run command embedded in a script, or back to the shell from which nbadmin was invoked.

Configuration File Format

An example of the file format for configuration of both topological export and forwarding filters is shown in the example below:
name="SomeArbitraryName"
section1
{
    inner_section
    {
        settingA="value"
    }
    settingB="anotherValue"
}
section2
{
    settingA="valueA"
    settingB="valueB"
    settingC="valueC"
}
Note The example does not represent an actual configuration file, just the format used.

The file format also supports multiple values for a key. For example:
settings
{
    param="value1"
    param="value2"
    param="value3"
}
The data in the configuration files are made available to the topological export and fault forwarding filters to allow them to configure themselves.

Required Configuration File Entries

There are some entries which are required in the configuration file for filters to work successfully.

Each configuration file must specify a name for the filter outside of any section. For example:
name="myFilter"
Each name must be unique. The filter cannot be installed if the name clashes with a filter already installed.

If the filter is to support either topological exporting or fault forwarding, it must contain a section named "exporting". The contents of this section are described in Topological Export.

If the filter is to support fault forwarding, it must contain a section named "forwarding". The contents of this section are described in Fault Forwarding.

Note When the NbAsciiForwarder is being used there are no additional settings in the forwarding section.

Topological Export

Topological export allows a user to define a scope of objects using a Cisco EMF containment path that will be periodically exported using a configurable output filter.

Specific output filters may also be independently configured via settings passed in the configuration file. In particular, the HP-OEMF export filter has specific settings. These will also be covered in this chapter.

Configuration File Settings

Generic Settings

For topological export, the configuration file section named "exporting" contains the following mandatory and optional sections and settings (some will apply only to the HP-OEMF export filter):

•origin—(mandatory setting), which specifies the origin of the scope of objects that will be exported. The origin should be expressed as an existing path in a containment view. For example, the following fragment defines a valid origin point:
name="ExampleFilter"
exporting
{
    origin="Physical:/US-Region"
}
Note The path specified need not be to a specific node, but may specify just a view name.

•filter—(mandatory setting), specifies the name of the class used to translate topological export data to its final format.

Note This setting may currently only have the value NbHPExporter.

•dump—(optional section), which will in turn contain the settings temp (specifies the output filename for temporary dump files) and result (specifies the final filename for dump output).

If not specified, temp will default to the setting for filter with the extension ".dmp.tmp" and result will default to the setting for filter with the extension ".dmp".

•delta—(optional section), which will in turn contain the settings temp (specifies the output filename for temporary delta files) and result (specifies the final filename for delta output).

If not specified, temp will default to the setting for filter with the extension ".dlt.tmp" and result will default to the setting for filter with the extension ".dlt".

HP-OEMF Specific Settings

The HP-OEMF filter supports the following extra settings in the export section of the configuration file:

•config—specifies the full UNIX path to the file containing mappings from Cisco EMF platform classes to HP-OEMF classes.

Topological Export Usage

Exporting topological data has three distinct phases:

1. filter registration,

2. initial dump, followed by

3. subsequent deltaing.

The initial dump must be performed after a filter is first registered and the output will be placed in either the default location or in the location specified in the configuration file.

Subsequent delta files will be produced to the same location each time the delta command is invoked on the filter. This means it is the responsibility of the delta command invoker to ensure that the delta file is picked up at the correct time and processed before it is overwritten by another delta.

The example command lines in the following sections assume that the Cisco EMF platform is installed in the directory "/opt/platform" and that all commands are issued in the context of a Cisco EMF shell.

Note Faults will not be forwarded from a filter until objects have been output by either dumping or delta-dumping. Hence, even if topological data is not being used by an external system, the initial dump and periodic delta dumps must still be invoked.

Registering a Filter

A filter is registered as follws:
/opt/platform/bin/nbadmin register /opt/myConfig/myFilter.nbf
This command will cause the topological export and forwarding filters specified in the file "/opt/myConfig/myFilter.nbf" to be loaded into the backend.

Terminal output from successful completion of this command would look like:
/opt/cemf/bin/nb/hpfilter.nbf:ok
Terminal output from unsuccessful completion of this command would look like:
/opt/cemf/bin/nb/ahpfilter.nbf:failed
Note It is important to realize that filters are registered persistently. This means that if the platform is stopped for any reason they will be re-registered.

Triggering a Dump

Assuming that a filter is loaded named "myFilter", the command to cause a topological dump to be produced by the filter is:
nbadmin command dump myFilter.
Terminal output from successful completion of this command would look like:
myFilter:dump:dump completed
Terminal output from unsuccessful completion of this command would look like:
myFilter:not a filter
Triggering a Delta

Assuming that a filter is loaded named "myFilter", the command to cause a topological delta to be produced by the filter is:
nbadmin command dump myFilter.
Terminal output from successful completion of this command would look like:
myFilter:delta:dump completed
Terminal output from unsuccessful completion of this command would look like:
myFilter:not a filter
Fault Forwarding

Global Configuration Sections and Settings

Fault forwarding may be influenced by two sets of parameters from the configuration file:

•Global sections and settings, which can affect the faults that will be passed to a specific forwarding filter.

•Filter specific settings that may, for example, affect the destination of a generated SNMP trap or the format of an ASCII log file.

This section details the global sections and settings that exist. Those of the forwarding filters distributed with the base product will be described in subsequent sections.

For fault forwarding, the configuration file section named "forwarding" contains the following global mandatory and optional sections and settings:

•filter (mandatory setting), specifies the name of the class used to forward Cisco EMF faults.

Note This setting may currently only have either the value NbSNMPForwarder or NbAsciiForwarder.

•added_aqs—(optional section), which allows the user to specify a filter on newly added faults. It may have the following settings:

–severity—a multi-value parameter which may be set to values of fault severities to filter in to the alarms output by a forwarding filter. The default valid severities are "informational", "normal", "minor", "major" and "critical". These may be dynamically added to.

–statusFlag—a multi-value parameter which may be set to the values of fault statuses to filter in to the faults output by a forwarding filter. The valid statuses are: "active", "cleared", "acknowledged" and "unacknowledged".

The default setting is for only faults of status "active" to be forwarded, with no filtering based on severity.

•changed_aqs—(optional section), which allows the user to specify a filter on changed faults. It may have the following settings:

–severity—same values as in section added_aqs.

–statusFlag—same values as in section added_aqs.

The default setting is for only faults of status "cleared" to be forwarded, with no filtering based on severity.

NbSNMPForwarder

This section describes the functionality and configuration of the forwarding filter for generating SNMP traps.

Functionality

NbSNMPForwarder generates two variants of SNMPv1 traps that each have the following varbinds:

•accessVisionEventSeverity—textual representation of the severity of the platform fault.

•accessVisionEventTimestamp—textual representation of the time at which the platform became aware of the fault.

•accessVisionEventDescription—textual description of the fault.

•accessVisionEventOriginDomain—textual representation of the source domain of the fault. This may have one of the following values:

–"SNMP"—fault was sourced from a SNMP trap originally.

–"Internal"—fault was generated internally by the platform, perhaps as the result, for example, of a threshold breach detected by polling.

•accessVisionEventSourceObject - name of the object as used by the corresponding topological export filter.

•accessVisionEventSourceObjectClass - name of the class of the managed object the fault was raised on. This is the Cisco EMF class.

•accessVisionEventIdUpper—unsigned integer with the upper 32 bits of the fault identifier, used to uniquely identify the fault to Cisco EMF.

•accessVisionEventIdLower—unsigned integer with the lower 32 bits of the fault identifier, used to uniquely identify the fault to Cisco EMF.

Any trap generated by the NbSNMPForwarder will have a generic id of 6, signifying that it is an enterprise specific.

Traps representing newly raised faults will have a specific id of 1, while traps representing faults now cleared will have a generic id of 2.

The fields accessVisionEventIdUpper and accessVisionEventIdLower may be used by receiving applications to correlate the two varieties of traps.

Specific Settings

When the NbSNMPForwarder is being used, the following additional settings in the forwarding section are used:

•snmp-destination—(mandatory setting), defines the IP address of the destination for traps in dotted notation.

•snmp-port—(optional setting), defines the target port for traps at the address specified in the destination. The default value is "162".

•enterprise—(optional setting), defines the enterprise that will be placed in the traps generated. The default used is "1.3.6.1.4.1.1469.6".

Note The format of traps generated by the filter NbSNMPForwarder is appropriate for HP-OEMF. However, it may also useful to other trap processing applications.

NbAsciiForwarder

The NbAsciiForwarder provides the ability to log the information that is provided in the traps of the NbSNMPForwarder to a flat file.

Specific Settings

•file-destination—(optional setting) The default is set to a file alarms0000.log in the /tmp directory.

Note This directory is volatile. If the machine restarts all the files inside the directory will be lost. It is therefore desirable that the user set the destination to another directory.

•file-linenumber-roller—this is the maximum number of lines the log file will grow to before a new log is created. The log file has an incremented counter in the filename, for example if the default file /tmp/alarms0000.log reaches the default maximum of one thousand lines, a new file /tmp/alarms0001.log is used.

Ancillary Information

This chapter contains details on the to HP-OEMF class mapping file and the MIB defining the traps generated by the default SNMP forwarding filter.

HP-OEMF Class Mapping File

Role of the Class Mapping File

The class mapping file defines the mappings from Cisco EMF managed object classes to HP-OEMF managed object classes. This mapping file must be present for the HP-OEMF topological export filter to function correctly.

If classes in the Cisco EMF model are not present in the mapping file but are used in the exported hierarchy, incorrect dump and delta files will be produced.

File Format

The class mapping file is in ASCII format and has start and end delimiters with a record based structure between.

The start delimiter is:
OEMBEGIN
The end delimiter is:
OEMEND
The fields of a record are:

•BEGINREC—record start delimiter.

•PRESENT—whether or not the class of object should be exported. The following settings are valid:

–"Yes"—output a record for this class of object.

–"No"—do not output a record for this class of object.

•MOCTYPE—HP-OEMF specific field, usually set to "NW". Please see HP-OEMF manuals for further details.

•MOCAVCLASS—the Cisco EMF class this record refers to.

•MOCOUTPUT—the HP-OEMF class that will be written out by the filter.

•MOISTR—the output format of the string that will be inserted in the HP-OEMF managed object path. It may embed the following special identifiers to parameterize this string:

–%<name>—embeds the name of the Cisco EMF object in the output string.

•PREFIX—arbitrary string the will be prefixed to the paths of managed objects exported.

•ENDREC—record end delimiter.

Example File

For reference, a full example file is presented here:
OEMBEGIN 
BEGINREC 
PRESENT      Yes 
MOCTYPE      NW 
MOCAVCLASS   cisco90iSite 
MOCOUTPUT    Cisco90iSite 
MOISTR       Site-id=%<name> 
PREFIX       /network-id=Telia 
ENDREC 
BEGINREC 
PRESENT      No 
MOCTYPE      NE 
MOCAVCLASS   cisco90iAgent 
MOCOUTPUT    Cisco90iAgent 
MOISTR       Agent-id=%<name> 
PREFIX       /network-id=Telia 
ENDREC 
BEGINREC 
PRESENT      No 
MOCTYPE      NE 
MOCAVCLASS   cisco90iUnit 
MOCOUTPUT    Cisco90iUnit 
MOISTR       Unit-id=%<name> 
PREFIX       /network-id=Telia 
ENDREC 
BEGINREC 
PRESENT      No 
MOCTYPE      NE 
MOCAVCLASS   cisco90iBank 
MOCOUTPUT    Cisco90iBank 
MOISTR       Bank-id=%<name> 
PREFIX       /network-id=Telia 
ENDREC 
BEGINREC 
PRESENT      Yes 
MOCTYPE      CP 
MOCAVCLASS   cisco90iPort 
MOCOUTPUT    Cisco90iPort 
MOISTR       Port-id=%<name> 
PREFIX       /network-id=Telia 
ENDREC 
OEMEND 
Trap MIB
-- Atlantech Technologies Ltd
-- Atlantech Event Trap MIB
--
-- This document contains propriety information of Atlantech Technologies
-- Ltd. and is not to be disclosed, reproduced, or published without the
-- express written consent of Atlantech Technologies Ltd.
--
-- Atlantech Technologies Ltd.,
-- 3 Carradale Crescent,
-- Broadwood Business Park,
-- Cumbernauld, 
-- Glasgow,
-- G68 9LE,
-- Tel +44 (0)1236 737393
-- Fax +44 (0)1236 458366
AccessVisionEventTrap-mib DEFINITIONS ::= BEGIN
IMPORTS
    enterprises    FROM  RFC1155-SMI
    OBJECT-TYPE    FROM  RFC-1212
    DisplayString  FROM  RFC1213-MIB
    TRAP-TYPE      FROM  RFC-1215
    Unsigned32     FROM  SNMPv2-SMI
    atlantech      FROM  Atlantech-mib;
--
-- This MIB defines an object identifier for Access Vision events.
-- 
accessVisionEventTrap OBJECT IDENTIFIER ::= { atlantech 6 }
accessVisionEventSeverity OBJECT-TYPE
    SYNTAX DisplayString
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
        "Event severity."
::= { accessVisionEventTrap 1 }
accessVisionEventTimestamp OBJECT-TYPE
    SYNTAX DisplayString
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
        "Time stamp of event. Format is HH:MM:SS DD/MM/YYYY"
::= { accessVisionEventTrap 2 }
--
-- This is a text description of event which will uniquely 
-- identify it & will contain values for any relevant params.
--
accessVisionEventDescription OBJECT-TYPE
    SYNTAX DisplayString
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
        "Textual description of event."
::= { accessVisionEventTrap 3 }
accessVisionEventOriginDomain OBJECT-TYPE
    SYNTAX DisplayString
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
        "Identity of subsystem which raised event."
::= { accessVisionEventTrap 4 }
--
-- Identifies the source object for the event using the
-- same distinguished name for the object as the object model
--
accessVisionEventSourceObject OBJECT-TYPE
    SYNTAX DisplayString
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
        "Source object of event."
::= { accessVisionEventTrap 5 }
accessVisionEventID OBJECT-TYPE
    SYNTAX INTEGER	
    ACCESS read-only
    STATUS deprecated
    DESCRIPTION
        "Unique event identifier."
::= { accessVisionEventTrap 6 }
accessVisionEventSourceObjectClass OBJECT-TYPE
    SYNTAX DisplayString	
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
        "The object class of the source object for the event."
::= { accessVisionEventTrap 7 }
accessVisionEventIdUpper OBJECT-TYPE
    SYNTAX Unsigned32	
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
        "Unique event identifier (Upper 32 bits)"
::= { accessVisionEventTrap 8 }
accessVisionEventIdLower OBJECT-TYPE
    SYNTAX Unsigned32	
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
        "Unique event identifier (Lower 32 bits)"
::= { accessVisionEventTrap 9 }
--
-- Event trap for raised events.
--
EventRaiseTrap  TRAP-TYPE
    ENTERPRISE accessVisionEventTrap
    VARIABLES {
        accessVisionEventSeverity,
        accessVisionEventTimestamp,
        accessVisionEventDescription,
        accessVisionEventOriginDomain,
        accessVisionEventSourceObject,
        accessVisionEventSourceObjectClass,
        accessVisionEventIdUpper,
        accessVisionEventIdLower
    }
    DESCRIPTION
        "Access Vision Event Raised Trap."
::= 1
--
-- Event trap for cleared events.
--
EventClearTrap  TRAP-TYPE
    ENTERPRISE accessVisionEventTrap
    VARIABLES {
        accessVisionEventSeverity,
        accessVisionEventTimestamp,
        accessVisionEventDescription,
        accessVisionEventOriginDomain,
        accessVisionEventSourceObject,
        accessVisionEventSourceObjectClass,
        accessVisionEventIdUpper,
        accessVisionEventIdLower
    }
    DESCRIPTION
        "Access Vision Event Cleared Trap."
::= 2
END

	Cisco Element Manager System Installation and Configuration Guide, 3.1
	Northbound Event Interface
Cisco Element Manager System Installation and Configuration Guide, 3.1 About This Guide Installation Checklist Cisco EMF Configuration Options License Requirements ObjectStore Installation Options Administering Cisco EMF Workstations Upgrading Cisco EMF Installing and Deinstalling Element Managers Deinstalling Cisco EMF Installing and Deinstalling a Patch Cisco EMF Database Backup and Restore Procedures Access Control Auto Discovery Performance Data Storage Creating a New Thresholding Regime Using the Command Line Interface Northbound Event Interface Troubleshooting	Download this chapter Northbound Event Interface Table Of Contents Northbound Event Interface Configuration Overview nbadmin Tool help list register deregister check command run exit Configuration File Format Required Configuration File Entries Topological Export Configuration File Settings Generic Settings HP-OEMF Specific Settings Topological Export Usage Registering a Filter Triggering a Dump Triggering a Delta Fault Forwarding Global Configuration Sections and Settings NbSNMPForwarder Functionality Specific Settings NbAsciiForwarder Specific Settings Ancillary Information HP-OEMF Class Mapping File Role of the Class Mapping File File Format Example File Trap MIB Northbound Event Interface The Northbound Event Interface for the Cisco EMF platform is designed to allow integration with higher level systems such as fault management platforms, for example HP-OEMF. To provide this integration, the Northbound Event Interface provides two main areas of functionality: •Configurable topological export, to allow the external system to build its own model of the managed objects within Cisco EMF. •Configurable Cisco EMF fault forwarding. The current release of the Northbound Event Interface supports the following topological export and fault forwarding modules: –ASCII topological export file in a format compatible with HP-OEMF 4.0. –SNMP traps generated from Cisco EMF faults with information suitable for HP-OEMF 4.0. –ASCII logs generated from Cisco EMF faults with information similar to that presented by the standard Cisco EMF event browser. Configuration Overview This chapter presents an overview of the tool used to configure the Northbound Event Interface and the format of the files used by the configuration tool. nbadmin Tool The Northbound Event Interface is configured using the command line tool nbadmin. This tool should always be run within a Cisco EMF shell to ensure that its runtime environment is properly setup. This tool should always be run on the Cisco EMF server machine and all file pathnames passed to it should be valid on the Cisco EMF server. The format of a nbadmin invocation is as follows: nbadmin <operation> <operation-parameters> The operations that may be used and any parameters appropriate to them are documented in the following sections. help Display usage guidelines for nbadmin. list List all registered filters. register The parameters to this operation are the filenames of configuration files for filters to create. Each of the files specified will be read in turn and the results returned. Note The filenames must be fully specified UNIX paths. Relative paths are not allowed. deregister The parameters to this operation are the names of filters to be removed from the interface. This command will stop both topological change recording and fault forwarding. Note The names passed to this command are not the same as the filenames passed to the register command but are the names of the filters specified within the configuration file. check The parameters to this operation are the names of filters. Their existence will be confirmed or denied by the output of this command. command The first parameter to this operation is the name of the command to be invoked. Subsequent parameters will be passed to the implementation of the command. The default commands supported by the Northbound Event Interface are: •dump—where the parameters passed to it are the names of the topological filters to trigger a topological dump from. •delta—where the parameters passed to it are the names of the topological filters to trigger a topological delta from. run The parameter to this operation is the name of a file containing a sequence of commands and parameters. Each command should be separated by a new line. The script should be terminated by the exit command. exit If nbadmin is in script reading mode, it will exit back to the first run command reached, either back to the nbadmin command line, back to the run command embedded in a script, or back to the shell from which nbadmin was invoked. Configuration File Format An example of the file format for configuration of both topological export and forwarding filters is shown in the example below: name="SomeArbitraryName" section1 { inner_section { settingA="value" } settingB="anotherValue" } section2 { settingA="valueA" settingB="valueB" settingC="valueC" } Note The example does not represent an actual configuration file, just the format used. The file format also supports multiple values for a key. For example: settings { param="value1" param="value2" param="value3" } The data in the configuration files are made available to the topological export and fault forwarding filters to allow them to configure themselves. Required Configuration File Entries There are some entries which are required in the configuration file for filters to work successfully. Each configuration file must specify a name for the filter outside of any section. For example: name="myFilter" Each name must be unique. The filter cannot be installed if the name clashes with a filter already installed. If the filter is to support either topological exporting or fault forwarding, it must contain a section named "exporting". The contents of this section are described in Topological Export. If the filter is to support fault forwarding, it must contain a section named "forwarding". The contents of this section are described in Fault Forwarding. Note When the NbAsciiForwarder is being used there are no additional settings in the forwarding section. Topological Export Topological export allows a user to define a scope of objects using a Cisco EMF containment path that will be periodically exported using a configurable output filter. Specific output filters may also be independently configured via settings passed in the configuration file. In particular, the HP-OEMF export filter has specific settings. These will also be covered in this chapter. Configuration File Settings Generic Settings For topological export, the configuration file section named "exporting" contains the following mandatory and optional sections and settings (some will apply only to the HP-OEMF export filter): •origin—(mandatory setting), which specifies the origin of the scope of objects that will be exported. The origin should be expressed as an existing path in a containment view. For example, the following fragment defines a valid origin point: name="ExampleFilter" exporting { origin="Physical:/US-Region" } Note The path specified need not be to a specific node, but may specify just a view name. •filter—(mandatory setting), specifies the name of the class used to translate topological export data to its final format. Note This setting may currently only have the value NbHPExporter. •dump—(optional section), which will in turn contain the settings temp (specifies the output filename for temporary dump files) and result (specifies the final filename for dump output). If not specified, temp will default to the setting for filter with the extension ".dmp.tmp" and result will default to the setting for filter with the extension ".dmp". •delta—(optional section), which will in turn contain the settings temp (specifies the output filename for temporary delta files) and result (specifies the final filename for delta output). If not specified, temp will default to the setting for filter with the extension ".dlt.tmp" and result will default to the setting for filter with the extension ".dlt". HP-OEMF Specific Settings The HP-OEMF filter supports the following extra settings in the export section of the configuration file: •config—specifies the full UNIX path to the file containing mappings from Cisco EMF platform classes to HP-OEMF classes. Topological Export Usage Exporting topological data has three distinct phases: 1. filter registration, 2. initial dump, followed by 3. subsequent deltaing. The initial dump must be performed after a filter is first registered and the output will be placed in either the default location or in the location specified in the configuration file. Subsequent delta files will be produced to the same location each time the delta command is invoked on the filter. This means it is the responsibility of the delta command invoker to ensure that the delta file is picked up at the correct time and processed before it is overwritten by another delta. The example command lines in the following sections assume that the Cisco EMF platform is installed in the directory "/opt/platform" and that all commands are issued in the context of a Cisco EMF shell. Note Faults will not be forwarded from a filter until objects have been output by either dumping or delta-dumping. Hence, even if topological data is not being used by an external system, the initial dump and periodic delta dumps must still be invoked. Registering a Filter A filter is registered as follws: /opt/platform/bin/nbadmin register /opt/myConfig/myFilter.nbf This command will cause the topological export and forwarding filters specified in the file "/opt/myConfig/myFilter.nbf" to be loaded into the backend. Terminal output from successful completion of this command would look like: /opt/cemf/bin/nb/hpfilter.nbf:ok Terminal output from unsuccessful completion of this command would look like: /opt/cemf/bin/nb/ahpfilter.nbf:failed Note It is important to realize that filters are registered persistently. This means that if the platform is stopped for any reason they will be re-registered. Triggering a Dump Assuming that a filter is loaded named "myFilter", the command to cause a topological dump to be produced by the filter is: nbadmin command dump myFilter. Terminal output from successful completion of this command would look like: myFilter:dump:dump completed Terminal output from unsuccessful completion of this command would look like: myFilter:not a filter Triggering a Delta Assuming that a filter is loaded named "myFilter", the command to cause a topological delta to be produced by the filter is: nbadmin command dump myFilter. Terminal output from successful completion of this command would look like: myFilter:delta:dump completed Terminal output from unsuccessful completion of this command would look like: myFilter:not a filter Fault Forwarding Global Configuration Sections and Settings Fault forwarding may be influenced by two sets of parameters from the configuration file: •Global sections and settings, which can affect the faults that will be passed to a specific forwarding filter. •Filter specific settings that may, for example, affect the destination of a generated SNMP trap or the format of an ASCII log file. This section details the global sections and settings that exist. Those of the forwarding filters distributed with the base product will be described in subsequent sections. For fault forwarding, the configuration file section named "forwarding" contains the following global mandatory and optional sections and settings: •filter (mandatory setting), specifies the name of the class used to forward Cisco EMF faults. Note This setting may currently only have either the value NbSNMPForwarder or NbAsciiForwarder. •added_aqs—(optional section), which allows the user to specify a filter on newly added faults. It may have the following settings: –severity—a multi-value parameter which may be set to values of fault severities to filter in to the alarms output by a forwarding filter. The default valid severities are "informational", "normal", "minor", "major" and "critical". These may be dynamically added to. –statusFlag—a multi-value parameter which may be set to the values of fault statuses to filter in to the faults output by a forwarding filter. The valid statuses are: "active", "cleared", "acknowledged" and "unacknowledged". The default setting is for only faults of status "active" to be forwarded, with no filtering based on severity. •changed_aqs—(optional section), which allows the user to specify a filter on changed faults. It may have the following settings: –severity—same values as in section added_aqs. –statusFlag—same values as in section added_aqs. The default setting is for only faults of status "cleared" to be forwarded, with no filtering based on severity. NbSNMPForwarder This section describes the functionality and configuration of the forwarding filter for generating SNMP traps. Functionality NbSNMPForwarder generates two variants of SNMPv1 traps that each have the following varbinds: •accessVisionEventSeverity—textual representation of the severity of the platform fault. •accessVisionEventTimestamp—textual representation of the time at which the platform became aware of the fault. •accessVisionEventDescription—textual description of the fault. •accessVisionEventOriginDomain—textual representation of the source domain of the fault. This may have one of the following values: –"SNMP"—fault was sourced from a SNMP trap originally. –"Internal"—fault was generated internally by the platform, perhaps as the result, for example, of a threshold breach detected by polling. •accessVisionEventSourceObject - name of the object as used by the corresponding topological export filter. •accessVisionEventSourceObjectClass - name of the class of the managed object the fault was raised on. This is the Cisco EMF class. •accessVisionEventIdUpper—unsigned integer with the upper 32 bits of the fault identifier, used to uniquely identify the fault to Cisco EMF. •accessVisionEventIdLower—unsigned integer with the lower 32 bits of the fault identifier, used to uniquely identify the fault to Cisco EMF. Any trap generated by the NbSNMPForwarder will have a generic id of 6, signifying that it is an enterprise specific. Traps representing newly raised faults will have a specific id of 1, while traps representing faults now cleared will have a generic id of 2. The fields accessVisionEventIdUpper and accessVisionEventIdLower may be used by receiving applications to correlate the two varieties of traps. Specific Settings When the NbSNMPForwarder is being used, the following additional settings in the forwarding section are used: •snmp-destination—(mandatory setting), defines the IP address of the destination for traps in dotted notation. •snmp-port—(optional setting), defines the target port for traps at the address specified in the destination. The default value is "162". •enterprise—(optional setting), defines the enterprise that will be placed in the traps generated. The default used is "1.3.6.1.4.1.1469.6". Note The format of traps generated by the filter NbSNMPForwarder is appropriate for HP-OEMF. However, it may also useful to other trap processing applications. NbAsciiForwarder The NbAsciiForwarder provides the ability to log the information that is provided in the traps of the NbSNMPForwarder to a flat file. Specific Settings •file-destination—(optional setting) The default is set to a file alarms0000.log in the /tmp directory. Note This directory is volatile. If the machine restarts all the files inside the directory will be lost. It is therefore desirable that the user set the destination to another directory. •file-linenumber-roller—this is the maximum number of lines the log file will grow to before a new log is created. The log file has an incremented counter in the filename, for example if the default file /tmp/alarms0000.log reaches the default maximum of one thousand lines, a new file /tmp/alarms0001.log is used. Ancillary Information This chapter contains details on the to HP-OEMF class mapping file and the MIB defining the traps generated by the default SNMP forwarding filter. HP-OEMF Class Mapping File Role of the Class Mapping File The class mapping file defines the mappings from Cisco EMF managed object classes to HP-OEMF managed object classes. This mapping file must be present for the HP-OEMF topological export filter to function correctly. If classes in the Cisco EMF model are not present in the mapping file but are used in the exported hierarchy, incorrect dump and delta files will be produced. File Format The class mapping file is in ASCII format and has start and end delimiters with a record based structure between. The start delimiter is: OEMBEGIN The end delimiter is: OEMEND The fields of a record are: •BEGINREC—record start delimiter. •PRESENT—whether or not the class of object should be exported. The following settings are valid: –"Yes"—output a record for this class of object. –"No"—do not output a record for this class of object. •MOCTYPE—HP-OEMF specific field, usually set to "NW". Please see HP-OEMF manuals for further details. •MOCAVCLASS—the Cisco EMF class this record refers to. •MOCOUTPUT—the HP-OEMF class that will be written out by the filter. •MOISTR—the output format of the string that will be inserted in the HP-OEMF managed object path. It may embed the following special identifiers to parameterize this string: –%<name>—embeds the name of the Cisco EMF object in the output string. •PREFIX—arbitrary string the will be prefixed to the paths of managed objects exported. •ENDREC—record end delimiter. Example File For reference, a full example file is presented here: OEMBEGIN BEGINREC PRESENT Yes MOCTYPE NW MOCAVCLASS cisco90iSite MOCOUTPUT Cisco90iSite MOISTR Site-id=%<name> PREFIX /network-id=Telia ENDREC BEGINREC PRESENT No MOCTYPE NE MOCAVCLASS cisco90iAgent MOCOUTPUT Cisco90iAgent MOISTR Agent-id=%<name> PREFIX /network-id=Telia ENDREC BEGINREC PRESENT No MOCTYPE NE MOCAVCLASS cisco90iUnit MOCOUTPUT Cisco90iUnit MOISTR Unit-id=%<name> PREFIX /network-id=Telia ENDREC BEGINREC PRESENT No MOCTYPE NE MOCAVCLASS cisco90iBank MOCOUTPUT Cisco90iBank MOISTR Bank-id=%<name> PREFIX /network-id=Telia ENDREC BEGINREC PRESENT Yes MOCTYPE CP MOCAVCLASS cisco90iPort MOCOUTPUT Cisco90iPort MOISTR Port-id=%<name> PREFIX /network-id=Telia ENDREC OEMEND Trap MIB -- Atlantech Technologies Ltd -- Atlantech Event Trap MIB -- -- This document contains propriety information of Atlantech Technologies -- Ltd. and is not to be disclosed, reproduced, or published without the -- express written consent of Atlantech Technologies Ltd. -- -- Atlantech Technologies Ltd., -- 3 Carradale Crescent, -- Broadwood Business Park, -- Cumbernauld, -- Glasgow, -- G68 9LE, -- Tel +44 (0)1236 737393 -- Fax +44 (0)1236 458366 AccessVisionEventTrap-mib DEFINITIONS ::= BEGIN IMPORTS enterprises FROM RFC1155-SMI OBJECT-TYPE FROM RFC-1212 DisplayString FROM RFC1213-MIB TRAP-TYPE FROM RFC-1215 Unsigned32 FROM SNMPv2-SMI atlantech FROM Atlantech-mib; -- -- This MIB defines an object identifier for Access Vision events. -- accessVisionEventTrap OBJECT IDENTIFIER ::= { atlantech 6 } accessVisionEventSeverity OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "Event severity." ::= { accessVisionEventTrap 1 } accessVisionEventTimestamp OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "Time stamp of event. Format is HH:MM:SS DD/MM/YYYY" ::= { accessVisionEventTrap 2 } -- -- This is a text description of event which will uniquely -- identify it & will contain values for any relevant params. -- accessVisionEventDescription OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "Textual description of event." ::= { accessVisionEventTrap 3 } accessVisionEventOriginDomain OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "Identity of subsystem which raised event." ::= { accessVisionEventTrap 4 } -- -- Identifies the source object for the event using the -- same distinguished name for the object as the object model -- accessVisionEventSourceObject OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "Source object of event." ::= { accessVisionEventTrap 5 } accessVisionEventID OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS deprecated DESCRIPTION "Unique event identifier." ::= { accessVisionEventTrap 6 } accessVisionEventSourceObjectClass OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "The object class of the source object for the event." ::= { accessVisionEventTrap 7 } accessVisionEventIdUpper OBJECT-TYPE SYNTAX Unsigned32 ACCESS read-only STATUS mandatory DESCRIPTION "Unique event identifier (Upper 32 bits)" ::= { accessVisionEventTrap 8 } accessVisionEventIdLower OBJECT-TYPE SYNTAX Unsigned32 ACCESS read-only STATUS mandatory DESCRIPTION "Unique event identifier (Lower 32 bits)" ::= { accessVisionEventTrap 9 } -- -- Event trap for raised events. -- EventRaiseTrap TRAP-TYPE ENTERPRISE accessVisionEventTrap VARIABLES { accessVisionEventSeverity, accessVisionEventTimestamp, accessVisionEventDescription, accessVisionEventOriginDomain, accessVisionEventSourceObject, accessVisionEventSourceObjectClass, accessVisionEventIdUpper, accessVisionEventIdLower } DESCRIPTION "Access Vision Event Raised Trap." ::= 1 -- -- Event trap for cleared events. -- EventClearTrap TRAP-TYPE ENTERPRISE accessVisionEventTrap VARIABLES { accessVisionEventSeverity, accessVisionEventTimestamp, accessVisionEventDescription, accessVisionEventOriginDomain, accessVisionEventSourceObject, accessVisionEventSourceObjectClass, accessVisionEventIdUpper, accessVisionEventIdLower } DESCRIPTION "Access Vision Event Cleared Trap." ::= 2 END
	© 1992-2008 Cisco Systems, Inc. All rights reserved. Terms & Conditions \| Privacy Statement \| Cookie Policy \| Trademarks of Cisco Systems, Inc.