Marc> Actually, it seems to be a problem with the MIB file:
Marc> Here are excerpts:
[snip]
Marc> logicalPortDown TRAP-TYPE
Marc> ENTERPRISE { retix }
Marc> VARIABLES { portLgclPortID }
Marc> DESCRIPTION
Marc> "This trap signifies that a logical port identified by
Marc> portLgclPortID has gone off-line, i.e. the value of
Marc> the ifAdminStatus object for this port is now down(2)."
Marc> ::= { 11 }
Marc> As you can see, the trap is there, but if I uncomment it (as
Marc> shown here), scotty won't compile the MIB:
Marc> moremagic:/usr/local/lib/tnm2.1.5/mibs# scotty
Marc> % mib load retix-rx7000.mib
Marc> unable to parse ENTERPRISE {
Marc> retix-rx7000.mib:13304: bad format in TRAP-TYPE
Marc> Any idea about what I should try?
I fetched the full file and there are actually two problems here. The
first one is a bug in scotty's MIB parser. The ENTERPRISE value is
defined as { retix }, which seems to be perfectly legal, but scotty's
parser does not like it. Removing the braces around the label retix
makes the parser happy. (I have to dig into the parser to see if I can
fix this problem easily.) The seconds problem is that the value of the
TRAP-TYPE macro is a single INTEGER value (RFC 1215). I think that it
is not legal ASN.1 to put the INTEGER value in braces, but I have
currently no ASN.1 standard handy. So I am not 100% sure who is wrong
here. Anyway, remove the braces around the value and things should be
working.
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> According to Tkined's MIB tree, the traps are defined directly
Marc> under 529, so they show up in the tree as 529.0.x
The traps are defined with ENTERPRISE ascend (1.3.6.1.4.1.529) and RFC
1215 section 2.1.1 says:
The ENTERPRISE clause, which must be present, defines the management
enterprise under whose registration authority this trap is defined
(for a discussion on delegation of registration authority, see the
SMI [3]). This value is placed inside the enterprise field of the
SNMP Trap-PDU.
Your ascend device sends traps with an object identifier equal to
1.3.6.1.4.1.529.1.2.4. Conclusions:
a) The trap definition you are using does not apply to your ascend
device. (Ask the technical support to find out.)
b) The SNMP implementation does not conform to the TRAP definitions
in the MIB specification.
Marc> Just in case this helps, Gary_Wong@ascend.com (the tech
Marc> support guy I was in contact with) wrote me:
Marc> On my LAN, I have :
Marc> (1) max4000(5.0AP5)
Marc> (2) HP-UX with HP Openview running the latest Ascend MIB and trap
Marc> (3) Solaris with SunNet Manager with earlie(unknown) version of MIB and
Marc> trap
Marc> Max is sending traps to both HP and Sun.
Marc> On HP, I see snmpTrap = 1.3.6.1.4.1.529.12
Marc> On Sun, I see snmpTrap = 1.3.6.1.4.1.529.1.2.4.0.12
Marc> (For him it works with both managers).
Note that scotty is also able to receive the trap. The only problem
you have is that scotty fails to convert the trap OID into a human
readable name. Anyway, the fact that HP Openview and SunNet Manager
can read the trap does not mean that the trap is correctly defined in
the MIB file and that the trap send over the wire conforms to that
definition.
Juergen
-- Juergen Schoenwaelder <schoenw@gaertner.de> (Tel: +49-531-23873-0) Gaertner Datensysteme, Hamburger Strasse 273a, 38114 Braunschweig, Germany-- !! 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.