nv-l
[Top] [All Lists]

RE: [nv-l] cisco_link_down and status polling

To: nv-l@lists.us.ibm.com
Subject: RE: [nv-l] cisco_link_down and status polling
From: Leslie Clark <lclark@us.ibm.com>
Date: Sun, 7 Aug 2005 22:00:11 -0400
Cc: "'nv-l@lists.us.ibm.com'" <nv-l@lists.us.ibm.com>, owner-nv-l@lists.us.ibm.com
Delivery-date: Mon, 08 Aug 2005 03:00:31 +0100
Envelope-to: nv-l-archive@lists.skills-1st.co.uk
In-reply-to: <1D99739B79BF7744BF8927B8F2274CA251ED88@HQGTNEX5.doe.local>
Reply-to: nv-l@lists.us.ibm.com
Sender: owner-nv-l@lists.us.ibm.com

Well, at current maintenance levels I believe it is supposed to react to those traps by re-evaluating the IP status of all of the interfaces on the device that it usually polls, and do it right away instead of waiting for the next scheduled poll. There is an option in /usr/OV/conf/netmon.conf to turn this off if you want. I am not 100% certain that it speeds it up a lot, though.I think I am seeing it take almost the whole polling cycle to get around to that check. That may only be because netmon, on the system I am working on, has a lot to do.  

If this is on, you should look at your layer2 switches' configurations to ensure that you are not sending link up/down from all ports unless you plan to use that information. Each trap will theoretically send Netview off needlessly re-checking the IP status of the management interface. Where possible you would want to enable link traps only on the uplinks.

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

08/07/2005 12:56 PM
Please respond to
nv-l

To
"'nv-l@lists.us.ibm.com'" <nv-l@lists.us.ibm.com>
cc
Subject
RE: [nv-l] cisco_link_down and status polling





The “cisco_link_*” traps are from the agent on the Cisco box.  They are not part of the status polling done by NetView but independent notifications from the device software.  
 
Leslie’s post is still accurate, NetView does nothing with agent originated traps in it’s default state except to pass them along for display.  Unless you implement something to process them that’s all there is.  
 
In my system we have them set to “log only” so they’re there if we need to reconstruct the history of some failure but otherwise don’t find them useful.  Our installation only monitors the switches and not the devices beyond the switches.  We find the “cisco_link” traps are usually associated with workstations when they are powered up and down.  
 
We could use them in relation to our core switches but in that case they’re not needed since we’re actively monitoring the devices on the far side of our core links.  
 
Bill Evans
 
-----Original Message-----
From:
owner-nv-l@lists.us.ibm.com [mailto:owner-nv-l@lists.us.ibm.com] On Behalf Of Alaa Farrag
Sent:
Sunday, August 07, 2005 9:12 AM
To:
The nv-l mailing list
Subject:
[nv-l] cisco_link_down and status polling

 
Hi,
 
Is there any special action the netview takes when it receives a cisco_link_down or a cisco_link_up trap (status polling)?
 
I found the following old post by Leslie Clark:
" Netview does not automatically do anything other than report, via the
Events Display, unsolicited traps from devices in the network. You are free to customize those traps and do what you think is best."

 
I would like to know if this is valid uptill now?
 
Best regards,
Alaa Farrag
 
<Prev in Thread] Current Thread [Next in Thread>

Archive operated by Skills 1st Ltd

See also: The NetView Web