This is fantastic, and works great. The results match perfectly. Thank
you very much Greg--Drew
-----Original Message-----
From: Greg Keetch [mailto:gkeetch@ca.ibm.com]
Sent: Friday, October 20, 2006 9:32 AM
To: Tivoli NetView Discussions
Subject: RE: Resolved: [NV-L] NV 7.1.4AIX--advice onksh
nmdemandpollscript--coprocessing
Hello Again,
isNode covers all devices, including routers and hubs, which just have
the
additional field of isRouter or isHub set to true. It makes for a simple
way to list devices only and exclude interface, subnets, networks, etc.
Regards,
Greg Keetch
IT Specialist (Advisor), Network Services
Network Management Tools Specialist
Information Technology Services Americas (ITSA), Global Services, IBM
Canada
"Van Order, Drew
\(US -
Hermitage\)"
To
<dvanorder@deloit "Tivoli NetView Discussions"
te.com> <nv-l@lists.ca.ibm.com>
Sent by:
cc
nv-l-bounces@list
s.ca.ibm.com
Subject
RE: Resolved: [NV-L] NV 7.1.4
AIX--advice onksh
10/20/2006 07:18 nmdemandpollscript--coprocessing
AM
Please respond to
Tivoli NetView
Discussions
<nv-l@lists.ca.ib
m.com>
I thought about that using nvUtil. I thought isNode would exclude
routers, switches, etc. If I have that incorrect, your solution is much
more graceful, and takes one step!
-----Original Message-----
From: Greg Keetch [mailto:gkeetch@ca.ibm.com]
Sent: Friday, October 20, 2006 8:29 AM
To: Tivoli NetView Discussions
Subject: Re: Resolved: [NV-L] NV 7.1.4 AIX--advice onksh
nmdemandpollscript--coprocessing
Howdy,
You could make the first step of this run a little faster by using the
nvUtil command instead of nvdbformat. The 'while read hostname' line
below
could be changed to:
for hostname in `/usr/OV/bin/nvUtil e "((isNode=TRUE) &&
(isSNMPSupported=TRUE))"`
This should return an unsorted list of device (not interface) selection
names for isSNMPSupported=TRUE object very quickly.
Regards,
Greg Keetch
IT Specialist (Advisor), Network Services
Network Management Tools Specialist
Information Technology Services Americas (ITSA), Global Services, IBM
Canada
"Van Order, Drew
\(US -
Hermitage\)"
To
<dvanorder@deloit "Tivoli NetView Discussions"
te.com> <nv-l@lists.ca.ibm.com>
Sent by:
cc
nv-l-bounces@list
s.ca.ibm.com
Subject
Resolved: [NV-L] NV 7.1.4
AIX--advice on ksh
10/20/2006 05:46 nmdemandpollscript--coprocessing
AM
Please respond to
Tivoli NetView
Discussions
<nv-l@lists.ca.ib
m.com>
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
From: Leslie Clark [mailto:lclark@us.ibm.com]
Sent: Thursday, October 19, 2006 8:16 AM
To: Tivoli NetView Discussions
Subject: Re: [NV-L] NV 7.1.4 AIX--advice on ksh
nmdemandpollscript--coprocessing
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@deloitte.com>
Sent by:
nv-l-bounces@lists.ca.ibm.com
To
"Tivoli NetView Discussions"
<nv-l@lists.ca.ibm.com>
10/19/2006 08:13 AM
cc
Subject
Please respond to [NV-L] NV 7.1.4 AIX--advice
on
Tivoli NetView Discussions ksh nmdemandpoll
<nv-l@lists.ca.ibm.com> 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@lists.ca.ibm.com
Unsubscribe:NV-L-leave@lists.ca.ibm.com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to
internal IBM'ers only)
_______________________________________________
NV-L mailing list
NV-L@lists.ca.ibm.com
Unsubscribe:NV-L-leave@lists.ca.ibm.com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to
internal IBM'ers only)
_______________________________________________
NV-L mailing list
NV-L@lists.ca.ibm.com
Unsubscribe:NV-L-leave@lists.ca.ibm.com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to
internal IBM'ers only)
_______________________________________________
NV-L mailing list
NV-L@lists.ca.ibm.com
Unsubscribe:NV-L-leave@lists.ca.ibm.com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to
internal IBM'ers only)
_______________________________________________
NV-L mailing list
NV-L@lists.ca.ibm.com
Unsubscribe:NV-L-leave@lists.ca.ibm.com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to
internal IBM'ers only)
_______________________________________________
NV-L mailing list
NV-L@lists.ca.ibm.com
Unsubscribe:NV-L-leave@lists.ca.ibm.com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to
internal IBM'ers only)
|