Meyos,
I answered correctly the question you asked, which was how to resolve
duplicate events. You did not explain how you expected your ruleset to
work, nor ask for any comments on your design. It would do what it was
designed to do, which was resolve any existing Node Downs in the Events
display a matching Node Up was issued. That's all it was designed to do.
If you had expected it to do something else, then perhaps you should
explain what that was. A more complicated scenario will require a more
complicated ruleset, just as any programming exercise would.
A ruleset is, after all, a user programming exercise. It runs in the
specialized environment of the NetView event flow, but the user remains
responsible for the design of it. And you cannot design a program to work
on the standard netmon event flow if you do not know what that flow is.
The way netmon works with regard to Node Up, Node Marginal, and Node Down
(or Router Up, Router Marginal, Router Down when the node is also a router
according to the NetView database) is that you will get the Down event when
all interfaces on the device are down, the Marginal event when some
interfaces are down and some are up, and finally the Up event when all are
up. So your first design would work, but it won't do anything until the
final Up event arrives, and then it will resolve any matching Node Down
events.
At this point I am not at all certain what you or your customer expected to
happen. A Node Marginal event is the proper event for netmon to send.
Surely you wouldn't want a Node Up if it was not truly up "all the way"?
If you want Node Marginal events to be cleared by the Node Up event, then
you have to build that logic into your ruleset. If you also want Interface
Downs for the interfaces on that node to be resolved, then you have to
build in that logic as well. This is not a trivial task, but a serious
programming exercise.
One of the major differences between Netview for UNIX and TEC is that
NetView does not maintain a databases of recently passed events that you
can alter. You cannot "go back" and re-evaluate old events on the basis of
new ones unless you made special provisions to hold them in nvcorrd's cache
using the Pass-on-Match, Reset-on-Match, and Threshold functions ahead of
time. Those are the limitations of the implementation. I cannot do
anything about that, nor can I do anything about the way netmon works. So
you have to design your ruleset(s) within those parameters.
HTH
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group
|