RE: Help needed: Problem with snmptrapd 5.2.2 config parameter serverRecvBuf

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: [email protected]
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
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users