Folks,
I have something working that does the job and appears
very accurate. Thought I'd share it after learning the netmon commands did not
meet our requirements, and quicktest/nmdemandpoll were performance killers. The
output tells you which SNMP capable devices are being monitored with ping, and
which ones are being SNMP queried for status. Great for
auditing.
It's 2 steps--
1. Use nvdbformat to spit out a list of devices where
isSNMPSupported=TRUE. You must get the Selection Name, whatever it may be. If
you don't; the ovtopodump command used below will not return the SNMP STATUS
POLL field:
SELECTRULE:isSNMPSupported=TRUE
SELECTFIELD:1:Selection
Name
SELECTFIELD:2:SNMP
ipAddress
GROUPBY:1:Selection Name
SORTBY:1:Selection Name
OUTPUT:${1}
2.
Feed the output of this to a script that does the
following:
while read hostname
do
if [[ `ovtopodump -rl $hostname |grep -c "SNMP STATUS
POLL: MAXIMUM TIME"` -ge 1 ]]
then
echo "$hostname is monitored using ping" >>
$FILE
else
echo "$hostname is monitored using SNMP query" >>
$FILE
fi
done
I think one of the netmon action
commands (netmon -a xx ) might produce that list in netmon.trace. Check the man
page for netmon.
Cordially,
Leslie A. Clark IT Services Specialist, Network
Mgmt Information Technology Services Americas IBM Global Services (248)
552-4968 Voicemail, Fax, Pager
"Van Order, Drew \(US -
Hermitage\)" <dvanorder AT deloitte DOT com> Sent by: nv-l-bounces AT lists.ca.ibm DOT com
10/19/2006 08:13 AM
Please respond
to Tivoli NetView Discussions
<nv-l AT lists.ca.ibm DOT com> |
|
To
| "Tivoli NetView Discussions"
<nv-l AT lists.ca.ibm DOT com>
|
cc
|
|
Subject
| [NV-L] NV 7.1.4 AIX--advice on ksh
nmdemandpoll script--coprocessing |
|
Hi all,
Our DNOC needs a report that shows what IP
addresses are managed via SNMP query versus ping. I searched the archives and it
appears one can't get this report using nvdbformat--isSNMPSupported is not an
accurate indicator. So, I'm getting the list of IP's that match
isSNMPSupported=TRUE from nvdbformat, then feeding the list into `ndmdemandpoll
$hostname |grep "Get SNMP status"`. This will do the job, but we all know
nmdemandpoll kills CPU if it takes any time at all to run. I have 1500 addresses
to cycle through.
So, I figure I can kill nmdemandpoll if it's going
to take longer than 15 seconds to finish, log the IP address that needed to be
killed, then go back to the loop. No problem, except I'm a novice ksh scripter,
and having trouble with co-processes (required to watch the nmdemandpoll PID
because nothing will occur until nmdemandpoll finishes, right?). If someone can
help me with the logic, I'll post the whole smash for everyone to use when it's
finished.
This works fine, just takes forever, and sends
uptime values skyward. It sets off NetIQ alerts for CPU utilization.
# Read in IP address list from
NVout.report # nv_getSNMPquerystatus.sh < NVout.report
while read ipAddress do nmdemandpoll $ipAddress | grep "Get
SNMP status"
if [[ $? -eq 0 ]]
then echo "$ipAddress is currently
monitored using SNMP query" else echo "$ipAddress is currently NOT
monitored using SNMP query" fi done
Many thanks in advance to anyone with
advice on how to finish this one off. --Drew
Drew Van
Order Information Technology Services Deloitte
Services LP Tel: +1 615 882 7836
www.deloitte.com
This
message (including any attachments) contains confidential information intended
for a specific individual and purpose, and is protected by law. If you are
not the intended recipient, you should delete this message.
Any disclosure, copying, or distribution of this message, or
the taking of any action based on it, is strictly prohibited.
[v.E.1]_______________________________________________ NV-L mailing
list NV-L AT lists.ca.ibm DOT com Unsubscribe:NV-L-leave AT lists.ca.ibm DOT com http://lists.ca.ibm.com/mailman/listinfo/nv-l
(Browser access limited to internal IBM'ers
only)
_______________________________________________
NV-L mailing list
NV-L AT lists.ca.ibm DOT com
Unsubscribe:NV-L-leave AT lists.ca.ibm DOT com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to
internal IBM'ers only)
|