网管SNMP Agent的快速开发

说明：这篇文章是因为做了一个网关Agent的小项目，作为应对知识积累的差使而写的。相当部分文字是zt来填充版面，有些细节尤其是开发方面的算是语焉不详，只是给了一个大致的框架。但也算是对工作的一点总结。

之所以想起来了，是因为内刊主编突然给我打电话，告诉我头儿把文章推荐给她了，然后她问我这篇文章发表前还是否需要修饰，吓我一跳，郑重告诉她这篇文章其实只是个草稿，还没有完善到能发表的地步--至少我不认为可以发表，因为写的时候就有点应付。

不过其实有点后悔，每千字能有不少稿费呢，这一篇连空格都有5K字了~~~

网管SNMP Agent的快速开发

前言

概述：根据以前的项目经验，介绍一个SNMP网管代理的开发方案。重点是如何利用相关开发包／测试工具，屏蔽大部分低层细节，快速的实现网管代理。

范围：本文不全面讨论网管系统的业务实现，不着重介绍编程细节。重点在介绍Agent在网管系统里的作用和局限，以及使用相关开发包实现Agent时的一些技术难点。

关键字:

u SNMP

u Agent

u MIB

u SMI

u UCD-SNMP

u LIBSMI

一：简单网管概念概述

所谓网管，一般是指对网络系统中的各种设备进行监测、分析与控制，从而保障整个网络系统可靠、有效地运行．网络管理员通过管理者与管理代理之间的交互通信而达到对网络进行管理的目的．

为了保证管理者与管理代理之间能正确地交换管理信息，需对管理信息作出定义和在两者之间达成一致协议．前者即是管理对象，有时简称为对象，管理对象的集合称为管理信息库MIB(Management Information Base)，后者就是网管协议．目前，世界上使用最广泛的网管协议是基于TCP/IP的简单网络管理协议SNMP(Simple Network Management Protocol)，该协议简单、易于实现且具有良好的可扩充性，是工业界事实上的网管协议标准．

SNMP协议现在有３个版本。

SNMPv1有５个基本原语

l get-request

l set-request

l get-next-request

l get-reponse

l trap

SNMPv2增加了两个原语

l get-bulk- request

l inform-request

SNMPv3主要是在安全上进行了加强。

二网管系统软件结构概述

一个典型网管系统软件是由以下部分组成的

1：Manager：

管理员使用的工作站，通过网管软件查看和分析网管数据。

2：Agent

网管代理。网管代理一般分为两个功能模块和一个公用模块MIB库

2.1查询/设置模块

此模块接受来自Manager的查询和设置指令，并根据指令处理相关数据，如将被查询的数据返回给Manager,或使设置的数据对相关Device生效。

对于SNMP Agent，此模块至少需要实现以下协议接口：

l get-request

l set-request

l get-next-request

l get-reponse

2.2告警模块

告警模块将设备产生的告警发送给Manager。对于SNMP Agent.此模块至少需要实现Trap协议接口。

2.3 MIB库

MIB(管理信息库)保存被管理设备的相关管理信息。在SNMP Agent里， MIB通常用文本文件格式保存。

一个MIB描述了包含在数据库中的对象或表项。每一个对象或表项都有以下四个属性：

l 对象类型（Object Type）

l 语法（Syntax）

l 存取（Access）

l 状态（Status）

在SNMP规范之一的管理信息结构与标识（SMI；RFC 1155/1065）规范中定义了这些属性。SMI对于MIB来说就相当于模式对于数据库。

3 Device

被管理设备，可以是一台一个进程，计算机，或者分布式的系统。这些设备负责产生和收集诸如配置，性能和业务数据以及告警,是网管数据的来源，同时负责原始数据的整理和统计。Device和Agent之间的交互协议可以不受SNMP协议限制，可以采用任何一种协议交换数据。

4: Agent设计

可见Agent在网管系统结构的位置相当于管理器和被管设备之间的网关和协议转换器。对Agent的功能需求的范围应该为：

l 协议转换。将SNMP协议和被管设备之间的协议互相转换

l 转发请求。包括向被管设备转发查询，设置请求。向Manager转发设备产生的告警

l 通过MIB库维护被管设备的信息结构

