Table Of Contents

Northbound Event Interface

NEI Overview

What is NEI?

How Does NEI Work?

What Are the Processes Involved?

Planning Which Filters to Use

Export Filters

Forward Filters

Recommended Filter Usage

Prerequisite for CIC Users Only

Creating Filter Files

Filter File Names

Filter File Parameters

Sample Filter Files

Export Filters

Forward Filters

Using the nbadmin Tool

Registering Filters

Dumping Topology

Managing Filters

Making Changes to an Existing Filter

Managing Alarms Using the nbadmin Tool

nbadminTool Messages

Northbound Event Interface

---

The Northbound Event Interface (NEI) allows for integration with network management systems (NMSs), such as Hewlett Packard-OpenView Element Management Framework (HP-OEMF) and CIC (Cisco Information Center). Using NEI, you can export topological information about managed objects and forwardCisco EMF events to NMSs.

This chapter contains the following information:

•NEI Overview

•Planning Which Filters to Use

•Prerequisite for CIC Users Only

•Creating Filter Files

•Using the nbadmin Tool

NEI Overview

This section contains the following information:

•What is NEI?

•How Does NEI Work?

•What Are the Processes Involved?

What is NEI?

The main purpose of NEI is to convert Cisco EMF events (appearing in the Event Browser) to a particular output for NMSs. Output can be in the form of an SNMP trap, log files, or TCP connections.

NEI has two main functions: exporting and forwarding. To define export and forward filters, you can create a filter file that will contain both types of information.

How Does NEI Work?

Events come into NEI in different forms and from different sources, as follows:

•Traps can be sent from network elements

•Events can be sent from EMs, as a result of presence polling

•Events can be sent from the thresholding processes, which scan for out of bounds statistics

Once an event (or trap) is generated, the event is passed through the PreFilter application. After the event is filtered, it moves into the Alarm Database Storage, and is then passed on to the Event Browser and NEI. NEI then scopes and filters the event. The export function within NEI scopes the event to be sure the origin matches as specified in the filter file. If the origin does not match, the process terminates. If the origin does match, it goes on to be filtered by the forwarding function within NEI. The forwarding function ensures that the severity and status parameters match the parameters set in the filter file. If the parameters do not match, the process terminates. If the parameters do match, the event is then sent to the NMS, where the operator can view the event.

Figure 16-1 How does NEI Work?

What Are the Processes Involved?

The following steps outline the NEI processes you need to perform.

1. Planning Which Filters to Use

2. Creating Filter Files

3. Registering Filters

4. Dumping Topology

5. Managing Filters

Planning Which Filters to Use

There are two classes of filters:

•Export Filters

•Forward Filters

Export Filters

There are three types of export filters:

•NbHPExporter—Exports topology data in HP-OEMF format

•NbNullExporter—Does not export any topology data

•NbAsciiExporter—Exports data to a file

Forward Filters

There are four types of forward filters:

•NbExtensibleSNMPForwarder—Forwards event data in SNMP traps

•NbAsciiForwarder—Logs event data into files

•NbAsciiTCPForwarder—Forwards event data to a TCP port

•NbSNMPForwarder—Forwards event data in SNMP traps

---

Note The NbSNMPForwarder will be phased out in the future. It has been retained to ensure compatibility with older deployments.

---

Recommended Filter Usage

The following combinations are recommended for export and forward filters:

Table 16-1 Recommended Export and Forward Filter Combinations

Scenario	Export Filter	Forward Filter
HP-OEMF	NbHPExporter	NbExtensibleSNMPForwarder
NMS can receive traps	NbNullExporter or NbAsciiExporter	NbExtensibleSNMPForwarder
NMS does not receive traps, but does receive event information through a TCP port	NbNullExporter or NbAsciiExporter	NbAsciiTCPForwarder
CIC	NbNullExporter	NbExtensibleSNMPForwarder
If you want to log events into a file	NbNullExporter	NbAsciiForwarder

---

