Using your input this is what I come up with: any more comments appreciated :)
Advania-Traps-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
DisplayString, enterprises FROM SNMPv2-SMI;
-- Module identity
advania MODULE-IDENTITY
LAST-UPDATED "201404090000Z"
ORGANIZATION "Advania hf"
CONTACT-INFO "Aki Barkarson - [email protected]"
REVISION "201404090000Z"
DESCRIPTION
"This revision of this MIB module was published as
a test for custom traps."
DESCRIPTION "Intended for internal Advania use only."
::= { enterprises 1513 }
-- Structure
traps1 OBJECT IDENTIFIER ::= { advania 1 }
objects OBJECT IDENTIFIER ::= { traps1 1 }
notifications OBJECT IDENTIFIER ::= { traps1 2 }
-- sub-id zero for SNMPv1 compatibility
notificationsPrefix OBJECT IDENTIFIER ::= { notifications 0 }
-- Objects
trapState OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..31))
MAX-ACCESS notify
STATUS current
DESCRIPTION
"A brief description."
::= { objects 1 }
shortMsg OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..31))
MAX-ACCESS notify
STATUS current
DESCRIPTION
"A brief description."
::= { objects 2 }
longMsg OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..1279))
MAX-ACCESS notify
STATUS current
DESCRIPTION
"Detailed info."
::= { objects 3 }
-- Notifications
customTrap NOTIFICATION-TYPE
STATUS current
VARIABLES { trapState, shortMsg, longMsg }
DESCRIPTION "Custom trap alert."
::= { notificationsPrefix 1 }
END
Áki Hermann Barkarson
Sérfræðingur / Service Engineer
CCDP / CCIE # 27552
Skilmálar/Disclaimer
-----Original Message-----
From: Olivier Miakinen [mailto:[email protected]]
Sent: 8. apríl 2014 22:04
To: Áki Hermann Barkarson; [email protected]
Subject: Re: creating custom mib
Hello Áki Hermann,
Le 08/04/2014 01:45, Áki Hermann Barkarson a écrit :
>
> [...]
>
> To learn more about this I want to create my own MIB and I have an
> enterprise OID (1513) that I can use.
>
> So I send traps with SNMPv2-SMI::enterprises.1513.... and passing
> along some variable and this is where I'm struggling with syntax and
> general lack of understanding. I want to format my mib in the correct
> way..
I wrote mibs a few years ago, and I think I can give you some advice, but
probably I will forget things, and maybe I will be wrong on some points. I hope
others would correct me if needed.
> maybe it should be split down into one mib defining objects and then I
> define the notifications in another mib..
I believe it is not necessary to write two separate mibs.
> and and.. so many
> questions :) I can see various examples out there but I'd love to have
> a conversation with someone who actually knows this stuff.
>
>
> This is what I have so far:
>
>
> Advania-Traps-MIB DEFINITIONS ::= BEGIN
Ok.
>
> IMPORTS
> enterprises FROM RFC1155-SMI
This is the old deprecated SMIv1 version of the SNMP syntax. You should import
enterprises from SNMPv2-SMI instead, and don't forget the ';' at the end of the
IMPORTS clause.
But also, you need to import the OBJECT-TYPE, DisplayString and
NOTIFICATION-TYPE that you use, and the MODULE-IDENTITY macro that you ought to
use. ;-)
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
DisplayString, enterprises FROM SNMPv2-SMI;
>
> advania OBJECT IDENTIFIER ::= { enterprises
> 1513 }
I think that advania could be defined to be the one and only MODULE-IDENTITY of
the mib, especially if this mib will be the only one (or the main) mib under
enterprises 1513.
Though, I prefer not taking the responsibility of this choice.
You may read the standard, and wait for other answers, before deciding what to
do.
<http://tools.ietf.org/html/rfc2578#section-5>
<http://tools.ietf.org/html/rfc2578#section-5.6>
> objects OBJECT IDENTIFIER ::= { advania 1 }
> notifications OBJECT IDENTIFIER ::= { advania 2 }
Unless you are absolutely sure that the traps will never been generated using
SNMPv1 protocol but only SNMPv2c or SNMPv3 -- and even if you are sure of that
-- it would be highly desirable that you define a prefix with a sub-id having
the value zero for the notifications :
<http://tools.ietf.org/html/rfc2578#section-8.5>
Hence :
objects OBJECT IDENTIFIER ::= { advania 1 }
notifications OBJECT IDENTIFIER ::= { advania 2 }
notificationsPrefix OBJECT IDENTIFIER ::= { notifications 0 }
>
> -- Objects
>
> trapState OBJECT-TYPE
> SYNTAX DisplayString (SIZE (0..31))
> MAX-ACCESS read-write
> STATUS current
> DESCRIPTION
> "A brief description."
> ::= { msg 1 }
{ objects 1 } I suppose
>
> shortMsg OBJECT-TYPE
> SYNTAX DisplayString (SIZE (0..31))
> MAX-ACCESS read-write
> STATUS current
> DESCRIPTION
> "A brief description."
> ::= { msg 1 }
{ objects 2 } I suppose
>
> longMsg OBJECT-TYPE
> SYNTAX DisplayString (SIZE (0..1279))
I'm not sure whether it is allowed to redefine a DisplayString with a maximum
size greater than 255. What is the opinion of other readers of this mailing
list ?
> MAX-ACCESS read-write
> STATUS current
> DESCRIPTION
> "Detailed info."
> ::= { msg 2 }
{ objects 3 } I suppose
Also, if these objects are not actual objects than can be read and written
independently of traps, the MAX-ACCESS should probably be accessible-for-notify
and not read-write.
>
>
> -- Notifications
>
> customTrap NOTIFICATION-TYPE
> STATUS current
> VARIABLES { trapState, shortMsg, longMsg }
> DESCRIPTION "Custom trap alert."
> ::= { notifications 1 }
{ notificationsPrefix 1 }
(see above, about the required zero subid)
>
> END
>
> Not sure if this is how it's meant to be formatted, any help would be
> appreciated..
I hope other answers will follow mine.
Best regards,
--
Olivier Miakinen
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
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
