SNMPv1 traps in SMIv2 MIB (TRAP-TYPE to NOTIFICATION-TYPE) - SNMP

This is a discussion on SNMPv1 traps in SMIv2 MIB (TRAP-TYPE to NOTIFICATION-TYPE) - SNMP ; Hi there, I know this one has already been discussed here, I've found web pages about it, I've read RFC2578 and RFC2576, yet it doesn't seem to work for me... I'm trying to make an SMIv2 MIB for an SNMPv1 ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: SNMPv1 traps in SMIv2 MIB (TRAP-TYPE to NOTIFICATION-TYPE)

  1. SNMPv1 traps in SMIv2 MIB (TRAP-TYPE to NOTIFICATION-TYPE)

    Hi there,

    I know this one has already been discussed here, I've found web pages
    about it, I've read RFC2578 and RFC2576, yet it doesn't seem to work
    for me...

    I'm trying to make an SMIv2 MIB for an SNMPv1 agent, therefore I must
    translate the TRAP-TYPE to NOTIFICATION-TYPE.
    I used the rule in RFC2576: take the SNMPv1 trap's ENTERPRISE OID,
    append a .0 and then the enterprise specific trap number.

    In my case, the SNMPv1 agent's ENTREPRISE parameter is not simply the
    enterprise OID but it has a .2 appended (afaik, it's allowed). A
    simplified SMIv1 MIB would look something like:


    ====
    my OBJECT IDENTIFIER ::= { enterprises 1234 }
    myTraps OBJECT IDENTIFIER ::= { my 2 }

    myTrap8 TRAP-TYPE
    ENTERPRISE myTraps
    DESCRIPTION "Test trap 8"
    ::= 8
    ====

    My minimal SMIv2 test MIB follows. It only contains two traps. I made
    them belonging to a NOTIFICATION-GROUP as required by RFC2576.

    ====
    MY-TESTv1-MIB DEFINITIONS ::= BEGIN

    IMPORTS
    MODULE-IDENTITY,
    NOTIFICATION-TYPE,
    enterprises
    FROM SNMPv2-SMI
    NOTIFICATION-GROUP
    FROM SNMPv2-CONF;


    -- 1.3.6.1.4.1.1234
    my MODULE-IDENTITY
    LAST-UPDATED "200802181431Z"
    ORGANIZATION
    "My Systems"
    CONTACT-INFO
    "John Doe"
    DESCRIPTION
    "Test MIB with SNMPv1 traps converted to SMIv2"
    ::= { enterprises 1234 }


    myTraps OBJECT IDENTIFIER ::= { my 2 }
    myTrapPrefix OBJECT IDENTIFIER ::= { myTraps 0 }


    -- 1.3.6.1.4.1.1234.2.0.8
    myTrap8 NOTIFICATION-TYPE
    STATUS current
    DESCRIPTION
    "Test trap, specific number 8"
    ::= { myTrapPrefix 8 }

    -- 1.3.6.1.4.1.1234.2.0.9
    myTrap9 NOTIFICATION-TYPE
    STATUS current
    DESCRIPTION
    "Test trap, specific number 9"
    ::= { myTrapPrefix 9 }


    -- 1.3.6.1.4.1.1234.5
    myTrapGroup NOTIFICATION-GROUP
    NOTIFICATIONS { myTrap8, myTrap9 }
    STATUS current
    DESCRIPTION
    "Group of traps"
    ::= { my 5 }

    END -- MY-TESTv1-MIB DEFINITIONS

    ====

    I've loaded this MIB onto two different SNMP Managers (Network
    Instruments' Observer and MG Soft's MIB Browser) and then I sent fake
    SBMPv1 traps identical to the real agent's ones. While both managers
    indeed received the traps, they have been unable to translate them. I
    don't know if it's due to an error in my MIB or if the managers are
    simply not capable of doing the translation...

    The fake traps I send with UCD's Net-SNMP look like:

    > snmptrap -d -v1 -c public 192.168.125.16 1.3.6.1.4.1.1234.2 "" 6 8 10000


    Sending 43 bytes to UDP: [192.168.125.16]:162
    0000: 30 29 02 01 00 04 06 70 75 62 6C 69 63 A4 1C 06
    0).....public˝..
    0016: 08 2B 06 01 04 01 89 52 02 40 04 C0 A8 7D 11 02 .+....ŰR.@.
    +┐}..
    0032: 01 06 02 01 08 43 02 27 10 30 00 .....C.'.
    0.


    > snmptrap -d -v1 -c public 192.168.125.16 1.3.6.1.4.1.1234.2 "" 6 9 10000


    Sending 43 bytes to UDP: [192.168.125.16]:162
    0000: 30 29 02 01 00 04 06 70 75 62 6C 69 63 A4 1C 06
    0).....public˝..
    0016: 08 2B 06 01 04 01 89 52 02 40 04 C0 A8 7D 11 02 .+....ŰR.@.
    +┐}..
    0032: 01 06 02 01 09 43 02 27 10 30 00 .....C.'.
    0.


    I don't see why it doesn't work. Is there a hidden error in my MIB or
    in the way I send my traps? Or is it due to the "extended" enterprise
    OID in the traps? Any idea is welcome...

    Thanks in advance, Eric

  2. Re: SNMPv1 traps in SMIv2 MIB (TRAP-TYPE to NOTIFICATION-TYPE)

    eric.voisard@gmail.com wrote:

    > I'm trying to make an SMIv2 MIB for an SNMPv1 agent, therefore I must
    > translate the TRAP-TYPE to NOTIFICATION-TYPE.
    > I used the rule in RFC2576: take the SNMPv1 trap's ENTERPRISE OID,
    > append a .0 and then the enterprise specific trap number.
    >
    > In my case, the SNMPv1 agent's ENTREPRISE parameter is not simply the
    > enterprise OID but it has a .2 appended (afaik, it's allowed). A
    > simplified SMIv1 MIB would look something like:


    [...]

    This translates back to SMIv1 as follows (smidump output):

    myTraps OBJECT IDENTIFIER
    ::= { my 2 }

    myTrapPrefix OBJECT IDENTIFIER
    ::= { myTraps 0 }

    myTrap8 TRAP-TYPE
    ENTERPRISE myTraps
    -- STATUS mandatory
    DESCRIPTION
    "Test trap, specific number 8"
    ::= 8

    myTrap9 TRAP-TYPE
    ENTERPRISE myTraps
    -- STATUS mandatory
    DESCRIPTION
    "Test trap, specific number 9"
    ::= 9

    I guess this is indeed what you wanted.

    > I've loaded this MIB onto two different SNMP Managers (Network
    > Instruments' Observer and MG Soft's MIB Browser) and then I sent fake
    > SBMPv1 traps identical to the real agent's ones. While both managers
    > indeed received the traps, they have been unable to translate them. I
    > don't know if it's due to an error in my MIB or if the managers are
    > simply not capable of doing the translation...


    Not sure what you mean by "translate them". The MIB module looks fine
    as far as I can tell.

    /js

    --
    Juergen Schoenwaelder Jacobs University Bremen gGmbH
    Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany
    Fax: +49 421 200 3103

  3. Re: SNMPv1 traps in SMIv2 MIB (TRAP-TYPE to NOTIFICATION-TYPE)


    > I don't see why it doesn't work. Is there a hidden error in my MIB or
    > in the way I send my traps? Or is it due to the "extended" enterprise
    > OID in the traps? Any idea is welcome...
    >
    > Thanks in advance, Eric


    Your MIB definition looks good. Perhaps you need to load your module
    manually into those tools first.

    I added your MIB and sent the traps to Unbrowse SNMP.
    It translated and displayed them as expected (as "myTrap8" and
    "myTrap9")

    -

    Vivek Rajan


  4. Re: SNMPv1 traps in SMIv2 MIB (TRAP-TYPE to NOTIFICATION-TYPE)

    Hi,

    Thanks for your followups!

    Happy to see that what I did looks correct.

    Juergen, by "translating" I meant the SNMP Monitor providing actual
    names instead of raw OID and trap numbers once the MIB has been
    loaded.
    The SMIv1 version I had made of my MIB looks like your smidump output,
    and this one works fine.

    Vivek, I downloaded Unbrowse SNMP evaluation version and tried with
    it. It worked fine and I got same output as you, trap names and
    description were displayed as I wanted.

    It looks that not all SNMP Monitors are equal in regards to the way
    they handle the MIBs and SNMP itself (even wondering how close to the
    RFCs they respectively are). So it looks I'm rather in software
    compatibility or config issues than in SNMP/SMI theory of operation
    ones. I think I'll take Net-SNMP for reference...

    Many thanks, Eric


    On Feb 26, 4:50 am, VivekRajan wrote:
    > > I don't see why it doesn't work. Is there a hidden error in my MIB or
    > > in the way I send my traps? Or is it due to the "extended" enterprise
    > > OID in the traps? Any idea is welcome...

    >
    > > Thanks in advance, Eric

    >
    > Your MIB definition looks good. Perhaps you need to load your module
    > manually into those tools first.
    >
    > I added your MIB and sent the traps to Unbrowse SNMP.
    > It translated and displayed them as expected (as "myTrap8" and
    > "myTrap9")
    >
    > -
    >
    > Vivek Rajan



+ Reply to Thread