nv-l
[Top] [All Lists]

Re: Ruleset Suggestions

To: nv-l@lists.tivoli.com
Subject: Re: Ruleset Suggestions
From: Jan Green <greenjan@YAHOO.COM>
Date: Thu, 13 May 1999 10:02:06 -0700
Reply-to: Discussion of IBM NetView and POLYCENTER Manager on NetView <NV-L@UCSBVM.UCSB.EDU>
Sender: Discussion of IBM NetView and POLYCENTER Manager on NetView <NV-L@UCSBVM.UCSB.EDU>
Thanks to everyone who sent suggestions on this
problem. I believe I can use some of the ideas and
solve my problem.

Jan


--- James Shanks <James_Shanks@TIVOLI.COM> wrote:
> 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
>

_________________________________________________________
Do You Yahoo!?
Free instant messaging and more at http://messenger.yahoo.com

<Prev in Thread] Current Thread [Next in Thread>

Archive operated by Skills 1st Ltd

See also: The NetView Web