CN101192984A

CN101192984A - 一种基于简单网络管理协议的Trap确认方法

Info

Publication number: CN101192984A
Application number: CNA2006101607375A
Authority: CN
Inventors: 苏春山
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2006-11-29
Filing date: 2006-11-29
Publication date: 2008-06-04
Anticipated expiration: 2026-11-29
Also published as: CN100561944C

Abstract

本发明公开了一种基于SNMP的Trap确认方法，包括以下步骤：(a)SNMP代理在Trap消息的Trap团体名中加入是否需要确认Trap的关键字，用标准的SNMP Trap发送流程发送Trap消息给SNMP管理者；(b)所述SNMP管理者收到Trap消息后，检查Trap团体名字符串中是否包含需要确认Trap的关键字，如果是，则设置所述SNMP代理上的管理信息库变量值；(c)所述SNMP代理检测其上管理信息库变量的设置无误，认为所述SNMP管理者已确认收到该Trap消息，Trap发送流程结束。本方法节省了网管系统提高告警可靠性的成本，大大提高了Trap消息接收的可靠性。

Description

一种基于简单网络管理协议的Trap确认方法

技术领域

本发明涉及一种在SNMP v1/v2c管理框架中实现Trap确认的方法，尤其涉及以SNMP为管理接口的各种设备的告警、消息管理领域。

背景技术

SNMP(简单网络管理协议)是网络管理中基于UDP报文的一种管理协议，用于SNMP Manager(以下简称管理者)和SNMP Agent(以下简称代理)之间进行通讯、管理操作。在SNMP v1和v2c的版本中，代理主动发给管理者的消息称为Trap(陷阱)。

Trap一个显著特点是代理发送Trap时是不需要管理者返回确认消息的。加之SNMP又是基于UDP(用户数据报协议)，是无连接的，因此管理者比较容易丢掉Trap，使得Trap传递消息的可靠性大大降低。

在由管理者和代理组成的网管系统中，Trap的这个缺点成为了网管系统的薄弱环节，降低了网管系统故障管理功能的可用性和可靠性。

发明内容

本发明所要解决的技术问题是提供一种基于简单网络管理协议的Trap确认机制，解决在SNMPv1/v2c管理框架中Trap消息没有确认机制而导致的消息传递可靠性差的问题。

为了解决上述技术问题，本发明提供了一种基于简单网络管理协议的Trap确认方法，所述简单网络管理协议以下简称SNMP，包括以下步骤：

(a)SNMP代理在Trap消息的Trap团体名中加入是否需要确认Trap的关键字，用标准的SNMP Trap发送流程发送Trap消息给SNMP管理者；

(b)所述SNMP管理者收到Trap消息后，检查Trap团体名字符串中是否包含需要确认Trap的关键字，如果是，则设置所述SNMP代理上的管理信息库变量值；

(c)所述SNMP代理检测其上管理信息库变量的设置无误，则认为所述SNMP管理者已确认收到该Trap消息，Trap发送流程结束。

进一步地，上述方法还可具有以下特点：在所述步骤(a)前，所述SNMP代理判断该Trap消息是否需要确认，如果是，执行步骤(a)，否则，进行普通的Trap发送流程。

进一步地，上述方法还可具有以下特点：在所述步骤(a)中，所述Trap团体名中还包括Trap消息的消息号，在所述步骤(b)中，所述SNMP管理者将所述管理信息库变量值设为该Trap消息的消息号。

进一步地，上述方法还可具有以下特点：在所述步骤(a)中，所述SNMP代理构造的新的团体名字符串格式如下：实际的community+“@eventId＝”+eventId+“@confirm”，其中，“@eventId＝”用于标识Trap消息号属性的关键字，即通过该字符串标识“@eventId＝”后面跟的是Trap消息号，其后的“eventId”即为Trap消息号，“@confirm”是Trap是否需要确认的关键字；在所述步骤(b)中，所述SNMP管理者检查Trap团体名字符串中是否包含关键字“@confirm”。

