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
