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
|
