关闭

Converting MIBs Using mib2opennms

标签: notificationseventsvariablesfileopensourceimport
1975人阅读 评论(0) 收藏 举报
分类:

-----------------------------------------------------------------------------

opennms中两个相当有份量的工具就是mib2opennms和mibparser,mibparser专门用来分析mib文件以形成相应的SNMP采集配置文件XML形式,而mib2opennms负责trap相关Mib的提取以实现opennms中的event和notify,供opennms中的trapd进程来使用.

  From OpenNMS

Contents

[hide]

mib2opennms How-To

This little document provides an explanation of how to import SNMP MIBs into OpenNMS, using the opensource tool 'mib2opennms'.

本文描述了使用开源的mibopennms工具将SNMP MIBs文件导入到OpenNMS的方法.

Why import the OIDs using this tool?

OpenNMS has the ability to receive SNMP traps; In order to do that, OpenNMS must know how to treat each event (thus requires a description for each OID that it receives). Normally if you don't do that you will receive anoying messages like the following on your event database:

OpenNMS有接收SNMP traps(陷阱)的能力.因此,OpenNMS必须知道如何去处理每一个发生的时间,也就是说OpenNMS需要每一个接受到的OID都有相应的描述信息.通常来说,在你没有设置描述信息的情况下,你将收到如下的消息,并被存储于你的信息数据库中.

Received unformatted enterprise event (enterprise:.1.3.6.1.4.1.2021.250.10 generic:0 specific:0). 0 args:

Also importing the OIDs by hand is error prone and tedious, so the use of this tool is a must when adding new OIDs.

同样的,当你手工导入错误或冗余时,也回产生上面的信息.不难发现mib2opennms是添加新OIDs的必要工具.

Download the software

There are several alternatives (RPM, source code). Look for it in the contrib directory of OpenNMS.

可以选择RPM和源代码包的形式.从OopenNMS安装目录下的contrib中,可以看到mib2opennms文件夹.

How to use

It is better to get a detailed list of OIDs in the form of XML files; so that you can choose what to cut/paste into your "eventconf.xml," instead of a huge (and useless) list of OIDs.

Here is a Bash script that can do the nasty work for you (take care to define the appropiate variables first):

# <----- CUT HERE ----->

#!/bin/bash
#
# This program generates a list of XML files to be used with OpenNMS and the 
# "event" section.
# Author: Jose Vicente Nunez Zuleta (josevnz@newbreak.com)
# Requires: mib2openms (http://www.tompa.nu/mib2opennms/)
#

MIBPATH="/usr/share/snmp/mibs:/usr/share/mibs:/home/josevnz/mibs"
MIBDEF=$1
destdir=$2

if [ -z $MIBDEF ] ; then
cat <<EOF;
[ERROR]:
You must supply values for the mib directory. Examples:

/home/josevnz/mibs

/usr/share/snmp/mibs

Then the script will locate all the '*.txt' files present.


EOF
exit 1
fi


mibc="/usr/bin/mib2opennms"
mkdir="/bin/mkdir"
perl="/usr/bin/perl" # sed SUCKS!!! ;)

# Use the user destination dir if present
if [ -z $destdir ] ; then
  destdir="/tmp";
fi

if [ ! -e $destdir ] ; then
  $mkdir -p $destdir
  if [ $? -ne 0 ] ; then
    echo "Error creating destination dir"
  fi
fi

# Get the list of all the MIBs on this system
LIST=`find $MIBDEF -type f -name '*.txt' | /usr/bin/xargs`
if [ $? -ne 0 ] ; then
  echo "Error locating the MIBS"
fi

