MLM does not support SNMPV2 traps or MIBs, that is true. So if the traps
which are causing your storm are V2, then MLM cannot threshold them nor
forward them. In that case, using MLM between your agents and trapd is a
bad idea, otherwise not. Note that there is no reason why you cannot
point your V1 agents to MLM and your V2 agents directly to NetView's
trapd, but usually this requires the MLM to on a separate box. Only one
agent can own 162/udp, the default port for incoming traps.
If you cannot filter out unnecessary traps with MLM when you have a storm,
then the only solution I see is the one I suggested yesterday. Put a
threshold mechanism in your ruleset so that you only forward the first one
of many. This will reduce the load on TEC. But as Ray noted, it does
nothing for the load on NetView, which may bog down under the weight of
the storm.
James Shanks
Level 3 Support for Tivoli NetView for UNIX and NT
Tivoli Software / IBM Software Group
"Delaire, Patrick" <delairep AT aetna DOT com>
06/18/2003 11:26 AM
To: James Shanks/Raleigh/IBM@IBMUS
cc:
Subject: RE: [nv-l] Flooding TEC
James,
I was involved in the forwarding to TEC process and are ruleset
is simple but it not forwarding every event that netview receives.
Basically we identified each individual event from the trapd.conf file
we want forwarded and gave them a certain source character
and built rulesets to forward just those events, which work great except
when we have run-away processing from certain sources.
Ray, made a good point about using MLM but we are attempting to migrate
to AIX 5.1 and currently have it
Inour development lab but were told that MLM in AIX 5.1 does not support
SNMPV2. Since most of the data we
load these days Use SNMPV2 so, we collectively decided to disable it.
Bad idea?
-----Original Message-----
From: James Shanks [mailto:jshanks AT us.ibm DOT com]
Sent: Tuesday, June 17, 2003 8:37 PM
To: nv-l AT lists.tivoli DOT com
Subject: Re: [nv-l] Flooding TEC
I take it that you did not set up the TEC forwarding from NetView
yourself.
What is forwarded to TEC from NetView are events. In a UNIX environment
those are selected by a NetView ruleset which you specify in
/usr/OV/conf/tecint.conf. Apparently you are using a very simple
ruleset, perhaps forwardall.rs, which sends every event from NetView to
TEC. Bad idea. You can customize that ruleset in hundreds of different
ways to send just exactly what you want to TEC. In fact, you need not
send a any events from your IVR system at all if you so choose. Or you
can set up a threshold node for your IVR events to only send the first
of many duplicate in a short time. But you have to analyze just what is
being sent and what you want to filter out. Until you do, it will be
difficult for anyone to advise you on what to do or how to set it up,
until you can say just exactly what you want to accomplish.
The trick to all this is to use the ruleset editor,nvrsEdit, to create a
new ruleset which only forwards what you want.
I would also take a look at the 7.1.3 Release Notes about running the
itsupgrade script and changing your NetView / TEC environment to use the
new TEC_ITS_BASE classes. Then you would only forward NetView events
needed for automatic correlation. You could. of course, expand on that
too if you wish.
James Shanks
Level 3 Support for Tivoli NetView for UNIX and NT
Tivoli Software / IBM Software Group
"Delaire,
Patrick" To:
<nv-l AT lists.tivoli DOT com>
<[email protected] cc:
om> Subject: [nv-l] Flooding
TEC
06/17/03 04:38 PM
We are running AIX 4.3 with Netview 7.1.3. Our new IVR (voice response
system) is sending SNMP data to our Netview platform
which is then forwarded to TEC. The problem we are experiencing a times
is our IVR application/s including speechworks and conversant
servers machine gun both Netview and TEC when we experience problems.
This results in TEC buffering messages and eventually
stop functioning. The voice response people cannot do any more
filtering from the source. Does any one on this list have any suggestion
on how we could stop 'machine gun' type alert processing either on the
Netview side or TEC side.
Side note: We have filtering on TEC but only after the alerts has been
processed through TEC. The buffering issue occurs before the alerts
are processed, which at times bring down TEC.
P.S. We have disabled MLM.
Automation & Systems Monitoring
Enterprise System Management
Aetna Information services
E_mail: DelaireP AT Aetna DOT com
phone: 860-636-8126
Fax: 860-636-6807
This e-mail may contain confidential or privileged information. If you
think you have received this e-mail in error, please advise the sender
by
reply e-mail and then delete this e-mail immediately. Thank you.
Aetna
---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe AT lists.tivoli DOT com
For additional commands, e-mail: nv-l-help AT lists.tivoli DOT com
*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group help
line at 1-800-TIVOLI8(848-6548)
---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe AT lists.tivoli DOT com
For additional commands, e-mail: nv-l-help AT lists.tivoli DOT com
*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)
|
