trap_mgr.conf any ideas why this is so?

Hi,

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

Hi MrRohan,

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).

This may be the answer of your concern...

My 2 cents,

--Fred

Frederic Meunier
Solutions Watch4Net Inc
APG & Smarts InCharge integration
http://www.watch4net.com

Yes



I got a shock when I saw this one too !!



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).

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.



Can you point me to the specific reference?

(1) http://www.ietf.org/rfc/rfc3584.txt

(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.

HTH,

--Fred

Frederic Meunier
Solutions Watch4Net Inc
APG & Smarts InCharge integration
http://www.watch4net.com