for file in $LIST; do
  # Get the mib name from the file
  mib=`echo $file |$perl -e' while(<STDIN>) { 

-----------------------------------------------------------------------------

opennms中两个相当有份量的工具就是mib2opennms和mibparser,mibparser专门用来分析mib文件以形成相应的SNMP采集配置文件XML形式,而mib2opennms负责trap相关Mib的提取以实现opennms中的event和notify,供opennms中的trapd进程来使用.

  From OpenNMS

Contents

[hide]

mib2opennms How-To

This little document provides an explanation of how to import SNMP MIBs into OpenNMS, using the opensource tool 'mib2opennms'.

本文描述了使用开源的mibopennms工具将SNMP MIBs文件导入到OpenNMS的方法.

Why import the OIDs using this tool?

OpenNMS has the ability to receive SNMP traps; In order to do that, OpenNMS must know how to treat each event (thus requires a description for each OID that it receives). Normally if you don't do that you will receive anoying messages like the following on your event database:

OpenNMS有接收SNMP traps(陷阱)的能力.因此,OpenNMS必须知道如何去处理每一个发生的时间,也就是说OpenNMS需要每一个接受到的OID都有相应的描述信息.通常来说,在你没有设置描述信息的情况下,你将收到如下的消息,并被存储于你的信息数据库中.

Received unformatted enterprise event (enterprise:.1.3.6.1.4.1.2021.250.10 generic:0 specific:0). 0 args:

Also importing the OIDs by hand is error prone and tedious, so the use of this tool is a must when adding new OIDs.

同样的,当你手工导入错误或冗余时,也回产生上面的信息.不难发现mib2opennms是添加新OIDs的必要工具.

Download the software

There are several alternatives (RPM, source code). Look for it in the contrib directory of OpenNMS.

可以选择RPM和源代码包的形式.从OopenNMS安装目录下的contrib中,可以看到mib2opennms文件夹.

How to use

It is better to get a detailed list of OIDs in the form of XML files; so that you can choose what to cut/paste into your "eventconf.xml," instead of a huge (and useless) list of OIDs.

Here is a Bash script that can do the nasty work for you (take care to define the appropiate variables first):

___FCKpd___1

Then you can call it like this:

 ./generate_mibs.bsh /home/josevnz/mibs 1> output.txt 2> errors.txt

Resources

List of extracted (and ready to use) MIBs:

More on mib2opennms

This came up on the discussion list, so I thought it should go here.

Q: I am trying to get the Juniper MIBs into OpenNMS, but I can't get mib2opennms to work. I only get segmentation faults:

# mib2opennms mib-jnx-ipv6.txt
mib2opennms version 0.2.2
Segmentation fault

A: This usually means that there is a problem with the ASN.1 notation in your mibs.

I don't get a seg fault on that mib, but since:

grep NOTIF mib-jnx-ipv6.txt

and

grep TRAP mib-jnx-ipv6.txt

return nothing, there are no events defined in that MIB.

A quick search shows the following files support NOTIFICATION-TYPE objects:

Stormbringer:~/Desktop/JuniperMibs tarus$ grep -l NOTIF *
mib-jnx-bgpmib2.txt
mib-jnx-cfgmgmt.txt
mib-jnx-chassis.txt
mib-jnx-coll.txt
mib-jnx-ldp.txt
mib-jnx-mpls.txt
mib-jnx-ping.txt
mib-jnx-pmon.txt
mib-jnx-rmon.txt
mib-jnx-sonet.txt
mib-jnx-sonetaps.txt
mib-jnx-vpn.txt

Let's check out the first one. if I run:

/usr/local/bin/mib2opennms mib-jnx-bgpmib2.txt

I get:

        <mask>
                <maskelement>
                        <mename>id</mename>
                        <mevalue>.0.1.1</mevalue>
                </maskelement>
                <maskelement>
                        <mename>generic</mename>
                        <mevalue>0</mevalue>
                </maskelement>
                <maskelement>
                        <mename>specific</mename>
                        <mevalue>1</mevalue>
                </maskelement>
        </mask>

Note that the id looks wrong. It should be something like .1.3.6.1.4.1.x

This usually means that there is a broken import somewhere, so we should include the MIB files in the current directory:

/usr/local/bin/mib2opennms -m. mib-jnx-bgpmib2.txt
        <mask>
                <maskelement>
                        <mename>id</mename>
                        <mevalue>.0.1.1</mevalue>
                </maskelement>
                <maskelement>
                        <mename>generic</mename>
                        <mevalue>0</mevalue>
                </maskelement>
                <maskelement>
                        <mename>specific</mename>
                        <mevalue>1</mevalue>
                </maskelement>
        </mask>

Hrm, not much better, and adding the path to the default MIBs doesn't help either:

/usr/local/bin/mib2opennms -m/usr/share/snmp/mibs:. mib-jnx-bgpmib2.txt

So, it's time to look into the mib file. The first NOTIFICATION-TYPE object is:

jnxBgpM2Established NOTIFICATION-TYPE
    ::= { jnxBgpM2BaseNotifications 1 }

So let's work backwards.

jnxBgpM2BaseNotifications
    OBJECT IDENTIFIER ::= { jnxBgpM2BaseScalars 0 }

jnxBgpM2BaseScalars
    OBJECT IDENTIFIER ::= { jnxBgpM2 1 }

jnxBgpM2 MODULE-IDENTITY
     ::= { jnxBgpM2Experiment 1 }

Now, jnxBgpM2Experiment comes from:

jnxBgpM2Experiment
    FROM JUNIPER-EXPERIMENT-MIB

Therein lies the problem. As mentioned in the README:

If mib2opennms complains about a missing MIB, be sure that there is a file
in your "-m" MIB path that has the *exact* name as the MIB it is complaining
about.

For example, if it complains "Can't find RFC-1213" and you have a file in your path called "RFC1213", you must rename it or copy it to "RFC-1213".

The extensions .txt, .my and I believe .mib are acceptable, so in the above example, RFC-1213.txt should work."

Well, there is no file called JUNIPER-EXPERIMENT-MIB. So:

cp mib-jnx-exp.txt JUNIPER-EXPERIMENT-MIB

and rerun:

/usr/local/bin/mib2opennms -m/usr/share/snmp/mibs:.  mib-jnx-bgpmib2.txt
        <mask>
                <maskelement>
                        <mename>id</mename>
                        <mevalue>.0.5.1.1.1</mevalue>
                </maskelement>
                <maskelement>
                        <mename>generic</mename>
                        <mevalue>0</mevalue>
                </maskelement>
                <maskelement>
                        <mename>specific</mename>
                        <mevalue>1</mevalue>
                </maskelement>
        </mask>

Better. More research shows that the JUNIPER-SMI MIB is referenced by JUNIPER-EXPERIMENT-MIB:

cp mib-jnx-smi.txt JUNIPER-SMI
/usr/local/bin/mib2opennms -m/usr/share/snmp/mibs:.  mib-jnx-bgpmib2.txt
        <mask>
                <maskelement>
                        <mename>id</mename>
                        <mevalue>.1.3.6.1.4.1.2636.5.1.1.1</mevalue>
                </maskelement>
                <maskelement>
                        <mename>generic</mename>
                        <mevalue>0</mevalue>
                </maskelement>
                <maskelement>
                        <mename>specific</mename>
                        <mevalue>1</mevalue>
                </maskelement>
        </mask>

Success! The only problem is that "generic" is set to zero, so add the -6 option:

/usr/local/bin/mib2opennms -6 -m/usr/share/snmp/mibs:.  mib-jnx-bgpmib2.txt
        <mask>
                <maskelement>
                        <mename>id</mename>
                        <mevalue>.1.3.6.1.4.1.2636.5.1.1.1</mevalue>
                </maskelement>
                <maskelement>
                        <mename>generic</mename>
                        <mevalue>6</mevalue>
                </maskelement>
                <maskelement>
                        <mename>specific</mename>
                        <mevalue>1</mevalue>
                </maskelement>
        </mask>

The final steps are to take the new file and make it contain "events" by adding an <events> tag at the very top and an </events> tag at the bottom. The file can now be added to eventconf.xml via an include. Restart OpenNMS and the events are ready to go.

This is just an example of how mib2opennms should work. I don't understand the seg faults - could be an issue with the build. We don't support stuff in contrib, so anyone with come C++ experience might want to check it out for us. WORKSFORME on my Mac (built using libsmi from fink).


Varbinds --- Nasty ..... until recently ...

Recently the behavior of OpenNMS, at least regarding the current SVN trunk, has been changed in conformance with RFC2089. This change takes care of all the problems mentioned below.


--- obsolete --- mib2opennms also converts the varbinds from the MIB as puts them into the event message. Because of the fact that SNMPv1 traps are different in data layout from SNMPv2 notifications might be things to correct before using the converted mib.

SNMPv2 notifications contain the originator OID of the trap and also a timestap as first two variables in the packet being send. Because of this the varbinds of converted MIBs with NOTIFICATIONs are always shifted by two.

This means that parm[#1] does not contain the fist variable that the agent sent, but more the OID of the NOTIFICATION originator.

The only thing you need to do (until mib2opennms might be changed) is to always add "2" to any parm# that is in the xml file created.

 

= m#.*/(.*)/.txt#; print $1 }'` echo "Processing: $mib" # Generate a OpenNMS MIB xml file for each located mib COMMAND="$mibc -f "$destdir/$mib.xml" -m $MIBPATH $file" echo $COMMAND $COMMAND if [ $? -ne 0 ]; then echo "MIB conv failed" fi done # <----- CUT HERE ----->

