Re: Can We place Traps as part of Tables

On 13/10/06, santhosh <santhosh@rtsindia.com> wrote:
> how to I implement the above idea

Firstly, can you please show a little patience,
You are not contributing anything towards this project, nor paying for
the support you are receiving. So it feels a little unnecessary to
resend a reminder barely an hour after you posted the original
request.
I answer questions on this mailing list in my spare time - if my
employers (who *are* paying me) require my attention, then that takes
priority.


> so this was the MIB's which I have created

OK - the first thing is to correct the errors in this MIB:

> xdslEntry OBJECT-TYPE
> SYNTAX XDSLEntry

It's conventional for the per-row name (and syntax name) to match the
overall table name.
So this should ideally read

xdslTableEntry OBJECT-TYPE
SYNTAX XdslTableEntry

with a corresponding change to the "XdslTableEntry ::= SEQUENCE" definition


> INDEX { interface1,interface2,interface3 }
> ::= { xdsltrapTable 1 }

The INDEX clause is wrong.
This needs to list the *name* of the column object that indexes the
table - not the values (or something vaguely related).

So this would typically be something like "INDEX { interfaceNo }"


> XDSLEntry ::=
> SEQUENCE {
> InterfaceNo INTEGER,
> SystemType INTEGER,
> LocalPair1 INTEGER,
> LocalPair2 INTEGER,
> RemotePair1 INTEGER,
> RemotePair2 INTEGER
> }

Quite apart from the name of the per-row syntax (see above), none of
these column objects have valid names. In general SMI uses a leading
capital to indicate a syntax token - the name of management objects
should start with a lower case letter.
This would conventially have a common prefix (to indicate that they
all belong to the same table).

So this would be better as
XdslTableEntry ::= SEQUENCE {
xdslInterfaceNo INTEGER,
xdslSystemType INTEGER,
xdslLocalPair1 INTEGER,
xdslLocalPair2 INTEGER,
xdslRemotePair1 INTEGER,
xdslRemotePair2 INTEGER
}

(with corresponding changes to the individual OBJECT-TYPE definitions).


> TableCardNo OBJECT-TYPE
> SYNTAX INTEGER (1..3)

Errr... this seems to be the index object, but you've changed the name from the
XDSLEntry sequence above. The name of the table index(es) *must* be
consistent between the INDEX clause, the entry SEQUENCE and the
individual column object definitions.

> DESCRIPTION
> " "

You've omitted the DESCRIPTION from every one of your MIB object definitions.
This is *extremely* bad practise. Not only does it make it impossible
for the people using your MIB to know what the objects represent - it
also means that anyone actually trying to implement this MIB is
equally in the dark.
You should always complete the design of a program before starting
to code it - the same holds true here. The MIB file is effectively
the design document (with a very formalised structure).

> SystemType OBJECT-TYPE
> ACCESS not-accessible

Why is this object defined as "not-accessible"?
It means that you can't retrieve it via SNMP requests, or include it in a trap.
It doesn't appear to be a table index either - so it's completely irrelevant.

Similarly for the other "column" objects.
*None* of these are accessible in any way, which makes the whole table pointless
(as well as being invalid).


> when I started the code for this I got the confusion what OID i need to
> Specify for particular entity
> so to get the confirmation I asked you, which I am partially clear about

Errrmmm....
Sorry - I don't mean to be rude, but I don't think you are.

If this is a MIB that you have written yourself, then you are showing
some serious misunderstanding of how SNMP works. I would strongly
suggest that you get hold of a good book, and study it carefully
before proceeding any further.

If this is a MIB that someone else has designed for you, then I
suggest you ask for your money back. It is completely unfit for
purpose as it currently stands.


You also say:

> These are the alarms which I need to monitor "Local Pair 1", "Local Pair 2",
> Remote Pair 1" & "Remote Pair 2"

But what do you mean by that?
Without the descriptions for these four column objects, I can't begin
to guess what these values might mean - let alone what is intended by
"monitoring" them. You need to be much more precise about the exact
circumstances in which you should generate a "Local Pair 1" trap, etc.

I'm sorry if I'm sounding rather frustrated, but it is proving
extremely difficult to get a clear description of what exactly you are
trying to do. It all still feels very vague and hand-waving.

Dave

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=...057&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/...net-snmp-users