Any opinions expressed in this message are those of the sender only and
do not necessarily represent the views or opinions of Woolwich plc, any
of its subsidiaries or it's associated companies. The sender may not be
authorised to give financial advice, and nothing in this message should
be construed as offering such advice. Woolwich plc is an Introducer
Firm only for Woolwich Life, Woolwich Unit Trust Managers and Woolwich
Plan Managers which are regulated by the Personal Investment Authority
for Life Assurance, Pension, Unit Trust and other Investment business.
Registered Office: Watling Street, Bexleyheath, Kent DA6 7RR.
Registered in England No.3295699
The information contained in this message and any attachments are
intended solely for the use of the individual or entity to whom they
are addressed. It may contain privileged and confidential information
and if you are not the intended recipient you must not copy, distribute
or take any action in reliance on it. If you have received this email
in error please notify the system manager ADMINISTRATOR@WOOLWICH.CO.UK
-----------------------------------------------------------------------
James,
Thanks for your reply.
I am not actually looking to ignore the traps completely, merely process
them differently to other traps.
The background is that one of our implementations is using SMS to forward
the Windows NT traps to NetView/AIX.
Unfortunately SMS is not configurable for thresholds and sends all traps
passed by the applications with the result that there are many duplicates
which kill our paging system (last week they sent 424 duplicates in a 6
minute period!). Also SMS sends 5 standard 'varbinds' so threshold checking
needs to look at Specific trap, Enterprise Id, Origin and varbinds 6 & up.
I also wanted to ensure that the checking only took in the Microsoft traps
so that when we implement a device/package that uses Enterprise Ids
3110-3119 these are not affected (just thinking of the people who will have
to support the system when I'm gone!).
I have now created a ruleset that does what I want and it appears not to be
dragging NetView down to it's knees so I'm going to leave it for a while.
Thanks for all your help
Ken Freeman
Woolwich plc
-----Original Message-----
From: James Shanks [mailto:James_Shanks@TIVOLI.COM]
Sent: 19 November 1999 16:47
Subject: Re: Wildcards in 'Event Attributes' ruleset node
Ken -
Your response so surprised me that I did some checking. The match should be
for
"311."
and not for 1.3.6.1.4.1.3110-3119. We have an open internal defect to fix
this, which should be done in the next round of maintenance. So your script
will be redundant one of these days.
But if you really don't have any of those agents in your network now, I am
surprised that you are worried about them. The cost of running a script
like
that as an inline action is that every Microsoft trap will slow down nvcorrd
by
whatever cycles it takes to run that script, and based on what you said, it
sounds like that overhead could be significant over time. The only reason
for
the script now would seem to be that someone, unbeknownst to you, would
implement one of these agents and configure it to send traps to NetView, and
that without the script, they would not show in the event window (though
they
would in the log). Is that really likely? If not, I would dispense with the
script. But the choice is yours.
The reason that I say this is a point I harp on a lot, that for the sake of
one's network, you should not, as a matter of business policy, allow someone
to
configure an agent to send traps to the NetView box without knowing in
advance
what they will do with them when they get there. Traps can eat a lot of
bandwidth and if they arrive at too great a rate, can delay other NetView
processing to the point where it cannot keep up. I make this warning because
I
have been involved in too many critical situations over NetView performance
which were resolved by restricting the trap flow to only what was necessary
and
useful.
I have seen routers take up to 60% of the available bandwidth on a segment
sending traps. I have seen errant routers send hundreds of traps per
second. I
have seen someone configure a hundreds of routers to send silly traps (e.g.
"OSPF table updated") so that all of them together raise the aggregate trap
rate
to a constant 20 to 30 per second. And these are the kinds of things that
will
kill NetView.
Now I don't want to suggest that you are in this situation. Far from it.
But I
do wonder when you tell me that you are worried about filtering out traps
somebody might send in the indefinite future. See my drift?
James Shanks
Tivoli (NetView for UNIX) L3 Support
-----------------------------------------------------------------------
James,
Thanks for your suggestion.
I tried it using our test system and you are right - it blocks all the
Microsoft Enterprise IDs and it is fast!
Unfortunately it also blocks any Enterprise IDs in the range
1.3.6.1.4.1.3110-3119 and their variants which may cause a problem if we
ever receive traps from vendors using these Enterprise IDs. I guess I will
need to use some form of hybrid solution where the 'grep' is only performed
when the Enterprise Id starts with 1.3.6.1.4.1.311 (at least this will limit
the number of Inline Actions that are called).
Ken Freeman
Woolwich plc
|