This may be more difficult than it seems on the surface. This is a classic
case of wanting to have an intelligent fault correlator which can make the
determination that the router being down is the cause of the server problem
so the server problem can be ignored. This is not always a simple exercise
and that is why third-party software exists which will do this function.
Tivoli has even started marketing some of its own: Tivoli Manager for
Network Connectivity. But this is an expensive way to go. These products
cost more than NetView itself.
The point of saying this is that if you are not willing to pay someone else
to write the code, then you have to decide what level of confidence your
ruleset solution will have. Is it OK that most of the time the pages are
for server problems and not router problems? How exacting you want to be
will determine how difficult your solution is to implement.
When I suggested reset-on-match, my suggestion was based on the assumption
(false as it turns out) that the traps from the server and router shared
some attribute in common. This would be the case if they were NetView
traps, which always have the hostname of the affected node in var 2. The
reset-on-match (and pass-on-match) assume that a match can be made using
the contents of the trap. If the "match" is an external correlation (I
know that server_xyz is on the same subnet as router_pqr ) then you will
indeed have to make that correlation another way. Like any other
programming task this requires creativity on your part, and the simplicity
and elegance of the solution will depend upon how creative you are.
You could write a script and run it as an inline action to determine the
router associated with each server, and then take some action to determine
if that router has a problem, such as ping it or do an ovobjprint -s and
determine its current status in the object database. You could also
maintain your set of 60 collections and have your script do an nvutil
command to determine the correct router, but this seem more tedious to
maintain than a simple file of these correlations.
The problem as I see it is that you will still have a lot of programming to
do, since you cannot extract the router name and pass it to the next node
in the ruleset, unless that node is another action. So perhaps we could
just deal with the server trap and forget the router. What could you do
there?
One thing that comes to mind is that you could do a checkroute when the
server trap comes in. Can you get a route back to the server? If so, then
it is not a network connectivity problem (though it might be a performance
or congestion one). The problem here is that I don't see how you can be
100 per cent certain that there is not a network problem.
Just some ideas
James Shanks
Tivoli (NetView for UNIX) L3 Support
Jan Green <greenjan@YAHOO.COM> on 05/12/99 03:35:56 PM
Please respond to Discussion of IBM NetView and POLYCENTER Manager on
NetView <NV-L@UCSBVM.UCSB.EDU>
To: NV-L@UCSBVM.UCSB.EDU
cc: (bcc: James Shanks/Tivoli Systems)
Subject: Re: Ruleset Suggestions
Dennis -
My customer only wants pages when the server only is
down. They do not want server pages when there is a
network problem. I notify another customer when there
is a network outage.
It is a ruleset developed in NetView.
> If you know the relationship of the server(s) to the
> router(s), then you
> can suppress the associated server notifications
> when it's related router
> is unavailable.
If you know of a way to do this, I would appreciate
the info.
Thanks
Jan
--- Dennis Aguilar <dennis@SMARTS.COM> wrote:
> At 08:03 AM 5/12/99 -0700, you wrote:
> >I am running Netview 5.1.1, Framework 3.6 on AIX
> 4.3.1
> >and am trying to suppress a server notification if
> a
> >network problem exists. Specifically, If a server
> and
> >a router trap come in, throw them both out and do
> not
> >process them through the ruleset.
>
> Wouldn't you want to throw the server notification
> out and keep the router
> trap when a network problem exists?
>
> >
> >Does anyone have any suggestions as to what node or
> >combination of nodes might work?
>
Is this a ruleset developed in
> NetView or is this a TEC
> ruleset?
>
> >
> >Thanks for any suggestions
> >
> >Jan
>
>_________________________________________________________
> >Do You Yahoo!?
> >Free instant messaging and more at
> http://messenger.yahoo.com
> >
>
_________________________________________________________
Do You Yahoo!?
Free instant messaging and more at http://messenger.yahoo.com
|