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
|