opinions wanted - typical manager capabilities - SNMP

This is a discussion on opinions wanted - typical manager capabilities - SNMP ; hello folks i've designed and implemented an snmp agent a client who wants to interface with the agent is saying "the way you've done this is not standard snmp, our manager can't deal with it" i am fairly sure they ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: opinions wanted - typical manager capabilities

  1. opinions wanted - typical manager capabilities

    hello folks

    i've designed and implemented an snmp agent

    a client who wants to interface with the agent is saying "the way
    you've done this is not standard snmp, our manager can't deal with it"

    i am fairly sure they are talking rubbish, and they just want us to
    make highly specific changes to fit in with their (rather limited)
    manager

    I WOULD REALY APPRECIATE YOUR OPINION!

    the important bit of the MIB we've designed is this:

    there is a table with three index columns and only one readable
    (non-index) column

    every time a value changes in the readable column, a trap goes out
    containing the OID of that column INSTANCE (column OID plus index
    values for that row) and the value in the column instance

    if the manager has the MIB definition, surely it should be able to
    look up the OID in the MIB, decode the index columns, and present all
    four bits of information (three index columns identifying the row,
    plus the value in the non-index column) to the user

    is this an unreasonable expectation of the manager?

    the client says "it is standard snmp to deliver each bit of
    information in a separate OID/value pair within the trap - the trap
    should contain 4 OID/value pairs not one"

    in other words, they are saying that i should give an OID/value pair
    for each of the three index columns PLUS one for the readable column

    surely this is madness!

    any thoughts???

    aparimana

  2. Re: opinions wanted - typical manager capabilities

    In article ,
    ap@camart.ignore-this-bit.co.uk says...

    Hi, ap.

    > every time a value changes in the readable column, a trap goes out
    > containing the OID of that column INSTANCE (column OID plus index
    > values for that row) and the value in the column instance


    The value identified by OID being that of the one accessible column
    instance, right? So, e.g., if your table defines objects "a, b, c, d"
    with "d" being the accessible column, then you're sending an instance of
    "d"? In that case ---

    > is this an unreasonable expectation of the manager?


    Not at all. This is the right way to do it. It is considered bad
    pratice in expert circles to provide redundant information in traps such
    as would be the case here if you sent a, b and c as well. The
    information is in the instance identifier portion of the OID, so it
    serves little purpose to have those other columns be present as well,
    other than to waste bandwidth and increase the likelihood that the trap
    will get dropped during network congestion.

    > surely this is madness!


    Agreed. They're lazy.

    --
    Michael Kirkham
    Muonics
    http://www.muonics.com/

  3. Re: opinions wanted - typical manager capabilities

    many thanks michael!

    that was just the reassurance i needed!

    ap

    >
    >Hi, ap.
    >
    >> every time a value changes in the readable column, a trap goes out
    >> containing the OID of that column INSTANCE (column OID plus index
    >> values for that row) and the value in the column instance

    >
    >The value identified by OID being that of the one accessible column
    >instance, right? So, e.g., if your table defines objects "a, b, c, d"
    >with "d" being the accessible column, then you're sending an instance of
    >"d"? In that case ---
    >
    >> is this an unreasonable expectation of the manager?

    >
    >Not at all. This is the right way to do it. It is considered bad
    >pratice in expert circles to provide redundant information in traps such
    >as would be the case here if you sent a, b and c as well. The
    >information is in the instance identifier portion of the OID, so it
    >serves little purpose to have those other columns be present as well,
    >other than to waste bandwidth and increase the likelihood that the trap
    >will get dropped during network congestion.
    >
    >> surely this is madness!

    >
    >Agreed. They're lazy.



  4. Re: opinions wanted - typical manager capabilities

    In article ,
    ap@camart.ignore-this-bit.co.uk says...

    > many thanks michael!
    >
    > that was just the reassurance i needed!


    If they continue to be stubborn, I'd ask them how they deal with
    non-accessible tabular index values that they retrieve via get/get-
    next/get-bulk requests. Surely they must have the ability to parse the
    instance identifiers already, because there is no other way to extract
    that information and most tables these days have non-accessible indexes.

    --
    Michael Kirkham
    Muonics
    http://www.muonics.com/

  5. Re: opinions wanted - typical manager capabilities

    aparimana wrote:

    > the important bit of the MIB we've designed is this:


    > there is a table with three index columns and only one readable
    > (non-index) column


    > every time a value changes in the readable column, a trap goes out
    > containing the OID of that column INSTANCE (column OID plus index
    > values for that row) and the value in the column instance


    > if the manager has the MIB definition, surely it should be able to
    > look up the OID in the MIB, decode the index columns, and present all
    > four bits of information (three index columns identifying the row,
    > plus the value in the non-index column) to the user


    > is this an unreasonable expectation of the manager?


    The SMIv2 actually requires to make index columns not-accessible and
    hence there is no way to put these auxiliary objets into an OBJECTS
    clause. This is all spelled out in RFC 2578 (April 1999) and the same
    text used to exit in RFC 1902 (1996) and probably even earlier versions
    of the document.

    Now to your question: Is it unreasonable expectation that managers
    implement SMIv2 and related stuff correctly? Unfortunately, there
    are still a noticeable amount of implementations that just suck -
    and some even with an interesting market share so that they end
    up being strong enough to push others to also make broken
    implementations. This certainly does not lead to a happy end.

    > the client says "it is standard snmp to deliver each bit of
    > information in a separate OID/value pair within the trap - the trap
    > should contain 4 OID/value pairs not one"


    It is certainly not standard as you can easily proof by showing them
    the standard. ;-)

    > in other words, they are saying that i should give an OID/value pair
    > for each of the three index columns PLUS one for the readable column


    The end game is not who is right but who is stronger. I wish you good
    luck.

    /js

    --
    Juergen Schoenwaelder International University Bremen
    P.O. Box 750 561, 28725 Bremen, Germany

  6. Re: opinions wanted - typical manager capabilities

    In article <1066055223.695794@salvator.ibr.cs.tu-bs.de>,
    schoenw@ibr.cs.tu-bs.de says...

    > The SMIv2 actually requires to make index columns not-accessible and
    > hence there is no way to put these auxiliary objets into an OBJECTS
    > clause. This is all spelled out in RFC 2578 (April 1999) and the same
    > text used to exit in RFC 1902 (1996) and probably even earlier versions
    > of the document.


    Re: "no way to..." would you say that "accessible-for-notify" is not
    legal for index objects? I've looked in the past and hadn't read
    anything to indicate that "accessible-for-notify" was only allowed for
    the objects added by proxies when switching versions (snmpTrapAddress,
    snmpTrapEnterprise, etc.) and snmpTrapOID, which are scalars. I
    believe some SMIv1 modules had not-accessible index objects in traps
    (Printer-MIB for instance, though it's incorrect in that it lists them as
    not-accessible despite the current version being SMIv2, which is wrong).
    Converting to SMIv2 it would be more correct, IMHO, to change it to
    "accessible-for-notify" than to "read-only"; and there is no way,
    generally speaking, to determine that a MIB module was or was not
    originally written in SMIv1.

    --
    Michael Kirkham
    Muonics
    http://www.muonics.com/

  7. Re: opinions wanted - typical manager capabilities

    >If they continue to be stubborn, I'd ask them how they deal with
    >non-accessible tabular index values that they retrieve via get/get-
    >next/get-bulk requests. Surely they must have the ability to parse the
    >instance identifiers already, because there is no other way to extract
    >that information and most tables these days have non-accessible indexes.


    armed with my newfound cast-iron confidence, i've had the conversation
    with them, and they have gone off to think about how to configure
    their manager!

    i'm very happy

    thanks again
    ap


  8. Re: opinions wanted - typical manager capabilities

    aparimana wrote in message news:...
    > hello folks
    >
    > i've designed and implemented an snmp agent
    >
    > a client who wants to interface with the agent is saying "the way
    > you've done this is not standard snmp, our manager can't deal with it"
    >
    > i am fairly sure they are talking rubbish, and they just want us to
    > make highly specific changes to fit in with their (rather limited)
    > manager
    >
    > I WOULD REALY APPRECIATE YOUR OPINION!
    >
    > the important bit of the MIB we've designed is this:
    >
    > there is a table with three index columns and only one readable
    > (non-index) column
    >
    > every time a value changes in the readable column, a trap goes out
    > containing the OID of that column INSTANCE (column OID plus index
    > values for that row) and the value in the column instance
    >
    > if the manager has the MIB definition, surely it should be able to
    > look up the OID in the MIB, decode the index columns, and present all
    > four bits of information (three index columns identifying the row,
    > plus the value in the non-index column) to the user
    >
    > is this an unreasonable expectation of the manager?
    >
    > the client says "it is standard snmp to deliver each bit of
    > information in a separate OID/value pair within the trap - the trap
    > should contain 4 OID/value pairs not one"
    >
    > in other words, they are saying that i should give an OID/value pair
    > for each of the three index columns PLUS one for the readable column
    >
    > surely this is madness!
    >
    > any thoughts???
    >
    > aparimana



    While you are right from the standards point of view, the request your
    client makes is not rubbish at all. In reality one of the leading NMS
    software, HP OpenView NNM, could not be costumized by a user to
    extract index values from an OID in a recieved trap, and IIRC the same
    goes to its MIB browser. So you might (rightly) call it rubbish but
    this is what people came to expect.

    It is pitty that you have implemented the agent before agreeing on the
    MIBs.

    Good luck,
    Mark.

  9. Re: opinions wanted - typical manager capabilities

    Michael Kirkham wrote:

    > Re: "no way to..." would you say that "accessible-for-notify" is not
    > legal for index objects? I've looked in the past and hadn't read
    > anything to indicate that "accessible-for-notify" was only allowed for
    > the objects added by proxies when switching versions (snmpTrapAddress,
    > snmpTrapEnterprise, etc.) and snmpTrapOID, which are scalars. I
    > believe some SMIv1 modules had not-accessible index objects in traps
    > (Printer-MIB for instance, though it's incorrect in that it lists them as
    > not-accessible despite the current version being SMIv2, which is wrong).
    > Converting to SMIv2 it would be more correct, IMHO, to change it to
    > "accessible-for-notify" than to "read-only"; and there is no way,
    > generally speaking, to determine that a MIB module was or was not
    > originally written in SMIv1.


    You are right. But "accessible-for-notify" is just a hack to be used
    in cases where you need to apply a hack. ;-)

    /js

    --
    Juergen Schoenwaelder International University Bremen
    P.O. Box 750 561, 28725 Bremen, Germany

+ Reply to Thread