Subject: open issues in agentX MIB

From: "Smitha Gudur" <[email-masked]>
Date: Fri, 31 Jul 1998 10:32:29 PDT

Hi,

Some of the open issues that needs to be addressed for agentx MIB 
include:

1. Relevance of agentxConnNumber, and agentxSessionNumber.  
This gives the number of entries in each respective table. Do
we need these in the tables?           

2.   Add agentXLastChange to RegistrationTable to be consistent
with the other tables.

If there are any other open items that need to be addressed in the MIB, 
I urge everyone on the mailing list to send them as early as possible. 

These need to be resolved before the Chicago IETF meeting in
August.

Please send all email to agentx mailing list.

thanks
smitha

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

---

From: Mike Thatcher <[email-masked]>
Date: Fri, 31 Jul 1998 13:24:35 -0700

If there is a relationship between sessionID as defined in RFC2257and
agentxSessionIndex then the relationship needs to be clarified and the
description of agentxSessionIndex made consistent with the definition in
the RFC. (See sections 6.1, 6.2.16, 7.1.1(3))

MikeT

---

From: Martin Jacobsson <[email-masked]>
Date: Fri, 31 Jul 1998 23:56:59 +0200 (CEST)

> I urge everyone on the mailing list to send them as early as possible. 

Section 2, goal 4 says:

- Provide statistics about the protocol operation such as the number of
  packets to and from each subagent

This information is not available through the mib as defined.
One option is to add agentxSessionInPackets and agentxSessionOutPackets to
the session table. And another is to add agentxConnInPackets,
agentxConnOutPackets, agentxConnProtocolErrors and agentxConnParseErrors
to the connection table. All as Counter32's.

Then a port table would be nice, so that it is possible to see what ports
the master agent accepts connections from and if it listens on any
nondefault ports. A typical unix master agent will listen on both tcp port
705 and unix-domain socket "/var/agentx/master".

/Martin Jacobsson

---
.signature: No such file or directory

---

From: Bob Natale <[email-masked]>
Date: Fri, 31 Jul 1998 18:58:35 -0400

>At 7/31/98 11:56 PM, Martin Jacobsson wrote:

Hi Martin,

>Section 2, goal 4 says:
>
>- Provide statistics about the protocol operation such
>as the number of packets to and from each subagent
>
>One option is to add agentxSessionInPackets and
>agentxSessionOutPackets to the session table. And another is
>to add agentxConnInPackets, agentxConnOutPackets,
>agentxConnProtocolErrors and agentxConnParseErrors

First, let me note that there is considerable sentiment to
keep this MIB relatively minimal.

Second, you are right, if state such purposes (and the
one you quote seems like a sound one to me).  The approach
that I would like to propose for this purpose is to add
an agentxResponseTable.  This would be indexed by
agentxSessionID and consist of a set of objects (with
syntax of GAUGE32, I suggest), one for each of the possible
AgentX-Response-PDU res.error codes (including no_error).

Such a table would handle overall (by simple summing),
connection-specific (by mapping back to agentxConnectionTable
via the agentxConnIndex in the corresponding agentxSessionTable
row, and session-specific traffic and error counts for all
active sessions. 

>Then a port table would be nice, so that it is possible to see
>what ports the master agent accepts connections from

I think this can be had now, via the agentxConnTransportDomain
and agentxConnTransportAddress objects in the agentxConnectionTable.
No...?

>and if it listens on any nondefault ports.

I'll pass on that one (I don't really see the need for it).

>A typical unix master agent will listen on both tcp port

True...and the two objects mentioned above would, I think,
tend to reveal that, given at least one active connection
from each domain.

Cordially,

BobN
------------ ISO 9001 Registered Quality Supplier -----------
Bob Natale         | ACE*COMM              | 301-721-3000 [v]
Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f]
[email-masked]| Gaithersburg MD 20878 | www.acecomm.com
------------- Free downloads at www.winsnmp.com -------------

---

From: "Ashish Hanwadikar" <[email-masked]>
Date: Sun, 2 Aug 1998 13:32:36 +0530

Ashish K Hanwadikar
Senior Software Engineer,
Wipro Infotech, Technology Solutions,
Bangalore
INDIA

-----Original Message-----
From: Bob Natale [mailto:[email-masked]]
Sent: Saturday, August 01, 1998 4:29 AM
To: Martin Jacobsson
Cc: Smitha Gudur; [email-masked]
Subject: Re: open issues in agentX MIB

Hi Martin,

<Ashish> given at least one active connection .. That is the hitch. Suppose,
the sub agent wants to know which transport should he use to communicate
with the Master Agent? If no connections are active, then it is very
difficult to known on which transport domains the Master Agent is listening.
I think it will be generally be useful from the Sub Agent and Sub Agent API
developers point of view to add an agentxListenTable to the AgentX MIB.
I guess such a table was there in the DPI from which AgentX derives its
inspiration.
Thanks
Cordially,

BobN
------------- Free downloads at www.winsnmp.com -------------

---

From: Martin Jacobsson <[email-masked]>
Date: Wed, 5 Aug 1998 00:13:58 +0200 (CEST)

Hi Bob,

> row, and session-specific traffic and error counts for all

This table will be big since there a lot of possible res.error values.
First the 10 values in RFC2257 and then the 19 values in RFC1905. Most of
these values are normal and don't indicate a problem, so this would be
useless when debugging.

I propose to add agentxSessionInPackets to the agentxSessionTable because
this will show that there are activity on the session. Keeping track of
the parse and protocol errors seems unnecessary because a master agent may
choose to close the connection immediately without doing a recovery
attempt when a parse/protocol error is found. But the number of timeouts
is perhaps useful so you can find out if the timeout values are to small.

But global counters of parse and protocol errors could be useful. Say my
master agent closes the connection immediately if it recieves a bad
packet. Then the subagent reconnect if the session is closed with a reason
other than reasonShutdown or reasonByManager. A manager will not notice if
this happens very often or not if there are no global counters of parse
and protocol errors. (actually it can detect this beacuse the
agentxConnIndex becomes very big, but this is, in my opinion, not a clear
indication.)

> and agentxConnTransportAddress objects in the agentxConnectionTable.

No! It's the wrong end of the connection. agentxConnTransportAddress will
contain the subagent's address, not the master agent's address. Then what
happens if there are no subagents running or if there are no subagents
using a opened port? Say all subagents use the unix domain socket and none
use the tcp port. The tcp port would be missing.

The table could be used to reveal configuration errors. For instance, you
can see that the master agent listens to the tcp port when it shouldn't
due to security reasons.

/Martin Jacobsson

---