对MIB文件中一些常见的宏定义的描述
1.DEFINITIONS ::= BEGIN
SNMP始终使用ASN.1概念中的描述块(module)来组织ASN.1对象的,ASN.1的描述块是一些相关描述语句的集合,module的结构如下
<<module>> DEFINITIONS ::= BEGIN
<<linkage>>
<<declarations>>
END
2.<<basetype>> ::= TEXTUAL-CONVENTION
定义了对标准数据类型的进行扩展的语法
很多MIB定义中都会先定义一些基于标准类型的扩展类型,如:
CiFlowDirection ::= TEXTUAL-CONVENTION
CiFlowDirection 是基于INTEGER的枚举类型
3.<<mibname>> MODULE-IDENTITY
该定义添加了一个公共的标示段来对整个信息描述块进行顶层的文字描述,以加强对管理MIB描述块的文档管理和控制,每个MIB定义中都会有该定义。
如:
circuitIfMIB MODULE-IDENTITY
4.OBJECT-IDENTIFIFIER
声明一个节点
如:
atmClpTaggingNoScr
5.OBJECT-TYPE
如:
包括了SNMP定义该管理对象的全部信息,相当于一个模板。
表,实体,叶子都是该类型。
SNMPv2中对SNMP的兼容性做了规定,主要是通过引入三个宏: OBJECT-GROUP,MODULE-COMPLIANCE,AGENT-CAPABILITIES.
6.OBJECT-GROUP
定义相关管理对象集合以及他们彼此关联的一致性程度。OBJECT-GROUP声明的MIB对象是实现该组所必须包括的MIB对象的最小集合。也就是说,要实现这个组,必须包括这些对象。
7.MODULE-COMPLIANCE
通过定义模块内所包含的组来保证模块的兼容性。
规定了要实现该模块必须包含的组的最小集合。
其中MANDATORY-GROUPS规定了此模块必须实现的组的名称。GROUP子句说明条件必须活条件可选的组。
8.AGENT-CAPABILITIES
管理代理实现了模块中的哪些组以及这些组中的MIB对象在实现时和原定义的差别在管理信息结构中由此宏定义表示。此宏定义在实际应用中很少见。
9.OBJECT-IDENTITY
对象标示宏,此宏定义用于说明对象标示符(OBJECT-IDENTIFIER),给对象标示符的说明加上附加信息,包括状态,文字说明等,可用于对一个表中几个参数的不同组合的意义的说明。
10.NOTIFICATION-TYPE
说明了SNMPv2的trap格式。定义了通知类型报文中传输的数据。
3.1 MIB对象定义格式http://bbs.chinaunix.net/thread-1137550-1-1.html
ASN.1是一种用于描述结构化客体的结构和内容的语言,基于编码规则BER(Basic Encoding Rules)是ASN.1标准定义的一种传送文法。每个MIB变量格式是SMI规定的,用ASN.1描述如下:
OBJECTNAME BOJECT-TYPE
DESCRIPTION:(description)
SYNTAX: (syntax)
ACCESS: (access)
STATUS: (status)
::={(Parent)number}
OBJECTNAME是被管对象的名字,ASN.1要求所有对象的名字在MIB中必须是唯一的;
BOJECT-TYPE 是每一个节点对象所必需的关键字;
SYNTAX是被管对象类型的关键字,随后跟着的是一个类型(syntax);
ACCESS是被管对象的访问方式关键字,在SNMP 第二版中为MAX-ACCESS 关键字,(access)是被管对象的访问方式,可为如下列举值之一: read-only、read-write、no-accessible, SNMP 第2 版中又增加了read-create;STATUS是被管对象关键字,(status)是被管对象的状态,如必备的、可选的或废弃的;
DESCRIPTION是 对被管对象的功能、特征等进行描述的关键字,(description)是被管对象的文本描述,在::={(Parent)number }中,Parent表示位于MIB树中的父节点,number表示是第几个子节点。
--
3.2 MIB 树
每个MIB对象都用对象标识符(OID)来唯一的标识,这是用定义在ASN.1语法中的树型结构来组织的可用信息,其中每个可用信息是一个带标号的节点,每个节点用数字和字符两种方式显示,其中对象标识符OID是由句点隔开的一组整数,也就是从根节点通向它的路径,它命名节点并指示它在ASN.1树中的准确位置。一个带标号节点可以拥有包含其它带标号节点为它的子树,如果没有子树它就是叶子节点,它包含一个值并被称为对象。图3是带有ASN.1编号的MIB树实例:可以看出MIB-Ⅱ的OID是:1.3.6.1.2.1或者iso.org.dod.internet.mgmt.mib2。在SNMP中,实现应用到的MIB对象都是MIB-Ⅱ的子树节点。
On the server, the file is /home/geo/spIserver/etc/inet.defs
(2) On 12u probes, the file is /inet/spIprobe/basic/arm-xinu/mibs/mib, or /inet/spIprobe/basic/xscale-xinu/mibs/mib. There is also a version for mips-xinu.
On 14u probes, the file is /inet/spIprobe/basic/atca-x86-linux/mibs/mib.
Step two:How to add a new alarm
a. modify mib file, for ip application the file is "spidev/spiV4.5/mibs/ipAlarms.my"
the definition is the same with phyDeviceStateAlarm. |
ipInterfaceShteamAlarm NOTIFICATION-TYPE OBJECTS { phyDeviceStateTime, phyDeviceState, ipInterfaceIdForPd } STATUS current DESCRIPTION " Test Alarms " ::= {ipAlarmsMib 5}
note. In fact, 5 is the alarmID. It must keep unique in spidev-spiV4.5-mibs-ipAlarms.my. If the last alarmID is 9 then we define the alarmID of ipInterfaceShteamAlarm as 10
b. compile mibs
c. copy inet.defs to probe /inet/spIprobe/basic/atca-x86-linux/mibs, change name to mib.
d. copy inet.defs,inet.alarms.defs and inet.events.defs to server/station :/home/geo/spIserver/site or (etc) for test
e. update spidev/spiV4.5/spi/etc/server/
defaultSpiProbeAlarmDefn |
A 2 209 3813 1 0x0006 0x0006 0 "Shteam Test Alarms Device Available" ""\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ 3814 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\ "ipInterfaceShteamAlarm 1" A 2 209 3814 1 0x0006 0x0002 0 "Shteam Test Alarms Equipment Down" "" \\\\\\\\\\\\\\\\\\\\\\\\\\\\\ "ipInterfaceShteamAlarm 2" |
defaultBullsEye.txt |
ALARM 10 3813 # Shteam Test Alarms Device Available ALARM 25 3814 # Shteam Test Alarms Equipment Down |
f. copy defaultSpiProbeAlarmDefn
g. update spIprobeApps/v4.5/basic/mibs/event, add a line
ipInterfaceShteamAlarm initialContextId.198.4.15.2.24 |
copy to probe:/inet/spIprobe/support/site, /inet/spIprobe/basic/atca-x86-linux/mibs |
h. update spidev/spiV4.5/spi/src/alarms/probe/AlarmWork.cc, h.
AlarmWork.h - add one new line
static const char* const ipInterfaceShteamChanged= "ipInterfaceShteamAlarm";
AlarmWork.cc - we just re-use PhyDeviceStateAlarm function
pProc->name = ipInterfaceShteamChanged; pProc->proc = &AlarmWork::PhyDeviceStateAlarm; pProc->logProc = &AlarmWork::PhyDeviceStateAlarmLogPr oc; pProc->parm = 0; pProc ;
compile it and copy alarmSpiProbe binary execute file to server:/home/geo/spIserver/bin [Q&A]Why sometimes alarmSpiProbe restarts when it receive the alarm of Shteam Test Alarm? Answer: The version of libnwGprsDbExt.so is not compitable to alarmSpiProbe. We have to rebuild spi/api/src/db/nwGprs, then copy libnwGprsDbExt.so to server:/home/geo/spIserver/lib |
i. update spIprobeApps/v4.5/basic/src/ipMon/ipStateMonitor/src
IPStateMonSnmp.h--compare to phyDeviceStateAlarm, only trap name is different,so update phyDeviceStateAlarm to ipInterfaceShteamAlarm.
const char* const ipTrapNames\[\] = { "ipInterfaceShteamAlarm", "ipInterfaceStateAlarm" } ;
compile it and repleace binary ipStateMonitor in the probe. |
j. server restart
su - geo spiStop (make sure no db process running, "ps -eaf | grep db") spiStart |
k. re-configure alarms
l. probe restart
su - root service spIprobe restart all |
m. probe side: command: aui ipStateMon1, send i 3, then check the alarm in the GUI
IP-ALARMS-MIB
-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
--
--
--
--
--
--
--
--
--
--------------------------------------------------------------------------
--
--
phyDeviceStateAlarm NOTIFICATION-TYPE
ipInterfaceStateAlarm NOTIFICATION-TYPE
ipProbeBandwidthAlarm NOTIFICATION-TYPE
ipInterfaceAddChannelAla
ipApplIdMapConflictAlarm
etherealToDiskNoDataAlar
etherealToDiskResumeData
etherealToDiskSessionReb
etherealToDiskSessionFai
END
Another example of imports during compilation comes from the BLADETYPE2-TRAP MIB used by the HP ProLiant BL p-Class GbE2 Interconnect Switch:
BLADETYPE2-TRAP-MIB DEFINITIONS ::= BEGIN
IMPORTS
TRAP-TYPE
sysName
hpSwitchBladeType2-Mgmt
agSlotNumber
ipCurCfgGwIndex
In this example,
TRAP-TYPE and sysName are readily resolved as in the example above.
hpSwitchBladeType2-Mgmt is resolved by mcompile checking HP-SWITCH-PL.MIB.
agSlotNumber is resolved from BLADETYPE2-SWITCH.MIB
and ipCurCfgGwIndex is resolved from BLADETYPE2-NETWORK.MIB.
To illustrate further how imports are resolved—the following procedure shows how mcompile would attempt to resolve the import for hpSwitchBladeType2-Mgmt:
1. Look for a file named HP-SWITCH-PL-MIB.mib (module name, uppercase).
2. Look for a file named HP-SWITCH-PL.mib (module name without -MIB, uppercase).
3. Look for hp-switch-pl.mib (convert name to lowercase for case sensitivity in Linux/HP-UX).
4. Look for hp-switch-pl-mib.mib (convert name to lowercase for case sensitivity in Linux/HP-UX).
5. Report an error indicating that the imported MIB could not be found.
A major consideration when importing MIBs is locating variables from other third-party MIBs. In many cases, MIBs are named to match module names. However, in some circumstances it might be necessary to rename MIB files to match the module names prior to compilation. For example, some vendors might provide MIB files with different extensions such as .my. In this case, before using mcompile, the mibfile.my file needs to be renamed to mibfile.mib.