分类： 系统运维
2007-04-06 16:23:28
SNMP包括三部分 (tcp/ip协议详解卷1第25章有提到)
MIB 管理信息库
SMI 管理信息结构
代理机和管理机之间的协议
协议事实上是支持所有协议的
目前常用TCP/IP
使用 UDP/161 UDP/162 端口 tcp/199 也是一块 大多不用
经过十多年 如果已发展到了v3版本 (v1 v2c v3)
v1 主要实现了5个命令
get-request
get-next-request
set-request
get-response
trap
v1 是明文认证
见 RFC1213
v2 增加了两个命令
大块数据的get-bulk-request和代理机之间通信 inform-request
两个新的MIB SNMPv2-M2M MIB 和 SNMPV2 MIB
也支持加密
snmp 通过 oid (objectid) 标识
.1.3.6.1.2.1 即是 iso.org.dod.internet.mgmt.mib
下分 system interfaces at ip icmp tcp udp …
.1.3.6.1.4.1. 是enterprise的mib库
比如ibm家是2 cisco家是9 squid家的是3495
linux 下常用的是 net-snmp 软件包 (以前的 ucd-snmp)
net-snmp-utils 提供一下相关工具 snmpwalk 等
比如 snmpwalk -v 2c localhost -c public system | snmpwalk -v 2c localhost -c public .1.3.6.1.2.1.1
perl 也有 Net::SNMP 等相应module
所谓网管，一般是指对网络系统中的各种设备进行监测、分析与控制，从而保障整个网络系统可靠、有效地运行．网络管理员通过管理者与管理代理之间的交互通信而达到对网络进行管理的目的．
为了保证管理者与管理代理之间能正确地交换管理信息，需对管理信息作出定义和在两者之间达成一致协议．前者即是管理对象，有时简称为对象，管理对象的集合称为管理信息库MIB(Management Information Base)，后者就是网管协议．目前，世界上使用最广泛的网管协议是基于TCP/IP的简单网络管理协议SNMP(Simple Network Management Protocol)，该协议简单、易于实现且具有良好的可扩充性，是工业界事实上的网管协议标准．
SNMP协议现在有３个版本。
SNMPv1有５个基本原语
u get-request
u set-request
u get-next-request
u get-reponse
u trap
SNMPv2增加了两个原语
u get-bulk- request
u inform-request
SNMPv3主要是在安全上进行了加强。
一个典型网管系统软件是由以下部分组成的
管理员使用的工作站，通过网管软件查看和分析网管数据。
网管代理。网管代理一般分为两个功能模块和一个公用模块MIB库
2.1查询/设置模块
此模块接受来自Manager的查询和设置指令，并根据指令处理相关数据，如将被查询的数据返回给Manager,或使设置的数据对相关Device生效。
对于SNMP Agent，此模块至少需要实现以下协议接口：
u get-request
u set-request
u get-next-request
u get-reponse
2.2告警模块
告警模块将设备产生的告警发送给Manager。对于SNMP Agent.此模块至少需要实现Trap协议接口。
2.3 MIB库
MIB(管理信息库)保存被管理设备的相关管理信息。在SNMP Agent里， MIB通常用文本文件格式保存。
一个MIB描述了包含在数据库中的对象或表项。每一个对象或表项都有以下四个属性：
u 对象类型（Object Type）
u 语法（Syntax）
u 存取（Access）
u 状态（Status）
在SNMP规范之一的管理信息结构与标识（SMI；RFC 1155/1065）规范中定义了这些属性。SMI对于MIB来说就相当于模式对于数据库。
被管理设备，可以是一台一个进程，计算机，或者分布式的系统。这些设备负责产生和收集诸如配置，性能和业务数据以及告警,是网管数据的来源，同时负责原始数据的整理和统计。Device和Agent之间的交互协议可以不受SNMP协议限制，可以采用任何一种协议交换数据。
可见Agent在网管系统结构的位置相当于管理器和被管设备之间的网关和协议转换器。对Agent的功能需求的范围应该为：
u 协议转换。将SNMP协议和被管设备之间的协议互相转换
u 转发请求。包括向被管设备转发查询，设置请求。向Manager转发设备产生的告警
u 通过MIB库维护被管设备的信息结构
u 对Manager提供一个统一的网管接口，无论被管设备有多复杂，对Manager来说只需要和Agent交互就可以获得所有被管设备的网管信息
u 不需要牵涉诸如轮巡，告警策略等网管业务逻辑。也不参与被管设备本身对网管数据的处理流程。这些由被管设备的网管业务逻辑层自行处理。
u 不需要对数据进行统计分析
u 不需要保存历史或实时网管数据
可见对于网管系统来说，Agent功能明确，结构相对简单，虽然必不可少但并非核心部件，并且SNMP Agent已经是事实上的工业标准，有大量的开发包帮助开发人员快速的实现Agent，可以让开发人员将精力投入到网管业务逻辑上。
SNMP网管系统的开发包最出名的是开源项目UCD-SNMP(最新版本已经更名为NET-SNMP)。.
UCD-SNMP开发包提供了几乎所有SNMP网管开发所需要的资源
u SNMP API。封装SNMP协议和网络接口细节。提供了方便调用的SNMP操作接口
u MIB管理。提供了所有的典型MIB库。并可以将MIB库映射到进程内部，按MIB所定义的层次结构组织数据
u 扩展Agent的编程框架。屏蔽所有SNMP操作流程和细节，用户只需要接管格式化过的SNMP请求，编写网管业务代码。
u 相关工具，包括snmpget，snmpgetnext，snmpwalk，snmpbulkget，snmpbulkwalk，snmptable，snmpset，snmptrap，snmpinform，snmpdelta，snmptest，snmptranslate，snmpstatus，等等。
LIBSMI同样也是开源的开发包，提供针对MIB库的一套功能函数 。可以很方便的解析和修改MIB。
关于如何使用UCD-SNMP开发包扩展Agent的资料见附件。这里就项目里出现的一些技术难点逐一介绍：
1. Q:为什么要使用LIBSMI？
A:首先介绍一下UCD-SNMP扩展Agent的编程框架：
一般资料介绍UCD-SNMP开发包时，都推荐使用mib2c脚本根据MIB库生成.C文件，此文件定义了一个静态的OID(Object ID,mib库里对每个元数据的索引方式)二维表，当接受到SNMP请求时根据所请求的OID从表里取出回调函数地址并调用。
这种做法有几个弊端：
首先，实践中发现，mib
其次，用mib
最后，生成的静态表里，每个OID默认对应一个不同的回调函数，需要再每个回调函数里都写几乎相同的业务逻辑代码，这是不合理的。一般设计Agent，尤其被管设备并非简单的网络设备而是一个分布式业务系统时，Agent只起网络和协议Adapter请求dispatch的作用，所有的请求进来后，都是根据和设备的内部协议重新打包并分发并取得返回结果，发送给manager.这样所有的OID只需要对应同一个函数就可以了。
取代的方案是每次启动AGENT的时候，根据MIB库生成动态OID表，在生成表的时候，按具体需求定义表数据，主要是回调函数。
这时就需要用到LIBSMI(或其他MIB解析库，经实践，发现LIBSMI是最简单易用的)了。
2. Q: SNMP Agent的网络端口能否修改
A:SNMP Agent需要用到两个网络端口：查询/设置端口，默认是161。TRAP(告警)端口162。其中TRAP端口是由Manager决定的，Agent作为客户端向Manager的IP地址和端口发送TRAP。如修改成和Manager不符的端口将导致Manager收不到告警。
查询/设置端口是由Agent监听的。可以由Agent自行修改，但建议保持默认的161端口，因为这是工业标准的默认约定。如需修改此端口，必须告知Mananger端进行同步。
这两个端口上的数据协议都是无连接的UDP,如果网络结构比较复杂，必须考虑UDP包是否会被防火墙或网关丢弃。
3. Q: 使用UCD-SNMP的框架扩展Agent,其进程模式是怎样的。
A: 默认是单进程。这样在回调函数里不需要考虑太多的进程内同步问题。但是必须意识到单进程处理请求是串行的，每个请求必须快速被处理，否则可能产生严重的效率问题，或在Manager 端频繁出现超时现象。一般来说，虽然网管系统的压力并不会非常大，但在告警频繁或轮巡性能参数等业务时，必须考虑效率问题。
4. Q:在扩展Agent中，除了自定义MIB信息之外，是否可以使用系统原来的MIB信息？
A:可以。UCD-SNMP自带了标准定义的所有通用MIB库，只需要在初始化Agent的时候调用init_mib_all而不是只初始化自定义Agent就可以了。这样基本上所有的通用网管数据（如系统信息，网络信息等）都不需要自行开发，由UCD-SNMP实现了。大大的减少了工作量。