Note The NbExtensibleSNMPForwarder is an upward compatible replacement for the NbSNMPForwarder, which will be phased out in future releases, as the NbExtensibleSNMPForwarder has greater functionality than the NbSNMPForwarder. For information on how to update existing filter files that currently use the NbSNMPForwarder, see Reconfiguring the NbSNMPForwarder.

---

Prerequisite for CIC Users Only

To allow the Cisco EMF Info Mediator to process traps forwarded by NEI, you need to create a new rules file that will map the traps forwarded by NEI to CIC. The rules file defines how the Info Mediators should rationalize or add to the contents of an event to create a meaningful CIC alert. In addition, the rules file creates a unique identifier for each event it acquires.

The CIC version should be 3.4.1 FCS (or later), and the CIC server and Cisco EMF server should be in separate boxes.

The following steps outline how to create a rules file.

---

Step 1 Create a new directory named "nei" on the CIC server, under the following directory:

/opt/Omnibus/probes/solaris2/cisco.includes/mttrapd/

Step 2 Add a new file named "cemfnei.include.rules" under the following directory:

/opt/Omnibus/probes/solaris2/cisco.includes/mttrapd/nei

The following is a sample rules file:

case ".1.3.6.1.4.1.1469.6": ### Atlantech - Cisco CEMF

if (match ($3, "<n/a>"))

{

discard

}

if (regmatch ($3, "Asserted.*"))

{

discard

}

@AlertGroup = $4 + "." + $13

if (match ($13, "linkUp") or match ($13, "linkDown"))

{

@AlertGroup = "linkUpDown"

if (match ($13, "linkUp"))

{

@Type = 2

}

else if (match ($13, "linkDown"))

{

@Type = 1

}

}

@Agent = "Cisco CEMF NEI"

@Class = 10073

@Summary = $3

@AlertKey = $12

@Node = $9

@NEAddress = $10

@Slot = $7 + ":" + $8

## End

@Location = $11

# Set Severity

switch ($1)

{

case "normal":

      @Severity = 0

case "informational":

      @Severity = 1

case "warning":

      @Severity = 2

case "minor":

      @Severity = 3

case "major":

      @Severity = 4

case "critical":

      @Severity = 5

default:

      @Severity = 1

}

switch ($specific-trap)

{

case "1": # EventRaiseTrap

      @Summary = "(Active) " + @Summary

      details($*)

      @Identifier = $1 + $3 + $4 + $5 + $6 + "Active"

case "2": # EventClearTrap

      @Summary = "(Cleared) " + @Summary

      details($*)

      @Identifier = $1 + $3 + $4 + $5 + $6 + "Cleared"

## End

default:

}

Step 3 Add the following line to the rules file include section of the CIC existing file "mttrapd.rules" found under /opt/Omnibus/probes/solaris2:

include

"/opt/Omnibus/probes/solaris2/cisco.includes/mttrapd/nei/cemfnei.include.rules"

---

Creating Filter Files

Create filter file(s) using an editor (for example, vi). Each filter file must begin with a filter name. Each filter file must contain only one exporter and one forwarder. The order of filter types (forwarder or exporter, first or second) is irrelevant.

Note that not all possible parameters are represented in the sample filter file, because different filter types require different parameters.

A sample filter file might appear as follows:

name="myFilter1.nbf"

exporting

{

delta

{

temp="/tmp/filter.delta.tmp"

result="/tmp/filter.delta.result"

}

dump

{

temp="/tmp/filter.dump.tmp"

result="/tmp/filter.dump.result"

}

filter="NbNullExporter"

origin="Physical:/"

}

forwarding

{

filter="NbExtensibleSNMPForwarder"

snmp-destination="1.1.1.1"

snmp-port="162"

enterprise="1.3.6.1.4.1.1469.6"

added_alarms

{

severity="critical"

severity="major"

severity="minor"

}

changed_alarms

{

status="acknowledged"

status="unacknowledged"

}

}

---

