[Top] [All Lists]

RE: [nv-l] ? about yellow map status near root - but zero "failin g reso

To: "'nv-l@lists.us.ibm.com'" <nv-l@lists.us.ibm.com>
Subject: RE: [nv-l] ? about yellow map status near root - but zero "failin g resources" found in submaps
From: "Evans, Bill" <Bill.Evans@hq.doe.gov>
Date: Fri, 24 Jun 2005 12:36:03 -0400
Delivery-date: Fri, 24 Jun 2005 17:36:35 +0100
Envelope-to: nv-l-archive@lists.skills-1st.co.uk
Reply-to: nv-l@lists.us.ibm.com
Sender: owner-nv-l@lists.us.ibm.com

I have similar problems mostly, but not entirely, with Layer2Staus icons related to ITSA 1.3 on NV 7.1.4 FP03.  I’ve done two things to cope.  The first was to figure out how to reset the device icon when the L2Status icon is acknowledged or normal and the second was to automate it.  The resetting sequence also works for the subject situation. 


The reset sequence is:

  • Acknowledge the device icon (with me it’s usually a switch)
  • Open the device to the interface submap
    • If there is an interface in yellow or red, acknowledge it.
    • If there are one or more interfaces in dark green, unacknowledged each.  Re-acknowledge each if  they become red or yellow.
    • If all interfaces are normal acknowledge and unacknowledged one of them. Preferably the one associated with the current network address. 
  • Return to the device interface and it may now be normal.  This works for me about 95% of the time. 


The other five percent are driving me crazy.  The hard ones are routers where I ACK  the device at the segment level and ack/unack the interface related to the IP network address.  That improves my percentage. 


Since the main problem is the L2Status on a switch going marginal when the users turn off their workstations at close of business, I’ve automated the corresponding trap to automatically ACK the devices.  The heart of that script is:


# Get the OID for the failing device and its interface icon. 

#  Ovtopodump returns the OIDs which must be stripped out of the data. 

#     NODES      1490/1489    E102241    Down

OID=`/usr/OV/bin/ovtopodump ${HostName} | grep Down`

OID1=`echo ${OID} | cut -d" " -f1 | cut -d/ -f1 `

OID2=`echo ${OID} | cut -d" " -f1 | cut -d/ -f2 `

echo "Ack for ${HostName}  ${OID1}  ${OID2}" >>${LogFile}

/usr/OV/bin/event -b openview -e ACK_EV -a ${OID1} >>${LogFile}

/bin/sleep 5

/usr/OV/bin/event -b openview -e ACK_EV -a ${OID2} >>${LogFile}


This script is hitting all the nodes I want plus a few more.  The problem with this is a bunch of Switches I have to unacknowledged every morning.  Then a half dozen or so marginal switches to clean up manually.  Most of these are in the state: Switch icon is marginal, L2Status is acknowledged and become unknown when unacked.   I’ll share the full script for offline requests but you should be able to reproduce the effect with what’s above. 


I think there’s a problem but I can’t state it clearly enough to open a problem report.  The situation I addressed is a normal case where ITSA is setting the state of the switch icon when L2Status is set.  The first ACK on the switch puts the icon back under the control of the NV processes and the second is then recognized for propagation of status up the chain.  The outstanding problem is the non-ITSL non-L2Status situation addressed by the same manual icon state resetting procedure. 


Bill Evans


-----Original Message-----
From: owner-nv-l@lists.us.ibm.com [mailto:owner-nv-l@lists.us.ibm.com] On Behalf Of Colin Mulkerrins
Friday, June 24, 2005 5:51 AM
To: nv-l@lists.us.ibm.com
Subject: RE: [nv-l] ? about yellow map status near root - but zero "failing resources" found in submaps




I have been having similar issues with icons going marginal when everything under them is OK (I have even had leaf interfaces going marginal).  All this started when I upgraded from 7.1.2 to 7.1.4 (on AIX) I am up to FP3 and it is still happening.  I can change them back to green by unmanaging and remanaging the icon (normally a router) but after a while (not consistant) it changes back to yellow again - I have set logging but so far cannot find any reason why this is happening nothing ashows up in the logs.  They do not appear to be generating traps and my network team have not complained about spurious alerts (and they would if they got any :-)).  It is just a pain in the a** and makes the map look bad.


I suppose I'll get around to opening a pmr on the problem at some stage when I get a chance




Colin M.


"We bought Tivoli to alleviate firefighting - now we are firefighting Tivoli" me.


-----Original Message-----
From: owner-nv-l@lists.us.ibm.com [mailto:owner-nv-l@lists.us.ibm.com] On Behalf Of Glen Warn
Sent: 23 June 2005 17:51
To: nv-l@lists.us.ibm.com
Subject: [nv-l] ? about yellow map status near root - but zero "failing resources" found in submaps



Running Netview 7.1.4 FP3 on Redhat Linux AS 2.1

My root map has been carved up into 5 objects that represent 5 different companies.  Each of those companies networks and devices have been cut from the root map and pasted into the company specific submaps.  Everything works perfectly - except on thing.  4 of the 5 submaps (representing each company) show status of yellow.  Drilling into the submaps - everything is either green or unmanaged (including hidden objects).  I've tried using the TOOLS-> FAILING RESOURCE DISPLAY utility to ID my problem, but it returns "no specified resources found".  Even odder, a month or so ago, Company X was green and everyone else yellow.  Now, company X is yellow and company Z is green!  I've run the various DB utilities too (resolve DB inconsistencies, compress IP and objects topology)

I also only have only a single map.


Any thoughts would be greatly appreciated,


Glen Warn

PEMCO Corporation Computer Services (PCCS)





This e-mail and its attachments, is confidential and is intended for the addressee(s) only. If you are not the intended recipient, disclosure, distribution or any action taken in reliance on it is prohibited and may be unlawful. Please note that any information expressed in this message or its attachments is not given or endorsed by An Post unless otherwise indicated by an authorised representative independently of this message. An Post does not accept responsibility for the contents of this message and although it has been scanned for viruses An Post will not accept responsibility for any damage caused as a result of a virus being passed on.


<Prev in Thread] Current Thread [Next in Thread>
  • RE: [nv-l] ? about yellow map status near root - but zero "failin g resources" found in submaps, Evans, Bill <=

Archive operated by Skills 1st Ltd

See also: The NetView Web