|
I N T E R O F F I C E M E M O R A N D U M
Sent: GMT
From:
[email protected]@umc@WRLMTS@WRL
Dept:
Tel no:
Message no: 000798
Reply to:
TO: hagenmuller@a1_annecy.valmts.aeo.MTS@umc@WRLMTS@WRL
Subject: Multiple Request Problem
Christophe,
This is a message from our engineer on a problem found with DECmcc on
the multiple OID request for the counters. Please let me know what you
think.
Regards,
Clyde
=======================================================================
>From ts Mon Dec 14 12:58:03 1992
Date: Mon, 14 Dec 92 12:58:02 -0800
>From: ts (Timon Sloane)
To: cki
Subject: DECmcc bugs
Clyde,
I have diagnosed the "multiple attribute request" problem
and it looks like a DECmcc problem. The following is
what the trace looks like when trying to dislay the "Counters"
from DECmcc of one of the packet lines.
Indices 12 through 33 are the Gauges in the MIB.
KEY:
-> GET 12-26
means DECmcc requested indicies 12 through 26
<- GOT 12,26, noSuchName #15
means a GET response was returned to DECmcc with a
noSuchName error on index #15. SNMP protocol
requires in these cases that no valid data be returned
for any of the other variables requested in the GET.
_+_+_+_+_+_+ TRACE _+_+_+_+_+_+_
1 -> GET sysUptime .. sysObjectId
2 <- GOT noSuchName
3 -> GET 12-26
4 <- GET 12-26, noSuchName #15
5 -> GET 27-33
6 <- GOT 27-33
7 -> GET 12-14, 16-27 ALREADY HAS 27!
8 <- GOT 12-14, 16-27, noSuchName #16
9 -> GET 28-33 ALREADY HAS 28-33 !!
10 <- GOT 28-33
11 -> get 12-14, 17-28 ALREADY HAS 27 and 28
12 <- GOT 12-14, 17-28, noSuchName #17
13 -> GET 29-33 ALREADY HAS 29-33
14 <- GET 29-33
15 -> GET 12-14, 18-29 ALREADY HAS 27-29
16 <- GOT 12-14, 18-29, noSuchName #18
17 -> GET 30-33 ALREADY HAS 30-33
18 <- GOT 30-33
19 -> GET 12-14, 19-30 ALREADY HAS 27-30
20 <- GOT 12-14, 19-30, noSuchName #20
21 -> GET 31-33 ALREADY HAS 31-33
22 <- GOT 31-33
23 -> GET 12-14, 19, 21-31 ALREADY HAS 27-31
** 5 second timeout **
24 -> GET 12-14, 19, 21-33 ALREADY HAS 27-33
25 <- GOT 12-14, 19, 21-33
26 -> GET 32-33 ALREADY HAS 32-33
** 5 second timeout ** (proxy is processing #24)
27 -> GET 32-33 ALREADY HAS 32-33
** 5 second timeout ** (proxy is processing #24)
28 -> GET 32-33 ALREADY HAS 32-33
** 5 second timeout ** (proxy is processing #24)
29 -> GET 32-33 ALREADY HAS 32-33
** 5 second timeout ** (proxy is processing #24)
30 <- GOT 12-14, 19, 21-31
31 <- GOT 32-33
32 <- GOT 32-33
33 <- GOT 32-33
_+_+_+_+_+_+ TRACE _+_+_+_+_+_+_
Note that DECmcc does a few things that are very inefficient.
First, it requests the same variable multiple times. This looks
like a serious and obvious DECmcc bug.
Second, once it has discovered that the table is sparse, it continues
to try to build large requests. Instead, it should back down
to small requests (with 1 or 2 variables) because in sparse
table situations large requests are much less efficient. Take for
example the request response pair:
3 -> GET 12-26
4 <- GET 12-26, noSuchName #15
This transaction requires the agent to calculate the values for
12-14 before it discovers that 15 is not available. The response
(msg #4) does not contain the values for 12-14 (that is the way
SNMP works). So all the time calculating 12-14 is wasted. Smaller
requests avoid this problem.
Third, I had reset the UDP timeout to be 60 seconds. I was still
seeing 5 second timeouts on the wire. It looks like there is
an ordering dependency between adding an IP device or opening an
IP device and resetting the UDP timeout. DECmcc also does not
seem to save the new timeout value over restarts.
timon
=======================================================================
|