Then you can call it like this:

___FCKpd___2

Resources

List of extracted (and ready to use) MIBs:

More on mib2opennms

This came up on the discussion list, so I thought it should go here.

Q: I am trying to get the Juniper MIBs into OpenNMS, but I can't get mib2opennms to work. I only get segmentation faults:

___FCKpd___3

A: This usually means that there is a problem with the ASN.1 notation in your mibs.

I don't get a seg fault on that mib, but since:

___FCKpd___4

and

___FCKpd___5

return nothing, there are no events defined in that MIB.

A quick search shows the following files support NOTIFICATION-TYPE objects:

___FCKpd___6

Let's check out the first one. if I run:

___FCKpd___7

I get:

___FCKpd___8

Note that the id looks wrong. It should be something like .1.3.6.1.4.1.x

This usually means that there is a broken import somewhere, so we should include the MIB files in the current directory:

___FCKpd___9

Hrm, not much better, and adding the path to the default MIBs doesn't help either:

___FCKpd___10

So, it's time to look into the mib file. The first NOTIFICATION-TYPE object is:

___FCKpd___11

So let's work backwards.

___FCKpd___12

Now, jnxBgpM2Experiment comes from:

___FCKpd___13

Therein lies the problem. As mentioned in the README:

___FCKpd___14

