MIB vs wire-format - SNMP

This is a discussion on MIB vs wire-format - SNMP ; Hi all, I have developed a program that sends an SNMP v2c notification (trap) to a OpenView NNM station. NNM doesn't seem to think that the notifitcation is in accordande with the MIB. Since I'm an SNMP newbie, NNM is ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: MIB vs wire-format

  1. MIB vs wire-format

    Hi all,
    I have developed a program that sends an SNMP v2c notification (trap)
    to a OpenView NNM station. NNM doesn't seem to think that the
    notifitcation is in accordande with the MIB. Since I'm an SNMP newbie,
    NNM is probably right...

    Can a kind soul please provide me with a sanity check on this.


    I send:
    Frame 217 (362 bytes on wire, 362 bytes captured)
    Ethernet II, Src: 00:08:02:bd:20:86, Dst: 00:00:0c:07:ac:00 Internet
    Protocol, Src Addr: 192.168.3.117 (192.168.3.117), Dst Addr:
    192.168.129.45
    (192.168.129.45) User Datagram Protocol, Src Port: 4761 (4761), Dst
    Port:
    snmptrap (162) Simple Network Management Protocol
    Version: 2C (1)
    Community: public
    PDU type: TRAP-V2 (7)
    Request Id: 0x3570c5ba
    Error Status: NO ERROR (0)
    Error Index: 0
    Object identifier 1: 1.3.6.1.2.1.1.3.0 (SNMPv2-MIB::sysUpTime.0)
    Value: Timeticks: (0) 0:00:00.00
    Object identifier 2: 1.3.6.1.6.3.1.1.4.1.0
    (SNMPv2-MIB::snmpTrapOID.0)
    Value: OID: SNMPv2-SMI::enterprises.999.100.110.2.20
    Object identifier 3: 1.3.6.1.4.1.999.100.110.1.1
    (SNMPv2-SMI::enterprises.999.100.110.1.1)
    Value: STRING: "joe:7001"
    Object identifier 4: 1.3.6.1.4.1.999.100.110.1.2
    (SNMPv2-SMI::enterprises.999.100.110.1.2)
    Value: STRING: "Type=JRockitRuntime,*"
    Object identifier 5: 1.3.6.1.4.1.999.100.110.1.3
    (SNMPv2-SMI::enterprises.999.100.110.1.3)
    Value: STRING: "Uptime"
    Object identifier 6: 1.3.6.1.4.1.999.100.110.1.4
    (SNMPv2-SMI::enterprises.999.100.110.1.4)
    Value: STRING: "Value has changed from 8859977 to 8866008"
    Object identifier 7: 1.3.6.1.4.1.999.100.110.1.5
    (SNMPv2-SMI::enterprises.999.100.110.1.5)
    Value: STRING: "Oh my god! The server is still up and running"

    ---------------
    MIB:

    FOO-MIB DEFINITIONS ::= BEGIN

    IMPORTS
    enterprises, Counter
    FROM RFC1155-SMI
    OBJECT-TYPE
    FROM RFC-1212
    DisplayString
    FROM RFC1213-MIB
    TRAP-TYPE
    FROM RFC-1215;

    moo MODULE-IDENTITY
    LAST-UPDATED "200504150000Z"
    ORGANIZATION "xxx(moo)"
    CONTACT-INFO
    "...."

    DESCRIPTION
    "....."
    ::= { enterprises 999 }

    foo OBJECT IDENTIFIER ::= { moo 100 }

    fooTrap OBJECT IDENTIFIER ::= { foo 110 }
    fooTrapMsgs OBJECT IDENTIFIER ::= { fooTrap 1 }
    fooTraps OBJECT IDENTIFIER ::= { fooTrap 2 }

    --
    -- These are the varibles used in our traps
    --
    fooNode OBJECT-TYPE
    SYNTAX DisplayString ( SIZE ( 1.. 128 ) )

    ACCESS read-only
    STATUS mandatory


    DESCRIPTION
    "..."

    ::= { fooTrapMsgs 1 }


    monitoredBean OBJECT-TYPE
    SYNTAX DisplayString ( SIZE ( 1.. 128 ) )

    ACCESS read-only
    STATUS mandatory


    DESCRIPTION
    "The JMX MBean that is causing the alarm"

    ::= { fooTrapMsgs 2 }

    monitoredAttribute OBJECT-TYPE
    SYNTAX DisplayString ( SIZE ( 1.. 128 ) )

    ACCESS read-only
    STATUS mandatory


    DESCRIPTION
    "The JMX MBean attribute that is causing the alarm"

    ::= { fooTrapMsgs 3 }


    errorMessage OBJECT-TYPE
    SYNTAX DisplayString ( SIZE ( 1.. 256 ) )

    ACCESS read-only
    STATUS mandatory


    DESCRIPTION
    "A message telling what triggered the alarm trap"

    ::= { fooTrapMsgs 4 }

    descriptionMessage OBJECT-TYPE
    SYNTAX DisplayString ( SIZE ( 1.. 256 ) )

    ACCESS read-only
    STATUS mandatory


    DESCRIPTION
    "A message describing the alarm trap"

    ::= { fooTrapMsgs 5 }

    --
    -- These are the traps we send:
    --

    fooNodeDown NOTIFICATION-TYPE
    OBJECTS {fooNode}
    STATUS current
    DESCRIPTION
    "This trap is sent when a server is down."
    ::= { elwisTraps 10 }

    fooAlarm NOTIFICATION-TYPE
    OBJECTS {fooNode, monitoredBean,
    monitoredAttribute, errorMessage,
    descriptionMessage}
    STATUS current
    DESCRIPTION
    "This trap is sent when alarms are triggered"
    ::= { fooTraps 20 }

    END


  2. Re: MIB vs wire-format


    Stefan Norberg wrote:
    > snmptrap (162) Simple Network Management Protocol
    > Version: 2C (1)
    > Community: public
    > PDU type: TRAP-V2 (7)
    > Request Id: 0x3570c5ba
    > Error Status: NO ERROR (0)
    > Error Index: 0
    > Object identifier 1: 1.3.6.1.2.1.1.3.0 (SNMPv2-MIB::sysUpTime.0)
    > Value: Timeticks: (0) 0:00:00.00
    > Object identifier 2: 1.3.6.1.6.3.1.1.4.1.0
    > (SNMPv2-MIB::snmpTrapOID.0)
    > Value: OID: SNMPv2-SMI::enterprises.999.100.110.2.20


    I fixed it myself. The OID was incorrect. NNM likes it better when I
    insert a zero before the trap id (20).

    Stefan


  3. Re: MIB vs wire-format

    Stefan Norberg wrote:

    > I have developed a program that sends an SNMP v2c notification (trap)
    > to a OpenView NNM station. NNM doesn't seem to think that the
    > notifitcation is in accordande with the MIB. Since I'm an SNMP newbie,
    > NNM is probably right...


    > FOO-MIB DEFINITIONS ::= BEGIN


    [...]

    You MIB module is neither legal SMIv1 nor legal SMIv2. Note that SMIv1
    is historic and you should really write SMIv2. Use smilint of some other
    validator to make sure your MIB is valid. HP OV is known to accept
    arbitrary junk - so use a real SMIv2 implementation to ensure your MIB
    module is valid.

    /js

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

+ Reply to Thread