Hi Dave,
Thanks for your inputs. I guess I will have to look into the snmptrapd code.
I am using a locally (on solaris_5.8) compiled binary of snmptrapd v 5.2.2, as I was not able to locate any for solaris on the sourceforge download links.
But this snmptrapd binary cores when I try to run it with the "debug all" option , as seen below
If possible, can you please point me to a stable released snmptrapd 5.2.2 binary for Solaris (sun4u) ?
# ./snmptrapd -D ALL -Lo
trace: default_store.c, 205:
netsnmp_ds_set_boolean: Setting APP:1 = 1/True
trace: default_store.c, 232:
netsnmp_ds_toggle_boolean: Setting APP:2 = 6/True
trace: default_store.c, 232:
netsnmp_ds_toggle_boolean: Setting APP:6 = 70/True
trace: default_store.c, 205:
netsnmp_ds_set_boolean: Setting LIB:11 = 1/True
trace: default_store.c, 205:
netsnmp_ds_set_boolean: Setting APP:1 = 0/False
trace: agent_handler.c, 212:
handler::register: Registering (::null) at .0
trace: agent_handler.c, 337:
handler:inject: injecting bulk_to_next before null
trace: agent_registry.c, 587:
Segmentation Fault - core dumped
# uname -a
SunOS pun-sms-sun29 5.10 Generic sun4u sparc SUNW,Sun-Fire-V240
Thanks and regards,
>Prashant Rane
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Dave Shield
Sent: Friday, January 20, 2006 9:52 PM
To: Rane, Prashant
Cc: net-snmp-users@lists.sourceforge.net
Subject: Re: Help needed: Problem with snmptrapd 5.2.2 config parameterserverRecvBuf
On Fri, 2006-01-20 at 21:30 +0530, Rane, Prashant wrote:
> Need urgent help/advice on:
> 2. Any insights on possible reasons for the traps getting dropped
I make no claims to any sort of expertise on high-volume systems, but I offer the following suggestion for your consideration.
Off the top of my head, there are probably three levels of processing
involved:
- low-level acceptance of the raw UDP packets
- parsing and validation of SNMP requests
- processing of SNMP notifications
any one (or more) of which could be resulting in an inability to keep up with an incoming flood of notifications.
I'd be inclined to try stripping away each of these in turn, to see what difference this might make to the proportion of traps dropped.
So to start with, try using a version of snmptrapd with a minimal 'snmp_input()' routine, that just counts how many packets are received (but doesn't try to do anything with
them). You needn't bother about the 'pre_parse' routine
either.
The second stage could be achieved by using a trivial version of 'snmp_read', that just reads in the raw UDP packet but doesn't try to do anything with it. That might need a bit more understanding of the library internals, but shouldn't be too difficult.
That would effectively strip out most of the SNMP-related delays, and reveal the fundamental limits of the basic framework.
Dave
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
