Subject: RE: Fwd: Regarding Agentx

From: "Ayers, Mike" <[email-masked]>
Date: Wed, 23 Aug 2000 11:39:30 -0500

> From: Daris A Nevil [mailto:[email-masked]]

> > 
> > >(our particular proxy agent protocol responds very slowly).
> > 
> > I assume you are saying that this slowness is not inherently
> > related to AgentX itself?
> 
> You are correct in that it has nothing to do with AgentX. Our
> subagent collects data across a slow async bus, so the snmpd
> program sometimes times out the subagent.  The original code
> always shuts down the subagent after 3 timed out AgentX packets
> (or whatever AgentxSubagmentMaxTimeouts was set to in 
> /etc/snmpd.conf).
> Our modified code lets us disable this "feature" by setting
> AgentxSubagentMaxTimeouts and AgentxSubagentMaxParseErrors to zero.
> 

	I feel obligated to point out that this is not the best solution to
this problem.  If you have a slow link to your subagent, then you should set
the timeout to a correspondingly high value.  The best thing to do would be
to set the timeout for the region which is serviced over the slow link.
However, you could, if necessary, set the master agent default timeout -
it's really a question of how the CMU package supports timeouts.  Telling
the master agent never to disconnect means disabling connection management,
which probably wouldn't be well received in the event of a real connection
failure.  If you set the timeout to a sufficiently high value, then the
master agent will wait for the slow link but will still be able to detect a
failed link.  The key problem is that the patch you made violates:

=====8<-----SNIP-----
7.2.5.1.  Common Processing of All AgentX Response PDUs

   1) If a response is not received on a session within the timeout
      interval for this dispatch, it is treated as if the subagent had
      returned `genErr' and processed as described below.

      A timeout may be due to a variety of reasons, and does not
      necessarily denote a failed or malfunctioning subagent.  As such,
      the master agent's response to a subagent timeout is
      implementation-specific, but with the following constraint:

      A session that times out on three consecutive AgentX requests is
      considered unable to respond, and the master agent must close the
      AgentX session as described in section 7.1.8, "Processing the
      agentx-Close-PDU", step (2).
=====8<-----SNIP-----

	...and a must is a must...

/|/|ike

---

From: Daris A Nevil <[email-masked]>
Date: Wed, 23 Aug 2000 11:51:54 -0500

Hi Mike,

Thanks for the feedback.  Since we are running in an embedded system
we never want to have our subagent disconnected.  And it should never
disconnect anyway, since we are using Unix domain sockets.  If we were
using the TCP socket protocol then I could see the importance of the
connection management code.

We are currently experienting with the timeout mechanism, but its not
too cut-and-dry since we have variable response times from our managed
cards depending on the data (sent to our subagent).

Regards,
Daris

-- 
Daris A Nevil
Simple Network Magic Corporation
401 Kentucky Lane
McKinney, TX 75069
214-793-7757
[email-masked]
www.snmc.com
quickstack.com
qslinux.org