Tip All parameters can only contain one value, aside from the added_alarms and changed_alarms parameters, which can contain more than one value.

---

This section contains the following information:

•Filter File Names

•Filter File Parameters

•Sample Filter Files

Filter File Names

The name you choose for the filter file can be any name of your choice. A recommended location for storing the filter file(s) is <CEMF_ROOT>/config/nbfilter. This directory is provided by the NEI application for this purpose, although you may choose to place the filter files in any directory. However, when you place the files under the config directory, they will be included in the Cisco EMF backup.

Filter File Parameters

This section defines all possible filter file parameters. Each filter can have different combinations of these parameters (for details on which parameters are contained within each filter; see Sample Filter Files).

•name—Provide a name for the filter. This name must be unique to ensure correct operation.

•exporting—Can contain the following parameters:

–dump—Dumps all topology. Contains the following parameters:

temp—Specifies the output filename for temporary dump files

result—Specifies the final filename for dump output

–delta—Dumps only the topology changes that have been made since the previous dump. Contains the following parameters:

temp—Specifies the output filename for temporary delta files

result—Specifies the final filename for delta output

---

Tip If not specified, temp defaults to the filter name provided, with the extension .dmp.tmp or .dlt.tmp. Result also defaults to the filter name provided, but with the extension .dmp or .dlt.

---

---

Tip The default directory for these files is /tmp. The contents of the /tmp directory is volatile and is deleted when the machine reboots, so it is recommended that you place the result files in another location, such as <CEMF_ROOT>/config/nb, if these files are retrieved by the NMS.

---

–filter—Defines which exporter you want to use (NbHPExporter, NbNullExporter, or NbAsciiExporter)

–origin—Pathname that contains the managed objects you want to monitor. The pathname is the scope of managed objects that NEI will forward events on to the NMS. You can only specify one origin per filter file. To rename or move the object that is being used as an origin in an active filter, see Renaming or Moving Objects Specified in an Origin.

–config—(applicable only for NbHPExporter) Specifies the full path to the file containing mappings from Cisco EMF classes to HP-OEMF classes

•forwarding—Can contain the following parameters:

–filter—Defines which forwarder you want to use (NbExtensibleSNMPForwarder, NbAsciiForwarder, NbAsciiTCPForwarder, or NbSNMPForwarder)

–file-destination—(applicable only for NbAsciiForwarder) Supply the full path where NEI should write events to. The default file name is /tmp/alarms0000.log.

–file-linenumber-rollover—(applicable only for NbAsciiForwarder) Specifies the maximum number of lines the log file will grow to before a new, incremental log is created. The default value is 1000 lines.

–snmp-destination—(applicable only for SNMP Forwarders) Defines the IP address of the trap destination

–snmp-port—(optional, applicable only for SNMP Forwarders) Defines the target port for traps at the address specified in the destination. The default value is 162.

–enterprise—(optional) Indicates the type of device that is setting traps. The default value is 1.3.6.1.4.1.1469.6, which identifies Cisco EMF as the enterprise agent sending traps.

–tcpForwarder—(applicable only for NbAsciiTCPForwarder) The following parameters are required:

destination-name—Host name or IP address to connect to

destination-port—Port number to connect to

–added_alarms (previously added_aqs)—(optional section) Allows the user to specify a filter on newly added faults. It may have the following settings:

severity—The default valid severities are: informational, normal, minor, major, critical, or warning. You can specify one or more of these severities in your filter file. By default, there is no filtering based on severity, unless otherwise specified.

status—The valid statuses are:active, cleared, acknowledged, and unacknowledged. You can specify one or more of these statuses in your filter file. By default, only faults of active status are forwarded, unless otherwise specified.

---

Note The previous syntax for this parameter was added_aqs. NEI accepts this syntax; however, you will receive a warning message when you register the filter containing this syntax. You should update the syntax in the filter as soon as possible.

---

–changed_alarms (previously changed_aqs)—(optional section) Allows the user to specify a filter on changed faults. It may have the following settings:

severity—(See above for definition.) By default, there is no filtering based on severity, unless otherwise specified.

status—The valid statuses are: cleared, acknowledged, and unacknowledged. You can specify one or more of these statuses in your filter file. By default, only faults of cleared status are forwarded, unless otherwise specified. Note that cleared events will always be forwarded; specifying is only needed if you want to forward events of other statuses.

---

Note The previous syntax for this parameter was changed_aqs. NEI accepts this syntax; however, you will receive a warning message when you register the filter containing this syntax. You should update the syntax in the filter as soon as possible.

---

–containment-tree—(applicable only for NbAsciiForwarder and NbExtensibleSNMPForwarder) Defines which containment tree to use. When an object exits in multiple containment trees, it has a different pathname for each containment tree. You can specify another containment tree other than the pathname specified in origin that the forwarder will use to identify the object.

Sample Filter Files

This section provides specific examples of each filter file, detailing which parameters belong in each different filter.

First choose the type of filter:

•Export Filters

•Forward Filters

Export Filters

Choose from the following types of export filters:

•NbHPExporter

•NbNullExporter

•NbAsciiExporter

NbHPExporter

The NbHPExporter filter file should contain the parameters shown in the example below.

name="hpfilter"

exporting

{

delta

{

temp="/tmp/filter.delta.tmp"

result="/opt/cemf/config/nb/filter.delta.result"

}

dump

{

temp="/tmp/filter.dump.tmp"

result="/opt/cemf/config/nb/filter.dump.result"

}

filter="NbHPExporter"

origin="Physical:/"

config="/opt/cemf/config/hpexportconfig"

}

---

Caution The /tmp directory is volatile and can delete data. You should change this directory.

---

Creating the Class Mapping File

---

Tip For detailed tips on how to create the class mapping file, see Appendix C, "Tips for Creating a Class Mapping File".

---

The class mapping file for the NbHPExporter defines 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 defined in the mapping file but are in the exported hierarchy, those managed object classes will not be exported.

Create the class mapping file using an editor (for example, vi). The class mapping file must be in ASCII format, and should contain the parameters shown in the example below.

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 

The parameters in the class mapping file consist of the following:

•OEMBEGIN—Beginning parameter for OEM (OpenView Element Manager)

•BEGINREC—Start record

•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". See HP-OEMF manuals.

•MOCAVCLASS—Cisco EMF class this record refers to.

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

•MOISTR—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—End record

•OEMEND—End parameter for OEM

NbHPExporter Output

NbHPExporter output looks similar to the following example:

'D'"cre","NE","Cisco90iAgent","/network-id=Telia/Agent-id=C90i1","C90i1"

• 'D'—Stands for a dump or delta record

•"cre"—Means object has been created. Can also be "del" - means object has been deleted

•"NE"—The MOCTYPE from the class mapping file

•"Cisco90iAgent"—The MOCOUTPUT from the class mapping file

•"/network-id=Telia/Agent-id=C90i1"—The full name of the managed object. The name is constructed by putting together the PREFIX and MOISTR from the class mapping file and replacing the %<name> with the simple name of the managed object.

•"C90i1"—The simple name of the managed object

NbNullExporter

The NbNullExporter filter file should contain the parameters shown in the example below:

exporting

{

delta

{

temp="/tmp/filter.delta.tmp"

result="/tmp/filter.delta.result"

}

dump

{

temp="/tmp/filter.dump.tmp"

result="/tmp/filter.dump.result"

}

filter="NbNullExporter"

origin="Physical:/"

}

---

Note Although no topology information is needed for the NMS, you still need to point the temp and result parameters to valid file locations. This location can be within the /tmp directory.

---

NbAsciiExporter

The NbAsciiExporter filter file should contain the parameters shown in the example below.

exporting

{

delta

{

temp="/tmp/filter.delta.tmp"

result="/tmp/filter.delta.result"

}

dump

{

temp="/tmp/filter.dump.tmp"

result="/tmp/filter.dump.result"

}

filter="NbAsciiExporter"

origin="Physical:/"

}