For example, if it complains "Can't find RFC-1213" and you have a file in your path called "RFC1213", you must rename it or copy it to "RFC-1213".

The extensions .txt, .my and I believe .mib are acceptable, so in the above example, RFC-1213.txt should work."

Well, there is no file called JUNIPER-EXPERIMENT-MIB. So:

___FCKpd___15

and rerun:

___FCKpd___16

Better. More research shows that the JUNIPER-SMI MIB is referenced by JUNIPER-EXPERIMENT-MIB:

___FCKpd___17

Success! The only problem is that "generic" is set to zero, so add the -6 option:

___FCKpd___18

The final steps are to take the new file and make it contain "events" by adding an <events> tag at the very top and an </events> tag at the bottom. The file can now be added to eventconf.xml via an include. Restart OpenNMS and the events are ready to go.

This is just an example of how mib2opennms should work. I don't understand the seg faults - could be an issue with the build. We don't support stuff in contrib, so anyone with come C++ experience might want to check it out for us. WORKSFORME on my Mac (built using libsmi from fink).


Varbinds --- Nasty ..... until recently ...

Recently the behavior of OpenNMS, at least regarding the current SVN trunk, has been changed in conformance with RFC2089. This change takes care of all the problems mentioned below.


--- obsolete --- mib2opennms also converts the varbinds from the MIB as puts them into the event message. Because of the fact that SNMPv1 traps are different in data layout from SNMPv2 notifications might be things to correct before using the converted mib.

SNMPv2 notifications contain the originator OID of the trap and also a timestap as first two variables in the packet being send. Because of this the varbinds of converted MIBs with NOTIFICATIONs are always shifted by two.

This means that parm[#1] does not contain the fist variable that the agent sent, but more the OID of the NOTIFICATION originator.

The only thing you need to do (until mib2opennms might be changed) is to always add "2" to any parm# that is in the xml file created.

 

0
0

猜你在找
【直播】机器学习&数据挖掘7周实训--韦玮
【套餐】系统集成项目管理工程师顺利通关--徐朋
【直播】3小时掌握Docker最佳实战-徐西宁
【套餐】机器学习系列套餐(算法+实战)--唐宇迪
【直播】计算机视觉原理及实战--屈教授
【套餐】微信订阅号+服务号Java版 v2.0--翟东平
【直播】机器学习之矩阵--黄博士
【套餐】微信订阅号+服务号Java版 v2.0--翟东平
【直播】机器学习之凸优化--马博士
【套餐】Javascript 设计模式实战--曾亮
查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:664144次
    • 积分:8772
    • 等级:
    • 排名:第2153名
    • 原创:145篇
    • 转载:316篇
    • 译文:13篇
    • 评论:81条
    最新评论