Here's a repost of the warning on this subject that appeared recently. It
is very difficult to
explain to a customer that it is the device's fault when your management
tool takes down
part of the network. I have been asking customers about these devices and
code levels
when I walk in the door, just to be safe.
>Hello all,
>Thought I'd pass on a problem I ran into today. Whilst investigating a
slow response >problem I attempted to obtain the status of a port in
Expanded View. This upset the agent >to the extent that it rebooted the
5000BH and took down our ATM network...you can imagine >my
embarrassment!!!!! The agent is an MCP v3.2.2 handle with care!!!!
>Incidentally...can anyone confirm whether the fault_correlator_filter off
command actually >works? It doesn't seem to do anything on our system!?!
>regards paul
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
(248) 552-4968 Voicemail, Fax, Pager
---------------------- Forwarded by Leslie Clark/Southfield/IBM on 02-22-99
06:29 PM ---------------------------
Connie Logg <cal@SLAC.STANFORD.EDU> on 01-27-99 03:12:47 PM
Please respond to Discussion of IBM NetView and POLYCENTER Manager on
NetView <NV-L@UCSBVM.UCSB.EDU>
To: NV-L@UCSBVM.UCSB.EDU
cc: (bcc: Leslie Clark/Southfield/IBM)
Subject: Re: data collection on switches
You might want to be ware of the following warning from cisco when it comes
to frequently polling the cisco switches:
>>
>>This e-mail is generated by an automatic daemon. If you have
>>any questions or comments, please send them to cco-team@cisco.com
>>along with a copy of this message. To turn off this Alert or to
>>update your Profile, please go to the Bug Watcher homepage at
>>http://www.cisco.com/support/bugtools/homepage.shtml - Please
>>refer to http://www.cisco.com/kobayashi/releases/bugstate.html for
>>information regarding Bug states.
>>
>>
>>The following defect(s) matched your Bug Alerts profile for this Agent:
>>-------------------------------------------------------------------------
---
>>-
>> BugID: CSCdk78385
>> Title: WS-X5224/WS-X5010 modules disappear with SNMP polling
>> Feature: snmp
>> Version: 3.2(3)
>> Integrated:
>> Severity: 3
>> State: C
>>Release Notes:
>>Catalyst 5000 and 5500 switches with WS-X5506 or WS-X5509 supervisor
modules
>>may report that modules have been removed. Modules will continue to pass
>>traffic normally. Only Supervisor II modules runnning release 3.2.3 are
>>affected. This problem is not seen with Supervisor III modules or with
>>Supervisor II modules running versions other than 3.2.3.
>>The commands show port, show mod, reset will not see the modules and
>>will not function.
>>The problem has only been experienced in environments with excessive SNMP
---------------
>>polling of the supervisor module.
>>-------------------------------------------------------------------------
---
I have not been able to find out from cisco what they consider "excessive
polling"...
At 08:13 AM 1/27/99 -0500, you wrote:
>Subject: Re: data collection on switches
>
>
>>Hello,
>>
>>
>>I believe that the figures I see are not the pure counter value.
>>They appear to be the change in the counter value since last poll devided
>>by the polling interval in seconds. ?
>>
>>Has anyone looked into this further or found documentation ?
>>
>Right. Say, you are collecting every five minutes. What you will get is
>the average of the five minute interval. This will, of course, level out
>peaks, but if you want to see peaks shorten the interval. For example,
>collecting every thirty seconds will get you close to the sniffer level.
I
>would not recommend doing this except for short periods of time and
special
>cases. A tremendous amount of data is produced.
>
>The basis of the question is what do you want to see. Octets per second
on
>a net of
>so many bits per second allows you to see the load on the net on a timed
>basis. If you are interested in see how many octets have went over the
net
>in a period of time, you can snmpwalk the counters on a snapshot basis.
You
>have to handle counter rollover which can occur frequently on a very busy
>network. Some people handle it with scripts. I handle it with COBOL
>programming. Good luck and happy wading through all that data.
>
>Mel
>
*********************************************************************
" Of course the opinions expressed here are my own. "
Connie Logg CAL@SLAC.Stanford.Edu ph: 650-926-2879
Network Management and Performance Analyst
SLAC (MS 97), P.O. Box 4349, Stanford, CA 94309
"Happiness is found along the way, not at the end of the road."
|