The dump output for the NbAsciiExporter looks similar to the following:

Dump Begins

--------------

(mib2)     /

(region)     Region-2/

(site)     Site-3/

(unixManagerAgent)     unix-3/

(region)     Region-1/

(site)     Site-2/

(unixManagerAgent)     unix-2/

(site)     Site-1/

(unixManagerAgent)     unix-1/

--------------

Dump Ends

Forward Filters

Choose from the following types of forward filters:

•NbExtensibleSNMPForwarder

•NbSNMPForwarder

•NbAsciiForwarder

•NbAsciiTCPForwarder

NbExtensibleSNMPForwarder

The NbExtensibleSNMPForwarder filter file should contain the parameters shown in the example below.

forwarding

{

filter="NbExtensibleSNMPForwarder"

snmp-destination="1.1.1.1"

snmp-port="162"

enterprise="1.3.6.1.4.1.1469.6"

added_alarms

{

severity="critical"

severity="major"

severity="minor"

}

changed_alarms

{

status="acknowledged"

status="unacknowledged"

}

}

NbSNMPForwarder

The NbSNMPForwarder filter file should contain the parameters shown in the example below.

forwarding

{

filter="NbSNMPForwarder"

snmp-destination="1.1.1.1"

snmp-port="162"

enterprise="1.3.6.1.4.1.1469.6"

added_alarms

{

severity="critical"

severity="major"

severity="minor"

}

changed_alarms

{

status="acknowledged"

status="unacknowledged"

}

}

Trap Varbinds

The NbSNMPForwarder and NbExtensibleSNMPForwarder forward traps that contain varbinds. A varbind is a sequence of variable names and corresponding values. This section describes the different varbinds generated by each SNMP forwarder.

The following varbinds apply to both forwarders:

•cemfEventSeverity—Severity of the platform fault

•cemfEventTimestamp—Time at which the platform became aware of the fault

•cemfEventDescription—Fault description

•cemfEventOriginDomain—Source domain of the fault; can 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

•cemfEventSourceObject—Name of the object as used by the corresponding topological export filter

•cemfEventSourceObjectClass—Name of the Cisco EMF class of the managed object the fault was raised on

•cemfEventIdUpper—Unsigned integer with the upper 32 bits of the fault identifier, used to uniquely identify the fault to Cisco EMF

•cemfEventIdLower—Unsigned integer with the lower 32 bits of the fault identifier, used to uniquely identify the fault to Cisco EMF

The following varbinds apply to the NbExtensibleSNMPForwarder only:

•cemfEventNetworkElementName—Name of the network element

•cemfEventIPAddress—IP address of the network element

•cemfEventLocationName—Location in the containment tree of the network element

•cemfEventFaultyEntity—Name of the faulty entity

•cemfEventAlarmClassName—Name of the event class

•cemfEventAlarmCount—Number of times this event has occurred

•cemfEventFaultyEntityType—Faulty entity type. Can be one of the following values:

–Other

–NE

–Chassis

–FRU

–Port

•cemfEventNEClassName—Name of the class of the indicated network element

•cemfEventAlarmDataName—Name of all the attribute(s) included with the event. Can have multiple names, which are always paired with values (see below).

•cemfEventAlarmDataValue—Value of all the attribute(s) included with the event. Can have multiple values, which are always paired with names (see above).

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

Traps representing newly raised faults have a specific ID of 1, while traps representing faults now cleared have a specific ID of 2.Traps representing acknowledged faults have a specific ID of 3.

The fields cemfEventIdUpper and cemfEventIdLower may be used by receiving applications to correlate two varieties of traps, that is, newly raised and cleared faults.

Sample Trap Output

The following is an example of trap output:

"informational"

"Wed Sep  4 13:55:12 EDT 2002"

"Chassis is determining state"

"SNMP" Hex: 53 4E 4D 50

"Physical:/Site-2/CTB3620-10.1.101.1"

