This is the "way it is designed". I called in the same problem. Please send
mail to:
netview@tivoli.com
requesting a design change. I think it is defective to have a router which
has suffered a power failure in marginal status instead of critical status just
because one of the interfaces was administratively down. The AD interface
doesn't
count for status when all other interfaces are up, but it does when all
interfaces are down. I believe that it should be treated as an unmanaged
interface in that regard.
"Whitehead, Neil" wrote:
> Hi list !
>
> I don't know if this is a bug, or my incompetence, or a design request!
> Still, press on...
>
> I'm using NetView v4.1.3 (maybe its fixed in v5 ?).
>
> Often I get device objects which are showing MARGINAL status even though
> every interface that I'm monitoring is actually down.
>
> What appears to be happening is that the parent object (usually a router
> with multiple interfaces) has many of these interfaces either Admin Down
> or Unmanaged. To my way of thinking, if an interface is Admin Down or
> Unmanaged, you don't really care about its status taking part in the
> Status propagation algorithm. NetView believes otherwise!
>
> The status propagation appears to be based on something like....
> (no. of sub-objects marked down) / (Total number of sub-objects,
> regardless of whether they're unmanaged or Admin down).
>
> Is there a fix for this?
>
> What I'd really like would be for status propagation to be based on ...
> (No of sub-objects down) / (Total no of Sub-objects that are being
> monitored)
>
> Neil Whitehead (x22808)
> IT Services (Telecoms)
> The Royal Bank of Scotland
> Tel: 0131-523 2808
> e-mail: whitern@rbos.co.uk
>
> This e-mail message is confidential and for use by the addressee only. If
> the message is received by anyone other than the addressee, please return the
> message to the sender by replying to it and then delete the message from your
> computer..
>
> 'Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc
> does not accept responsibility for changes made to this message after it was
> sent.'
--
Ray Schafer | schafer@tkg.com
The Kernel Group | Distributed Systems Management
http://www.tkg.com
|