|Subject:||RE: [nv-l] cisco_link_down and status polling|
|From:||Leslie Clark <firstname.lastname@example.org>|
|Date:||Sun, 7 Aug 2005 22:00:11 -0400|
|Cc:||"'email@example.com'" <firstname.lastname@example.org>, email@example.com|
|Delivery-date:||Mon, 08 Aug 2005 03:00:31 +0100|
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.
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
(248) 552-4968 Voicemail, Fax, Pager
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.
From: firstname.lastname@example.org [mailto:email@example.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
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?
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||RE: [nv-l] cisco_link_down and status polling, Evans, Bill|
|Next by Date:||[nv-l] Documentation for NetView on GNU/Linux (SuSE 9.2), Georg Gangl|
|Previous by Thread:||RE: [nv-l] cisco_link_down and status polling, Evans, Bill|
|Next by Thread:||RE: [nv-l] cisco_link_down and status polling, Alaa Farrag|
|Indexes:||[Date] [Thread] [Top] [All Lists]|
Archive operated by Skills 1st Ltd
See also: The NetView Web