Is .1.3.6.1.4.1.6889.2.18.1.1.4.0.5 the trap OID you're receiving?
I couldn't find any trap with that definition although 6889 seems to be AVAYA. Sometimes companies implement mibs and traps in quite a lousy way.
the last number you have, the number 5, is the specific trap. Since it is supposed to be an enterprise specific you should put a 6 in your trap_mgr 'BEGIN_TRAP' statement. 1.3.6.1.4.1.6889.2.18.1.1.4.0 should be the OID number for the mib.
But, i have seen companies which implement the standard snmp mib in their mibs, so in this case, this could be like a generic trap of type 'egpNeighborLoss' and the configuration will be a differente one.
If you have never seen any notifications coming from that trap i would recommend you to add a trap definition which will catch all traps and store it in a log file. See example below:
when you say you are expecting a trap OID, how do you know which trap OID it should be ? Because you capture a SNMP packet on the wire or because the MIB said so. Because there is a ".0 issue" (not an issue in fact, just something to know) related to SNMPv1 / SNMPv2 trap where the trap ID on the wire (or sent if you did create your own SNMP agent) is not the same received by the trap adapter (which should follow the RFC).
Is .1.3.6.1.4.1.6889.2.18.1.1.4.0.5 the trap OID you're receiving?
Yes
I couldn't find any trap with that definition although 6889 seems to be AVAYA. Sometimes companies implement mibs and traps in quite a lousy way.
I got a shock when I saw this one too !!
the last number you have, the number 5, is the specific trap. Since it is supposed to be an enterprise specific you should put a 6 in your trap_mgr 'BEGIN_TRAP' statement. 1.3.6.1.4.1.6889.2.18.1.1.4.0 should be the OID number for the mib.
That is what I would have expected, however SMARTS won't accept this it does something to drop the .0 (perhaps because it's some code assuming that it's a value behind an OID, rather than an OID as a value).
when you say you are expecting a trap OID, how do you know which trap OID it should be ? Because you capture a SNMP packet on the wire or because the MIB said so.
Because that's what the value is in the MIB. i.e. if a trap of that type is created then I should expect the enterprise set to that value.
Because there is a ".0 issue" (not an issue in fact, just something to know) related to SNMPv1 / SNMPv2 trap where the trap ID on the wire (or sent if you did create your own SNMP agent) is not the same received by the trap adapter (which should follow the RFC).
(2) what is your agent's SNMP version ? V1 or V2c ? - if MIB format is SNMPv2 and agent is V1, then this is what I told you (see RFC) - in any other case (V1/V1 or V2/V2, or MIB V1/agent V2), it should work as stated, but a snoop of the SNMP traffic should tell you what's sent by the agent.
Dinand1
89 Posts
422
0
Posted January 21st, 2008 23:00
Is .1.3.6.1.4.1.6889.2.18.1.1.4.0.5 the trap OID you're receiving?
I couldn't find any trap with that definition although 6889 seems to be AVAYA.
Sometimes companies implement mibs and traps in quite a lousy way.
the last number you have, the number 5, is the specific trap. Since it is supposed to be an enterprise specific you should put a 6 in your trap_mgr 'BEGIN_TRAP' statement.
1.3.6.1.4.1.6889.2.18.1.1.4.0 should be the OID number for the mib.
But, i have seen companies which implement the standard snmp mib in their mibs, so in this case, this could be like a generic trap of type 'egpNeighborLoss' and the configuration will be a differente one.
If you have never seen any notifications coming from that trap i would recommend you to add a trap definition which will catch all traps and store it in a log file. See example below:
# Catch all traps
#---------------------------------------------------------------------
BEGIN_TRAP * * *
ClassName: TestTraps
Severity: 5
UnknownAgent: CREATE
State: NOTIFY
LogFile: catch_all.log
EventType: MOMENTARY
Expiration: 5
EventText: $V*$
END_TRAP