Well, this may not be it exactly, but I know that prior to 6.02, Netview
would
surreptitiously reduce the timeout when things were responding quickly.
This caused false alarms when things reverted to normal. A fix in 6.02
makes sure the timeout you specify is honored. I don't know for a fact,
though, that the reduced timeout is stored in the topology database.
Maybe that refers to the actual timeout. The defaults are 2 seconds,
3 retries. Maybe you should try increasing it a tiny bit more.
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit
echevarria@ES.IBM.COM@tkg.com on 03/26/2001 04:55:07 AM
Please respond to IBM NetView Discussion <nv-l@tkg.com>
Sent by: owner-nv-l@tkg.com
To: nv-l@tkg.com
cc:
Subject: [NV-L] No Subject
Hello all,
I have Netview 6.0 on AIX 4.2.1 and I had some timeout problems with
some routers so I tried to change snmp timeout parameter. I set it to 2.0
secs by using the graphic utility (xnmsnmpconf). It didn't fix it and I can
see the following discrepancies between the xnmsnmpconf database and the
ovtopodump information relating to SNMP timeout:
#(MPN:echeva)/home/echeva> xnmsnmpconf -resolve router1
name = router1
community = ATTgns13nocspain
proxy = <none>
timeout = 20
retry = 3
pollInterval = 300
remotePort = 161
setCommunity = <default>
discoveryPoll = 1
useAutoAdjust = 1
fixedInterval = 900
confInterval = 86400
nodeDownIntrval= 604800
routeEntries = 800
discoverManage = 1
ipAddr = 195.51.114.250
isProxied = FALSE
ipAddrAge = Fri Mar 23 16:38:23 2001
#(MPN:echeva)/home/echeva>
#(MPN:echeva)/home/echeva> ovtopodump -l router1
HOSTNAME: router1
...
blah blah blah...
...
SUPPORTS SNMP: YES
NETMON FLAGS: 0x800103d3
SNMP ADDRESS: 195.51.114.250
SNMP TIMEOUT: 1 second
CYCLE TIME: 35 minutes, 15 seconds
INIT CONFIG POLL: MAXIMUM TIME
CONFIG POLL: Sat Mar 24 17:05:01 NFT 2001
NEW NODE POLL: Fri Mar 23 17:11:57 NFT 2001
TOPOLOGY POLL: MAXIMUM TIME
SNMP STATUS POLL: Fri Mar 23 17:11:50 NFT 2001
OTHER POLLING INTERVALS/TIMES:
2147483647 (MAXIMUM TIME)
2147483647 (MAXIMUM TIME)
2147483647 (MAXIMUM TIME)
2147483647 (MAXIMUM TIME)
985363910 (Fri Mar 23 17:11:50 NFT 2001)
NUMBER OF INTERFACES:5
INTERFACE: Loopback0
INTERFACE ID: 14025
CREATE TIME: Wed Mar 7 16:06:47 NFT 2001
MODIFIED TIME: Fri Mar 23 17:09:11 NFT 2001
SYMBOL CHANGE TIME: Fri Mar 23 17:06:50 NFT 2001
SEGMENT CHANGE TIME: Tue Jan 13 13:57:01 NFT 1998
STATUS: Up
IF FLAGS: CONNECTED BUS_SEG
IP ADDR: 195.51.114.250
IP MASK: 255.255.255.255
IF NUMBER: 4
IF TYPE: Software Loopback
PHYSICAL ADDRESS: <none>
IF SPEED: -589934592
NODE/SEG/NET IDS: 14026/14032/14027
POSITION: 0
LEFT NEIGHBOR NODE/IF IDS: 0/0
NETMON FLAGS: 0x10000000
TIMEOUT INTERVAL: 1 second
LAST SUCCESSFUL POLL: Fri Mar 23 17:09:10 NFT 2001
NEXT NETMASK POLL: MAXIMUM TIME
POLLING INTERVALS/TIMES:
0 (<unset>)
0 (<unset>)
0 (<unset>)
0 (<unset>)
0 (<unset>)
CONSECUTIVE FAILED POLLS: 0
LLA SOURCE: 0x0
MASK FROM: 0x1
PORT CLASS: 0
...
blah blah blah...
...
#(MPN:echeva)/home/echeva>
So I get two answers: 2 seconds with xnmsnmpconf and 1 second with
ovtopodump -l. I'm wondering if there is some database corruption in snmp
configuration. Or maybe I don't understand well how this works.
thanksyou for any help and regards,
Juan.
Juan Echevarría López
AT&T Global Network Services
Internet: jechevarria@att.com
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
|