SNMPv1 traps in SMIv2 MIB (TRAP-TYPE to NOTIFICATION-TYPE)
- From: eric.voisard@xxxxxxxxx
- Date: Mon, 25 Feb 2008 04:08:09 -0800 (PST)
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
.
- Follow-Ups:
- Re: SNMPv1 traps in SMIv2 MIB (TRAP-TYPE to NOTIFICATION-TYPE)
- From: VivekRajan
- Re: SNMPv1 traps in SMIv2 MIB (TRAP-TYPE to NOTIFICATION-TYPE)
- From: Dr. Juergen Schoenwaelder
- Re: SNMPv1 traps in SMIv2 MIB (TRAP-TYPE to NOTIFICATION-TYPE)
- Prev by Date: ATM
- Next by Date: Re: SNMPv1 traps in SMIv2 MIB (TRAP-TYPE to NOTIFICATION-TYPE)
- Previous by thread: ATM
- Next by thread: Re: SNMPv1 traps in SMIv2 MIB (TRAP-TYPE to NOTIFICATION-TYPE)
- Index(es):
Relevant Pages
|
|
