CN101572621A - 一种出错原因返回方法和一种实现网络管理的*** - Google Patents
一种出错原因返回方法和一种实现网络管理的*** Download PDFInfo
- Publication number
- CN101572621A CN101572621A CNA2008101807648A CN200810180764A CN101572621A CN 101572621 A CN101572621 A CN 101572621A CN A2008101807648 A CNA2008101807648 A CN A2008101807648A CN 200810180764 A CN200810180764 A CN 200810180764A CN 101572621 A CN101572621 A CN 101572621A
- Authority
- CN
- China
- Prior art keywords
- request message
- snmp
- managed devices
- designated identification
- snmp request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
Abstract
本发明公开了一种出错原因返回方法和一种实现网络管理的***。所述方法包括:被管理设备根据来自管理站的第一SNMP请求消息进行相应的操作出错时,保存出错原因信息,并向管理站返回第一SNMP响应消息;管理站接收到第一SNMP响应消息后,向被管理设备发送第二SNMP请求消息,以请求所述保存的出错原因信息;被管理设备接收到第二SNMP请求消息后,将保存的出错原因信息携带在第二SNMP响应消息中返回给管理站。本发明的技术方案能够实现向管理站返回具体的出错原因信息,且比较容易实现。
Description
技术领域
本发明涉及网络管理技术领域,尤指一种出错原因返回方法、一种网络管理***、一种被管理设备、一种管理站以及一种在管理站上借助计算机程序进行网络管理的方法。
背景技术
简单网络管理协议(SNMP,Simple Network Management Protocol)是目前应用最为广泛的网络管理协议,是管理站和被管理设备之间通信采用的标准协议。
图1是现有技术中的SNMP网络管理模型示意图。如图1所示,被管理设备包括SNMP代理以及管理信息库(MIB,Management InformationBase),其中,SNMP代理为一个软件程序,MIB是对象的集合,它代表网络中可以管理的资源和设备,每个对象基本上是一个数据变量,它代表被管理的对象的一方面的信息。管理站使用SNMP协议通过网络与被管理设备上的SNMP代理进行通信,并维护管理MIB。
管理站使用SNMP协议与SNMP代理进行通信时,共有5种消息格式:1)提取参数请求(get-request)消息,用于由管理站从SNMP代理处提取一个以上的参数;2)提取下一个参数请求(get-next-request)消息,用于由管理站从SNMP代理处提取所述一个以上的参数的下一个参数值;3)设置参数请求(set-request)消息,用于由管理站设置SNMP代理的一个以上的参数;4)提取响应(get-response)消息,用于由SNMP代理向管理站返回一个以上的参数;5)攻击报告(trap)消息,用于由SNMP代理向管理站主动报告某些事件的发生。
当SNMP代理接收到管理站发出get-request、get-next-request或set-request消息后进行相应的操作失败时,会通过get-response消息向管理站返回错误码,现有的SNMP定义了19种错误码,这19中错误码都是用来描述SNMP协议本身的错误原因,如数据类型不对、数据不可写等等。但这19中错误码有时并不能反映出当时的实际情况,如VLAN不存在、ID超出范围等,用户根据返回的错误码无法明白被管理设备上到底出现了什么样的错误,也就无法进行正确的网络管理。因此,在实际当中需要把被管理设备上更详细更直接的错误原因反馈给用户。
在申请号为200410004132.8的专利申请中公开了一种用于支持简单网络管理协议错误原因的方法和设备。其具体公开的内容为:将已编号的所有错误原因存储到管理站数据库和被管理设备数据库中各一份;当管理站向被管理设备发出SNMP请求消息出错后,被管理设备的程序判断当前的操作错误是否可以用SNMP所定义的19种错误码表示,如果可以则返回标准的错误码,否则从数据库中找出对应的错误原因,并将错误原因的编号返回给管理站;管理站收到被管理设备返回的消息后从自身的数据中查找与所述编号对应的错误原因。
但是这种方法的缺点在于:需要在管理站和被管理设备都保存预先定义好的错误原因和其编号之间的对应关系,不但占用空间,且在有新的错误出现(如新业务的扩展)时,需要同时升级管理站和被管理设备中保存的内容,实施起来比较繁琐。此外,当被管理设备和管理站属于不同厂商时,其自定义的编号和错误原因的对应关系可能不同,此时管理站无法根据被管理设备返回的编号获取正确的错误原因。
在申请号为200710112460.3的专利申请中公开了一种SNMP交互中返回错误信息的方法和装置。其具体公开的内容为:在MIB中定义错误消息或错误码的MIB量,这是一个全局标量;当管理站向被管理设备发送SNMP请求消息时,在消息中绑定所定义的MIB量;被管理设备根据SNMP请求消息操作失败时,将出错消息或错误码填写到返回的SNMP响应消息的MIB量中;管理站收到SNMP响应消息后,首先根据SNMP本身的错误码判断操作是否成功,如果不成功,则将MIB量中的错误消息显示给用户,或者将MIB量中的错误码转换成错误消息显示给用户。
但是这种方法的缺点在于:对于被管理设备,全局共用一个MIB标量,用于存储最新一次的错误原因,如果多个管理站同时对该被管理设备进行访问时出错,则同时需要写这个MIB量,会造成混乱。另外,该方法相当于直接将错误原因打包在SNMP响应消息中反馈给管理站,管理站需要判断SNMP响应消息的用户数据报协议(UDP)单元中哪一段保存的是错误原因信息,实现起来难度较大。
综上所述,现有的向管理站返回具体的出错原因信息的方案,实现起来难度较大。
发明内容
本发明提供了一种出错原因返回方法,该方法能够实现向管理站返回具体的出错原因信息,且比较容易实现。
本发明还提供了一种实现网络管理的***,该***能够实现向管理站返回具体的出错原因信息,且比较容易实现。
本发明还提供了一种被管理设备和一种管理站以及一种在管理站上借助计算机程序进行网络管理的方法。
为达到上述目的,本发明的技术方案具体是这样实现的:
本发明公开了一种出错原因返回方法,该方法包括:
管理站向被管理设备发送第一简单网络管理协议SNMP请求消息;
被管理设备根据所述第一SNMP请求消息进行相应的操作出错时,保存出错原因信息,并向管理站返回第一SNMP响应消息;
管理站接收到所述第一SNMP响应消息后,向被管理设备发送第二SNMP请求消息,以请求所述出错原因信息;
被管理设备接收到所述第二SNMP请求消息后,将所述保存的出错原因信息携带在第二SNMP响应消息中返回给管理站。
本发明公开了一种实现网络管理的***,该***包括:
管理站,用于向被管理设备发送第一简单网络管理协议SNMP请求消息;用于在接收到被管理设备返回的第一SNMP响应消息后,向被管理设备发送第二SNMP请求消息,以请出错原因信息;
被管理设备,用于根据所述来自管理站的第一SNMP请求消息进行相应的操作出错时,保存出错原因信息,并向管理站返回所述第一SNMP响应消息;用于在接收到来自管理站的所述第二SNMP请求消息后,将保存的出错原因信息携带在第二SNMP响应消息中返回给管理站。
本发明公开了一种被管理设备,用于通过简单网络管理协议SNMP接受管理站的管理,该被管理设备包括:
错误信息列表单元,用于保存出错原因信息;
处理单元,用于根据来自管理站的第一SNMP请求消息进行相应的操作,并在所述操作出错时将出错原因信息保存到错误信息列表单元中,并向管理站返回响应的第一SNMP响应消息;
出错原因返回单元,用于在接收到来自管理站的表示请求获取所述出错原因信息的第二SNMP请求消息后,将保存在所述错误信息列表单元中的出错原因信息携带在第二SNMP响应消息中返回给管理站。
本发明公开了一种管理站,包括:
交互单元,用于向被管理设备发送第一简单网络管理协议SNMP请求消息,并将被管理设备返回的第一SNMP响应消息发送给解析单元;在接收到解析单元返回的相应操作失败的结果后,向被管理设备发送第二SNMP请求消息,以请求被管理设备所保存的出错原因信息;
解析单元,用于解析来自交互单元的第一SNMP响应消息,并在解析出所述第一SNMP响应消息表征相应操作失败时,向交互单元返回解析结果。
本发明该公开了一种在管理站上借助计算机程序进行网络管理的方法,方方法包括以下步骤:
向被管理设备发送第一SNMP请求消息;
在接收到所述被管理设备返回的表征所述第一SNMP请求消息的相应操作失败的第一SNMP响应消息时,向被管理设备发送第二SNMP请求消息,以请求被管理设备保存的出错原因信息;
接收被管理设备返回的携带出错原因信息的第二SNMP响应消息。
由上述技术方案可见,本发明这种被管理设备在根据来自管理站的第一SNMP请求消息进行相应的操作出错时,保存出错原因信息,并在接收到管理站发送的表示请求所述保存的出错原因信息的第二SNMP请求消息时,将保存的出错原因信息返回给管理站的技术方案,能够实现向管理站返回具体的出错原因信息。此外,本发明的技术方案不需要像200410004132.8号专利申请所公开的技术方案那样在管理站和被管理设备上分别保存预先定义的错误信息,因此不会导致占用大量空间,也不需要对所保存的错误信息进行升级管理;本发明的技术方案也不像200710112460.3号专利申请所公开的技术方案那样在操作出错时直接将错误原因信息填写到返回的SNMP响应消息的MIB量中,因此在多个管理站同时对同一被管理设备进行管理时不会出现混乱,且管理站不需要判断SNMP响应消息的UDP中哪一段是错误原因信息;因此,本发明的技术方案比现有的其它方案容易实现。
附图说明
图1是现有技术中的SNMP网络管理模型示意图;
图2是本发明一种出错原因返回方法的第一实施例流程图;
图3是本发明一种出错原因返回方法的第二实施例流程图;
图4是本发明一种出错原因返回方法的第三实施例流程图;
图5为本发明实施例一种被管理设备的组成结构框图;
图6本发明实施例一种管理站的组成结构框图。
具体实施方式
本发明的核心思想是:被管理设备在根据来自管理站的SNMP请求消息进行相应的操作出错时,保存出错原因信息,并向管理站返回SNMP响应消息;管理站根据所述SNMP响应消息获知操作出错后,向被管理设备请求所述保存的出错原因信息;被管理设备根据所述请求返回相应的出错原因信息。
上述保存出错原因信息的位置可以由管理站和被管理设备预先预定好,比如,在本发明实施例中,被管理设备可以预先建立一个专用于保存出错原因信息的MIB表,并在根据管理站的SNMP请求消息进行相应的操作出错时,将出错原因信息保存到MIB表中的由指定标识所指示的特定位置中。所述指定标识可以是第一SNMP请求消息的标识;或者,所述指定标识为由被管理设备所确定的标识,并且所述被管理设备向管理站通知所述指定标识;或者,所述指定标识为所述第一SNMP请求消息所请求操作的管理信息库MIB节点的对象标识。
为使本发明的目的、技术方案及优点更加清楚明白,以下参照附图并举较佳实施例,对本发明进一步详细说明。
图2是本发明一种出错原因返回方法的第一实施例流程图。如图2所示,包括以下步骤:
步骤201,管理站向被管理设备发送第一SNMP请求消息。
本步骤中,所述第一SNMP请求消息具体可以为:提取参数请求(get-request)消息,或者为提取下一个参数请求(get-next-request)消息,或者为设置参数请求(set-request)消息。
步骤202,被管理设备根据所述第一SNMP请求消息进行相应的操作出错时,将出错原因信息与所述第一SNMP请求消息的标识对应保存到错误信息列表中,并向管理站返回第一SNMP响应消息。
本步骤中,所述错误信息列表是预先建立在被管理设备的MIB中。在MIB中建立错误信息列表具体可以为:在被管理设备的MIB中建立三个节点,分别为concreteErrorReason节点、errorID节点和errorReason节点,其中,concreteErrorReason节点为errorID节点和errorReason节点的父节点,errorID节点用于保存操作出错的SNMP请求消息的标识,errorReason节点用于保存对应的出错原因。而SNMP请求消息的标识具体可以为snmpRequestID,因为它是SNMP请求消息报文的唯一标识。
本步骤中,被管理设备向管理站返回的第一SNMP响应消息中可以携带现有的SNMP协议中定义的19种错误码的一种,虽然该错误码不能表示详细的出错原因,但表示被管理设备操作已出错以及简单的出错原因。或者,被管理设备向管理站返回的第一SNMP响应消息中可以携带一个特定值,该特定值表示第一SNMP请求消息的相应操作失败。
步骤203,管理站接收到所述第一SNMP响应消息后,获知所述第一SNMP请求消息的操作失败,向被管理设备发送第二SNMP请求消息,以请求所述错误信息列表中的与第一SNMP请求消息标识对应的出错原因信息。
本步骤中,管理站侧是预先知道被管理设备MIB中的错误信息列表的,即预先知道所述错误信息列表在MIB中的地址,这是因为管理站依据MIB对被管理设备进行管理时,其本身是保存有MIB的所有节点的信息的。例如,当上述concreteErrorReason节点在MIB中地址为1.1.3,且errorID节点和errorReason节点的标号分别为1和2,则errorReason节点在MIB中的地址为1.1.3.2,又如果上述第一SNMP请求消息标识为110110,则本步骤的第二SNMP请求消息携带如下格式的信息:1.1.3.2.110110,以表示请求errorReason节点中的与errorID节点中的110110对应的条目信息,即对应的出错原因信息。
步骤204,被管理设备接收到所述第二SNMP请求消息后,将保存在所述错误信息列表中的与第一SNMP请求消息标识对应的出错原因信息携带在第二SNMP响应消息中返回给管理站。
前面提到SNMP请求消息的标识具体可以为snmpRequestID,因为它是SNMP请求消息报文的唯一标识。这里需要说明的是,对于同一个管理站来说snmpRequestID是SNMP请求报文的唯一标识,但是对于不同的管理站来说其SNMP请求报文的snmpRequestID有可能是重叠的。那么在有多个管理站同时对被管理设备进行管理的情况下就只用snmpRequestID不能唯一标识一个SNMP请求消息,会出现混乱。为此,本发明还给出了如下的解决方案:
1)同时对被管理设备进行管理的多个管理站软件程序分别安装在各不相同的机器上的情况:用“IP地址+snmpRequestID”来区分不同管理站的SNMP请求消息,这样即使不同管理站发送的SNMP请求消息的snmpRequestID相同,其IP地址也不相同,因此能够进行区分;
此时,对于图2所示的流程,在步骤202中,被管理设备根据所述第一SNMP请求消息进行相应的操作出错时,将出错原因信息与“IP地址+第一SNMP请求消息的标识”对应保存到错误信息列表中,其中IP地址为第一SNMP请求消息中携带的源IP地址,即发送该第一SNMP请求消息的管理站所在的机器的IP地址;则在步骤203中,管理站接收到所述第一SNMP响应消息后,向被管理设备发送第二SNMP请求消息,以请求所述错误信息列表中的与“IP地址+第一SNMP请求消息的标识”对应的出错原因信息。
2)同时对被管理设备进行管理的多个管理站软件程序安装在同一台机器上的情况:用“端口号+snmpRequestID”来区分不同管理站的SNMP请求消息,这样即使不同管理站发送的SNMP请求消息的snmpRequestID相同,其发送SNMP请求消息的端口也不相同,因此能够进行区分;
此时,对于图2所示的流程,在步骤202中,被管理设备根据所述第一SNMP请求消息进行相应的操作出错时,将出错原因信息与“端口号+第一SNMP请求消息的标识”对应保存到错误信息列表中,其中端口号为第一SNMP请求消息中携带的源端口号,即发送该第一SNMP请求消息的管理站所在的机器上的发送该第一SNMP请求消息的端口号;则在步骤203中,管理站接收到所述第一SNMP响应消息后,向被管理设备发送第二SNMP请求消息,以请求所述错误信息列表中的与“端口号+第一SNMP请求消息的标识”对应的出错原因信息。
3)同时对被管理设备进行管理的多个管理站软件程序被安装在不同的机器上,且也存在同一台机器上安装了两个以上的管理站软件程序的情况:用“IP地址+端口号+snmpRequestID”来区分不同管理站的SNMP请求消息,这样即使不同管理站发送的SNMP请求消息的snmpRequestID相同。
此时,对于图2所示的流程,在步骤202中,被管理设备将出错原因信息与“IP地址+端口号+第一SNMP请求消息的标识”对应保存到错误信息列表中;则在步骤203中,管理站接收到所述第一SNMP响应消息后,向被管理设备发送第二SNMP请求消息,以请求所述错误信息列表中的与“IP地址+端口号+第一SNMP请求消息的标识”对应的出错原因信息。
图3是本发明一种出错原因返回方法的第二实施例流程图。如图3所示,包括以下步骤:
步骤301,管理站向被管理设备发送第一SNMP请求消息。
同样,本步骤中所述的第一SNMP请求消息具体可以为:get-request、get-next-request或者set-request。
步骤302,被管理设备根据所述第一SNMP请求消息进行相应的操作出错时,确定一指定标识,将出错原因信息与所述指定标识对应保存到错误信息列表中,并向管理站返回携带所述指定标识的第一SNMP响应消息。
本步骤中,为了与现有的SNMP协议中定义的19种错误码(1至19)进行区别,所述指定标识取除1至19以外的值,例如取20以及大于20的值。本步骤中,被管理设备向管理站返回携带指定标识的第一SNMP响应消息具体可以为:在第一SNMP响应消息的“errorStatus”字段中写入与出错原因信息对应的指定标识。
本步骤,所述错误信息列表是预先建立在被管理设备的MIB中。
步骤303,管理站接收到所述携带指定标识的第一SNMP响应消息后,获知所述第一SNMP请求消息的操作失败,向被管理设备发送第二SNMP请求消息,以请求所述错误信息列表中的与所述指定标识对应的出错原因信息。
步骤304,被管理设备接收到所述第二SNMP请求消息后,将保存在所述错误信息列表中的与所述指定标识对应的出错原因信息携带在第二SNMP响应消息中返回给管理站。
图4是本发明一种出错原因返回方法的第三实施例流程图。如图4所示,包括以下步骤:
步骤401,管理站向被管理设备发送第一SNMP请求消息。
在本实施例中,所述第一SNMP请求消息可以是对被管理设备中的多个MIB节点进行配置。例如,同时对MIB中的三个节点分别配置不同的参数,如表1所示:
MIB节点的名称(MIB节点的对象标识(OID)) | 配置参数 |
1.3.6.1.2.1.2.2.1.2 | 5 |
1.3.6.1.2.1.2.2.1.3 | 6 |
1.3.6.1.2.1.2.2.1.4 | 7 |
表1
如表1所示,所述第一SNMP请求消息是请求被管理设备将MIB中的对象标识(OID,Object Identifier)为1.3.6.1.2.1.2.2.1.2的节点配置为参数5、将MIB中的OID为1.3.6.1.2.1.2.2.1.3的节点配置为参数6、将MIB中的OID为1.3.6.1.2.1.2.2.1.4的节点配置为参数7。
步骤402,被管理设备根据所述第一SNMP请求消息进行相应的操作出错时,将出错原因信息与所述第一SNMP请求消息所请求操作的MIB节点的对象标识对应保存到错误信息列表中,并向管理站返回第一SNMP响应消息。
本步骤中,所述错误信息列表是预先建立在被管理设备侧的一个MIB表,用来保存出错原因信息以及其索引,在本实施例中出错原因信息的索引是MIB节点的OID。在本实施例中设所述预先建立的MIB表的名称为SnmpOperationResultTable,包括两个节点:SnmpOperationResultID和SnmpOperationErrorStatus,其中SnmpOperationResultID是表的索引,为OBJECT IDENTIFIER类型,用于保存出错原因的索引,即用于保存SNMP操作的MIB节点的OID;SnmpOperationErrorStatus用于存放出错原因信息,可以直接是表示出错原因的字符串,也可以是错误码,如果是错误码,则管理站和被管理设备之间还要约定出错原因和错误码之间的对应关系。
例如,当所述第一SNMP请求消息请求被被管理设备执行如表1所示的操作,且被管理设备在根基第一SNMP请求消息配置节点1.3.6.1.2.1.2.2.1.2时由于Radius服务器没有配置(对应的错误码为1001)而出错、在配置节点1.3.6.1.2.1.2.2.1.3时由于端口安全没有配置(对应的错误码为1002)而出错、配置节点1.3.6.1.2.1.2.2.1.4成功时,被管理设备在所述预先建立的作为错误信息列表的MIB表中配置如表2所示的信息:
SnmpOperationResultID | SnmpOperationErrorStatus |
1.3.6.1.2.1.2.2.1.2 | 1001 |
1.3.6.1.2.1.2.2.1.2 | 1002 |
1.3.6.1.2.1.2.2.1.2 | 0 |
表2
在表2中,0表示配置成功,没有出错。当然管理站和被管理设备之间也可以不约定错误码,则表2中SnmpOperationErrorStatus处直接填写出错原因的字符串。
本步骤中,被管理设备向管理站返回的第一SNMP响应消息中可以携带现有的SNMP协议中定义的19种错误码的一种,虽然该错误码不能表示详细的出错原因,但表示被管理设备操作已出错。或者,被管理设备向管理站返回的第一SNMP响应消息中可以携带一个特定值,该特定值表示第一SNMP请求消息的相应操作失败。
步骤403,管理站接收到所述第一SNMP响应消息后,获知所述第一SNMP请求消息的操作失败,向被管理设备发送第二SNMP请求消息,以请求所述错误信息列表中的与第一SNMP请求消息所请求操作的MIB节点的对象标识对应的出错原因信息。
本步骤中,管理站侧是预先知道被管理设备MIB中的错误信息列表的,即预先知道所述错误信息列表在MIB中的地址,这是因为管理站依据MIB对被管理设备进行管理时,其本身是保存有MIB的所有节点的信息的。
本实施例中,由于第一SNMP请求消息请求对多个MIB节点进行操作,因此,管理站也发送多个第二SNMP请求消息,以分别请求与所述多个MIB节点对应的出错原因。例如在本实施例中,管理站向被管理设备分别发送请求错误信息列表中的与1.3.6.1.2.1.2.2.1.2对应的出错原因信息的SNMP请求消息、请求错误信息列表中的与1.3.6.1.2.1.2.2.1.3对应的出错原因信息的SNMP请求消息以及请求错误信息列表中的与1.3.6.1.2.1.2.2.1.4对应的出错原因信息的SNMP请求消息。
步骤404,被管理设备接收到所述第二SNMP请求消息后,将保存在所述错误信息列表中的与第一SNMP请求消息所请求操作的MIB节点的对象标识所对应的出错原因信息携带在第二SNMP响应消息中返回给管理站。
需要说明的是,如果在图4所示的实施例中,所示第一SNMP请求消息所请求操作的MIB节点是表节点,且第一SNMP请求消息请求操作的是该表节点的某一行,则步骤402中保存的出错原因信息的索引信息是:该表节点的OID加上所操作的行的索引。
通过图4所示实施例的技术方案,不仅可以返回具体的出错原因信息,而且在对多个变量操作失败时,能够返回对每个变量的操作出错原因信息。
在图2、3和4所示的实施例中,对于被管理设备而言,出于时效性和空间占用的考虑,可以利用老化机制对在所述错误信息列表进行管理,例如配置一个老化时间,超过该时间长度的记录自动被删除,从而使得错误信息列表中存放最近的几条出错原因信息即可,这样即节省了空间,还加快了对管理站侧的出错原因请求消息的反馈效率。
在图2、3和4所示的实施例中,管理站和被管理设备也可以预先约定一个算法,则在上述步骤202(或步骤302,或步骤402)中,被管理设备根据所述第一SNMP请求消息进行相应的操作出错时,根据第一SNMP请求消息的标识(或所确定的指定标识,或***作的MIB节点的OID)以及所述预先约定的算法计算出一个用于保存出错原因信息的特定位置,如某个地址等,然后将出错原因信息保存到所计算出的特定位置中;则相应地在步骤203(或步骤303,或步骤403)中,管理站也根据第一SNMP请求消息的标识(或所述指定标识,或***作的MIB节点的OID)以及所述预先约定的算法计算出同样的特定位置后,向被管理设备发送第二SNMP请求消息,以请求所计算出的特定位置中保存的出错原因信息。上述预先约定的算法可以是类似V3中的鉴权和加密机制的算法,管理站和被管理设备双方通过将第一SNMP请求消息的标识作为键值(key),根据所述约定算法计算出保存地址(ID)。从上述实施方式中,本领域人员可以清楚地了解到在本发明中,对于特定位置的约定是有很多种方式的,其各有各的特点。本领域技术人员可以根据实际需要采用合适的约定,也根据公知常识和公知技术实施符合实际情况的新约定;总之这些约定只要让管理站有途径获知具体出错的原因存放的位置即可。
在图2、3和4所示的实施例中,如果步骤204(或步骤304,或步骤404)中被管理设备根据第二SNMP请求消息进行相应的操作仍出错时,则管理站不应该再次进行出错原因信息的请求,否则有可能会产生死循环。但是,在实际应用中被管理设备根据第二SNMP请求消息进行相应的操作仍出错的情况很难发生,除非与设备之间的通信出现了问题,或者被管理设备在步骤202(或步骤302,或步骤402)中,没有将出错原因信息和第一SNMP请求消息的标识对应保存。
在图2、3和4所示的实施例中,所有被管理设备所执行的操作都是由被管理设备中的SNMP代理来完成的,而管理站所执行的操作都是由管理站上的专用于进行网络管理的计算机程序来执行的。
通过图2、3和4所示的实施例可以看出,本发明的方案基于MIB中的错误信息列表实现错误原因的反馈,整个流程兼容了原有的SNMP协议,即在不改变原有SNMP协议的情况下,被管理设备可以让管理站知道出错原因信息在MIB表中的位置,从而使得管理站可以通过再次的get操作获得出错原因信息,因此具体实施时,对原有的设备和机制不需要做太大的改动,实现起来比较容易。
接下来给出本发明中的一种实现网络管理的***的组成结构。
本发明中的实现网络管理的***的组成结构与图1所示的结构相同,这里不再画出,但是在本发明实施例中:
管理站,用于向被管理设备发送第一简单网络管理协议SNMP请求消息;用于在接收到被管理设备返回的第一SNMP响应消息后,向被管理设备发送第二SNMP请求消息,以请求出错原因信息;
被管理设备,用于根据所述来自管理站的第一SNMP请求消息进行相应的操作出错时,保存出错原因信息,并向管理站返回所述第一SNMP响应消息;用于在接收到来自管理站的所述第二SNMP请求消息后,将保存的出错原因信息携带在第二SNMP响应消息中返回给管理站。
在本发上述明实施中所述的实现网络管理的***中,所述被管理设备,在根据所述来自管理站的第一SNMP请求消息进行相应的操作出错时,用于将出错原因信息保存到指定标识所指示的特定位置中;所述管理站,用于在接收到被管理设备返回的第一SNMP响应消息后,向被管理设备发送第二SNMP请求消息,以请求所述指定标识所指示的特定位置中所保存的出错原因信息。
在本发上述明实施中所述的实现网络管理的***中,所述指定标识为所述第一SNMP请求消息的标识;或者,所述指定标识为所述第一SNMP请求消息的标识和所述第一SNMP请求消息的源IP地址的集合;或者,所述指定标识为所述第一SNMP请求消息的标识和所述第一SNMP请求消息的源端口号的集合;或者,所述指定标识为所述第一SNMP请求消息的标识、所述第一SNMP请求消息的源IP地址以及所述第一SNMP请求消息的源端口号的集合;或者,所述指定标识为由被管理设备所确定的标识,并且所述被管理设备进一步用于在向管理站返回的第一SNMP响应消息中携带所述指定标识;或者,所述指定标识为所述第一SNMP请求消息所请求操作的管理信息库MIB节点的对象标识。
在本发明实施例中所述的实现网络管理的***中,由被管理设备中的SNMP代理完成上述关于被管理设备的所有操作。
在本发明实施例中所述的实现网络管理的***中,当所述指定标识为所述第一SNMP请求消息的标识或所述第一SNMP请求消息所请求操作的MIB节点的对象标识时,被管理设备向管理站返回的第一SNMP响应消息中携带有特定值或SNMP协议中定义的19种错误码的一种,以告知所述管理站所述第一SNMP请求消息的相应操作失败。
在本发明实施例中所述的实现网络管理的***中,被管理设备,用于将出错原因信息与所述指定标识对应保存到自身管理信息库MIB中预先建立的错误信息列表中;管理站,用于预先保存所述MIB的各节点信息;在接收到所述第一SNMP响应消息后,向被管理设备发送所述第二SNMP请求消息,以请求所述MIB错误信息列表中的与所述指定标识对应的错误原因信息。其中,所述被管理设备用于在自身的MIB中预先建立三个节点作为所述错误信息列表,且其中的第一节点为第二节点和第三节点的父节点;并在根据所述第一SNMP请求消息进行相应的操作失败时,将所述指定标识填写到所述第二节点的指定行,将所述出错原因信息填写到第三节点中与第二节点的指定行对应的行中。
或者,被管理设备,用于在根据所述第一SNMP请求消息进行相应的操作出错时,根据与管理站约定好的算法以及所述指定标识计算出一个特定的位置,并将所述出错原因信息保存到所计算出的特定位置中;管理站,用于在接收到所述第一SNMP响应消息之后,并在发送第二SNMP请求消息之前进一步根据所述约定好的算法以及所述指定标识计算出所述特定位置。
接下来给出本发明中的一种被管理设备的组成结构。
图5为本发明实施例一种被管理设备的组成结构框图。如图5所示,该被管理设备用于通过简单网络管理协议SNMP接受管理站的管理,包括:错误信息列表单元501、处理单元502和出错原因返回单元503,其中:
错误信息列表单元501,用于保存出错原因信息;
处理单元502,用于根据来自管理站的第一SNMP请求消息进行相应的操作,并在所述操作出错时将出错原因信息保存到错误信息列表单元501中,并向管理站返回相应的第一SNMP响应消息;
出错原因返回单元503用于在接收到来自管理站的表示请求获取所述出错原因信息的第二SNMP请求消息后,将保存在所述错误信息列表单元501中的出错原因信息携带在第二SNMP响应消息中返回给管理站。
在图5所示的实施例中,处理单元502,在根据来自管理站的第一SNMP请求消息进行相应的操作出错时,将出错原因信息保存到错误信息列表单元501中的由指定标识所指示的特定位置中;其中,管理站根据预先的约定获知所述指定标识,并向出错原因返回单元503发送第二SNMP请求消息,以请求错误信息列表单元501中的由指定标识所指示的特定位置中的出错原因信息。
在图5所示的实施例中,所述指定标识为所述第一SNMP请求消息的标识;或者,所述指定标识为所述第一SNMP请求消息的标识和所述第一SNMP请求消息的源IP地址的集合;或者,所述指定标识为所述第一SNMP请求消息的标识和所述第一SNMP请求消息的源端口号的集合;或者,所述指定标识为所述第一SNMP请求消息的标识、所述第一SNMP请求消息的源IP地址以及所述第一SNMP请求消息的源端口号的集合;或者,所述指定标识为由处理单元所确定的标识,并且所述处理单元502进一步用于在向管理站返回的第一SNMP响应消息中携带所述指定标识;或者,所述指定标识为所述第一SNMP请求消息所请求操作的管理信息库MIB节点的对象标识
在图5中,当所述指定标识为所述第一SNMP请求消息的标识或所述第一SNMP请求消息所请求操作的管理信息库MIB节点的对象标识时,所述处理单元502向管理站返回的第一SNMP响应消息中携带有特定值或SNMP协议中定义的19种错误码的一种,以告知所述管理站所述第一SNMP请求消息的相应操作失败。
在图5中,错误信息列表单元501设置在所述被管理设备的管理信息库MIB中;所述处理单元502为SNMP代理,用于在根据所述第一SNMP请求消息进行相应的操作出错时,将出错原因信息与所述指定标识对应保存到所述MIB中的错误信息列表单元中。其中,当错误信息列表单元501设置在所述被管理设备的管理信息库MIB中时,所述错误信息列表单元具体包括所述MIB中的三个节点,且其中的第一节点为第二节点和第三节点的父节点;此时,处理单元502,用于在根据所述第一SNMP请求消息进行相应的操作失败时,将所述指定标识填写到所述第二节点的指定行,将所述出错原因信息填写到第三节点中与第二节点的指定行对应的行中。
或者,在图5中,处理单元502,在根据第一SNMP请求消息进行相应的操作出错时,根据与管理站约定好的算法以及所述指定标识计算出错误信息列表单元501中的一个特定位置,并将所述出错原因信息保存到错误信息列表单元中的特定位置中,然后返回所述第一SNMP响应消息。则所述第二SNMP请求消息是管理站在接收到所述第一SNMP响应消息之后,根据所述约定好的算法以及所述指定标识计算出所述错误信息列表单元的特定位置后发送的。
图6本发明实施例一种管理站的组成结构框图。如图6所示,包括:交互单元601和解析单元602,其中:
交互单元601,用于向被管理设备发送第一简单网络管理协议SNMP请求消息,并将被管理设备返回的第一SNMP响应消息发送给解析单元502;在接收到解析单元602返回的操作失败结果后,向被管理设备发送第二SNMP请求消息,以请求被管理设备所保存的出错原因信息。
解析单元602,用于解析来自交互单元601的第一SNMP响应消息,并向交互单元601返回解析结果。
在图6所示的实施例中,被管理设备将所述出错原因信息保存在指定标识所指示的特定位置中;交互单元601,用于向被管理设备发送第二SNMP请求消息,以请求所述指定标识所指示的特定位置中所保存的出错原因信息。
在图6所示的实施例中,所述指定标识为所述第一SNMP请求消息的标识;或者,所述指定标识为所述第一SNMP请求消息的标识和所述第一SNMP请求消息的源IP地址的集合;或者,所述指定标识为所述第一SNMP请求消息的标识和所述第一SNMP请求消息的源端口号的集合;或者,所述指定标识为所述第一SNMP请求消息的标识、所述第一SNMP请求消息的源IP地址以及所述第一SNMP请求消息的源端口号的集合;或者,所述指定标识为由被管理设备所确定的标识,并且所述被管理设备返回的第一SNMP响应消息中进一步携带所述指定标识,所述解析单元根据第一SNMP响应消息中的指定标识确定相应操作失败;或者,所述指定标识为所述第一SNMP请求消息所请求操作的管理信息库MIB节点的对象标识。
如图6所示,该管理站还可以包括:存储单元603,用于保存所述被管理设备的各MIB节点信息;所述MIB中包括一个用于保存指定标识与出错原因信息的对应关系的指定MIB节点;交互单元601,根据存储单元603中保存的MIB节点信息发送所述第二SNMP请求消息,以请求保存在被管理设备的指定MIB节点中的与指定标识对应的出错原因信息。
或者,如图6所示的管理站可以包括一个计算单元604,在图6中用虚线框表示。计算单元604,用于接收来自交互单元601的指定标识,并根据指定标识以及与被管理设备约定好的算法计算出指定位置返回给交互单元601;交互单元601,用于根据计算单元604返回的指定位置,向被管理设备发送第二SNMP请求消息,以请求所述指定位置中的出错原因信息。
综上所述,本发明这种被管理设备在根据来自管理站的第一SNMP请求消息进行相应的操作出错时,将出错原因信息和指定标识对应保存到错误信息列表,并在接收到管理站发送的表示请求所述错误信息列表中的与指定标识对应的出错原因信息的第二SNMP请求消息时,将所述错误信息列表中的与指定标识对应的出错原因信息返回给管理站的技术方案,不仅能够实现向管理站返回具体的出错原因信息,且比现有的其它方案容易实现。
以上所述,仅为本发明的较佳实施例而已,并非用于限定本发明的保护范围,凡在本发明的精神和原则之内所做的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (37)
1、一种出错原因返回方法,其特征在于,该方法包括:
管理站向被管理设备发送第一简单网络管理协议SNMP请求消息;
被管理设备根据所述第一SNMP请求消息进行相应的操作出错时,保存出错原因信息,并向管理站返回第一SNMP响应消息;
管理站接收到所述第一SNMP响应消息后,向被管理设备发送第二SNMP请求消息,以请求所述保存的出错原因信息;
被管理设备接收到所述第二SNMP请求消息后,将所述保存的出错原因信息携带在第二SNMP响应消息中返回给管理站。
2、如权利要求1所述的方法,其特征在于,
所述被管理设备保存出错原因信息包括:所述被管理设备将出错原因信息保存到指定标识所指示的特定位置中;
所述管理站向被管理设备发送的第二SNMP请求消息,用以请求所述指定标识所指示的特定位置中所保存的出错原因信息。
3、如权利要求2所述的方法,其特征在于,
所述指定标识为所述第一SNMP请求消息的标识;或者
所述指定标识为所述第一SNMP请求消息的标识和所述第一SNMP请求消息的源IP地址的集合;或者
所述指定标识为所述第一SNMP请求消息的标识和所述第一SNMP请求消息的源端口号的集合;或者
所述指定标识为所述第一SNMP请求消息的标识、所述第一SNMP请求消息的源IP地址以及所述第一SNMP请求消息的源端口号的集合;或者
所述指定标识为由被管理设备所确定的标识,并且所述被管理设备向管理站返回的第一SNMP响应消息中进一步携带所述指定标识;或者
所述指定标识为所述第一SNMP请求消息所请求操作的管理信息库MIB节点的对象标识。
4、如权利要求1所述的方法,其特征在于,所述第一SNMP请求消息为提取参数请求消息,或者为提取下一个参数请求消息,或者为设置参数请求消息。
5、如权利要求1所述的方法,其特征在于,由被管理设备上的SNMP代理完成所述的由被管理设备完成的操作。
6、如权利要求3所述的方法,其特征在于,当所述指定标识为第一SNMP请求消息标识或所述第一SNMP请求消息所请求操作的MIB节点的对象标识时,所述第一SNMP响应消息中携带有特定值或SNMP协议中定义的19种错误码的一种,以告知所述管理站所述第一SNMP请求消息的相应操作失败。
7、如权利要求2至6中任一项所述的方法,其特征在于,
所述被管理设备将出错原因信息保存到所述指定标识所指示的特定位置中包括:所述被管理设备将出错原因信息与所述指定标识对应保存到自身管理信息库MIB中预先建立的错误信息列表中;所述管理站中预先保存有所述MIB的各节点信息;
所述管理站向被管理设备发送第二SNMP请求消息,以请求所述MIB错误信息列表中的与所述指定标识对应的错误原因信息。
8、如权利要求7所述的方法,其特征在于,所述错误信息列表为所述MIB中的三个节点,其中第一节点为第二节点和第三节点的父节点;
所述将出错原因信息与所述指定标识对应保存到错误信息列表中包括:将所述指定标识填写到所述第二节点的指定行,将所述出错原因信息填写到第三节点中与第二节点的指定行对应的行中。
9、如权利要求2至6中任一项所述的方法,其特征在于,
所述被管理设备将出错原因信息保存到所述指定标识所指示的特定位置中包括:被管理设备根据与管理站约定好的算法以及所述指定标识计算出特定位置,并将所述出错原因信息保存到所计算出的特定位置中;
在所述管理站接收到所述第一SNMP响应消息之后,并在发送第二SNMP请求消息之前进一步包括:所述管理站根据所述约定好的算法以及所述指定标识计算出所述特定位置。
10、一种实现网络管理的***,其特征在于,该***包括:
管理站,用于向被管理设备发送第一简单网络管理协议SNMP请求消息;用于在接收到被管理设备返回的第一SNMP响应消息后,向被管理设备发送第二SNMP请求消息,以请求出错原因信息;
被管理设备,用于根据所述来自管理站的第一SNMP请求消息进行相应的操作出错时,保存出错原因信息,并向管理站返回所述第一SNMP响应消息;用于在接收到来自管理站的所述第二SNMP请求消息后,将保存的出错原因信息携带在第二SNMP响应消息中返回给管理站。
11、如权利要求10所述的实现网络管理的***,其特征在于,
所述被管理设备,在根据所述来自管理站的第一SNMP请求消息进行相应的操作出错时,用于将出错原因信息保存到指定标识所指示的特定位置中;
所述管理站,用于在接收到被管理设备返回的第一SNMP响应消息后,向被管理设备发送第二SNMP请求消息,以请求所述指定标识所指定的特定位置中所保存的出错原因信息。
12、如权利要求11所述的实现网络管理的***,其特征在于,
所述指定标识为所述第一SNMP请求消息的标识;或者
所述指定标识为所述第一SNMP请求消息的标识和所述第一SNMP请求消息的源IP地址的集合;或者
所述指定标识为所述第一SNMP请求消息的标识和所述第一SNMP请求消息的源端口号的集合;或者
所述指定标识为所述第一SNMP请求消息的标识、所述第一SNMP请求消息的源IP地址以及所述第一SNMP请求消息的源端口号的集合;或者
所述指定标识为由被管理设备所确定的标识,并且所述被管理设备进一步用于在向管理站返回的第一SNMP响应消息中携带所述指定标识;或者
所述指定标识为所述第一SNMP请求消息所请求操作的管理信息库MIB节点的对象标识。
13、如权利要求10所述的实现网络管理的***,其特征在于,所述被管理设备包括:SNMP代理,用于根据所述来自管理站的第一SNMP请求消息进行相应的操作出错时,将出错原因信息保存到所述指定标识所指示的特定位置中,并向管理站返回所述第一SNMP响应消息;用于在接收到来自管理站的所述第二SNMP请求消息后,将保存在所述指定标识所指示的特定位置中的出错原因信息携带在第二SNMP响应消息中返回给管理站。
14、如权利要求12所述的实现网络管理的***,其特征在于,当所述指定标识为所述第一SNMP请求消息的标识或所述第一SNMP请求消息所请求操作的MIB节点的对象标识时,
所述被管理设备,用于在向管理站返回的第一SNMP响应消息中携带特定值或SNMP协议中定义的19种错误码的一种,以告知所述管理站所述第一SNMP请求消息的相应操作失败。
15、如权利要求11至14中任一项所述的实现网络管理的***,其特征在于,
所述被管理设备,用于将出错原因信息与所述指定标识对应保存到自身管理信息库MIB中预先建立的错误信息列表中;
所述管理站,用于预先保存所述MIB的各节点信息;在接收到所述第一SNMP响应消息后,向被管理设备发送所述第二SNMP请求消息,以请求所述MIB错误信息列表中的与所述指定标识对应的错误原因信息。
16、如权利要求15所述的网络管理***,其特征在于,
所述被管理设备,用于在所述MIB中预先建立三个节点作为所述错误信息列表,且其中的第一节点为第二节点和第三节点的父节点;用于在根据所述第一SNMP请求消息进行相应的操作失败时,将所述指定标识填写到所述第二节点的指定行,将所述出错原因信息填写到第三节点中与第二节点的指定行对应的行中。
17、如权利要求11至14中任一项所述的实现网络管理的***,其特征在于,
所述被管理设备,用于在根据所述第一SNMP请求消息进行相应的操作出错时,根据与管理站约定好的算法以及所述指定标识计算出特定位置,并将所述出错原因信息保存到所计算出的特定位置中;
所述管理站,用于在接收到所述第一SNMP响应消息之后,并在发送第二SNMP请求消息之前进一步根据所述约定好的算法以及所述指定标识计算出所述特定位置。
18、一种被管理设备,用于通过简单网络管理协议SNMP接受管理站的管理,其特征在于,该被管理设备包括:
错误信息列表单元,用于保存出错原因信息;
处理单元,用于根据来自管理站的第一SNMP请求消息进行相应的操作,并在所述操作出错时将出错原因信息保存到错误信息列表单元中,并向管理站返回相应的第一SNMP响应消息;
出错原因返回单元,用于在接收到来自管理站的表示请求获取所述出错原因信息的第二SNMP请求消息后,将保存在所述错误信息列表单元中的出错原因信息携带在第二SNMP响应消息中返回给管理站。
19、如权利要求18所述的被管理设备,其特征在于,
所述处理单元,根据所述被管理设备与所述管理站的约定将出错原因信息保存到错误信息列表单元的特定位置中。
20、如权利要求19所述的被管理设备,其特征在于,所述约定具体为:将出错原因信息保存到错误信息列表中的由一个指定标识所指示的特定位置中。
21、如权利要求20所述的被管理设备,其特征在于,
所述指定标识为所述第一SNMP请求消息的标识;或者
所述指定标识为所述第一SNMP请求消息的标识和所述第一SNMP请求消息的源IP地址的集合;或者
所述指定标识为所述第一SNMP请求消息的标识和所述第一SNMP请求消息的源端口号的集合;或者
所述指定标识为所述第一SNMP请求消息的标识、所述第一SNMP请求消息的源IP地址以及所述第一SNMP请求消息的源端口号的集合;或者
所述指定标识为由处理单元所确定的标识,并且所述处理单元进一步用于在向管理站返回的第一SNMP响应消息中携带所述指定标识;或者
所述指定标识为所述第一SNMP请求消息所请求操作的管理信息库MIB节点的对象标识。
22、如权利要求21所述的被管理设备,其特征在于,当所述指定标识为所述第一SNMP请求消息的标识或所述第一SNMP请求消息所请求操作的管理信息库MIB节点的对象标识时,所述处理单元向管理站返回的第一SNMP响应消息中携带有特定值或SNMP协议中定义的19种错误码的一种,以告知所述管理站所述第一SNMP请求消息的相应操作失败。
23、如权利要求20至22中任一项所述的被管理设备,其特征在于,
所述错误信息列表单元设置在所述被管理设备的管理信息库MIB中;
所述处理单元为SNMP代理,用于在根据所述第一SNMP请求消息进行相应的操作出错时,将出错原因信息与所述指定标识对应保存到所述MIB中的错误信息列表单元中。
24、如权利要求23所述的被管理设备,其特征在于,当所述错误信息列表单元设置在所述被管理设备的管理信息库MIB中时,所述错误信息列表单元具体包括所述MIB中的三个节点,且其中的第一节点为第二节点和第三节点的父节点;
所述处理单元,用于在根据所述第一SNMP请求消息进行相应的操作失败时,将所述指定标识填写到所述第二节点的指定行,将所述出错原因信息填写到第三节点中与第二节点的指定行对应的行中。
25、如权利要求20至22中任一项所述的被管理设备,其特征在于,所述处理单元,在根据第一SNMP请求消息进行相应的操作出错时,根据与管理站约定好的算法以及所述指定标识计算出所述错误信息列表单元的特定位置,并将所述出错原因信息保存到所述错误信息列表单元的特定位置中,然后返回所述第一SNMP响应消息;
所述第二SNMP请求消息是管理站在接收到所述第一SNMP响应消息之后,根据所述约定好的算法以及所述指定标识计算出所述错误信息列表单元的特定位置后发送的。
26、一种管理站,其特征在于,包括:
交互单元,用于向被管理设备发送第一简单网络管理协议SNMP请求消息,并将被管理设备返回的第一SNMP响应消息发送给解析单元;在接收到解析单元返回的相应操作失败的结果后,向被管理设备发送第二SNMP请求消息,以请求被管理设备所保存的出错原因信息;
解析单元,用于解析来自交互单元的第一SNMP响应消息,并在解析出所述第一SNMP响应消息表征相应操作失败时,向交互单元返回解析结果。
27、如权利要求26所述的管理站,其特征在于,被管理设备将所述出错原因信息保存在管理站与被管理设备之间约定的特定位置中,而所述解析单元根据所述既有的约定将保存出错原因信息的特定位置通知交互单元。
28、如权利要求27所述的管理站,其特征在于,所述约定具体为:将出错原因信息保存在一个指定标识所指示的特定位置中。
29、如权利要求28所述的管理站,其特征在于,
所述指定标识为所述第一SNMP请求消息的标识;或者
所述指定标识为所述第一SNMP请求消息的标识和所述第一SNMP请求消息的源IP地址的集合;或者
所述指定标识为所述第一SNMP请求消息的标识和所述第一SNMP请求消息的源端口号的集合;或者
所述指定标识为所述第一SNMP请求消息的标识、所述第一SNMP请求消息的源IP地址以及所述第一SNMP请求消息的源端口号的集合;或者
所述指定标识为由被管理设备所确定的标识,并且所述被管理设备返回的第一SNMP响应消息中进一步携带所述指定标识,所述解析单元根据第一SNMP响应消息中的指定标识确定相应操作失败;或者
所述指定标识为所述第一SNMP请求消息所请求操作的管理信息库MIB节点的对象标识。
30、如权利要求28或29所述的管理站,其特征在于,该管理站进一步包括:存储单元,用于保存所述被管理设备的各MIB节点信息;所述MIB中包括一个用于保存指定标识与出错原因信息的对应关系的指定MIB节点;
所述交互单元,根据存储单元中保存的MIB节点信息发送所述第二SNMP请求消息,以请求保存在被管理设备的指定MIB节点中的与指定标识对应的出错原因信息。
31、如权利要求28或29所述的管理站,其特征在于,该管理站进一步包括计算单元,用于接收来自交互单元的指定标识,并根据指定标识以及与被管理设备约定好的算法计算出特定位置返回给交互单元;
所述交互单元,用于根据计算单元返回的特定位置,向被管理设备发送第二SNMP请求消息,以请求所述特定位置中的出错原因信息。
32、一种在管理站上借助计算机程序进行网络管理的方法,其特征在于,该方法包括以下步骤:
向被管理设备发送第一SNMP请求消息;
在接收到所述被管理设备返回的表征所述第一SNMP请求消息的相应操作失败的第一SNMP响应消息时,向被管理设备发送第二SNMP请求消息,以请求被管理设备保存的出错原因信息;
接收被管理设备返回的携带出错原因信息的第二SNMP响应消息。
33、如权利要求32所述的方法,其特征在于,所述出错原因信息保存在管理站与被管理设备约定的特定位置中,而所述第二SNMP请求消息用于请求所述约定的特定位置中的出错原因信息。
34、如权利要求33所述的方法,其特征在于,
所述约定具体为:将出错原因信息保存在一个指定标识所指示的特定位置中。
35、如权利要求34所述的方法,其特征在于,
所述指定标识为所述第一SNMP请求消息的标识;或者
所述指定标识为所述第一SNMP请求消息的标识和所述第一SNMP请求消息的源IP地址的集合;或者
所述指定标识为所述第一SNMP请求消息的标识和所述第一SNMP请求消息的源端口号的集合;或者
所述指定标识为所述第一SNMP请求消息的标识、所述第一SNMP请求消息的源IP地址以及所述第一SNMP请求消息的源端口号的集合;或者
所述指定标识为由被管理设备所确定的标识,并且所述被管理设备返回的第一SNMP响应消息中进一步携带所述指定标识;或者
所述指定标识为所述第一SNMP请求消息所请求操作的管理信息库MIB节点的对象标识。
36、如权利要求34或35所述的方法,其特征在于,所述管理站预先保存有被管理设备的管理信息库MIB中的各节点信息,所述被管理设备将出错原因信息保存到所述指定标识所指示的特定位置中是,将出错原因信息和SNMP请求标识对应保存到所述MIB中的错误信息列表中;
则所述计算机程序向被管理设备发送第二SNMP请求消息,以请求所述指定标识所指示的特定位置中所保存的出错原因信息,即为请求所述错误信息列表中与所述指定标识所对应的出错原因信息。
37、如权利要求34或35所述的方法,其特征在于,所述被管理设备将出错原因信息保存到所述指定标识所指示的特定位置中是,根据与所述管理站约定好的算法和所述指定标识计算出特定位置,并将所述出错原因信息保存到所述特定位置中;
所述计算机程序在接收到第一SNMP响应消息后,进一步根据所述预定好的算法和所述指定标识计算出特定位置,然后再发送第二SNMP请求消息,以请求保存在所述特定位置中的错误原因信息。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNA2008101807648A CN101572621A (zh) | 2008-03-26 | 2008-12-02 | 一种出错原因返回方法和一种实现网络管理的*** |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN200810102807.0 | 2008-03-26 | ||
CN200810102807 | 2008-03-26 | ||
CN200810094730.7 | 2008-05-14 | ||
CNA2008101807648A CN101572621A (zh) | 2008-03-26 | 2008-12-02 | 一种出错原因返回方法和一种实现网络管理的*** |
Publications (1)
Publication Number | Publication Date |
---|---|
CN101572621A true CN101572621A (zh) | 2009-11-04 |
Family
ID=41231859
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNA2008101807648A Pending CN101572621A (zh) | 2008-03-26 | 2008-12-02 | 一种出错原因返回方法和一种实现网络管理的*** |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101572621A (zh) |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103152193A (zh) * | 2011-12-07 | 2013-06-12 | 迈普通信技术股份有限公司 | 简单网络管理协议操作错误信息的获取方法及*** |
CN103501240A (zh) * | 2013-09-16 | 2014-01-08 | 华为技术有限公司 | 一种发现设备的方法、装置及*** |
CN103516530A (zh) * | 2012-06-20 | 2014-01-15 | 中兴通讯股份有限公司 | 一种获取代理端扩展错误信息的方法及装置 |
WO2016101223A1 (en) * | 2014-12-25 | 2016-06-30 | Thomson Licensing | Method and apparatus for snmp set operations |
CN107360037A (zh) * | 2017-08-08 | 2017-11-17 | 京信通信***(中国)有限公司 | 一种错误信息获取方法及网络管理设备 |
WO2021057524A1 (zh) * | 2019-09-27 | 2021-04-01 | 中兴通讯股份有限公司 | 获取snmp操作失败信息的方法、网管设备、网元设备及网管*** |
CN112925779A (zh) * | 2021-03-02 | 2021-06-08 | 重庆度小满优扬科技有限公司 | 一种报文回执修改方法及装置 |
-
2008
- 2008-12-02 CN CNA2008101807648A patent/CN101572621A/zh active Pending
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103152193A (zh) * | 2011-12-07 | 2013-06-12 | 迈普通信技术股份有限公司 | 简单网络管理协议操作错误信息的获取方法及*** |
CN103516530A (zh) * | 2012-06-20 | 2014-01-15 | 中兴通讯股份有限公司 | 一种获取代理端扩展错误信息的方法及装置 |
CN103501240A (zh) * | 2013-09-16 | 2014-01-08 | 华为技术有限公司 | 一种发现设备的方法、装置及*** |
WO2016101223A1 (en) * | 2014-12-25 | 2016-06-30 | Thomson Licensing | Method and apparatus for snmp set operations |
CN107360037A (zh) * | 2017-08-08 | 2017-11-17 | 京信通信***(中国)有限公司 | 一种错误信息获取方法及网络管理设备 |
WO2021057524A1 (zh) * | 2019-09-27 | 2021-04-01 | 中兴通讯股份有限公司 | 获取snmp操作失败信息的方法、网管设备、网元设备及网管*** |
CN112925779A (zh) * | 2021-03-02 | 2021-06-08 | 重庆度小满优扬科技有限公司 | 一种报文回执修改方法及装置 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101572621A (zh) | 一种出错原因返回方法和一种实现网络管理的*** | |
CN104394008B (zh) | 一种统一配置不同类型交换机的方法及其*** | |
CN1992635B (zh) | 模拟snmp网元及用该网元进行网管***测试的方法 | |
CN102932493B (zh) | 记录无状态的ip地址 | |
US7493378B2 (en) | Network management method for providing device list and network management device to provide device list | |
CN102185716B (zh) | 一种通信设备通用管理方法及*** | |
CN106953905A (zh) | 域间目录共享方法及装置 | |
CN101238680A (zh) | 产生唯一且持久的标识符的***和方法 | |
CN101616022A (zh) | 一种基于snmp协议的智能设备管理方法及*** | |
CN101505550A (zh) | 设备管理的方法和终端、装置、*** | |
CN112217656B (zh) | Sd-wan***中的网络设备的配置信息同步方法和装置 | |
US9009306B2 (en) | Method, system, client and server for locating operation nodes in communication system | |
CN101257406B (zh) | 网元发现方法和*** | |
CN100479367C (zh) | 一种基于分布式网络的程序部署方法和*** | |
CN101778486A (zh) | 设备管理服务器、客户端及目标操作对象定位方法 | |
CN102271052A (zh) | 网络***、网络管理装置及网关装置 | |
CN101494551A (zh) | 业务割接的方法、装置及*** | |
CN101848107A (zh) | Snmp网元及snmp网元与私有协议网元通信的方法 | |
CN101360345A (zh) | 一种数据业务的管理方法、装置及*** | |
CN101247272B (zh) | 网络管理方法和装置 | |
CN101076028B (zh) | 采用snmp协议的通信***和消息交互方法 | |
CN102742218B (zh) | 中继服务器及中继通信*** | |
CN113992504A (zh) | 一种基于工业互联网标识解析的网络传输设备管理方法 | |
CN101212346B (zh) | 一种网元管理***的软件版本管理方法及装置 | |
CN109039753B (zh) | 一种基于以太网的通信方法以及通信设备 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C12 | Rejection of a patent application after its publication | ||
RJ01 | Rejection of invention patent application after publication |
Open date: 20091104 |