Il s'agit d'un message multivolet au format MIME.
Thanks for your quick and pertinent answer, as usual.
I know that we should go on 6.0 releases, but as we experienced some regressions
in the past, and because the installed system is operational, our final customer
is very reticent about a full Netview COTS upgrade. This would involve a new
complete validation activity we all want to avoid. However, for the futur
implementation of our solution, we will go on the 6.0.2 release which should be
quite stable now...
Do you no if this (netmon auto-adjusting its timeout / retries) has been
identified through an APAR, so as to allow me requesting netmon 5.1.3+ including
> The way to prevent netmon from auto-adjusting these values is to install
> 6.0.2 and get rid of 5.1.3
> It cannot be done without a new netmon. I don't know if the change to
> remove auto-adjusting of polling time-outs was moved into the 5.1 service
> tree or not. If you want to find out, I suggest you call Support and get a
> new copy of netmon at the current level for 5.1, which would be 5.1.3+, as
> an e-fix, and see if that helps. But ultimately you need to let go of
> NetView 5.1. It is on its way out anyway and there is no good reason to
> stay where you are. 6.0.2 will work in the same operating system
> environment you describe.
> James Shanks
> Team Leader, Level 3 Support
> Tivoli NetView for UNIX and NT
> luc BARNOUIN <luc.barnouin@FR.AIRSYSATM.THOMSON-CSF.COM>@tkg.com on
> 04/25/2001 03:43:47 AM
> Please respond to IBM NetView Discussion <firstname.lastname@example.org>
> Sent by: email@example.com
> To: "'IBM NetView Discussion'" <firstname.lastname@example.org>
> Subject: [NV-L] Netmon polling raises too many interface Down/Up events
> Hi forumers,
> Netview 5.1.3 + fixes,
> Tru64 (Digital) UNIX 4.0f
> Network implementation (FDDI, single and dual Ethernet - redundant
> transceivers) based on DEC900 family (concentrators, repeaters,
> When one of the redunded element is down, it has an impact on all of the
> network elements (i.e. many interface down, then up traps generated by
> netmon), including nodes that have no link with the failed element. After
> analysis, failure of one element induce an unstability in the network, with
> automatic reconfiguration which needs several seconds to recover (FDDI and
> Ethernet redundancy, dynamic routing, ...). During this reconfiguration
> phase, netmon fails pinging some interfaces, which seems reasonnable.
> In order to coope with this unstability period, I've tried to configured
> timeout and retries values for this polling (wildcard values in xsnmpconf),
> but these values are automatically decreased by netmon down to 1 second and
> no retries, which does not coope with the tolerance that was expected!!!
> Is there any way to prevent netmon from adjusting dynamically these values?
> If using SNMP polling, will netmon also adjust its internal timeouts?
> Thanks for any help
> Luc BARNOUIN
Description: Carte pour luc BARNOUIN