Event Management and Best Practices

Chapter 6. Event management products and best practices 315

Handling related events

You may be concerned with tracking events from the same problem that come in

after you open a trouble ticket. One way to manage this is in the supplied

troubleticket.rls.

If the flag

called _assoc_flag is set to on, it calls TroubleTicket.sh to send only an

update event and not to create a new ticket. This is for any events that are

duplicates of the original event that came in.

6.8 Maintenance mode

There are a many things to consider when it comes to maintenance modes. This

section attempts to describe how the corresponding IBM products handle this

type of situation.

6.8.1 NetView

NetView tracks the status of the devices it manages. It generates traps when it

detects changes in the condition of those devices. It also receives and processes

traps sent to it by SNMP-capable devices that have NetView defined as one of

their trap receivers. When discussing maintenance mode, it is important to

consider both types of traps.

Another consideration is how the NetView product is used. Consider the example

where all events within an organization are managed from IBM Tivoli Enterprise

Console, and no-one uses the NetView console for monitoring traps. In this case,

it may be sufficient to handle maintenance mode at the IBM Tivoli Enterprise

Console level and allow NetView to continue processing as normal. See 6.8.2,

“IBM Tivoli Enterprise Console” on page 328, for information about handling

event from devices in maintenance mode at the IBM Tivoli Enterprise Console

event server. Likewise, if the NetView user who monitors the console is the same

person who is performing the maintenance, it may not be necessary to take any

special action for the events.

We recommend that you use IBM Tivoli Enterprise Console to handle

maintenance mode when possible. Allow NetView to process traps as normal.

NetView and IBM Tivoli Switch Analyzer’s correlation capabilities can be used to

handle events generated by those products, performing root cause analysis to

suppress several unnecessary events. The device in maintenance mode is most

likely identified as the root cause of the problems. A trap reporting its status is

forwarded to other event processors. Assuming the processors were informed

that the network device is in maintenance mode through their normal means,

316 Event Management and Best Practices

they properly handle both the root cause event and any unsolicited traps

generated by the device itself.

An organization that does not have a higher level event processor may want to

implement a method of handling traps from devices in maintenance mode at the

NetView server. The same applies to organizations with users who are actively

monitoring events using NetView. Several NetView features can be implemented

to accomplish this.

Unmanaging SNMP devices in maintenance mode

The NetView object database contains global information for each object that

NetView has discovered. Two of the fields it maintains for an object are OVW

Maps Exists and OVW Maps Managed. These fields contain integers showing

the numbers of maps on which the object is located and the number on which it is

managed respectively. The information stored in the object database can be

displayed using the ovobjprint command. In Example 6-48, the information

about device sapsw01 was displayed using the command:

ovobjprint -s sapsw01

Example 6-48 Information from NetView’s object database

OBJECTID SELECTION NAME

OBJECT: 543

FIELD ID FIELD NAME FIELD VALUE

10 Selection Name "sapsw01"

11 IP Hostname "sapsw01"

14 OVW Maps Exists 2

15 OVW Maps Managed 2

20 IP Status Normal(2)

23 isIPRouter FALSE

35 vendor cisco Systems(12)

47 isNode TRUE

50 isConnector TRUE

51 isBridge TRUE

52 isRouter FALSE

53 isHub TRUE

54 isRepeater TRUE

75 isIP TRUE

94 isSNMPSupported TRUE

96 SNMP sysDescr "Cisco Systems Catalyst

1900,V9.00.06 "

97 SNMP sysLocation ""