HP OpenView System Administration Handbook [Electronic resources] : Network Node Manager, Customer Views, Service Information Portal, HP OpenView Operations نسخه متنی

9.4 DEFINING FILTERS

Filters are designed to eliminate clutter on submaps and subsequently reduce the number of objects that are loaded into memory when a map is opened, sent from a collection station to a management station, or that are discovered by netmon. The type of filter (discovery, map, or topology) is determined based on how the filter is implemented. All filters are defined in the file

$OV_CONF/C/filters . Filters are defined using the three building blocks: sets, filters, and filter expressions.

NNM provides a default filters file that can be used when defining filters. Refer to the sample filters file listed in Section 9.4.1, "The Default Filters File." The filters file must contain the following three elements in the following order:

Sets { }

Filters { }

FilterExpressions { }

To define a filter, determine a common attribute for the devices you are interested in capturing.^[4] For example, a common attribute might be all the devices manufactured by a particular vendor. In some cases, you may not be able to capture all the devices with one filter definition. For example, what if you were interested in all devices by the same vendor or devices that include the network or segment attribute? You may also encounter a list of hostnames or IP addresses that have no common attribute. A set allows you to define lists of hostnames and IP address ranges. Listed are some examples used in the default filters file:

^[4] Object attributes may be listed typing ovobjprint -s selectionName from the command line. SelectionName is name of the object in the database. If necessary, use ovtopodump -L to list all objects in the topology database. Object attributes may also be obtained from the NNM GUI by right clicking the symbol, selecting Object Properties… and viewing the Capabilities, General Attributes, or IP Map attributes of the object.

