UNSOLVED

rlenard1

updated

19 years ago

R

rlenard1

7 Posts

0

1197

January 21st, 2008 15:00

trap_mgr.conf any ideas why this is so?

So I am expecting a trap with trap OID
.1.3.6.1.4.1.6889.2.18.1.1.4.0.5

so went to update trap_mgr.conf to support it.

However I've noticed another colleque has done the trap with OID of
.1.3.6.1.4.1.6889.2.18.1.1.4.0.4

But started the trap definition in trap_mgr.conf like this --
BEGIN_TRAP .1.3.6.1.4.1.6889.2.18.1.1.4 6 4
...

Now I'd have though it should be --
BEGIN_TRAP .1.3.6.1.4.1.6889.2.18.1.1.4.0 6 4
or
BEGIN_TRAP .1.3.6.1.4.1.6889.2.18.1.1.4.0 6 5
(as appropriate).

Any ideas why the final .0 is dropped / why this is so? [I'm assuming the colleque has actually got it right].
  • Dinand1

    89 Posts

    422

    0

    Posted January 21st, 2008 23:00

    Hi,

    Is .1.3.6.1.4.1.6889.2.18.1.1.4.0.5 the trap OID you're receiving?

    I couldn't find any trap with that definition although 6889 seems to be AVAYA.
    Sometimes companies implement mibs and traps in quite a lousy way.

    the last number you have, the number 5, is the specific trap. Since it is supposed to be an enterprise specific you should put a 6 in your trap_mgr 'BEGIN_TRAP' statement.
    1.3.6.1.4.1.6889.2.18.1.1.4.0 should be the OID number for the mib.

    But, i have seen companies which implement the standard snmp mib in their mibs, so in this case, this could be like a generic trap of type 'egpNeighborLoss' and the configuration will be a differente one.

    If you have never seen any notifications coming from that trap i would recommend you to add a trap definition which will catch all traps and store it in a log file. See example below:


    # Catch all traps
    #---------------------------------------------------------------------
    BEGIN_TRAP * * *
    ClassName: TestTraps
    Severity: 5
    UnknownAgent: CREATE
    State: NOTIFY
    LogFile: catch_all.log
    EventType: MOMENTARY
    Expiration: 5
    EventText: $V*$
    END_TRAP
  • 420

    0

    Posted January 22nd, 2008 10:00

    Hi MrRohan,

    when you say you are expecting a trap OID, how do you know which trap OID it should be ? Because you capture a SNMP packet on the wire or because the MIB said so.
    Because there is a ".0 issue" (not an issue in fact, just something to know) related to SNMPv1 / SNMPv2 trap where the trap ID on the wire (or sent if you did create your own SNMP agent) is not the same received by the trap adapter (which should follow the RFC).

    This may be the answer of your concern...

    My 2 cents,

    --Fred

    Frederic Meunier
    Solutions Watch4Net Inc
    APG & Smarts InCharge integration
    http://www.watch4net.com
  • rlenard1

    7 Posts

    420

    0

    Posted March 25th, 2008 20:00

    Is .1.3.6.1.4.1.6889.2.18.1.1.4.0.5 the trap OID
    you're receiving?


    Yes

    I couldn't find any trap with that definition
    although 6889 seems to be AVAYA.
    Sometimes companies implement mibs and traps in quite
    a lousy way.


    I got a shock when I saw this one too !!

    the last number you have, the number 5, is the
    specific trap. Since it is supposed to be an
    enterprise specific you should put a 6 in your
    trap_mgr 'BEGIN_TRAP' statement.
    1.3.6.1.4.1.6889.2.18.1.1.4.0 should be the OID
    number for the mib.


    That is what I would have expected, however SMARTS won't accept this it does something to drop the .0 (perhaps because it's some code assuming that it's a value behind an OID, rather than an OID as a value).
  • rlenard1

    7 Posts

    420

    0

    Posted March 25th, 2008 20:00

    when you say you are expecting a trap OID, how do you
    know which trap OID it should be ? Because you
    capture a SNMP packet on the wire or because the MIB
    said so.


    Because that's what the value is in the MIB. i.e. if a trap of that type is created then I should expect the enterprise set to that value.

    Because there is a ".0 issue" (not an issue in fact,
    just something to know) related to SNMPv1 / SNMPv2
    trap where the trap ID on the wire (or sent if you
    did create your own SNMP agent) is not the same
    received by the trap adapter (which should follow the
    RFC).


    Can you point me to the specific reference?
  • 420

    0

    Posted March 26th, 2008 12:00

    (1) http://www.ietf.org/rfc/rfc3584.txt

    (2) what is your agent's SNMP version ? V1 or V2c ?
    - if MIB format is SNMPv2 and agent is V1, then this is what I told you (see RFC)
    - in any other case (V1/V1 or V2/V2, or MIB V1/agent V2), it should work as stated, but a snoop of the SNMP traffic should tell you what's sent by the agent.

    HTH,

    --Fred

    Frederic Meunier
    Solutions Watch4Net Inc
    APG & Smarts InCharge integration
    http://www.watch4net.com