nv-l
[Top] [All Lists]

RE: [nv-l] Status Polling

To: nv-l@lists.us.ibm.com
Subject: RE: [nv-l] Status Polling
From: Leslie Clark <lclark@us.ibm.com>
Date: Fri, 24 Jun 2005 14:49:56 -0400
Delivery-date: Fri, 24 Jun 2005 19:50:59 +0100
Envelope-to: nv-l-archive@lists.skills-1st.co.uk
In-reply-to: <1D99739B79BF7744BF8927B8F2274CA2063EA0@HQGTNEX5.doe.local>
Reply-to: nv-l@lists.us.ibm.com
Sender: owner-nv-l@lists.us.ibm.com

I agree with Bill. The timeouts and retries are your best bet for tuning out false alarms. Depending on your network, it may be the retries rather than the timeouts that work best for you. Say 5 retries with a timeout of 2, if pings are getting lost.

Cordially,

Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
(248) 552-4968 Voicemail, Fax, Pager



"Evans, Bill" <Bill.Evans@hq.doe.gov>
Sent by: owner-nv-l@lists.us.ibm.com

06/23/2005 09:11 PM
Please respond to
nv-l

To
"'nv-l@lists.us.ibm.com'" <nv-l@lists.us.ibm.com>
cc
Subject
RE: [nv-l] Status Polling





I’ve done it.  Not hard at all but expensive.  Demand Poll takes a lot of cycles.  This script is executed out of the ESE.Automation when an event indicating a failed poll is received.  A ruleset kicks it off as a background action.  
 
goshawk2#cat RouterDP.sh
#!/bin/ksh
Hostname=${1}
Date=`date`
echo ${Date} function off >>/opt/webmon/RouterDP.log
usr/OV/bin/nmdemandpoll ${Hostname} >>/opt/webmon/RouterDP.log &
 
One problem is that SNMP doesn’t really have any better priority or architectural power than ICMP.  I actually used the process when SNMP polling had a problem with late arriving responses on a slow and overloaded processor.  It’s an architectural fact that ICMP and SNMP are low priority and allowed to be thrown away.  NetView compensates by its geometrically increasing waits on retries and the ability to customize retries and wait time by device.  
 
I quit using the script once we had the problem figured out.  The overhead of Demand Poll actually made things a bit worse.  
 
I’d go for solving the root cause.  Manipulate the timeouts and retries for ICMP.  Make sure your NetView box has enough resources.  Check the delays at the routers and switches to see if there’s a bad card tying up traffic.  Etc.  
 
The other alternative is to look into the IBM Tivoli Switch Analyzer.  It automates the follow-up of failed polls and its slightly delayed follow up to the failed ICMP often clears the condition.  
 
Using an inline action is a VERY BAD idea.  Your entire rules processing waits for the demand poll to finish.  The system can totally bog down; note that my background script spins the demand poll off as an independent process because it was single threading the background action processing.    
 
Bill Evans
 
-----Original Message-----
From:
owner-nv-l@lists.us.ibm.com [mailto:owner-nv-l@lists.us.ibm.com] On Behalf Of Kumar Vanka
Sent:
Thursday, June 23, 2005 8:48 PM
To:
nv-l@lists.us.ibm.com
Subject:
[nv-l] Status Polling

 
I'm using ICMP for status polling in our environment. However, due to several factors, we're getting many false positives. One of these factors is that ICMP has a low priority in our environment. Is it possible to configure netmon so that if the ICMP status poll shows that a node is down, it can then do a demand poll using SNMP?
 
Based on my research, it appears this is not possible. So, I'm considering modifying my ruleset to  use an inline action to run nmdemandpoll. Is this a good option? Or, are there other options that I'm not considering?
 
Thanks.
 
- Kumar Vanka
ESM Architect
Invenio, Inc.
 
<Prev in Thread] Current Thread [Next in Thread>

Archive operated by Skills 1st Ltd

See also: The NetView Web