1. Devices made by Hewlett-Packard. These reside in the filters section of the filter file.

   
   HPNodes "Hewlett-Packard nodes"
    { isNode && ( vendor == "Hewlett-Packard" )
   

2. Objects which represent either a network or a segment. These also reside in the filters section.

   
   NetsNSegs "All networks & segments" { isNetwork || isSegment }
   

3. A list of hostnames. This resides in the sets section.

   
   servers "Set of Servers" { "sv1", "sv2", "sv3" }
   

   A filter must be defined to reference a set. This resides in the filters section.

   
   ServersSet "Any designated Server node"
    { "IP Hostname" in servers }
   

4. Devices defined by at least one of the filters or sets above. These reside in the FilterExpressions section.

   
   MyNet "HP nodes, nets, segs, or servers " 
   { HPNodes || NetsNSegs || ServersSet }
   

Not all object attributes can be used in a filter or filter expression. NNM supports only a limited number of filterable attributes. Custom fields, described in Chapter 7, "Advanced Customization," cannot be included in defining filters. Filterable attributes are listed in Table 9-3.

9.4.1 The Default Filters File

//
// @(#)$OV_CONF/$LANG/filters
// @(#)HP OpenView NNM Release B.07.00  Oct 07 2003
// @(#)(c) Copyright 1990-2003 Hewlett-Packard Development Company, LP
// $Revision: /main/NNMET/NC2.0/NCIII/2 $  $Date: 2003/05/15 20:58 UTC $
//
// This is the default filter file. These filters are
// examples which may be useful in your environment. Feel
// free to modify this file and/or add your own.
//
// You can check the syntax of this file after modifying it // by running ovfiltercheck.
 See ovfiltercheck(1) for more // details.
//
// You can check what nodes pass a filter using the ovfiltertest command.
// For example, to see the nodes that don''t support SNMP, run
// ovfiltertest -f NonSNMPNodes
// For more information, see ovfiltertest(1)
//
// You must stop and start openview processes after this file has
// been modified (ovstop; ovstart), before changes will take effect.
//
// See OVfilterIntro(5) for more information on this file.
//
// Sets are a simple way to list string values to test
// against in a filter. The "IN" operator tests a field value
// for membership in a set defined here.
//
// Sets {
//
// These are simple examples of sets.
// Sets are used to explicitly name a group of objects, such
// as a list of nodes to compare against. These set names are
// then used in Filters and FilterExpressions to test against
// an explicit list.
//
// servers "Set of Servers" { "sv1", "sv2", "sv3" }
// gateways "Backbone gateways " { "gw1", "gw2", "gw3" }
//
// Sets can include a filename that contains the entries.
// routers "Set of Routers" { /etc/opt/OV/share/conf/routers.set }
//
// Filenames are useful for creating ''important nodes'' filters, which
// can easily group together your critical servers and network
// infrastructure. Comments are allowed in these ''set'' files if
// the line begins with a ''#''.
//
// On Windows, the ''set'' file path must use forward slashes rather
// than backslashes, and can include a drive specifier:
//  routers "Set of Routers"
//     { C:/Program Files/HP OpenView/NNM/conf/routers.txt }
//
// Important Node Sets
// -
//
// Explicit list of nodes (keep node list in this file)
// importantNodesHostnameList "Explicit Set of Important Nodes"
//          { "node1.myco.com", "node2.myco.com" }
//
// Windows format of a file in $OV_CONF:
//  importantNodesHostnameFile "Set of Important Nodes"
//          { C:/Program Files/HP OpenView/NNM/conf/important
Nodes.txt }
//
// Unix format of a file in $OV_CONF:
//  importantNodesHostnameFile "Set of Important Nodes"
//          { /etc/opt/OV/share/conf/importantNodes.txt }
//
// For these Sets to be displayed in Node View, they must
// be incorporated into a "Filters" or "FilterExpressions"
definition.
// For example, see the "ImportantNodes" example below.
//
}
//
// Filters and FilterExpressions are used as Topology,
Discovery,
// Map or Persistence filters. Applications which use filters
// (like ipmap(1), ovtopmd(1m), ovtopodump(1), and ovtopofix(1m))
// can take the name of a Filter or a FilterExpression.
//
Filters {
// The following filters are potentially useful as either Discovery
// or Topology filters, or components for building Map filters.
//
// NOTES CONCERNING DISCOVERY FILTERS:
// Networks and Segments are not directly testing with Discovery
// filters (and so there is no need to include
// "isNetwork || isSegment" in these filters).
// However, it does not hurt to include networks or segments in
// a discovery filter, so long as you realize that they will not
// be acted on.
//
// Since nodes are only discovered in managed networks, the
network
// must already exist and be managed before the filtering test
// will be applied. New networks connected to discovered nodes will
// be discovered unmanaged. For discovery filters,
// a node and all its interfaces can be thought of
// as a single object. If any interface or the node itself passes the
// filter, the node and all of its interfaces will pass the
filter.
//
// ovtopofix -f follows the discovery filter semantics and only
// applies to locally monitored objects.  However, if a network or
// segment is empty after the processing of the nodes with
the -f
// option, that segment or network will also be removed.
//
// ovtopodump(1) also follows the discovery filter semantic, and
// the filter only applies to nodes/interfaces.
//
// NOTES CONCERNING MAP AND TOPOLOGY FILTERS:
// For these filters, all objects are subject to filtering.
// One must specify the networks and segments to be passed.
// Furthermore, objects are displayed/included only if all their
// parent objects (submaps) pass the map/topology filter. For example,
// if no networks would pass the filter ("isNetwork" is not included),
// then all segments and non-gateways nodes would be filtered out.
// Like Discovery filters, if any interface or
// node passes a Map filter, the node and all of its interfaces
// also pass the filter.
//
// See the FilterExpressions section for map and topology
// filter examples.
//
// Using Sets in Filters:
// An example of including a set, such as one that describes
// a file of important nodes would look like:
//
// ImportantNodes "Critical Servers and Infrastructure filelist"
//    { "IP Hostname" in importantNodesHostnameFile }
//
// where the set importantNodesHostnameFile was defined above
// in the Sets { ... } section.
//
Networks "Any network" { isNetwork }
Segments "Any segment" { isSegment }
Nodes "Any node" { isNode }
// The following filters are primarily for example purposes, though
// they might be useful as discovery filters. They do not
generally
// make sense as map or topology filters because they do not specify
// the inclusion of networks and segments. They also make sense as
// parts of a filter expression.
// Note: NNM considers any device that supports the Bridge MIB to
// be a bridge. This generally includes switches as well.
Routers "Any Router" { isRouter }
IPRouters "Any IP Router" { isIPRouter }
Bridges "Any bridge" { isBridge }
BridgesNSwitches "Any bridge or switch" { isBridge }
Hubs "Any multi-port repeater" { isHub }
SNMPNodes "Any node supporting SNMP" { isNode && isSNMPSup
ported }
NonSNMPNodes "Any node NOT supporting SNMP"
{ isNode && !isSNMPSupported }
// The next filter is useful for defining map and topology
filters
// (see the FilterExpresssions section). It is not
// particularly useful as a discovery filter
// since all networks and segments automatically pass Discovery
// filters. Nor is it useful as a standalone
// map filter, since it doesn''t pass any nodes.
NetsNSegs "All networks & segments" { isNetwork || isSegment }
// This filter specifies that only objects that support IP should
// be included. This filter should be used as a topology filter on
// any collection station discovering non-IP information (Level 2
// or IPX only nodes or networks) that is forwarding to a
// NNM 4.X management station. This will not completely remove
// all non-IP information (e.g. IPX interfaces on a node that also
// supports IP will come through), but will limit the impact on the
// management station, and make migration to NNM 5.X easier.
IPOnlyObjects "Only objects that support IP"
{ isIP || isSegment }
// The following filters are examples that you can customize to
// match your environment.
// LocalLAN "Nodes with interfaces on the 15.2.112-119 subnet"
//    { "IP Address" ~ 15.2.112-119.* }
// NeighborLANs "Node with interfaces on the neighboring LANs on site"
/     { "IP Address" ~ 192.1.2-10.* }
// HPNodes "Hewlett-Packard nodes"
//    { isNode && ( vendor == "Hewlett-Packard" ) }
// NonHPNodes "Non-HP nodes"
//    { isNode && ( vendor != "Hewlett-Packard" ) }
// These are example filters using the sets defined above.
// GatewaysSet "Any designated Gateway node"
//    { "IP Hostname" in gateways }
// ServersSet "Any designated Server node"
//    { "IP Hostname" in servers }
// The next filter is useful for defining map and topology
filters
// (see the FilterExpresssions section). It is not
// particularly useful as a discovery filter
// since all networks and segments automatically pass Discovery
// filters. Nor is it useful as a standalone
// map filter, since it doesn''t pass any nodes.
//
// The network name below assumes an entry in /etc/networks.
// If no such entry exists, the actual network name will be
// something like "15.2.112".
// MyNet "The network in which I''m interested"
// { isNetwork && "IP Network Name" == "yellow-lan" }
// This filter would be an example of a way to pass all objects
// contained in the subnet 15.2.112.0 with a subnet mask
// of 255.255.248.0 (so the subnet range is 15.2.112.0 to
// 15.2.119.255). Note that the inclusion of "isSegment" is
// not a concern, because all segments outside of this network
// would be filtered out because the networks containing them
// were filtered out. We must have some specification of
segments
// if we want the segment contents to be included.
// EngrLan "The 15.2.112 subnet used by engineering"
//    { ("IP Address" ~ 15.2.112-119.* ) || isSegment }
// This filter accomplishes the same thing, but is more
restrictive
// in the specification of segments to only include segments in that
// engineering network. This assumes there is an entry in /etc/networks
// such that the subnet gets the name "engr-LAN", and hence the segments
// in that network all have a name of form "engr-LAN.<something>"
// Generally, the above will accomplish what you want, but this
// may be necessary in some situations if you want specific
segments.
// In particular, it works well if you want to use this to EXCLUDE
// the objects in this network. See the example in the Filter
// expressions below.
// EngrLan2 "The 15.2.112 subnet used by engineering"
//    { ( "IP Address" ~ 15.2.112-119.* ) ||
//      ( "IP Segment Name" ~ "engr-LAN.*" ) }
// The following are some sample DHCPFilters.
// They can be specified by using the Network Polling
Configuration
// dialog application, xnmpolling, on the Status Polling page.
// DHCPSubnet "Addresses in subnet 15.70.177 are DHCP allocated"
//    { "IP Address" ~ 15.70.177.* }
// DHCPNode  "A particular address is DHCP allocated"
//    { "IP Address" ~ 15.70.177.9 }
// DHCPRange "IP Addresses from 15.70.177.5 through 15.70.177.10"
//    { "IP Address" ~ 15.70.177.5-10 }
//
// Access to various nodes based on SNMP MIBs that have
// been discovered as supporting a particular MIB
//
CDPnodes "Nodes supporting Cisco Discovery Protocol" { isCDP }
ATMnodes "Nodes supporting ATM" {
( isATM ) ||
("SNMP ifType" == "ATM")  ||
("SNMP ifType" == "atmLogical") ||
("SNMP ifType" == "atmDxi") ||
("SNMP ifType" == "atmFuni") || ("SNMP ifType" == "atmIma") }
DS1nodes "Nodes supporting DS1" {
( isDS1 ) ||
("SNMP ifType" == "T-1 Carrier (ds1)") }
DS3nodes "Nodes supporting DS3" {
( isDS3 ) ||
("SNMP ifType" == "T-3 Carrier (ds3)") }
SONETnodes "Nodes supporting SONET" {
( isSONET ) ||
("SNMP ifType" == "SONET") }
FrameRelayNodes "Nodes supporting Frame-Relay" {
( isFrameRelay ) ||
("SNMP ifType" == "Frame Relay") ||
("SNMP ifType" == "Frame Relay Service") ||
("SNMP ifType" == "frameRelayInterconnect") }
RMON1nodes "Nodes supporting RMON-1" { isRMON }
RMON2nodes "Nodes supporting RMON-2" { isRMON2 }
// Short-hand for any RMON device
RMONnodes "Nodes supporting RMON-1 or RMON-2" { isRMON || isRMON2 }
MPLSnodes "Nodes supporting MPLS Protocol" { isMPLS }
HSRPnodes "Nodes supporting HSRP Protocol" { isHSRP }
IPV6nodes "Nodes supporting version 6 of the IP Protocol" { isIPV6 }
OSPFnodes "Nodes supporting OSPF Protocol" { isOSPF }
BGP4nodes "Nodes supporting BGP4 Protocol" { isBGP4 }
VRRPnodes "Nodes supporting VRRP Protocol" { isVRRP }
STPnodes "Nodes supporting Spanning Tree Protocol" { isSTP }
WirelessNodes "Nodes supporting Wireless Protocols" { isWireless }
}
// FilterExpressions are simply combinations of filters defined in the
// same filter file (above).  FilterExpressions make it simple to
// combine filters without reproducing the expressions of each
// filter again
FilterExpressions {
// One can turn the filters defined above into viable map or
// topology filters by simply adding "|| NetsNSegs". (Doing so
// does not invalidate the filters as discovery
// filters. It just adds a superfluous test.)
NetInfrastructure "Any network connecting device and what they connect"
{ Routers || Bridges || Hubs || NetsNSegs }
NetBackbone "Networks and gateways/routers"
{ Routers || Networks }
// The following combines the two set filters
// defined above into one FilterExpression.
// It works unmodified as a discovery filter.
// To work as a map filter, network and segment filtering
// must be added (see below).
// VitalNodes "All Gateways and Servers"
//    { GatewaysSet || ServersSet }
// One can turn the filters defined above into viable map or
// topology filters by simply adding "|| NetsNSegs". (Doing so
// does not invalidate the filters as discovery
// filters. It just adds a superfluous test.)
// VitalNodesMap "All nets & segs, but only gateway and server nodes"
//     { GatewaysSet || ServersSet || NetsNSegs}
// LocalLANView "All nets & segs, but only local nodes"
//     { LocalLAN || NetsNSegs }
// Using the filters defined above that include only a specific
// network, we can also exclude the specific network like this
// Note the use of the more specific form to exclude only the segments
// in the engineering lan. This could have been specified directly
// as a negation in the filter part, but this form works well if you
// have several networks to manipulate in this manner.
// EverythingButEngr "Everything but the engineering LAN"
//     { !EngrLan2 }
// Of course the above filter expressions, when used as
// map filters, pass all networks and segments. You
// may wish to see only a particular network. The following map
// filters accomplish this. Note that though segments
// and nodes from other networks will pass the filters, IP Map
// will ignore them because their parent networks will not pass.
// NOTE: These filters will not work as Discovery
// filters because all network and segments automatically pass
// Discovery and Topology filters.
// MyNetMap "Only the network of interest and all its constituent parts"
//     { MyNet || Segments || Nodes}
// MyVitalNodesMap "Gateways, servers and segments in net of interest"
//     { MyNet || Segments ||  GatewaysSet || ServersSet }
// This is a map persistence filter which ensures that
// all Ungermann-Bass are kept in memory and up to date.
// Note that this will also keep any containing submaps in memory.
// PersFilter "Objects to keep in map memory"
//     { HPNodes }
}

