Skip to main content

Loading Modules for SNMP Trapd LAMbot v2

Notice

See Installing SNMP Trapd v2 for instructions on obtaining and installing SNMP Trapd v2.

Adding include files in the v1 MoogTrapd LAMbot involved three steps:

  1. Load the module

  2. Instantiate the modules

  3. Route traps to the module

For example:

// Load the module
LamBot.loadModule("trapModules/veritas/VeritasCCTraps.include");

// Instantiate the module
var veritas = new VeritasCCTraps(botUtil);

// Route the module
switch ( trapInfo.enterprise.toLowerCase() ) {
  ...
  case "veritas" : veritas.processTrap(moogEvent,trapData,trapInfo); break;
  ...
  }

The addition of custom include modules made this file very customer specific, and where the routing was at a sub-enterprise level, required a customer to understand both how to route traps to specific include files using JavaScript logic.

This process has been replaced using a simplified master.includes file.

By default this resided in

$MOOGSOFT_HOME/bots/lambots/trapModules/master.includes

The TrapLamV2 archive contains the default master.includes. This default master.includes loads all of the GA include files, and does not need modification unless adding or removing include files from the available set.

There is no need to remove unused include files from your install. If you are not receiving traps for a specific include file, then it can be loaded without any impact to the processing of other traps.

The master.include file lists all the include files and the routing to these in one simplified statement:

For example, the Veritas routing above is simplified to the following entry:

"VeritasCCTraps" : { "route" : "veritas.products.veritascc" , "file" : "trapModules/veritas/VeritasCCTraps.include" },

The mib2lam conversion process will provide the correct entry during the conversion process, and this can be cut and pasted directly into the master.include file without any modification.

master.include entries

An entry in the master.include file has three components:

<Module> : { "route" : "<trap path>", "file" : "<path to include file>"} 

where:

Attribute

Descripton

Module

The Name of the module — defined in the include file, the --module argument from mib2lam

route

A dotted notation of the SNMP trap “route” for this include. See below for a detailed explanation.

file

The include file that will be passed traps matching the route.

Trap routes

The “route” component is a description of the unique OID path to the traps that an individual include file contains.

An include file is created from a specific point in the full OID tree during the mib2lam process using the --oid parameter.

e.g.

mib2lam --oid cisco ... 

For example, given the following OID tree (taken from the mibparser -c output) :

"v2_trap_tree" : {
...
    "1.3.6.1.4": "private",
    "1.3.6.1.4.1": "enterprises",
    "1.3.6.1.4.1.30191": "iptrade",
    "1.3.6.1.4.1.30191.1": "ipt-turret",
    "1.3.6.1.4.1.30191.1.1": "sysinfo",
    "1.3.6.1.4.1.30191.1.1.0": "sysInfoTraps",
    "1.3.6.1.4.1.30191.1.1.0.1": "fdLowSpace",
  ...
    "1.3.6.1.4.1.30191.1.2": "callcontrol",
    "1.3.6.1.4.1.30191.1.2.0": "callControlTraps",
    "1.3.6.1.4.1.30191.1.2.0.1": "regErrorState",
  ...
    "1.3.6.1.4.1.30191.1.4": "tss",
    "1.3.6.1.4.1.30191.1.4.0": "tssTraps",
    "1.3.6.1.4.1.30191.1.4.0.1": "tssErrorState",
    "1.3.6.1.4.1.30191.1.5": "recorder",
    "1.3.6.1.4.1.30191.1.5.0": "recorderTraps",
    "1.3.6.1.4.1.30191.1.5.0.1": "recErrorState",
    "1.3.6.1.4.1.30191.1.7": "embeddedDB",
    "1.3.6.1.4.1.30191.1.7.0": "embeddedDBTraps",
    "1.3.6.1.4.1.30191.1.7.0.1": "eosLowMemory",
    "1.3.6.1.4.1.30191.2": "ipt-tpo",
    "1.3.6.1.4.1.30191.2.1": "sysinfo",
    "1.3.6.1.4.1.30191.2.1.0": "sysInfoTraps",
    "1.3.6.1.4.1.30191.2.1.0.1": "diskLowSpace",
...
    "1.3.6.1.4.1.30191.2.2": "callcontrol",
    "1.3.6.1.4.1.30191.2.2.0": "callControlTraps",
    "1.3.6.1.4.1.30191.2.2.0.1": "regErrorState",
...
    "1.3.6.1.4.1.30191.2.6": "recorder",
    "1.3.6.1.4.1.30191.2.6.0": "recorderTraps",
    "1.3.6.1.4.1.30191.2.6.0.1": "recErrorState",
    "1.3.6.1.4.1.30191.2.7": "redundancynode",
    "1.3.6.1.4.1.30191.2.7.0": "nodeTraps",
    "1.3.6.1.4.1.30191.2.7.0.1": "nodeVIPChangeMAC",
    "1.3.6.1.4.1.30191.3": "ipt-tss-va",
    "1.3.6.1.4.1.30191.3.1": "sysinfo",
    "1.3.6.1.4.1.30191.3.1.0": "sysInfoTraps",
    "1.3.6.1.4.1.30191.3.1.0.1": "fdLowSpace",
    ...
...
    }