l 对Manager提供一个统一的网管接口，无论被管设备有多复杂，对Manager来说只需要和Agent交互就可以获得所有被管设备的网管信息

l 不需要牵涉诸如轮巡，告警策略等网管业务逻辑。也不参与被管设备本身对网管数据的处理流程。这些由被管设备的网管业务逻辑层自行处理。

l 不需要对数据进行统计分析

l 不需要保存历史或实时网管数据

可见对于网管系统来说，Agent功能明确，结构相对简单，虽然必不可少但并非核心部件，并且SNMP Agent已经是事实上的工业标准，有大量的开发包帮助开发人员快速的实现Agent，可以让开发人员将精力投入到网管业务逻辑上。

三开发工具介绍

3.1 UCD-SNMP

SNMP网管系统的开发包最出名的是开源项目UCD-SNMP(最新版本已经更名为NET-SNMP)。.

UCD-SNMP开发包提供了几乎所有SNMP网管开发所需要的资源

l SNMP API。封装SNMP协议和网络接口细节。提供了方便调用的SNMP操作接口

l MIB管理。提供了所有的典型MIB库。并可以将MIB库映射到进程内部，按MIB所定义的层次结构组织数据

l 扩展Agent的编程框架。屏蔽所有SNMP操作流程和细节，用户只需要接管格式化过的SNMP请求，编写网管业务代码。

l 相关工具，包括snmpget，snmpgetnext，snmpwalk，snmpbulkget，snmpbulkwalk，snmptable，snmpset，snmptrap，snmpinform，snmpdelta，snmptest，snmptranslate，snmpstatus，等等。

3.2 LIBSMI

LIBSMI同样也是开源的开发包，提供针对MIB库的一套功能函数。可以很方便的解析和修改MIB。

关于如何使用UCD-SNMP开发包扩展Agent的资料见附件。这里就项目里出现的一些技术难点逐一介绍：

l Q:为什么要使用LIBSMI？

A:首先介绍一下UCD-SNMP扩展Agent的编程框架：

一般资料介绍UCD-SNMP开发包时，都推荐使用mib2c脚本根据MIB库生成.C文件，此文件定义了一个静态的OID(Object ID,mib库里对每个元数据的索引方式)二维表，当接受到SNMP请求时根据所请求的OID从表里取出回调函数地址并调用。

在.c文件中，主要的元素就是一个这个变量结构指定实现对象的细节，采用类型结构variable2数组的形式，数组的每一行对应MIB树的一个对象，并以OID升序排列。例如，slanBasicSet的变量定义为：

struct variable2 slanBasicSet_variables[] = {

/* magic number , variable type , ro/rw , callback fn , L, oidsuffix */

#define SLANNAME 1

{ SLANNAME , ASN_OCTET_STR , RWRITE, var_slanBasicSet, 1, { 1 } },

#define SLANAGENTTYPE 2

{ SLANAGENTTYPE , ASN_INTEGER , RWRITE, var_slanBasicSet, 1, { 2 } },

#define SLANAGENTSTATUS 3

{ SLANAGENTSTATUS , ASN_INTEGER , RONLY , var_slanBasicSet, 1, { 3 } },

};

这种做法有几个弊端：

首先，实践中发现，mib2c脚本兼容性并不是很好，在不同的环境上可能无法运行。

其次，用mib2c生成的.C文件里包含的是静态表，那么在更新mib库时，就需要重新生成.C文件以更新表结构。这样增加了开发的重复性，而且不利于部署和维护。

最后，生成的静态表里，每个OID默认对应一个不同的回调函数，需要再每个回调函数里都写几乎相同的业务逻辑代码，这是不合理的。一般设计Agent，尤其被管设备并非简单的网络设备而是一个分布式业务系统时，Agent只起网络和协议Adapter请求dispatch的作用，所有的请求进来后，都是根据和设备的内部协议重新打包并分发并取得返回结果，发送给manager.这样所有的OID只需要对应同一个函数就可以了。

取代的方案是每次启动AGENT的时候，根据MIB库生成动态OID表，在生成

表的时候，按具体需求定义表数据，主要是回调函数。

这时就需要用到LIBSMI(或其他MIB解析库，经实践，发现LIBSMI是最简单易用的)了。

