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