This covers 3 mibs from IP Trade - the IPT-TURRET-MIB, IPT-TSS-VA-MIB and IPT-TPO-MIB - each of these has a distinct set of traps, and given the trap name conflicts (fdLowSpace) would be candidates for separate conversion - one include file for each MIB.

IPTTPOTraps.include  
IPTTSSTraps.include  
IPTTurretTraps.include

These would have been converted using the mib2lam process using different starting OIDs:

mib2lam --oid ip-tss-va --module IPTTSSTraps ...
mib2lam --oid ip-tpo --module IPTTPOTraps ...
mib2lam --oid ip-turret --module IPTTurrentTraps ...

These would have produced the following routes, i.e. all the traps in the include file reside below this point in the OID tree.

"IPTTurretTraps" : { "route" : "iptrade.ipt-turret" , "file" : "trapModules/iptrade/IPTTurretTraps.include" }
"IPTTPOTraps" : { "route" : "iptrade.ipt-tpo" , "file" : "trapModules/iptrade/IPTTPOTraps.include" }
"IPTTSSTraps" : { "route" : "iptrade.ipt-tss-va.sysinfo.sysinfotraps" , "file" : "trapModules/iptrade/IPTTSSTraps.include" }

The routes for each of these is calculated by the mib2lam process as the lowest point (leaf) in the OID tree where all the included traps reside — and may be deeper than the starting point of the conversion.

For example, for the IPTRA\dE-TSS-VA-MIB the conversion point was “ip-tss-va” , but the resulting route was “iptrade.ipt-tss-va.sysinfo.sysinfotraps”.

Unlike the other two OID start points, where traps are distributed amongst several leaf paths, the TSS-VA traps all reside under one leaf.

e.g.

 "1.3.6.1.4.1.30191.3": "ipt-tss-va",
    "1.3.6.1.4.1.30191.3.1": "sysinfo",
    "1.3.6.1.4.1.30191.3.1.0": "sysInfoTraps",
    "1.3.6.1.4.1.30191.3.1.0.1": "fdLowSpace",
    "1.3.6.1.4.1.30191.3.1.0.2": "lowMemory",
    "1.3.6.1.4.1.30191.3.1.0.3": "dbLowSpace",
    "1.3.6.1.4.1.30191.3.1.0.4": "logsLowSpace",
    "1.3.6.1.4.1.30191.3.1.0.5": "cpuHighLoad",
    "1.3.6.1.4.1.30191.3.1.0.6": "replicationOff",
    "1.3.6.1.4.1.30191.3.1.0.7": "highPing",
    "1.3.6.1.4.1.30191.3.1.0.8": "certificateWillExpire",

However, or the ipt-tpo traps, these reside under several leaves : sysinfo.sysInfoTraps, callcontrol, recorder.recoderTraps, and redundancynode.nodeTraps.

"1.3.6.1.4.1.30191.2": "ipt-tpo",
    "1.3.6.1.4.1.30191.2.1": "sysinfo",
    "1.3.6.1.4.1.30191.2.1.0": "sysInfoTraps",
    "1.3.6.1.4.1.30191.2.1.0.1": "diskLowSpace",
    "1.3.6.1.4.1.30191.2.1.0.2": "lowMemory",
    "1.3.6.1.4.1.30191.2.1.0.3": "licenseError",
    "1.3.6.1.4.1.30191.2.1.0.4": "tpoHotBackupFailOver",
    "1.3.6.1.4.1.30191.2.2": "callcontrol",
    "1.3.6.1.4.1.30191.2.2.0": "callControlTraps",
    "1.3.6.1.4.1.30191.2.2.0.1": "regErrorState",
    "1.3.6.1.4.1.30191.2.2.0.2": "confBridgeError",
    "1.3.6.1.4.1.30191.2.2.0.3": "pladLineErrorState",
    "1.3.6.1.4.1.30191.2.2.0.4": "placeNoSubscribers",
    "1.3.6.1.4.1.30191.2.2.0.5": "ed137Alarm",
    "1.3.6.1.4.1.30191.2.6": "recorder",
    "1.3.6.1.4.1.30191.2.6.0": "recorderTraps",
    "1.3.6.1.4.1.30191.2.6.0.1": "recErrorState",
    "1.3.6.1.4.1.30191.2.7": "redundancynode",
    "1.3.6.1.4.1.30191.2.7.0": "nodeTraps",
    "1.3.6.1.4.1.30191.2.7.0.1": "nodeVIPChangeMAC",

As a result the IPT-TPO '“route” is higher up the OID tree, covering the required leaf objects.

Note

There is no need to modify the route provided by the mib2lam process, regardless of length.