进一步地，上述方法还可具有以下特点：所述SNMP代理上的管理信息库变量值为confirmedEventId。

进一步地，上述方法还可具有以下特点：在所述步骤(b)中，所述SNMP管理者收到Trap后，若需要对该Trap消息进行确认，则从Trap团体名字符串中提取eventId值即Trap消息号，向所述SNMP代理发送SNMP设置消息，将confirmedEventId值设置为Trap消息号；在所述步骤(c)中，所述SNMP代理检测其上管理信息库变量的设置无误是指，所述SNMP代理判断该confirmedEventId值与其发出过的Trap消息号是否相匹配，如果是，则认为该Trap消息已被确认收到，否则返回SNMP设置失败消息。

进一步地，上述方法还可具有以下特点：在所述步骤(c)中，如果所述SNMP代理在规定时间内没有收到所述SNMP管理者的确认消息，则重发该Trap消息，若重发的次数达到规定的次数后，所述SNMP代理结束此次Trap发送流程。

进一步地，上述方法还可具有以下特点：所述方法适用于SNMP v1/v2c。

采用本发明所述方法，与现有技术相比，弥补了SNMPv1/v2c管理框架中Trap可靠性方面的不足，达到了Trap消息可以根据需要进行确认的效果，节省了网管系统提高告警可靠性的成本，大大提高了Trap消息接收的可靠性。

附图说明

图1是SNMPv1/v2c管理者和代理间的消息；

图2是本实施例的Trap确认机制顺序图。

具体实施方式

本实施例的核心方法是：通过在Trap携带的团体名(community)中加入是否需要确认Trap的关键字，管理者收到Trap后，通过检查团体名(community)字符串中的关键字决定是否对Trap进行确认。确认的方法是管理者通过设置代理上的某个特定变量从而通知代理已经收到该Trap。

下面对技术方案的具体实施作进一步的详细描述：

1)代理修改现有Trap团体名(community)的构造方法

在驻留SNMPv1/v2c代理的网元上需要修改Trap团体名的构造方法，使团体名成为复合的团体名，包含是否需要进行Trap确认的关键字。比如，新的团体名可以是：

实际的community+′@eventId＝′+eventId+′@confirm′

这里：“@eventId＝”是用于标识Trap消息号属性的关键字，即通过该字符串标识“@eventId＝”后面跟的是Trap消息号，可以用于管理者确认消息时使用，其后的“eventId”即为Trap消息号；

“@confirm”则是Trap是否需要确认的关键字，如果Trap无需管理者确认，则可以不带该关键字。

复合团体名的实例如：public@eventId＝1022@confirm。

2)代理增加对Trap确认的MIB(管理信息库)变量

为了使管理者收到Trap后能够通知代理“我已经收到Trap了”，需要在代理中增加一个可以设置的MIB变量，比如，confirmedEventId，用于标识已经确认的事件ID。管理者向代理发出对此变量的SNMP Set消息，通过代理对该变量进行设置，代理将管理者设置的confirmedEventId值与之前产生的Trap消息号进行比较，如果发现能够找到匹配的，则认为是对相应trap的确认，即该事件ID对应的Trap已经被管理者收到，并进行了确认，否则返回标准的SNMP设置失败消息。

3)管理者增加对Trap团体名关键字的检查

管理者在收到Trap的处理流程中需要增加对Trap团体名关键字的检查，以判断是否需要对Trap进行确认。

判断的方法就是检查团体名中是否有关键字′@confirm′，如果不包含该字符串，则说明该Trap不需要进行确认，则按不需要确认的普通Trap处理即可，否则，则需要再从团体名中提取到eventId，并把代理上的confirmedEventId量设置成为团体名字符串中eventId的值。这样代理就知道管理者已经收到并确认了该Trap，从而可以结束该Trap的发送流程。

4)管理者、代理对于不需要确认Trap的处理

对于不需要确认的Trap，则代理发送Trap时无需构造复合的团体名。同样，管理者检查到Trap不需要进行确认时，则不需要再向代理发任何消息，该处理流程与普通的Trap处理是完全一样的。

