Thanks for your quick response. We're going live with our implementation,
so please excuse me if it takes a couple of days to get you those traces.
On Tue, 15 Jun 2004 18:27:46 -0400 Robert wrote:
RW> I'm using net-snmp on FreeBSD 3.2.
Which version of net-snmp? 5.1.1?
I'm using 5.0.6. 5.1.1 didn't compile under the old FreeBSD.
RW> 1. I have a subagent that supports a rather large table (up to 2000
RW> entries). I've implemented it using the iterator list. The problem is
RW> that there are several fields in the table entry that are no longer
RW> supported. Since the iterator walks the entire list for each field
RW> (supported or not) the request can actually timeout before the agent
RW> responds.
You should be able to avoid this by using the valid_columns field of the
netsnmp_table_registration_info. See include/agent/table.h for the structure
definitions. You can mix and match ranges (2-4, 9-12,...) and lists
(15,19,22,...), so long as there is no overlap (e.g (1,3,7)+(5-9)). It's not
an
oft-used feature, so give it a whirl and let us know (ASAP) if it doesn't
seem
to be working for you, and we can try to fix it before 5.1.2 (coming REAL
soon).
This structure is used in the table helper, which is above the iterator
helper,
so they *should* be compatible.
COOOL - I'll give this a whirl.
RW> I've optimised the iterator to minimize this behavior and skip
RW> the unsupported fields, but I still get timeouts when performing a
mibwalk
RW> which I attribute to the size of the list. My list is ordered, but
there
RW> seems no way for the iterator to use this information. Is there some
way
RW> to avoid this - should I be using the array style table implementation?
The array helper is one option, since it allows for more efficient
searching.
However, the out-of-the-box 5.1.x configuration keeps all the data in
memory.
(In 5.2 there will be a new helper that will be able to just cache the index
info).
However, with the array helper you could write a custom container to
interface
to your existing data set. The would be pretty easy if your data is already
in
memory, sorted and you have a single integer index.
Another option, if you stick with the iterator helper, is to add in a cache
helper to cache the data. This would help if (a) you have to load your data
from some slow medium and (b) you don't mind if the data is N seconds old
(you
get to pick N).
hmmm... I'm thinking of just creating my own version of the iterator helper
that accepts the first response greater than the input oid. I haven't
worked with the containers or the cache helper and don't know what the
learning curve would be, I can't seem to find them in the tutorial, faq or
AGENT.txt. I am caching the data on a one minute interval, it's the walking
of the list for each column that seems to cause the timeout.
RW> 2. When the problem (1) occurs, the subagent disconnects and seems
unable
RW> to re-establish communication with the master agent
That sounds like an older version of net-snmp. If this is 5.1.1, you should
stop by the irc channel for some one-on-one, to see if we can't get it fixed
for 5.1.2.
Note that you can increase the timeout between the master and subagent. In
your
snmpd.conf, add:
agentXtimeout 30
Increase the timeout until you find a value that works for you.
As for reconnecting, it should be retrying. Run with debug turned on, and
the
'agentx' token, and you should see the periodic ping messages.
I think I'll heed the warning that AgentX isn't ready for prime-time and
move to integrating our MIB support directly into snmpd.
RW> sometimes it crashes.
That's not good. A stack trace would be helpful.
RW> 3. Trying to set certain variables in the MIB_2 ip tables
RW> (ipRouteMetric1(2)(3)(...), ipRouteNextHop, etc.) causes snmpd to core.
RW> Our answer to this will be to turn off the ip tables. Is there a place
I
RW> should send the core?
RW>
RW> 4. While trying to set atIfIndex snmpwalk core'd. I probably won't
RW> troubleshoot this. Is there a place to send the core?
No, but you can create a bug report for each of these, and attach a stack
trace.
I'll get you those traces as soon as things settle down here, maybe early
next week.
again, thanks for your quick response and help.
Rob Waltz
-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Net-snmp-users mailing list
[EMAIL PROTECTED]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