"CTBCisco3620Chassis"

Gauge: 258

Gauge: 2737

"CTB3620-10.1.101.1"

"10.1.101.1"

"Physical:/Site-2"

"CTB3620-10.1.101.1"

"ciscoChassisCommissioningAlarm"

NbAsciiForwarder

The NbAsciiForwarder filter file should contain the parameters shown in the example below.

forwarding

{

filter="NbAsciiForwarder"

file-destination="/opt/cemf/logs/alarms"

file-linenumber-rollover="100000"

added_alarms

{

severity="critical"

severity="major"

severity="minor"

}

changed_alarms

{

status="acknowledged"

status="unacknowledged"

}

}

NbAsciiTCPForwarder

The NbAsciiTCPForwarder filter file should contain the parameters shown in the example below.

forwarding

{

filter="NbAsciiTcpForwarder"

tcpForwarder

{

destination-name="my-nms.company.com"

destination-port="10100"

}

added_alarms

{

severity="critical"

severity="major"

severity="minor"

}

changed_alarms

{

status="acknowledged"

status="unacknowledged"

}

}

Ascii Output

Both Ascii-type forwarders (NbAsciiForwarder and NbAsciiTCPForwarder) produce Ascii output. The NbAsciiForwarder writes output to a file; the NbAsciiTCPForwarder writes output to a defined TCP port.

The name and location of Ascii output files and the number of events per file are configurable. When a file reaches its size limit, a new file is created. The files are numbered, starting at 0000.

The following is an example of NbAsciiForwarder and NbAsciiTCPForwarder output:

Id=0x00000102:0x00000020,Severity=critical,State=active/unacknowledged,CommsDomain=SNMP, 
MgmtDomain=Internal,AlarmClass=unixAlarm4,Object=unix-1/,Msg="Specific Trap 4 
received",Time="Fri Mar 15 10:50:18 EST 2002"

The fields can be defined as follows:

•Id—Two 8-digit hex numbers separated by a colon, uniquely identifying the event object

•Severity—Event severity displayed in the Event Browser

•State—State of the event; can be active/unacknowledged, active/acknowledged, cleared/unacknowledged, or cleared/acknowledged

•CommsDomain—Comms domain displayed in the Event Browser

•MgmtDomain—Management domain displayed in the Event Browser

•AlarmClass—Class of the event, as filterable on in the Event Browser

•Object—Distinguished name for the managed object the event was raised or cleared against; the distinguished name format is defined by the topology export filter used

•Msg—Quote delimited message as defined with Cisco EMF event class

•Time—Time the event was stamped with, as displayed in the Event Browser

Using the nbadmin Tool

The nbadmin tool should always be run on the Cisco EMF server machine. All file pathnames passed to the nbadmin tool should be valid on the Cisco EMF server.

The nbadmin command is formatted as follows:

<CEMF_ROOT>/bin/nbadmin <operation> <operation parameters>

Replace <CEMF_ROOT> with the directory where Cisco EMF is installed.

---

Tip You should always run this tool within a Cisco EMF shell to ensure the runtime environment is properly set up.

---

The nbadmin tool allows you to perform the following tasks:

•Registering Filters

•Dumping Topology

•Managing Filters

•Managing Alarms Using the nbadmin Tool

You can also view error messages, which are defined in the following section:

•nbadminTool Messages

Registering Filters

---

Tip The registration process can take some time to complete. During the registration process, any other nbadmin commands issued will not take place until the registration process completes.

---

After you have created file(s) for your filter(s), you need to register the filter(s). To register filter(s), proceed as follows:

Enter the command:

<CEMF_ROOT>/bin/nbadmin register <filter_file_name(s)>

Replace <CEMF_ROOT> with the directory where Cisco EMF is installed. Replace <filter_file_name(s)> with the full path name(s) of the filter file(s) you want to register.

---

Tip Be sure to supply the full path name, or else the process fails.

---

For example, the register command may appear as follows:

<CEMF_ROOT>/bin/nbadmin register /<CEMF_ROOT>/config/nb/myFilter.nbf

Replace <CEMF_ROOT> with the directory where Cisco EMF is installed.

This command exports the information specified in the file /<CEMF_ROOT>/config/nb/myFilter.nbf.

If the command is successful, the following output appears:

/opt/cemf/bin/nb/hpfilter.nbf:ok

If the command is unsuccessful, the following output appears:

/opt/cemf/bin/nb/ahpfilter.nbf:failed

If the registration fails, you should look in the log file for further details. The log file can be found here:

<CEMF_ROOT>/logs/nbinterface.log

Replace <CEMF_ROOT> with the directory where Cisco EMF is installed.

---

Note NEI remembers registered filters even if Cisco EMF is stopped and restarted.

---

Dumping Topology

Once you have registered a filter(s), you need to perform a topology dump. Faults will not be forwarded from a filter until you perform a dump or a delta. If you are using the NbNullExporter, you do not need to perform the initial dump and periodic delta dumps, as these files are not used by the exporter.

---

Tip For definitions of dumps and deltas, see Filter File Parameters.

---

Enter the following command:

<CEMF_ROOT>/bin/nbadmin command <dump or delta> <filter_name>

For example, the register command may appear as follows:

/opt/cemf/bin/nbadmin command dump hpFilter

If the command is successful, the following output appears:

myFilter:<dump or delta>:<dump or delta> completed

If the command is unsuccessful, the following output appears:

myFilter:not a filter

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

Depending on the number of objects that comprise the dump, this operation may take some time to complete.

---

Caution The dump and delta topology files are overwritten each time the commands are ran. This means that at any given time, the dump and delta files will only contain the most recent topology information.

---

---

Tip You can create a cron job to write dump or delta topology at a specified time within a specified interval.

---

Managing Filters

The nbadmin tool also allows you to manage filters by performing the operations outlined below, using the following format:

<CEMF_ROOT>/bin/nbadmin <operation> <operation parameters>

Table 16-2 nbadmin Tool Filter Operations

Operation	Operation Parameter	Description
command	<dump or delta> <filter_name>	Run a dump or delta
register	<filter_file_name(s)>	Registers filter(s).
deregister	<filter_name(s)>	De-register filter(s).
list		Lists all registered filters
check	<filter_name(s)>	Checks for the existence of filter(s)
run	<script_file_name(s)>	Allows you to run a file that contains a "script" or "macro" for frequently run operations. For example, you may want to create a script that will register, check, and list filters.
exit		Exits command mode (nbadmin mode)
help		Displays usage guidelines for nbadmin tool
read		Reads class files

•Replace <filter_name> with the filter name specified in the filter file (name=xxx.xxx).

•Replace <filter_file_name(s)> with the full path name of the filter file(s) you want to perform the operation on.

•Replace <script_file_name(s)> with the full path name of the script file.

---

Tip If you execute nbadmin without any operational parameters, it will run in a shell with nbadmin> as the shell prompt. From here you can execute nbadmin operations.

---

Making Changes to an Existing Filter

If you want to change or stop using an existing filter, perform the following steps:

---

Step 1 De-register the filter you want to change. If you want to stop using this filter, you do not need to proceed any further. If you want to make changes to this filter, proceed on to Step 2.

Step 2 Make changes to the filter file, as desired.

Step 3 Register the amended filter file.

---

Renaming or Moving Objects Specified in an Origin

Within a filter file, there is an origin parameter (for a definition, see Filter File Parameters). If you want to change the name of a Cisco EMF object or you want to move a Cisco EMF object that is mentioned as part of an origin, you will need to modify the object both in Cisco EMF and in your filter file. Modifying the object in both places ensures consistency and accuracy of event forwarding.

---

Step 1 Deregister the filter that contains the origin to be modified.

Step 2 In Cisco EMF, make the desired changes to the object (rename or move the object).

Step 3 In your filter file, make the appropriate changes to the origin parameter, and save the changes.

