Dear Juergen,
> Marc> Here, the 0.11 trap wasn't converted into useful text, because
> Marc> I can't seem to get the MIB contain the 72.0 branch (traps if
> Marc> I'm not mistaken). That's a problem I'll have to solve with
> Marc> Retix.
>
> I am not sure if Retix will be able to help you here. Scotty follows
> the SNMPv2 rules and hence a SNMPv1 trap is automatically converted
> into an SNMPv2 trap. This means that the enterprise, generic and
> specific fields of a SNMPv1 message are converted into a trap object
> identifier. See RFC 1908 section 3.1.2 paragraph (2) for details.
Thanks for the pointer.
> The scotty MIB parser is supposed to do the same conversion when it
> reads a TRAP-TYPE macro. The parser registers a node with the correct
> trap object identifier in the MIB tree. This did not happen in your
> case. The question is now, whether the Retix MIB does not use the
> TRAP-TYPE properly, or if there is a bug in the parser, or both.
Actually, it seems to be a problem with the MIB file:
Here are excerpts:
-- This MIB also includes a list of the traps supported by this product
-- family. These are defined using the recommended Trap-definition MACRO
-- but are commented out, for compilation purposes.
-- portLgclPortID has come on-line, i.e. the value of
-- the ifAdminStatus object for this port is now up(1)."
-- ::= { 10 }
logicalPortDown TRAP-TYPE
ENTERPRISE { retix }
VARIABLES { portLgclPortID }
DESCRIPTION
"This trap signifies that a logical port identified by
portLgclPortID has gone off-line, i.e. the value of
the ifAdminStatus object for this port is now down(2)."
::= { 11 }
-- forwardingProcessorUp TRAP-TYPE
-- ENTERPRISE { retix }
-- VARIABLES { stnSlotIndex }
As you can see, the trap is there, but if I uncomment it (as shown here),
scotty won't compile the MIB:
moremagic:/usr/local/lib/tnm2.1.5/mibs# scotty
% mib load retix-rx7000.mib
unable to parse ENTERPRISE {
retix-rx7000.mib:13304: bad format in TRAP-TYPE
Any idea about what I should try?
(The full file is at http://www.retix.com/rns/support/mibs/retix-rx7000
if you would like to try compiling it yourself).
> This one is defined in rfc1493.mib or rfc1525.mib and looks like a
> proper definition, where the conversions actually work as designed.
Good, I'm happy to see that it works sometimes :-)
> Marc> Thu May 22 12:27:17 PDT 1997 SNMPv1 trap from [198.147.96.77]:
> Marc> sysUpTime.0 = 67d 10:32:16.00
> Marc> snmpTrapOID.0 = 1.3.6.1.4.1.529.1.2.4.0.12
> Marc> consoleIndex.2 = 2
> Marc> snmpTrapEnterprise.0 = max4000
>
> Marc> Descriptor: max4000
> Marc> MIB Module: ASCEND-MIB
> Marc> Identifier: 1.3.6.1.4.1.529.1.2.4
> Marc> Max. Access: not-accessible
> Marc> File: /usr/local/lib/tnm2.1.5/mibs/ascend.mib
>
> Marc> So, a trap like 1.3.6.1.4.1.529.1.2.4 would make sense and
> Marc> would be resolved as ascend.products.max.max4000, and the
> Marc> resulting string is max4000
>
> This is the same problem. This is SNMPv1 trap with enterprise =
> 1.3.6.1.4.1.529.1.2.4 and specific = 12. It all depends on the Trap
> definition in the MIB.
According to Tkined's MIB tree, the traps are defined directly under 529, so
they show up in the tree as 529.0.x
The trap MIB is at:
ftp://ftp.ascend.com/pub/Software-Releases/SNMP/MIBS/Release-970407/ascend.trp
The enterprise MIB is at:
ftp://ftp.ascend.com/pub/Software-Releases/SNMP/MIBS/Release-970407/ascend.mib
The entire problem comes from the fact that the Max sends '1.2.4' in
addition to the trap.
> The scotty protocol engine seems to handle this quite nicely. The
> question is whether the MIB parser does a poor job or if the MIB
> definition of these traps is insufficient/broken. Please look how the
> traps are defined in the Retix or in the Ascend MIB in order to
> determine where the problem actually is.
For Retix, as stated above, there is a problem with the MIB (the traps are
commented because the guy didn't seem to know how to do it). As for Ascend,
everything looks good.
Just in case this helps, Gary_Wong@ascend.com (the tech support guy I was
in contact with) wrote me:
On my LAN, I have :
(1) max4000(5.0AP5)
(2) HP-UX with HP Openview running the latest Ascend MIB and trap
(3) Solaris with SunNet Manager with earlie(unknown) version of MIB and
trap
Max is sending traps to both HP and Sun.
On HP, I see snmpTrap = 1.3.6.1.4.1.529.12
On Sun, I see snmpTrap = 1.3.6.1.4.1.529.1.2.4.0.12
(For him it works with both managers).
Thank you in advance for your insight.
Marc
PS: Does the 'S' in SNMP stand for simple? :-)
-- !! This message is brought to you via the `tkined & scotty' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to <tkined-request@ibr.cs.tu-bs.de>. !! See http://wwwsnmp.cs.utwente.nl/~schoenw/scotty/ for more information.