关于SNMP的GetNextRequest PDU实现分析
转自：https://blog.csdn.net/shanzhizi/article/details/12166829
在SNMPv1的标准文档RFC1157中对GetNextRequest PDU的应用列举了一个表格遍历的例子。因为第一次搞这个东西，初看那个例子时弄得我晕圈了。搞不明白GetNextRequest PDU该如何实现。
现在初步对那个例子有了点认识，记录下来，以免日后遗忘。不当之处请指正。
下面是SNMP协议文档RFC1157中4.1.3.1中的例子。
GetNextRequest PDU的最重要的功能是表的遍历，这种操作受到了前面所说的管理变量的表示方法的支持，从而可以访问一组相关的变量，就好象他们在一个表内。
下面通过一个例子解释表遍历的过程：
被管设备维护如下路由表：
Destination NextHop Metric
10.0.0.99 89.1.1.42 5
9.1.2.3 99.0.0.3 3
10.0.0.51 89.1.1.42 5
假设网管站欲取得这张路由表的信息，该表的索引是目的网络地址。
网管站向被管设备发送一个GetNextRequest PDU,其中的受管对象的标识如下
GetNextRequest ( ipRouteDest, ipRouteNextHop, ipRouteMetric1 )
SNMP agent响应如下GetResponse PDU:
GetResponse (( ipRouteDest.9.1.2.3 = "9.1.2.3" ),
( ipRouteNextHop.9.1.2.3 = "99.0.0.3" ),
( ipRouteMetric1.9.1.2.3 = 3 ))
说明：这里的响应初看就懵了。开始就是没明白( ipRouteDest.9.1.2.3 = "9.1.2.3" )是什么意思。其实他的意思是，代理向管理站回复时，回复了一个对象ID是ipRouteDest.9.1.2.3，value是"9.1.2.3"的对象。这样以来，管理站下一个GetNextRequest 报文中必然会包含ID是ipRouteDest.9.1.2.3的对象。
对于ipRouteDest.9.1.2.3这个ID是可以根据情况自己设计，不一定要使用这种方式。而代理要做的就是要对ipRouteDest对象做特殊处理，要根据ipRouteDest.9.1.2.3中“9.1.2.3”去查下一条记录。
网管站继续：
GetNextRequest ( ipRouteDest.9.1.2.3,
ipRouteNextHop.9.1.2.3,
ipRouteMetric1.9.1.2.3 )
agent响应：
GetResponse (( ipRouteDest.10.0.0.51 = "10.0.0.51" ),
( ipRouteNextHop.10.0.0.51 = "89.1.1.42" ),
( ipRouteMetric1.10.0.0.51 = 5 ))
值得注意的是agent必须能够确定下一个管理变量名，以保证所有变量能被取到且只被取到一次。
网管站继续：
GetNextRequest ( ipRouteDest.10.0.0.51,
ipRouteNextHop.10.0.0.51,
ipRouteMetric1.10.0.0.51 )
agent 响应：
GetResponse (( ipRouteDest.10.0.0.99 = "10.0.0.99" ),
( ipRouteNextHop.10.0.0.99 = "89.1.1.42" ),
( ipRouteMetric1.10.0.0.99 = 5 ))
网管站继续
GetNextRequest ( ipRouteDest.10.0.0.99,
ipRouteNextHop.10.0.0.99,
ipRouteMetric1.10.0.0.99 )
这时因为路由表中所有的行都被取遍，agent因返回路由表对象的下一字典后继即该管理对象在MIB树中的后序遍历的直接后继。这里应是nettoMediaIndex，管理对象的OBJECT IDENTIFIER。这个响应通知网管站对表的遍历已经完成。
再说一下“索引”的问题吧！开始给出的路由表是
Destination NextHop Metric
10.0.0.99 89.1.1.42 5
9.1.2.3 99.0.0.3 3
10.0.0.51 89.1.1.42 5
但是后来遍历时，第一个怎么是从9.1.2.3开始呢？其实上面的表或许只是随便这么一写。从代理应答的过程来看，这个表在程序真正的存储顺序应该是：
9.1.2.3--》10.0.0.51---》10.0.0.99.