l Q: SNMP Agent的网络端口能否修改

A:SNMP Agent需要用到两个网络端口：查询/设置端口，默认是161。TRAP(告警)端口162。其中TRAP端口是由Manager决定的，Agent作为客户端向Manager的IP地址和端口发送TRAP。如修改成和Manager不符的端口将导致Manager收不到告警。

查询/设置端口是由Agent监听的。可以由Agent自行修改，但建议保持默认的161端口，因为这是工业标准的默认约定。如需修改此端口，必须告知Mananger端进行同步。

这两个端口上的数据协议都是无连接的UDP,如果网络结构比较复杂，必须考虑UDP包是否会被防火墙或网关丢弃。

l Q: 使用UCD-SNMP的框架扩展Agent,其进程模式是怎样的。

A: 默认是单进程。这样在回调函数里不需要考虑太多的进程内同步问题。但是必须意识到单进程处理请求是串行的，每个请求必须快速被处理，否则可能产生严重的效率问题，或在Manager 端频繁出现超时现象。一般来说，虽然网管系统的压力并不会非常大，但在告警频繁或轮巡性能参数等业务时，必须考虑效率问题。

l Q:在扩展Agent中，除了自定义MIB信息之外，是否可以使用系统原来的MIB信息？

A:可以。UCD-SNMP自带了标准定义的所有通用MIB库，只需要在初始化Agent的时候调用init_mib_all而不是只初始化自定义Agent就可以了。这样基本上所有的通用网管数据（如系统信息，网络信息等）都不需要自行开发，由UCD-SNMP实现了。大大的减少了工作量。

l Q:Agent能否在没有安装UCD-SNMP的环境上运行

A:必须有必要的UCD-SNMP动态库

l Q:Agent和被管设备之间的协议应该如何实现？必须用udp吗？

A:这不是UCD-SNMP开发包所关心的问题，它关心的是Manager和Agent之间的通信。内部协议可以根据具体的业务需求，实现技术决定。推荐使用XML/FML等容易扩展的应用协议。在网络层，SNMP协议采用udp的考虑是：网管系统的潜在价值是在网络出现故障时依旧能最大数据的获得网管信息，这样在TCP虚拟链路无法维持时，面向无连接的udp数据报依旧可以自动选择路由传输。而在内部尤其是网络结构简单，质量良好的情况下，可以随意选择tcp/udp等协议进行开发

Q: Agent如何保证安全性？

SNMP协议本身是一种弱安全性协议，协议包不做加密（SNMPv1/v2,V3加入了SSL控制），容易被截取分析。仅仅通过包含在SNMP中的团体名提供简单的认证，其作用类似口令，SNMP代理检查消息中的团体名字段的值，符合预定值时接收和处理该消息。依据SNMPv1协议规定，大多数网络产品出厂时设定的只读操作的团体名缺省值为“Public”，读写操作的团体名缺省值为“Private”，许多情况下，网络管理人员从未修改过该值。

SNMP Agent是很容易被攻击的。由于SNMP主要采用UDP传输，很容易进行IP源地址假冒，所以，仅仅使用访问控制列表有时也不足以防范。大多数SNMP设备接收来自网络广播地址的SNMP消息，攻击者甚至可以不必知道目标设备的IP地址，通过发送广播SNMP数据包达到目的。此外ucd-snmp工具中存在几个缓冲溢出，格式化字符串漏洞，临时文件环境竞争条件漏洞，其中一些可以获得远程溢出并以SNMPD的UID来执行任意命令。防范措施是对软件打上最新的Patch,加强网络监控。

四测试工具介绍

在Agent开发结束后，可以使用ucd-snmp提供的工具如snmpget,snmpwalk等访问Agent查看请求是否被正确处理。

推荐使用Mg-MibBrowser或AdvanceNet提供的MIB管理端工具访问Agent和接收告警。不同的工具在一些细节如文本编码类型上少有不同，可以更好的检验Agent的兼容性。

五结束语

在网管业务的开发中，SNMP一直都是标准之一，除此之外，还有其他如

· TMN

· TINA

· TL1

· DMTF

· XML

· Radius

等一系列网管标准和相关技术。