CN101267335A - 一种保证简单网络管理协议告警成功收发的方法 - Google Patents

Abstract

本发明提供了一种保证SNMP告警成功收发的方法：网络设备在SNMP的Trap报文中加入标识告警的“要求确认”字符串和ID号；发送Trap报文到管理服务器，并存储Trap报文的内容和ID号；管理服务器收到Trap报文后对其进行检查，如果含有“要求确认”字符串，则解析出Trap报文的ID号，并根据ID号设置网络设备的相应的OID做确认；网络设备收到OID中的ID号后便查找Trap报文，如找到，便删除并返回管理服务器设置结果；如未找到，则直接返回管理服务器设置结果。本发明在现有技术的SNMP中增加了Trap报文ID号的信息，从而使得实际运用更加安全稳妥，具有改动成本低、可靠性高等方面的优势。

Description

一种保证简单网络管理协议告警成功收发的方法

技术领域

本发明涉及网络设备管理技术领域，特别是涉及一种保证简单网络管理协议(Simple Network Management Protocol，以下简称SNMP)告警成功收发的方法。

背景技术

网络管理是一个解决方案，它力求提高网络设备的利用率、性能、服务质量及安全性。随着计算机网络技术的发展，计算机网络的规模和应用范围急剧扩大，网络所承担的任务愈来愈繁重，因此出现了一系列专门的网络管理协议。

国际电信联盟的电信标准化部门ITU-T(原电报电话咨询委员会CCITT)提出了专门针对电信网络管理的电信管理网(TelecommunicationManagement Network，以下简称TMN)；国际标准化组织(InternationalStandards Organization，以下简称ISO)也为网络管理制订了公共管理信息协议(common management information protocol，以下简称CMIP)；而国际上的Internet组织则为网络管理制订了SNMP。这些管理标准的各自出发点不同：TMN是针对电信网管理而设计的；CMIP是为开放系统互连(OpenSystem Interconnection，以下简称OSI)的7层开放互连模型而设计的；而SNMP则是基于TCP/IP网的网络管理协议，它从早期的简单网关监控协议(Simple Gateway Monitoring Protocol，以下简称SGMP)发展而来。这些标准中，CMIP的功能最强大，但其实现难度也最大，这就妨碍了它的应用，因此目前支持CMIP的产品很少；而SNMP则由于它的简单和易操作，因此得到广泛的应用，并已成为事实上的标准。

SNMP的体系结构如图1所示。SNMP的体系结构主要由管理进程12(Manager)、管理代理13(Agent)、受管对象15(Managed Object)以及描述受管对象状态的管理信息库14(Management Information Base，以下简称MIB)组成。Manager12是整个网管系统的控制中心，它通过各管理代理对网络内的各种设备、设施和资源进行监测和控制，并完成各种管理功能。此外，Manager12通常配有人机界面，并对收集到的受管对象的信息和数据进行存档、分析和处理。Manager12运行在管理服务器上，而Agent13运行在网络设备上。

Manager12和Agent13之间通过SNMP进行通信的。SNMP定义了4类管理操作：获得(Get)操作；获得下一个(Get Next)操作；设置(Set)操作；陷阱(Trap)操作。Manager12利用Get和Get Next操作来提取各MIB14的信息，进而获得网络当前的综合状态信息。在必要时，Manager12可以通过Set操作间接设置或修改MIB14中的某些信息，以达到控制的目的。每当网络发生严重的异常事件时，Agent13就通过Trap操作主动向Manager12报告事件，从而大大改善了网络管理的时效性能。

SNMP是一种应用程序协议，封装在用户数据报协议(User datagramprotocol，以下简称UDP)中。各种版本的SNMP报文信息通用格式如图2所示，包括SNMP版本号(Version)21：管理器和代理器必须使用相同版本的SNMP；团体名称(Community)22：用于在访问代理器之前认证管理器；协议数据单元(Protocol Data Unit，简称PDU)23：包含具体的报文内容。

UDP是一个简单的面向数据报的运输层协议。UDP不提供可靠性，它只是把应用程序传给IP层的数据报发送出去，但是并不能保证它们能到达目的地。由于UDP在传输数据报前不用在客户和服务器之间建立一个连接，且没有超时重发等机制，故而传输速度很快。正因为SNMP是封装在UDP中，所以无法确认管理服务器是否收到网络设备的告警Trap信息，而当管理服务器和网络设备之间的网络通讯发生故障时，网络设备也不会得到“告警发送失败”的返回。在实际网络管理中，重要告警信息的丢失会给系统运行的稳定性和可维护性带来严重的负面影响。因此有必要对SNMP Trap报文的机制进行改进。

发明内容