Step 4 Register the amended filter.

---

Renaming an Object

For example, say you have an origin specified as "Physical:/Site1" and you want to rename Site1 to Site2. You would follow the steps above by doing the following:

---

Step 1 Deregister the filter to be modified.

Step 2 In Cisco EMF, rename Site1 to Site2.

Step 3 Change your origin in the filter file to "Physical:/Site2"

Step 4 Register the amended filter.

---

Moving an Object

For example, say you have an origin specified as "Physical:/Site1:/Chassis1" and you want to move Chassis1 to reside under another site called Site4. You would follow the steps above by doing the following:

---

Step 1 Deregister the filter to be modified.

Step 2 In Cisco EMF, move Chassis1 from Site1 to Site4.

Step 3 Change your origin in the filter file to "Physical:/Site4:/Chassis1"

Step 4 Register the amended filter.

---

Reconfiguring the NbSNMPForwarder

Because the NbSNMPForwarder is being phased out, you may want to implement the NbExtensibleSNMPForwarder instead. To change your existing NbSNMPForwarders into NbExtensibleSNMPForwarders, proceed as follows:

1. Deregister the filter containing the NbSNMPForwarder.

2. In your filter file, rename the filter parameter to the NbExtensibleSNMPForwarder, and save the changes.

3. Register the amended filter.

Managing Alarms Using the nbadmin Tool

The nbadmin tool also allows an operator to manage alarms from a command line interface. Using the commands listed in the following table, you can write automation scripts to manage alarms in Cisco EMF. Use the following format:

<CEMF_ROOT>/bin/nbadmin <operation> <alarm OIDs>

Table 16-3 nbadmin Tool Event Operations

Operation	Operation Parameter	Description
clearalarm	<alarm OIDs>1	Clears alarms
delalarm	<alarm OIDs>	Deletes alarms
ackalarm	<alarm OIDs>	Acknowledges alarms

1 Replace with the corresponding alarm OID(s), provided in the alarm/traps sent by the forwarder. Alarm OIDs can be in the standard 0xUUUUUUUU:0xLLLLLLLL format, where U is the upper portion of the OID in hex, and L is the lower portion of the OID in hex; or in the u:l format, where u is the upper portion of the OID in decimal, and l is the lower portion of the OID in decimal.

The following are examples of the nbadmin command to acknowledge an alarm, the first using hex format and the second decimal format:

nbadmin ackalarm 0x00000102:0x00000001 

nbadmin ackalarm 258:2737

nbadminTool Messages

There are two types of nbadmin tool messages: error messages and informational messages. The following tables provide sample messages and their descriptions.

The following error messages may occur while running an nbadmin command:

Table 16-4 nbadmin Tool Error Messages 

Error Message	Description
myFilter:dump:system temporary lock	System dump already in progress
myFilter:delta:system temporary lock	System delta already in progress
myFilter:delta:delta not available	Delta file unavailable
myFilter:unknown command	Unknown command
no filter file name specified	Incomplete command
<XXX> is an invalid class name	There was an invalid class name in a class file named <XXX>
unable to convert:<XXX> into an object ID	The alarm object ID specified(ackalarm, clearalarm, delalarm) was of an invalid format
unable to clear alarm:<X:Y>	NEI was unable to clear the alarm with ID <X:Y>
unable to acknowledge alarm:<X:Y>	NEI was unable to acknowledge the alarm with ID <X:Y>
unable to delete alarm:<X:Y>	NEI was unable to delete the alarm with ID <X:Y>

The following informational messages may occur while running an nbadmin command:

Table 16-5 nbadmin Tool Informational Messages

Informational Message	Description
class files read successfully	NEI read the class files successfully
no class files read	There were no class files to read
cleared alarm:<X:Y>	Alarm with ID <X:Y> was cleared
acknowledged alarm:<X:Y>	Alarm with ID <X:Y> was acknowledged
deleted alarm:<X:Y>	Alarm with ID <X:Y> was deleted