5)如果管理者不具备确认Trap的确认处理

如果管理者不具备确认Trap的确认处理，则代理就不会收到Trap确认的消息。因此，建议代理在等待管理者确认Trap时，可以采用超时和重试机制。即当在规定时间没有收到管理者的确认操作后，代理再重发一次继续等待确认，直到重发的次数达到规定的次数后，代理结束Trap发送过程。

本实施例所述Trap确认方法如下(参看图1和图2)：

步骤110，SNMP代理判断该Trap消息是否需要进行确认，如果是，执行下一步，否则，按普通Trap流程处理；

步骤120，SNMP代理在发送Trap前在Trap团体名中加入是否需要确认Trap的关键字；

步骤130，SNMP代理采用标准的SNMP Trap发送流程发送Trap给SNMP管理者；

步骤140，SNMP管理者采用标准的SNMP Trap接收流程接收Trap，SNMP管理者检查Trap的团体名字符串中是否包含需要确认Trap的关键字，如果是，执行下一步，否则，按普通Trap流程处理；

步骤1 50，SNMP管理者设置SNMP代理上的管理信息库变量，从而通知SNMP代理已经收到该Trap；

步骤160，SNMP代理检测该管理信息库变量的设置无误，则认为该Trap被确认，该带确认的Trap发送流程结束。

本实施例通过巧妙的使用了Trap报文中的团体名(community)域信息，配合简单的SNMP命令，很容易的建立起了Trap的确认机制，弥补了SNMPv1/v2c管理框架中Trap可靠性方面的不足。

通过以上对管理者、代理相应的改造，即实现了基于SNMPv1/v2c管理框架的Trap确认机制，从而使Trap消息的可靠性得到有效提高。

Claims

1.一种基于简单网络管理协议的Trap确认方法，所述简单网络管理协议以下简称SNMP，包括以下步骤：

2.如权利要求1所述的方法，其特征在于，在所述步骤(a)前，所述SNMP代理判断该Trap消息是否需要确认，如果是，执行步骤(a)，否则，进行普通的Trap发送流程。

3.如权利要求1或2所述的方法，其特征在于，在所述步骤(a)中，所述Trap团体名中还包括Trap消息的消息号，在所述步骤(b)中，所述SNMP管理者将所述管理信息库变量值设为该Trap消息的消息号。

4.如权利要求3所述的方法，其特征在于，在所述步骤(a)中，所述SNMP代理构造的新的团体名字符串格式如下：

实际的community+“@eventId＝”+eventId+“@confirm”

其中，“@eventId＝”用于标识Trap消息号属性的关键字，即通过该字符串标识“@eventId＝”后面跟的是Trap消息号，其后的“eventId”即为Trap消息号，“@confirm”是Trap是否需要确认的关键字；

在所述步骤(b)中，所述SNMP管理者检查Trap团体名字符串中是否包含关键字“@confirm”。

5.如权利要求4所述的方法，其特征在于，所述SNMP代理上的管理信息库变量值为confirmedEventId。

6.如权利要求5所述的方法，其特征在于，在所述步骤(b)中，所述SNMP管理者收到Trap后，若需要对该Trap消息进行确认，则从Trap团体名字符串中提取eventId值即Trap消息号，向所述SNMP代理发送SNMP设置消息，将confirmedEventId值设置为Trap消息号；在所述步骤(c)中，所述SNMP代理检测其上管理信息库变量的设置无误是指，所述SNMP代理判断该confirmedEventId值与其发出过的Trap消息号是否相匹配，如果是，则认为该Trap消息已被确认收到，否则返回SNMP设置失败消息。

7.如权利要求1所述的方法，其特征在于，在所述步骤(c)中，如果所述SNMP代理在规定时间内没有收到所述SNMP管理者的确认消息，则重发该Trap消息，若重发的次数达到规定的次数后，所述SNMP代理结束此次Trap发送流程。

8.如权利要求1所述的方法，其特征在于，所述方法适用于SNMPv1/v2c。