本发明的目的在于提供一种SNMP Trap报文的收发机制，使得在网络通讯不畅的情况下，也能最终将设备告警信息发送到管理服务器的方法。

鉴于上述目的，本发明提供了一种保证SNMP告警成功收发的方法，包括以下步骤：

步骤1，网络设备在SNMP的Trap报文中加入标识告警的“要求确认”字符串和标识(ID)号；

步骤2，发送上述Trap报文到管理服务器，并在网络设备上存储上述Trap报文的内容和ID号；

步骤3，管理服务器收到上述Trap报文后对其进行检查，如果含有“要求确认”字符串，则解析出该Trap报文的ID号，并根据上述ID号设置网络设备的相应的对象标识(Object Identity，以下简称OID)做确认；

步骤4，网络设备收到上述OID中的ID号后便查找该Trap报文，如果找到，便将其删除后返回管理服务器设置结果；如果未找到，则直接返回管理服务器设置结果；

步骤5，如果网络设备和管理服务器的网络通讯发生中断，则网络设备无法收到管理服务器的确认，相关的Trap报文也将保留在网络设备内；当网络设备和管理服务器的网络通讯恢复正常时，管理服务器将网络设备的相应OID设置为0，以此通知网络设备将当前存储的所有Trap报文进行重发，网络设备收到标识号为0的设置指令后查找其存储的Trap报文，将查找到的Trap报文逐条重发给管理服务器，并重复步骤3和步骤4，直至所有陷阱报文都成功重发。

上述“要求确认”字符串位于陷阱报文的community字段中，标识号位于community字段的尾部。上述ID号可以是累加的非零ID号或其他合适的ID号。上述OID可以通过SNMP的设置(Set)指令设置，将ID号作为OID的配置值。网络设备上配置有团体名称为“要求确认”的管理服务器IP。所述步骤1中，如果上述网络设备上存储的Trap报文已达到极限，则由最新产生的一条Trap报文覆盖最旧的一条Trap报文。如果上述网络设备采用链表结构存储上述Trap报文，则将发送出去的Trap报文加入该链表的尾部，如果链表长度达到存储空间的上限，则删除链表头部的Trap报文。所述步骤4中，如果网络设备找到并删除Trap报文后返回管理服务器设置成功确认结果，如果未找到则返回服务器设置未找到相关记录结果。所述步骤5中，如果所有Trap报文都已经重发，则返回管理服务器设置成功重发结果。

本发明所提供的一种确保SNMP Trap报文成功收发的方法，在现有技术的SNMP中仅增加了Trap报文ID号的信息，从而使得实际运用更加安全稳妥，具有改动成本低、可靠性高等方面的优势。

附图说明

图1是公知的SNMP的体系结构。

图2是SNMP报文信息的通用格式。

图3是本发明一较佳实施例的Trap报文发送和存储的流程图。

图4是本发明一较佳实施例的Trap报文确认的流程图。

图5是本发明一较佳实施例的Trap报文重发的流程图。

具体实施方式

下面结合附图和具体实施例对本发明作进一步地介绍，但不作为对本发明的限定。

本发明一较佳实施例的在网络设备侧的Trap报文发送和存储方式由图3所示。

步骤31，网络设备在Trap报文中加入“要求确认”字符串用以告警，该字段可以加入到报文的“community”字段22中，并加入该Trap报文的ID号，该ID号为一个非0的累加的ID号，其可以添加到“community”字段22的尾部或其他合适的位置。

步骤32，向管理服务器发送包括ID号的整条Trap报文。

步骤33，同时，再将包括ID号的整条Trap报文复制下来。

步骤34，判断网络设备上存储的Trap报文是否已满，Trap报文的存储方式可以是链表结构或其他合适的结构，这种由链表结构产生的Trap记录链表可以在网络设备启动时产生，则判断Trap报文是否已满即为判断Trap记录链表的长度是否达到存储容量的极限，如果是，转到步骤35，如果否，转到步骤36。

步骤35，删除最旧的一条Trap记录，即删除Trap记录链表中的第一条记录，然后转到步骤36。

步骤36，将整条Trap报文存储在网络设备中，即该整条Trap报文可以作为一个新元素插入Trap记录链表的尾部。

本发明一较佳实施例的Trap报文确认的过程如图4所示。

步骤41，管理服务器侧，相应的管理服务器收到网络设备发来的Trap报文。

步骤42，管理服务器查找Trap报文中的community字段是否带有“要求确认”字符串，如果是，转入步骤43。

步骤43，管理服务器将Trap报文中的ID号作为配置值，通过设置(Set)指令设置回网络设备相应的OID，以此通知网络设备确认已经收到该条Trap报文。

步骤44，在网络设备侧，网络设备收到管理服务器设置指令。

