TCP/IP详解 卷一 --------SNMP
1、引言
SNMP：简单网络管理协议
SNMP是关于管理网络中设备的标准
基于TCP/IP的网络管理包含两个部分：网络管理站（也叫管理进程）和被管的网络单元（也叫被管设备）。被管的网络设备都运行TCP/IP协议。被管设备端和管理相关的软件叫做代理程序或代理进程。管理站一般都是带有彩色监视器的工作站，可显示所有被管设备的状态。
管理进程和代理进程之间的通信有两种方式。一种是管理进程向代理进程发出请求，询问一个具体的参数（例如：你产生了多少个不可达的ICMP端口）。另一种方式是代理进程主动向管理进程报告有某些重要事的事件发生（例如：一个连接口掉线了）。管理进程除了可以询问某些参数外，还可按要求改变代理进程的参数值。
基于TCP/IP的网络管理包含3个组成部分：
- 一个管理信息库MIB。管理信息库包含所有代理进程的所有可被查询和修改的参数
- 关于MIB的一套公用的结构和表示符号。叫做管理信息结构 SMI （structure of management information）
- 管理进程和代理进程之间的通信协议，叫做简单网络管理协议SNMP。SNMP包括数据报交换的格式等。在SNMP中，运输层用的最多的协议是UDP。
2、协议
关于管理进程和代理进程之间的交互信息，SNMP定义了5种报文：
- get-request操作：从代理进程处提取一个或多个参数值
- get-next-request操作：从代理进程处提取一个或多个参数的下一个参数值
- set-request操作：设置代理进程的一个或多个参数值
- get-response操作：返回的一个或多个参数值。这个操作是由代理进程发出的。它是前面3中操作的响应操作
- trap操作：代理进程主动发出报文，通知管理进程有某些事情发生
3、管理信息结构
图1：SNMP的5种操作
前四种操作是简单请求-应答方式（管理进程发出请求，代理进程应答响应），SNMP往往使用UDP协议。所以可能发生管理进程和代理进程之间数据报丢失的情况，因此一定要有超时和重传机制。
前3种操作采用UDP的161端口，代理进程发出的Trap操作采用UDP的162端口。由于收发采用不同的端口，所以一个系统可以同时为管理进程和代理进程发送数据。
SNMP报文格式如下：
图2 SNMP报文格式
SNMP报文的编码采用ASN.1和BER，报文长度取决于变量的类型和值。
版本字段为0。该字段值是通过SNMP版本号减去1得到。因此表示为SNMP v1
图3 PDU对应值
PDU即协议数据单元。
共同体字段是一个字符串。这是管理进程和代理进程之间的口令，是明文格式，默认的值是public
对于get、get-next和set操作，请求标识由管理进程设置，然后由代理进程在get-response中返回。这个字段的作用是使客户进程（目前情况下是管理进程）能够将服务器进程（即代理进程）发出的响应和客户进程发出的查询进行匹配。这个字段允许管理进程对一个或多个代理进程发出多个请求，并且从返回的众多应答中进行分类。
差错状态字段是一个整数，它是由代理进程标注的，指明有差错发生。具体值如图4所示
图4 SNMP差错状态的值
差错索引字段是一个整数偏移量，指明当有差错发生时，差错发生在哪个参数。它是由代理进程标注的，并且只有在发生noSuchName、readOnly和badValue差错时才进行标注。
在get、get-next和set的请求数据报中，包含变量名称和变量值的一张表。对于get和get-next操作，变量值部分被忽略，不需要填写。
trap操作符，SNMP报文会有所变化。
4、对象标识符
- INTEGER。一个变量虽然被定义为整型，但也有多种形式。有些整型变量没有范围限制，有些整型变量定义为特定的数值（如：IP转发标志就只有允许转发时的1或者不允许转发时的2这两种），有些整型变量定义为一个特定的范围（如：UDP和TCP的端口号从0到655535）
- OCTER STRING 0或多个8bit字节，每个字节值在0~255之间。对于这种数据类型和下一种数据类型的BER编码，字符串的字节个数要超过字符串本身的长度。这些字符串不是以NULL结尾的字符串。
- DisplayString 0或多个8bit字节，但是每个字节必须是ASCII码。在MIB-II中，所有该类型的变量不能超过255个字符（0个字符是可以的）
- NULL 代表相关的变量没有值
- IpAddress 4字节长度的OCTER STRING，以网络序表示的IP地址。每个字节代表IP地址的一个字段。
- PhysAddress OCTER STRING类型，代表物理地址
- Counter 非负的整数，可从0递增到2^32-1(429976295)。达到最大值后归0
- Gauge 非负的整数，取值范围为从0到429976295（或增或减）。达到最大值后锁定，直到复位
- TimeTicks 时间计数器，以0.01秒为单位递增，但是不同的变量可以有不同的递增幅度。因此在定义这种类型的变量时，需要指定递增幅度。
- SEQUENCE 类似于C语言中的“structure”类型。一个SEQUENCE包括0个或多个元素，每个元素有时另一个ASN.1数据类型。例如：MIB中UdpEntry为此种类型的变量。它代表在代理进程侧目前“激活”的UDP数量（“激活”表示目前被应用程序所用）。在这个变量中包含两种元素：
- IpAddress类型的udpLocalAddress，表示IP地址
- INTEGER类型中的udpLocalPort，从0到65535，表示端口号
- SEQUENDE OF 此为一个向量的定义，其所有元素具有相同的类型。如果每一个元素都具有简单的数据类型，则就可以得到一个简单的向量。
对象标识是一种数据类型，它指明一种“授权”命名的对象。“授权”的意思是这些标识不是随便分配的，它是由一些权威机构进行管理和分配的。
对象标识是一个整数序列，以点（“.”）分隔。这些整数构成一个树形结构，类似于Unix的文件系统。对象标识从树的顶部开始，顶部没有标识，以root表示。
SNMP中用到的树形结构如图5所示。所有的MIB变量都从1.3.6.1.2.1开始。
图5 管理信息库中的对象标识
树上的每个结点同时还有一个文字名。在实际应用中，即在管理进程和代理进程进行数据报交互时，MIB变量名是以对象标识来标识的，即都是以1.3.6.1.2.1开头
ios.org.dod.internet.private.enterprises(1.3.6.1.4.1)此标识是厂家自定义而预留的。
5、管理信息库（MIB）
管理信息库（MIB）是所有代理进程包含的、并且能够被管理进程进程查询和设置的信息的集合
MIB被划分为若干个组，如system、interfaces、at（地址转换）和ip组等
在本节，只讨论UDP组中的变量。UDP组结构如图6所示
图6 UDP组的结构
该组包含4个简单变量和1个有两个简单变量组成的表格。图7描述了这4个简单变量。
图7 UDP组下的简单变量
上图中，“R/W”列若为空，则表示该变量是只读的；若变量是可读可写的，则以“.”符号来表示。哪怕整个组的变量都是只读的，则也列出"R/W"列。将变量数据类型是INTERGET类型并且有范围约束，则将注明它的上限和下限，如图8中描述UDP端口号一样
图8 UDP组下的简单变量
利用SNMP表格形式描述MIB时，表格第一行表示索引的值，它是表格中的每一列的参考。
Case图
6、实例标识前3个计数器是有相互关系的。Case图真是描述了一个给出的MIB组中变量之间的相互关系。UDP组的case图如图9所示
图9 UDP的case图
此图表明，发送到应用层的UDP数据报的数量（udpInDatagrames）就是从IP层送到UDP层的UDP数据报的数量，udpInErrors和udpNoPorts也类似。同样，发送到IP层的UDP数据报的数量就是从应用层发出的UDP数据报的数量，这表明udpInDatagram不包括udpInError和udpNoPorts。
Case图被用来验证：分组的所有数据路径都是被计算的
当对MIB变量进行操作，如查询和设置变量的值时，必须对MIB的每个变量进行标识。首先只有叶子节点是可操作的。mib、udp、udpTable和udpEntry不是叶子结点
6.1 简单变量
6.2 表格对于简单变量的处理方法是通过在其对象标识后面添加".0"来处理。例如计时器udpInDatagrams，它的对象标识是1.3.6.1.2.1.7.1，它的实例标识是1.3.6.1.2.1.7.1.0，对应的文字名称为iso.org.dod.internet.mgmt.mib.udp.udpInDatagrams.0。
变量处理后通常可缩写为udpInDatagrams.0，但是在SNMP报文中，该变量的名称是其对象标识符1.3.6.1.2.1.7.1.0
6.3 字典式排序每个MIB中的表格都指明一个以上的索引
MIB中按照对象标识进行排序时有一个隐含的排序规则。MIB表格是根据其对象标识按照字典的顺序进行排序的。即将图10中6个变量排序后的情况如图11所示。
图10 UDP监听表中行的实例标识
图11 UDP监听表的字典式排序
- 在表格中，一个给定变量（在这里指udpLocalAddress）的所有实例都在下个变量(这里指udpLocalPort)的所有实例之前显示。这里暗示表格的操作顺序是“先列后行”的次序。这是由于对对象标识进行字典式排序得到的
- 表格中对行的排序和表格中索引的值有关。在图11中，67字典序小于161，同样161的字典小于520
图12 按“先列后行”次序显示UDP监听表
图12描述了例子中UDP监听表的这种“先列后行”的次序
7、例子
共同体名：客户进程提供、同时能被服务器进程识别的一个口令，共同体名称是管理进程请求的全县标志。代理进程允许客户进程用只读共同体名对变量进行读操作，用读写共同体名对变量进行读和写操作。
7.1 简单变量
对一个路由器取两个UDP组的简单变量值
图13 UDP取值
-a选项代表要和之通信的代理进程名称，-c标识SNMP的共同体名。
图14显示了对图13tcpdump的两行输出结果
图14 简单SNMP查询操作tcpdump的输出结果
由图14可以看出这两个变量的查询请求是封装在一个UDP数据报中，而响应也是在一个UDP数据报中。
显示的变量是以其对象标识的形式显示的，这是在SNMP报文实际传输的内容。必须指定这两个变量的实例是0。
注意：变量的名称（它的对象标识）同样也在响应中返回。
7.2 get-next操作
7.3 表格的访问get-next操作是基于MIB的字典式排序的。当代理进程询问UDP后的下一个对象标识，由于不是一个叶子对象，没有指定任何实例，代理简称将返回UDP组中的第一个对象，然后继续向代理进程取该对象的下一个对象标识，这时候第2个对象将被返回。重复上面的步骤直到取出所有对象为止。
get-next操作总是返回变量的名称，这是因为我们向代理进程询问下一个变量，代理进程就把变量值和名称一起返回。
利用这种方式进行get-next操作，利用一个简单的循环操作，就可以从MIB数的定点开始，对代理进程一步步地进行查询，就可以得出代理进程处所有的变量值和标识。该方式的另一个用处就是可以对表格进行遍历。
对于“先列后行”次序的UDP监听表，只要采用最前面的简单查询程序一步一步的进行操作，就可以遍历整个表格。只要从询问代理进程udpTable的下一个变量开始就可以了。由于udpTable不是叶子对象，我们不能指定一个实例，但是get-next操作依然能够返回表格中的下一个对象，然后就以返回的结果为基础进行下一步的操作，代理进程也会以“先列后行”的次序返回一个变量，这样就可以遍历整个表格。
图15 对UDP监听表的遍历
判断已经到达表格最后一行的方法：get-next操作返回结果中包含表格中的下一个变量的值和名称，当返回的结果是超出表格之外的下一个变量时，管理进程就可以发现变量的名称发生了较大的变化。例如：图15中返回的snmpInpkts变量时就代表已经到了UDP监听表的最后一个变量。
8、关于SNMP
利用SNMP可以获得MTU，p288
9、 Trap
目前定义了6种特定的trap类型，如图16所示，第7中trap类型是有供应商自己定义的特定类型。
图16 trap类型