9.4.2 The Filters File Syntax

All filters must be defined in a file named

filters and must reside in the $OV_CONF/C directory. This is the only filter definition file. The basic syntax of the filters file for each section is

FilterName "Comment" { Filter }

The FilterName is actually either a set name, filter name or filter expression name. It is the label used when applying the filter. In the previous example, HPNodes, NetsNSegs, and servers are all filter names. Comments can be used to describe the filter and are enclosed in double quotes ("). The filter is enclosed in curly brackets { } and can be any of the filterable attributes (listed in Table 9-3) combined by the operators listed in Table 9-4.

9.4.2.1 Attribute Value Assertions

The operators listed in Table 9-4 may be used in

Attribute Value Assertions (AVA). An AVA is a statement used to describe a condition. An AVA statement evaluates to TRUE or FALSE and may use one of four types of operands:

AVAs can be written in a number of ways. The following two examples evaluate the same way:

isRouter

isRouter == TRUE

These two examples also give the same result:

! isRouter

isRouter == FALSE

Wildcards and ranges may be used in defining conditions for IP addresses and SNMP OIDs. A wildcard may be specified using an asterisk (*) to capture all number. A range may be specified using a hyphen (-) to capture a portion of numbers. You can use wildcards and ranges independently or combined. When using wildcards and ranges, you must use the like (~) operator. Here are some examples:

"IP Address" ~ 192. 201. 10.*

"IP Address" ~ 192.201.1-10.1

"IP Address" ~ 192.201.1-10.*

"

SNMP

sysObjectID" ~ .1.3.6.1.4.1.11.*

"

SNMP

sysObjectID ~ .1.3.6.1.4.1.1-11.*

9.4.2.2 Testing Your Filter

NNM provides two command-line utilities to help you check and test filters. The first utility,

ovfiltercheck allows you to check the syntax of the filters file. The

ovfiltercheck command does not require any arguments. You simply type

ovfiltercheck from the command line. If there are syntax errors in the filters file, the error and line number are written to standard out. If there are no syntax errors,

ovfiltercheck lists all the sets, filters, and filter expressions by name. The output of the

ovfiltercheck looks something like this:

Filter Table /etc/opt/OV/share/conf/C/filters
=============================================
Sets {
}
Filters {
Bridges "Any bridge"  { (isBridge) }
Hubs "Any multi-port repeater"  { (isHub) }
IPOnlyObjects "Only objects that support IP"  { ((isIP) || (isSegment)) }
IPRouters "Any IP Router"  { (isIPRouter) }
NetsNSegs "All networks & segments"  { ((isNetwork) ||
(isSegment)) }
Networks "Any network"  { (isNetwork) }
Nodes "Any node"  { (isNode) }
Routers "Any Router"  { (isRouter) }
SNMPNode "Any node supporting SNMP"  { ((isNode) &&
(isSNMPSupported)) }
Segments "Any segment"  { (isSegment) }
}
FilterExpressions {
NetBackbone "Networks and gateways/routers"  { (Routers || Networks) }
NetInfrastructure "Any network connecting device and what they connect" 
 { (((Routers || Bridges) || Hubs) || NetsNSegs) }
Defined Filter List
===================
Bridges
Hubs
IPOnlyObjects
IPRouters
NetBackbone
NetInfrastructure
NetsNSegs
Networks
Nodes
Routers
SNMPNode
Segments
Defined Set List
================
No sets defined

The second utility used in testing filters is

ovfiltertest . This utility can be used to display the number of object passing the filter. For example, to test the number of objects passing the NetsNSegs filter type

ovfiltertest f NetsNSegs on the command line.

The output of the

ovfiltertest command looks something like this:

Running filter NetsNSegs
PASSED: 15.32.120.Segment1
PASSED: 172.20.4.Segment1
PASSED: 172.20.4
PASSED: 15.32.120
Objects tested: 441, Objects passed: 4

Filter names (filters, sets, and filter expressions) are case sensitive. For example, if you had typed netsnsegs instead of NetsNSegs you would receive the message:

No such filter netsnsegs
No such filter

File: /etc/opt/OV/share/conf/C/filters
Error: "netsnsegs", filter not defined (-892)

Because NNM ships with a default filters file, both

ovfiltercheck and

ovfiltertest can be used without making any modifications to the file. You may try these utilities out before making any changes to the existing filters file. In the event that you destroy the filters file beyond repair and have made no backup, refer to the $OV_NEW_CONF/OVNNM-RUN/conf/C/filters for an original copy.

9.4.3 Map Filters

A map filter is one of the simplest filters to apply. The purpose of a map filter is to alter the view only. It does not remove anything from the database, only from the view of the map to which it is applied. A filter does not take effect until it is applied. Only one map filter may be applied to a map. Different maps can have different filters. Listed below are the steps to apply the filter named MyNet given the following filters file:

Sets {
servers "Set of Servers" { "sv1", "sv2", "sv3" }
}
Filters {
NetsNSegs "All networks & segments"  { ((isNetwork) || (isSegment))
HPNodes "Hewlett-Packard nodes" { isNode && 
( vendor == "Hewlett-Packard" )
ServersSet "Any designated Server node" { "IP Hostname" in servers }
}
FilterExpressions {
MyNet "HP nodes, nets, segs, or servers "
 { HPNodes || NetsNSegs || ServersSet }
}

1. Add the filter, set, and filter expressions to $OV_CONF/C/filters as necessary.

2. Test the filter expression using the ovfiltercheck and ovfiltertest utilities:

   ovfiltercheck

   ovfiltertest f MyNet

3. When satisfied with the results, apply the filter expression

   MyNet as a map filter by selecting

   MapProperties from the ovw GUI.

4. Select

   IP Map from Configurable Applications and click

   [Configure For This Map…] .

5. Using the filter name MyNet defined previously, type

   MyNet in the field labeled Map Filter. Refer to Figure 9-3 for the dialog box used when applying a map filter.

   Figure 9-3. To apply a map filter, select

   MapProperties , select

   IP Map and click

   [Configure For This Map…] . Type the name of the map filter,

   MyNet , in the

   Map Filter field and click the

   [Verify] button and

   [OK] twice.

   
   

   [View full size image]

   height="358" SRC="/image/library/english/10090_09fig03.gif" >

6. Click

   [Verify] .

7. Click

   [OK] in both dialog boxes.

The resulting map displays the servers sv1, sv2, sv3, all network and segment devices, and all Hewlett-Packard devices.

Note

When writing a map filter, you must include network and segment devices as part of the filter expression. The default filters file includes the NetsNSegs that will include all network and segment devices. If you do not include network and segment devices, the map in which your filter is applied will be empty.

A map filter may be removed simply by deleting the filter name from the

Map Filter field in the

IP Map Configuration dialog box (Figure 9-3) and clicking

[OK] twice. It is not required to remove the filter and filter expressions from the filters file in order to remove a filter.

9.4.4 Discovery Filters

A discovery filter actually affects which devices are added to the object database. Use a discovery filter to eliminate the discovery of specific devices. One example of a discovery filter would be if you were only interested in monitoring particular devices, such as network infrastructure devices and mission critical servers. Given the following filters file, here are the steps to apply a discovery filter:

Note

The discovery of any interface

automatically creates its associated network segment and network object within the object database. If you create a filter to discover nodes on networks 15.2.112-199.* and 15.3.123.* and there are multi-homed nodes on either of those networks that have interfaces configured for networks

other than 15.2.112-199.* and 15.3.123.*, all the networks will be discovered.

Sets {
servers "Set of Servers" { "sv1", "sv2", "sv3" }
}
Filters {
NetsNSegs "All networks & segments"  { ((isNetwork) ||
(isSegment)) }
HPNodes "Hewlett-Packard nodes" 
{
 isNode && ( vendor == "Hewlett-Packard" ) 
}
ServersSet "Any designated Server node" { "IP Hostname" in servers }
ImportantNodes "Important systems" { "IP Address" ~
15.2.112-119.* }
}
FilterExpressions {
CriticalDevices "HP nodes, nets, segs, or servers " 
{ HPNodes || NetsNSegs || ServersSet
 || ImportantNodes }
}

1. Add the filter, set, and filter expressions to $OV_CONF/C/filters as necessary.

2. Test the filter syntax using the

   ovfiltercheck .

3. Test the filter expression and check the results. Correct the filter syntax and retest if needed:

   ovfiltertest f CriticalDevices

4. When satisfied with the results, apply the filter expression

   CriticalDevices as a discovery filter by selecting

   OptionsNetwork Polling Configuration:IP from the NNM GUI, as shown in Figure 9-4.

   Figure 9-4. To apply a discovery filter, select

   OptionsNetwork Polling and Configuration: IP . Toggle on the

   Use Discovery Filter found in the

   General Configuration Area and type the name of the discovery filter. Click

   [OK] .

   
   

   [View full size image]

   height="477" SRC="/image/library/english/10090_09fig04.gif" >

5. In the General Configuration Area, toggle on the box labeled

   [Use Discovery Filter] .

6. Enter your filter expression name,

   CriticalDevices .

7. Click

   [OK] .

8. Stop the netmon process:

   ovstop netmon

9. Apply the filter to the existing database. This will remove devices in the database that do not pass the filter CriticalDevices:

   ovtopfix f CriticalDevices

10. Start the netmon process:

    ovstart netmon

The resulting database will only include nodes defined by the

CriticalDevices filter expression. This filter includes sv1, sv2, sv3, Hewlett-Packard devices, network objects, segment objects, and devices in the IP address range 15.2.112-119.*. The network and segment attributes are not required entries in the discovery filter, and it does not matter if they exist in your filter.

Because a discovery filter applies to the topology database as opposed to the map database, only one discovery filter may be defined per NNM system. It must include all the devices that any operator may want to see in any map. It may take several iterations to get the results you are looking for when writing a discovery filter.

A discovery filter can be removed by un-checking the

[Use Discovery Filter] field in the

Network Polling Configuration: IP dialog box and clicking

[OK] .

9.4.5 Topology Filters

A topology filter resides on a

Collection Station (CS) and determines which devices to pass to a

Management Station (MS). In this way, you are able to limit the view of the CS from the MS by allowing only a subset of objects to be passed to the MS. The configuration of CS and MS will be discussed in more detail in Section 9.5, "Distributed Internet Monitoring." Using the following filters file, follow the subsequent steps to apply the

TopoFilter filter.

Sets {
servers "Set of Servers" { "sv1", "sv2", "sv3" }
}
Filters {
NetsNSegs "All networks & segments"  { ((isNetwork) ||
(isSegment)) }
HPNodes "Hewlett-Packard nodes" { isNode && 
( vendor == "Hewlett-Packard" ) }
ServersSet "Any designated Server node" { "IP Hostname" in servers }
ImportantNodes "Important systems" { "IP Address" ~
15.2.112-119.* }
}
FilterExpressions {
CriticalDevices "HP nodes, nets, segs, or servers "
 { HPNodes || NetsNSegs || ServersSet

 || ImportantNodes }TopoFilter "HP nodes, nets, segs, and important sys"
 { HPNodes || NetsNSegs ||
 ImportantNodes }
}

1. Add the filter, set, and filter expressions to $OV_CONF/C/filters as necessary.

2. Test the filter expression using the

   ovfiltercheck and

   ovfiltertest utilities:Section 9.5. Network and segment devices must be included in the definition of a topology filter. A simple way to test a topology filter on the CS is to apply it as a map filter. When satisfied with the results of the map, remove the map filter and apply it as a topology filter.

   A topology filter may be deleted by removing the

   f

   filtername from

   ovtopmd.lrf and executing

   ovstop, ovaddobj , and

   ovstart as described in step 5 of the previous list.

   9.4.6 Persistence Filters

   
   

   Persistence filters are used to include systems when the demand level is set to anything other than

   All Levels . Recall that the demand level determines which levels of the network hierarchy devices are to be loaded into memory for display in ovw. A persistence filter causes an object to be resident in memory when the map is opened. If an object passes the filter, the object and all devices contained in the submap on which the object resides become persistent. Listed in the following are the steps to apply a persistence filter.

   
   Sets {
   }
   Filters {
   HPNodes "Hewlett-Packard nodes"
    { isNode && ( vendor == "Hewlett-Packard" ) }
   }
   FilterExpressions {
   }
   

   
   

   1. Add the filter to $OV_CONF/C/filters file.

   2. Test the filter expression using the

      ovfiltercheck and

      ovfiltertest utilities.

      ovfiltercheck

      ovfiltertest f HPNodes

   3. When satisfied with the results, apply the filter expression HPNodes as a persistence filter by selecting

      MapProperties from the ovw GUI.

   4. Select IP Map from Configurable Applications and click

      [Configure For This Map…] .

   5. Using the filter name HPNodes defined above, type HPNodes in the field labeled Persistence Filter. Refer to Figure 9-5 for the dialog box used when applying a persistence filter.

      Figure 9-5. To apply a persistence filter, select

      Map?Properties , select

      IP Map from

      Configurable Applications and click

      [Configure For This Map…] . Type the persistence filter name in the Persistence Filter field.

      
      

      [View full size image]

      height="358" SRC="/image/library/english/10090_09fig05.gif" >

   6. Click

      [Verify] .

   7. Click

      [OK] in both dialog boxes.

   The resulting map contains all persistent submaps plus all submaps that contain Hewlett-Packard devices. Only one persistence filter may be applied to a map. Different persistence filters may be applied to different maps to allow a user to customize his or her map.

   A persistence filter may be removed by deleting the filter name from the

   IP Map Configuration dialog box and clicking

   [OK] in the two required dialog boxes.

   9.4.7 Important Nodes Filter

   
   

   The purpose of an important node filter is to treat important secondary devices as primary devices during an outage. A secondary failure occurs when

   netmon cannot perform a status poll of a device because a connection device between NNM and the device has failed. For example, assume that you have a mission critical database server on a subnet other than the one on which NNM resides. If the connection device between NNM and the database server fails, the default behavior of NNM is to use the multiplier (2) to calculate the polling frequency for secondary devices. This means the database server and all other devices on that subnet would be polled every 30 minutes instead of every 15 minutes. Because the database server is mission critical, you may want to tag it as an important node.

   An important node filter may be defined using the following steps:

   
   Sets {
   dbservers "Set of DB Servers" { "dbs1", "dbs2", "dbs3" }
   }
   Filters {
   DBserversFilter "Database Servers" { "IP Hostname" in dbservers }
   }
   FilterExpressions {
   }
   

   
   

   1. Add the filter, set, and filter expressions to

      $OV_CONF/C/filters as necessary.

   2. Test the filter expression using the

      ovfiltercheck and

      ovfiltertest utilities.

      ovfiltercheck

      ovfiltertest f DBserversFilter

   3. When satisfied with the results, apply the filter expression DBserversFilter as an important nodes filter by selecting

      OptionsNetwork Polling Configuration:IP from the NNM GUI, as shown in Figure 9-6.

      Figure 9-6. To apply an important nodes filter select

      OptionsNetwork Polling and Configuration: IP . Select

      Secondary Failures from the Configuration Area. Toggle on the

      Secondary Failure Polling Options and the

      Identify Important Nodes Using Filters buttons and type the important nodes filter name in this field.

      
      

      height="478" SRC="/image/library/english/10090_09fig06.gif" >

   4. Select

      Secondary Failures from the Configuration Area and toggle on the box labeled Secondary Failure Polling Options.

   5. Toggle on the

      Identify Important Nodes Using Filter button and type the filter name

      DbserversFilger in the field.

   6. Select the setting you would like for Failure Status of Important Nodes: Down or Unknown.

   7. Click

      [OK] .

   The resulting configuration polls the database servers dbs1, dbs2, and dbs3 with the same polling frequency as primary devices during a network outage. Only one important nodes filter may be applied per NNM station. More importantly, the alarms for the important nodes are displayed directly in the alarm browser, not correlated under the alarm for the primary failure. The important nodes filter may be removed by toggling off the

   Important Nodes Using Filter button.

   9.4.8 DHCP Filters

   
   

   Dynamic Host Configuration Protocol (DHCP) automatically assigns IP addresses and delivers TCP/IP configuration parameters such as the subnet mask and the default router. Typically, DHCP devices are mobile devices such as laptops. They might also be systems that are shutdown during nights and weekends. These devices appear in NNM as going down frequently, causing Critical alarms and "red" symbols. One way to handle DHCP devices is to use a discovery filter to completely eliminate them from the database. Another way is to treat them with a special set of rules by using a DHCP filter.

   By default, NNM deletes a device from the database if it is down for one week, assuming that the device has been removed from the network. When defining DHCP devices, you may specify the window in which the devices may be deleted from the database. For example, if a DHCP device is down for 2 hours you may have it deleted from the database. The second "delete" field does not delete the record for the laptop from the database. It removes the IP address from the record so that the IP address can be assigned to some other record. When the IP address is removed from the record, the label reverts to the MAC address on the display. Listed here are the steps to apply a DHCP filter:

   
   Filters {
   DHCPnodes "DHCP nodes" { isNode && { "IP Address" ~ 15.2.112.* }
   }
   

   
   

   1. Add the filter listed previously to include the DHCP IP address range of your enterprise to $OV_CONF/C/filters file.

   2. Test the filter expression using the

      ovfiltercheck and

      ovfiltertest utilities.

      ovfiltercheck

      ovfiltertest f DHCPnodes

   3. When satisfied with the results, apply the filter expression DHCPnodes as a DHCP filter by selecting

      OptionsNetwork Polling Configuration:IP from the NNM GUI.

   4. Select the

      Status Polling Configuration Area .

   5. Toggle on the

      DHCP

      Polling Options button.

   6. Toggle on the

      Identify the

      DHCP

      IP Address Using Filter field.

   7. Type the filter name

      DHCPnodes in the field.

   8. If you would like to modify the deletion window, modify the

      field Delete Identified

      DHCP

      IP Addresses If Down For field. The default is 8h (8 hours).

   9. Click

      [OK] .

   Figure 9-7. To apply a DHCP filter, select

   OptionsNetwork Polling Configuration:IP from the NNM GUI. Select the

   Status Polling Configuration Area. Toggle on the

   DHCP Polling Options and

   Identify DHCP IP Addresses Using Filter buttons. Type the filter name in this field.

   
   

   height="478" SRC="/image/library/english/10090_09fig07.gif" >

   The resulting map will still have the nodes using DHCP displayed. If the IP address doesn''t respond to status polling for 8 hours, the label reverts to the MAC address. Only one DHCP filter can be applied to per management station. To delete the DCCP filter, toggle off the

   DHCP

   Polling Options button.

   9.4.9 Failover Filers

   
   

   A failover filter allows an MS to pick up status polling responsibility for a CS that fails. The configuration for MS/CS is discussed in detail in Section 9.5. When defining a failover filter, you must first issue the command to enable failover. The

   xnmtopoconf command is issued on the MS, and

   stationlist is a list of CS(s) to be managed by the MS in the event of the CS failure.

   xnmtopoconf failover

   stationlist

   
   

   The failover filter must then be specified to include the objects to be polled by the MS. The failover filter is applied using the following steps:

   
   Sets {
   servers "Set of Servers" { "sv1", "sv2", "sv3" }
   dbservers "Set of DB Servers" { "dbs1", "dbs2", "dbs3" }
   }
   Filters {
   NetsNSegs "All networks & segments"  { ((isNetwork) ||
   (isSegment)) }
   HPNodes "Hewlett-Packard nodes" 
   { isNode && ( vendor == "Hewlett-Packard" ) }
   ServersSet "Any designated Server node" 
   { "IP Hostname" in servers }
   ImportantNodes "Important systems" { "IP Address" ~
   15.2.112-119.* }
   DBservers "Database Servers" { "IP Hostname" in dbservers }
   }
   FilterExpressions {
   FailoverFilter "HP nodes, nets, segs, and important sys" {
   HPNodes || NetsNSegs || ImportantNodes || DBservers }
   }
   

   
   

   1. Add the sets, filters, and filter expressions to $OV_CONF/C/filters file.

   2. Test the filter expression using the

      ovfiltercheck and

      ovfiltertest utilities.

      ovfiltercheck

      ovfiltertest f FailoverFilter

   3. When satisfied with the results, issue the following commands on the MS to enable failover and to specify the failover filter:

      xnmtopoconf failover

      stationlist

      xnmtopoconf failoverFilter FailoverFilter

      stationlist

      Failover can be disabled by issuing the following command:

      xnmtopoconf nofailover

      You can remove the filter by typing

      xnmtopocof -FailoverFilter "

   A sample filters file is available for download from the server