步骤45，网络设备根据设置指令中的报文ID号后查找相应的存储的Trap报文，可以遍历Trap记录链表以查找该Trap报文。

步骤46，网络设备判断是否已查找所存储的所有的Trap报文，可以通过确定是否到达Trap记录链表尾来判断，如果是，则向管理服务器返回未找到相关Trap报文记录的结果，如果否，进行步骤47。

步骤47，网络设备判断设置指令中的报文ID号与存储的Trap报文的ID号是否匹配，如果是，进行步骤48，如果否，转到步骤45。

步骤48，删除网络设备中存储的该条Trap报文，即Trap记录链表中的该条Trap报文，并向管理服务器返回成功确认的结果。

如果网络设备和管理服务器的网络通讯发生中断，则网络设备无法收到管理服务器的确认，相关的Trap报文也将保留在网络设备内，而网络设备和管理服务器的网络通讯恢复正常时，便需要重发Trap报文。本发明一较佳实施例的Trap报文重发的过程由图5所示。

步骤51，网络连接恢复后，管理服务器将网络设备相应的OID设置为0，并将报文的ID号为0的设置(Set)指令发送给网络设备，以此通知网络设备将当前存储的所有Trap报文进行重发。

步骤52，网络设备收到报文ID号为0的设置(Set)指令。

步骤53，网络设备查找所有的Trap报文，如果是采用Trap记录链表存储，则遍历该Trap记录链表。

步骤54，查找到某一条Trap报文后，将记录该条整条Trap报文直接作为Trap报文重新发送给管理服务器，管理服务器进行Trap报文确认，确认过程如图4所示。

步骤55，网络设备判断是否达到该Trap记录链表尾，如果是，则向理服务器返回成功重发的结果，如果否，则转到步骤53。

以上所述仅为本发明的较佳实施例，并非用来限定本发明的实施范围；如果不脱离本发明的精神和范围，对本发明进行修改或者等同替换的，均应涵盖在本发明的权利要求的保护范围当中。

Claims (9)

1. 一种保证简单网络管理协议告警成功收发的方法，其特征在于包括以下步骤：

步骤1，网络设备在简单网络管理协议的陷阱报文中加入标识告警的“要求确认”字符串和标识号；

步骤2，发送上述陷阱报文到管理服务器，并在网络设备上存储上述陷阱报文的内容和标识号；

步骤3，管理服务器收到上述陷阱报文后对其进行检查，如果含有“要求确认”字符串，则解析出该陷阱报文的标识号，并根据上述标识号设置网络设备的相应的对象标识；

步骤4，网络设备收到上述OID中的ID号后便查找该陷阱报文，如果找到，便将其删除后返回管理服务器设置结果；如果未找到，则直接返回管理服务器设置结果；

步骤5，如果网络设备和管理服务器的网络通讯发生中断，则网络设备无法收到管理服务器的确认，相关的陷阱报文也将保留在网络设备内；当网络设备和管理服务器的网络通讯恢复正常时，管理服务器将网络设备的相应对象标识设置为0并发送回网络，以此通知网络设备将当前存储的所有陷阱报文进行重发，网络设备收到标识号为0的设置指令后查找其存储的陷阱报文，将查找到的陷阱报文逐条重发给管理服务器，并重复步骤3和步骤4，直至所有陷阱报文都成功重发。

2. 根据权利要求1所述的方法，其特征在于上述“要求确认”字符串位于陷阱报文的团体名称字段中，标识号位于团体名称字段的尾部。

3. 根据权利要求2所述的方法，其特征在于上述ID号是累加的非零ID号。

4. 根据权利要求3所述的方法，其特征在于通过简单网络管理协议的设置指令设置上述对象标识，将标识号作为对象标识的配置值。

5. 根据权利要求4所述的方法，其特征在于网络设备上配置有团体名称为“要求确认”的管理服务器网际协议。

6. 根据权利要求5所述的方法，其特征在于所述步骤1中，如果上述网络设备上存储的陷阱报文已达到极限，则由最新产生的一条陷阱报文覆盖最旧的一条陷阱报文。

7. 根据权利要求6所述的方法，其特征在于上述网络设备采用链表结构存储上述陷阱报文，将发送出去的陷阱报文加入该链表的尾部，如果链表长度达到存储空间的上限，则删除链表头部的陷阱报文。

8. 根据权利要求7所述的方法，其特征在于所述步骤4中，如果网络设备找到并删除陷阱报文，则返回管理服务器设置成功确认结果，如果未找到则返回服务器设置为找到相关记录结果。

9. 根据权利要求1所述的方法，其特征在于所述步骤5中，如果所有陷阱报文都已经重发，则向管理服务器返回成功重发的结果。

Images