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
10.1.65.14
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.
-----Original Message-----
From: owner-nv-l@lists.us.ibm.com
[mailto:owner-nv-l@lists.us.ibm.com] On
Behalf Of Colin Mulkerrins
Sent: 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
"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)
glen.warn@pemcocorp.com
206-628-5770
*********************************************************************************
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.
*********************************************************************************