Re: Can We place Traps as part of Tables

On 13/10/06, santhosh <[email protected]> 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=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users