Conference turris::digital_unix

>    Can anyone tell me if the snmpd is single threaded?
 
Yes it is.
   
>    Can anyone speculate as to whether or not other snmpd implementations
>    may or may not be single threaded.
 
My experience is that they typically are.
   
>    I'm wondering if multiple systems are trying to issue snmp requests
>    to the same system, what would be the results?  It seems that a busy
>    single threaded daemon would end up ignoring other requests if it could
>    not satisfy them?

I suppose that could happen, but it seems unlikely in general.  SNMP is 
a single request/response protocol and typically the requested operations
(returning the value of a MIB variable) have very little latency.

Combined with the typically low traffic rate for SNMP, it seems unlikely
that the daemon's recv buffer will fill before the next request can
be serviced.

When we made snmpd extensible, requiring interprocess communication
to service any request, a little more attention had to be payed here.
snmpd enqueues requests at the application level, and also checks     
each received request against the queue for duplicates (since UDP-based
applications have to resend if timely response isn't received).

snmpd times all ipc w/ the MIB implementation processes (subagents),
and "disconnects" any that are misbehaving.  So the chances of 
our SNMP agent losing packets is very small.  

During stress testing, snmpd runs at about 500 request-response pairs
per second.

Hope this helps.  If you have a specific concern or issue please let me
know.

Mike

    RE:.1   Thanks very much.  I was looking for any reason to explain
    why two identically configured systems running Netview, polling the
    same set of nodes, might experience different results, (i.e.
    reachability tests).
    
    Al

hi Al,

>    RE:.1   Thanks very much.  I was looking for any reason to explain
>    why two identically configured systems running Netview, polling the
>    same set of nodes, might experience different results, (i.e.
>    reachability tests).
    
One reason could be the configuration of snmpd on the managed nodes.
If the IP address in a community name specification in snmpd.conf is 
not 0.0.0.0, the agent will only respond to requests using that
community name if the sender's address matches.

The default configuration is to permit read access to the world
via "public", but the customer may have changed it.

If you haven't characterized the SNMP traffic yet you can use tcpdump
or other tools to do so.  Send me some mail if you need a hand.

Regards,
Mike

    Thanks Mike,
    
    In this case, it appears that one Netview system will show various
    clients as down when they aren't, on some days and other days the
    same system is fine.
    
    I suspect traffic patterns, or a possible transit delay since one nms
    is on a different segment.  I've suggested that these clients on the
    affected Netview system adjust the polling parameters to make them less
    sensitive to traffic delays.
    
    Al
    

>    I suspect traffic patterns, or a possible transit delay since one nms
>    is on a different segment.  

I don't, I suspect a bug introduced into NetView (based on the NetView
notes conference description of the symptoms).  But as I've said before,
it's all somewhat idle speculation until someone actually finds out
what SNMP packets are being sent/received by the NetView station...

Mike    

    RE: bug.
    
    Have any pointers to a particular note?
    
    Funny that it would show up in one machine and not the other as they
    are supposedly identically configured.
    
    Al

I don't remember what note, it's NOTED::NETVIEW.

Mike