大型的网络设备通常都需要支持依据SNMP的管理。在采用SNMP进 行管理的网络中,网管通过对象标识符(OID,Object Identifier)来
访问网 络设备上的MIB对象,从而收集网络设备的信息。MIB对象分为公用MIB 对象和私有MIB对象。原始设备制造商(OEM,Original Equipment Manufacturer)在为其他企业制造网络设备时,为了让这些网络设备都支持 SNMP,就需要针对各个使用该网络设备的企业,对网络设备的私有MIB对 象分别作适当的调整,才能让其他厂商各自能够正常使用OEM所制造的网 络设备。
例如,如果企业C是OEM,为企业A和企业B制造网络设备,企业C 对应某特定功能的私有MIB对象为C.MIBx,企业A相应的私有MIB对象 为A.MIBz,企业B相应的私有MIB对象为B.MIBy。网络设备上的SNMP 协议栈根据与MIB对象一一对应的OID,分别处理不同的MIB对象。在现 有技术中,为了使与网络设备配套的
软件版本可以支持所有使用该网络设备 的企业,一方面,配套软件中必须既要有私有MIB对象A.MIBx,又要有 B.MIBy和C.MIBz;另一方面,由于这些私有MIB对象的OID不一致,就 相应的需要不同的代码分别处理对这些
节点的访问
请求。虽然私有MIB对 象A.MIBx、B.MIBy和C.MIBz的功能是完全一致的,但是软件中这三个私 有MIB对象的数据同时存在,造成大量的数据冗余;并且针对这三个私有 MIB对象所开发的不同的处理代码完成的功能其实也是相同的,这样又造成 大量的代码冗余。总的来说,
现有技术会造成与网络设备配套的软件冗余, 进一步,会降低网络设备上系统资源的利用率。
有鉴于此,本发明的主要目的在于提供一种处理MIB的方法,以缩减 MIB数据结构的数据量和对MIB数据结构进行处理的代码量,从而提高系 统资源的利用率。
为了达到上述目的,本发明提供
一种管理信息库的处理方法。在该方法 的第一部分中,针对私有管理信息库MIB对象建立表示对象标识符OID和 内部对象标识符IOID对应关系的标识符对应表,在接收到对私有MIB对象 进行操作的指令时,该方法包括:
A1、根据指令中所
指定的私有MIB对象的OID,从所建立的标识符对应表 中确定对应的IOID,并根据IOID和指令中所指定的操作确定指令操作所需要 运行的处理模
块,然后运行所确定的处理模块。
其中,建立表示IOID和处理模块对应关系的处理对应表,步骤A1所述根 据IOID和指令中所指定的操作确定需要运行的处理模块为:
根据IOID以及指令中所指定的操作,从所建立的处理对应表中确定需要运 行的处理模块。
在本发明提供的管理信息库的处理方法的第二部分中,同样包括针对私有 管理信息库MIB对象建立表示对象标识符OID和内部对象标识符IOID对应关 系的标识符对应表,并且进一步包括以下步骤:
A2、获取需要重
定位的MIB对象的源节点OID和目标节点OID;
B2、将需要重定位的MIB对象从源节点取下,
修改所述MIB对象的OID 并保持其IOID不作改变,挂接在目标节点下;
C、在接收到对私有MIB对象进行操作的指令时,根据指令中所指定的私 有MIB对象的OID,从所建立的标识符对应表中确定对应的IOID,并根据IOID 和指令中所指定的操作确定指令操作所需要运行的处理模块,然后运行所确定 的处理模块。
其中,在步骤A2和步骤B2之间进一步包括:判断目标节点是否存在,如 果存在,则执行步骤B2,否则,创建目标节点后执行步骤B2。
其中,步骤B2所述修改需要重定位的MIB对象的OID为:
根据目标节点OID修改需要重定位的MIB对象的OID。
其中,步骤B2所述修改需要重定位的MIB对象的OID为:
根据目标节点OID以及需要重定位的MIB对象在目标节点下的
位置,修改 该MIB对象的OID。
其中,建立表示IOID和处理模块对应关系的处理对应表,步骤C所述根 据IOID和指令中所指定的操作确定需要运行的处理模块为:
根据IOID以及操作指令中所指定的操作,从所建立的处理对应表中确定 需要运行的处理模块,并运行该处理模块。
其中,在步骤C之前,该方法进一步包括:
判断操作指令中所指定的MIB对象是私有MIB对象还是公用MIB对 象,如果是私有MIB对象,则执行步骤C,否则,直接根据操作指令中所 指定的OID运行相应的处理模块,然后结束本次流程。
采用本发明所提供的技术方案,在MIB对象的数据结构中增加一个内 部对象标识符(IOID,Internal OID),对于具有相同功能的私有MIB对象, 令其内部标识符相同,而软件对于相同IOID的私有MIB对象做相同的处理, 这样就减少了代码冗余。另外,采用私有MIB对象重定位的方法,在网络 设备的配套软件的最初版本中只存在与OEM相对应的私有MIB对象,在将 该网络设备交给其他企业使用时,根据其他企业的需要,将与OEM相对应 的私有MIB对象重定位为其他企业的私有MIB对象,这样在任何时候只需 要一份私有MIB对象的数据,从而既保证了配套软件支持所有使用该网络 设备,又减少了数据冗余。
附图说明
图1是MIB对象树状结构的示意图。
图2是本发明提供的处理管理信息库的方法在访问MIB对象时的流程 图。
图3是本发明提供的处理管理信息库的方法在重定位MIB对象时的流 程图。
本发明的核心思想在于:在MIB对象的数据结构中增加IOID来解决代 码冗余问题,采用私有MIB对象重定位的方法来解决数据冗余问题。
为使本发明的目的、技术方案和优点更加清楚,下面结合附图及具体实 施例对本发明作进一步地详细描述。
在与网络设备配套的软件中,MIB对象以一种树状结构进行组织,这个 树状结构中的每个节点都是一个MIB对象。每个节点都同时有一个字符形 式的标识名和一个数字形式的标识号。一个典型的MIB对象树状结构如图1 所示。为了访问一个MIB对象,可以使用从树状结构的根节点到该MIB对 象所经过的中间节点的标识名来表示该MIB对象,例如在图1中, iso.org.dod.internet.private.enterprises.enterprises-C.func1-C就表示了一个 MIB对象。MIB对象也可以用标识号代替标识名。这样,上述的MIB对象 还可以用1.3.6.1.4.1.3.1来表示,这个用来标识节点的数字串就是所标识节 点的OID。
为了实现这种树状结构,树状结构中的每个节点都由一个数据结构来表 示,这个数据结构通常包括其所表示的节点的
父节点、OID、第一
子节点以 及下一兄弟节点这样几个数据域。在本发明中,在这个数据结构中添加一个 数据域,称为内部对象标识符IOID,具有相同功能的私有MIB对象的IOID 相同。例如,在图1中,假定企业C是OEM,同时为企业A和企业B制造 网络设备。企业C的私有MIB对象1.3.6.1.4.1.3.1和企业A的私有MIB对 象1.3.6.1.4.1.1.2.1以及企业B的私有MIB对象1.3.6.1.4.1.2.1是对应的,它 们的功能相同,则这三个MIB对象具有相同的IOID。
为了表示OID与IOID的对应关系,需要在网络设备上建立标识符对应 表。以图1所示的树状结构为例,一个典型的标识符对应表如表一所示。
OID IOID 1.3.6.1.4.1.3.1 1 1.3.6.1.4.1.1.2.1 1 1.3.6.1.4.1.2.1 1 1.3.6.1.4.1.3.2 2 1.3.6.1.4.1.1.2.2 2 1.3.6.1.4.1.2.2 2 ...... ......
表一
需要说明的是,由于可能出现冗余的代码只是对私有MIB对象进行处 理的代码,因此只需要为表示私有MIB对象的数据结构添加IOID数据域。 同样,在标识符对应表中,也只有私有MIB对象的OID与IOID的对应关 系。
另外,为了实现对相同IOID的MIB对象做统一的处理,还需要在网络 设备上建立处理对应表。一个典型的处理对应表如表二所示。
IOID 操作 处理模块 1 A 1A 1 B 1B 2 A 2A 2 B 2B 2 C 2C
…… …… ……
表二
在表二中,假设对于IOID为1的MIB对象有两种操作,而对于IOID 为2的MIB对象有三种操作。由表二可以看出,对于具有相同IOID的MIB 对象,如果要进行的操作也相同,那么就可以由相同的处理模块来完成。这 样就解决了代码的冗余问题。
请参考图2,图2是本发明提供的处理管理信息库的方法在访问MIB 对象时的
流程图。该流程包括:
步骤201:接收对MIB对象进行操作的指令。
对MIB对象进行操作的指令通常是由SNMP网络中的网管发送给网络 设备的。在该指令中,至少包含所要操作的MIB对象的OID和所要进行的 操作。
步骤202:根据指令所要操作的MIB对象的OID,判断指令所要操作的 MIB对象为私有MIB对象还是公用MIB对象,如果是公用MIB对象则执 行步骤203,否则执行步骤204。
步骤203:根据指令中包含的所要操作的MIB对象的OID以及所要进 行的操作,运行相应的处理模块,然后结束本次流程。
步骤204:根据指令中所指定的OID,在标识符对应表中确定对应的 IOID。
步骤205:在操作对应表中,根据IOID和指令所指定的操作,确定对 应的处理模块。
步骤206:运行处理模块。
在建立了表一和表二所示的对应表,以及采用图2所示的处理流程后, 在与网络设备配套的软件中,只需要一份对私有MIB对象进行处理的代码。 但是,在软件中,仍然需要存在对应于各企业的多份私有MIB对象的数据。 为了解决这个问题,可以采用本发明提供的重定位MIB对象的方法。
请参考图3,图3是本发明提供的处理管理信息库的方法在重定位MIB 对象时的流程图。
仍然以图1中所示的MIB对象树状结构为例。图1中所示的是现有技 术中的MIB对象树状结构,企业C是OEM,为企业A和企业B制造网络 设备。以下仅以企业A和企业C为例进行说明。在现有技术的MIB树状结 构中既存在企业C的私有MIB对象,又存在企业A的私有MIB对象。企业 C的私有MIB对象是节点1.3.6.1.4.1.3.1、节点1.3.6.1.4.1.3.2和节点 1.3.6.1.4.1.3.3,与之对应的企业A的私有MIB对象是节点1.3.6.1.4.1.1.2.1、 节点1.3.6.1.4.1.1.2.2和节点1.3.6.1.4.1.1.2.3。这两组MIB对象是一一对应 的,彼此对应的MIB对象的功能是相同的。两组MIB对象的同时存在就造 成了数据冗余。在本发明中,软件的初始版本中没有节点1.3.6.1.4.1.1.2及 其下的节点。企业C在将网络设备交给企业A时,采用本发明所提供的处 理管理信息库的方法对1.3.6.1.4.1.3下的MIB对象重定位到1.3.6.1.4.1.1.2 下。
本
实施例提供的处理管理信息库的方法在重定位MIB对象时包括以下 步骤:
步骤301:获取需要重定位的MIB对象的源节点OID和目标节点OID。
以处理1.3.6.1.4.1.3下的第一个MIB对象1.3.6.1.4.1.3.1为例,其源节 点为1.3.6.1.4.1.3,目标节点为1.3.6.1.4.1.1.2。
步骤302:根据所给定的目标节点OID,判断在MIB对象树状结构中是 否已经实际存在该节点,如果已经存在,则执行步骤304,否则执行步骤303。
步骤303:创建目标节点。
一般来说,源节点下会有多个MIB对象需要重定位。在对源节点下的 第一个MIB对象进行重定位时,指定的目标节点并不存在,因此需要首先 创建目标节点。
本实施例中,在处理1.3.6.1.4.1.3.1时,目标节点1.3.6.1.4.1.1.2并不存 在,因此需要创建该目标节点。
步骤304:将需要重定位的MIB对象从源节点上取下并挂接到目标节点 上。
为了将需要重定位的MIB对象从源节点取下并挂接到目标节点上,首 先需要修改用以表示该MIB对象的数据结构中的数据域,尤其是父节点数 据域,将父节点数据域的值从源节点变为目标节点。其次还需要修改用以表 示与该MIB对象有联系的其他MIB对象的数据结构中的数据域。例如,如 果需要重定位的MIB对象是源节点的第一个子节点,那么在取下需要重定 位的MIB对象时,还需要修改表示源节点的数据结构中的第一子节点数据 域,使该数据域的值为第二个子节点;如果没有第二个子节点,就修改该数 据域的值为空。如果需要重定位的MIB对象在目标节点下也是第一个子节 点,那么在将需要重定位的MIB对象挂接到目标节点时,还需要修改表示 目标节点的数据结构中的第一子节点数据域的值为需要重定位的MIB对象。 其他相关的操作和现有技术中对于树状结构中节点移动时所进行的操作一 样。
步骤305:修改需要重定位的MIB对象的OID。
这时有两种情况,一种情况是源节点1.3.6.1.4.1.3的第一个MIB对象 1.3.6.1.4.1.3.1对应到目标节点1.3.6.1.4.1.1.2下也是第一个MIB对象;另一 种情况是1.3.6.1.4.1.3的第一个MIB对象1.3.6.1.4.1.3.1对应到目标节点 1.3.6.1.4.1.1.2下不再是第一个MIB对象。具体是哪种情况是根据企业B的 要求决定的。因此,修改需要重定位的MIB对象的OID首先要根据目标节 点的OID,其次还可能要依据需要重定位的MIB对象在目标节点下的位置。
在执行完这一步以后,MIB对象1.3.6.1.4.1.3.1的新OID为 1.3.6.1.4.1.1.2.1。
步骤306,根据源节点数据结构中第一子节点数据域的值是否为空,判 断是否已将源节点下所有需要重定位的节点都处理完,如果是则执行步骤 307,否则返
回执行步骤304。
步骤307,结束本次处理流程。
在将MIB对象重定位到新的位置上以后,原来的MIB对象就不再存在 于MIB对象树状结构中。也就是说,任何时刻,MIB对象树状结构中只存 在一份私有MIB对象的数据,这样就解决了数据冗余问题。
需要说明的是,在重定位MIB对象的过程中,在修改了MIB对象的 OID后,如果该MIB对象是树状结构上的一个枝节点,即该MIB对象还有 子节点,那么就还需要进一步修改该MIB对象下子节点的OID。假设MIB 对象1.3.6.1.4.1.3.1下的某个子节点原OID为1.3.6.1.4.1.3.1.1,则这个子节 点的新OID为1.3.6.1.4.1.1.2.1.1。有的时候,在将一个MIB对象重定位到 新的位置以后,对这个MIB对象的子节点,除了如上所述修改其OID以外, 还需要进一步调整其位置。例如,假设MIB对象1.3.6.1.4.1.3.1下的第一子 节点原OID为1.3.6.1.4.1.3.1.1,在新位置下作为MIB对象1.3.6.1.4.1.1.2.1 的第三子节点,该子节点的新OID为1.3.6.1.4.1.1.2.1.3;而MIB对象 1.3.6.1.4.1.3.1下的第三子节点原OID为1.3.6.1.4.1.3.1.3,在新位置下作为 MIB对象1.3.6.1.4.1.1.2.1的第一子节点,该子节点的新OID为 1.3.6.1.4.1.1.2.1.1。修改MIB对象的子节点的OID实际上也是执行步骤301 到步骤308。例如,在对节点1.3.6.1.4.1.3.1.1的调整过程中,实际上是以 1.3.6.1.4.1.3.1为源节点,以1.3.6.1.4.1.1.2.1为目标节点,执行步骤301到步 骤307。
需要说明的是,在MIB对象重定位的过程中,需要修改MIB对象的 OID,但是MIB对象的IOID不作改变。这样,在MIB对象从原位置被重定 位到新的位置以后,虽然其OID发生了变化,但是代码仍然能根据其IOID 对MIB对象进行恰当的处理。
以上所述仅为本发明的较佳实施例而已,并非用于限定本发明的保护范 围。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等, 均应包含在本发明的保护范围之内。