基于SNMP的网络层网络拓扑算法改进研究
2012-08-14黄睿,王易
黄 睿 ,王 易
(1.重庆电子工程职业学院,重庆 401331;2.东北财经大学,辽宁 大连 116025;3.重庆信息职业技术学院,重庆 万州 404000)
0 引 言
互联网技术兴起的时候,对网络拓扑发现的研究就已开始起步。ICMP作为最早在TCP/IP网络协议,被广泛运用到网络拓扑发现技术中,这主要依赖于两个网络工具:Ping和Traceroute。Ping主要用于探测网络的状况,确定存活的主机;traceroute则用来追踪报文的传送路径。典型的如Mercator算法[1]CNRG算法[2]都是利用了Traceroute工具来发现Internet的骨干拓扑。其中前者是结合了启发式算法[3],进行多次有限跳的主动探测;后者则是从BGP(边界网关协议)的路由信息开始,逐步发现每个探测域的路由器与连接关系,最后对得到的结果进行合并[4]。由CAIDA项目组设计的基于通用协议的拓扑测量工具Skitter则是先用Traceroute主动探测转发路径[5],然后通过BGP表来推测Internet内部各自治域间的结构。为了提高发现路径的准确性,解决同一个路由器多个IP的问题[6],针对ICMP方法的特点,文献[7]又提出了别名探子和路径探子的概念,别名探子识别同一台路由器的所有IP,路径探子仍采用了Traceroute,用来探测路径上的路由器。算法中,很好地利用了这两种探子的功能[8],因此把算法的基本流程视作采用通用协议进行拓扑发现的典型。
基于通用协议的算法采用了Ping和Traceroute工具,属于主动探测算法[9],即由探测源主动向待测网络注入探测流量数据,因此会使用大量ICMP数据包,从而导致大量ICMP数据包占用网络带宽,网络负载重,在算法的实现上也有很大的难度。此外,主动探测在一定程度上也等同于网络入侵,存在潜在的隐患,在网络管理安全意识加强的今天,许多设备会通过防火墙等防护措施禁用ICMP包,造成了拓扑结构的不准确和不完整。本文提供一个统一的标准和工具,简化网络管理工作[10]。
1 简单网络协议
20世纪90年代初,由J·D·Case等人提出了名为“简单网络管理协议(SNMP)”的 RFC1157[11],之后又由K·McCloghrie等人提出了基于TCP/IP协议的管理信息库MIB-II。
SNMP的出现为网络管理带来了极大的便利,也给网络拓扑发现提供了新的思路和方法。在SNMP出现以后,Glenn Mansfield等人率先提出了一种基于SNMP的网络层拓扑发现方法[12],这种算法第一次提出了采用从MIB中读取路由表的方式来获得拓扑信息进行拓扑发现的思路,与通用协议相比,这种方法的特点是速度快,简单易实现,但通用性较差,要求所有目标设备必须支持SNMP协议。
2 基于SNMP的第三层网络拓扑发现
众所周知,网络层位于OSI七层模型中的第三层,所以网络层拓扑发现又称为三层拓扑发现。工作在网络层的主要设备是路由器,网络层拓扑发现的目的是发现路由器和路由器、路由器和子网间的连接关系。网络层拓扑对于明晰主干网结构,把握被管理网络的整体特征有重要作用。网络层拓扑发现又被称作逻辑拓扑发现,其获取的连接关系并非网络设备的实际物理连接关系,比如路由器与子网的连接必然通过连接子网内某设备的具体端口来实现,而在网络层拓扑发现中,并不关心具体的设备端口和子网内的设备信息,而把这个子网看作一个整体对待,如图1所示。
图1 网络层拓扑图
3 基于SNMP的第三层网络拓扑原算法分析
如图2所示,算法首先从程序运行的主机开始,读取主机MIB库的路由表,找到ipRouteDest值为0.0.0.0的表项,根据前面所述可知,该表项为缺省网关对应的表项。再查看对应的ipForwarding值,当值为1时,即可确定该缺省网关为路由器。获取对应的ipRouteNextHop值,即为此主机设置的缺省路由器的IP地址。将此路由器加到待测路由器队列,作为拓扑发现开始的种子路由器。向该种子路由器发送SNMP读取请求消息,获取该种子路由的ipRouteTable值。然后遍历该ipRouteDest值下ipRoute-Type的每一个实例,值为3的查找其对应的ipRouteDest与ipRouteMask,将其相与后加入子网队列,记住其直连关系;值为4的查找其对应的ipRouteNextHop,判定该ipRouteNextHop与原路由器直连,将ipRouteNextHop加入待测路由器队列,记住其直连关系。对该路由器所有表项遍历完成以后,将其对应的ipRouteNextHop从待测路由器队列中删除。然后查看待测路由器队列,将其中的路由器取出进行相同处理,直到待测队列为空,算法停止。
图2 SNMP网络层算法流程图
4 原算法存在的问题与改进
对上述算法进行仔细分析,发现存在多址问题,即当一个路由器只有一个IP时,按照上述方法能够达到网络层拓扑发现的目的,但若一个路由器有多个IP,则会使得到的拓扑图出现偏差。根据上述算法的原理可知,在读取MIB中的每一条记录时,是把每一条记录作为一个设备实例来看待,也是将一个ipRouteNextHop对应为一台路由器。但实际情况是,一台路由器常常有多个IP。那么当一台路由器的IP不止一个时,算法就会把同属于一台路由器的不同ipRouteNextHop当成不同的路由器来处理,造成拓扑结构发现的偏差。例如在图3中,实际情况是R3、R4分别与R5的A1、A2端口直连,但因为R5的A1和A2上分别有不同的IP地址,故R3、R4的ipRouteNextHop值不相同。因此,算法就会将A1、A2对应的两个ipRouteNextHop处理成两台不同的路由器,导致得到的拓扑图出现错误。
图3 路由器多址问题
图4 解决了路由器多址问题的算法
算法思路:为了解决路由多址问题,必须对上面所描述的基本算法进行修正。基本思路就是将待测队列中同属于一台路由器的IP地址进行归并,而在ip组的ipAddrTable,记录了设备所有的IP地址信息。在ipAddrTable中,每个ipAdEntAdd实例代表设备的一个IP地址,因此,只要遍历ipAdEntAdd的每个实例,就能获得一台设备的所有IP地址,从而确定哪些IP代表了一台路由器。
算法流程:改进的算法从这一点入手,每次从待测队列中取出一个新的待处理IP之后(记为A),先遍历队列中其他IP对应的ipAddrTable,这样就能获取每个待处理路由器的所有IP。判断A是否在某个路由器的IP集合中,若在,则可知A与该路由器在待测队列中的那个IP(记为M)同属一个路由器,因此将M从待测队列中删除,这样最终得到的待测队列中的IP必然分属不同路由器。改进后的算法流程图如图4所示。
5 算法对比分析与总结
基于SNMP通用的网络层拓扑发现算法获取信息的方式较为便捷,算法实现简单,而且发现效率较高、网络负载较小,但由于只设定了对一个IP进行寻址,若同个路由器有多个IP地址,则会出现寻址错误。本文中提出的改进SNMP算法,通过设定特殊的IP遍历路径,能对IP进行准确的判定,由此解决了路由器多址问题,能够在路由器有多个IP地址的情况下得到正确的拓扑结构。
与所有基于SNMP的网络层拓扑发现算法相同,改进SNMP算法有效的前提是必须保证待测网络内的所有路由器都支持SNMP,并且由于可能不知道一台路由器的共同体口令,因此没有访问权限,在这种情况下就根本不能通过SNMP获取路由器的信息,无法获得正确的拓扑结构。最后,因为设备的SNMP协议需要手工启用和配置,如果某台设备虽然支持SNMP,但未启用,同样也无法获取到该设备的信息。
表1 改进SNMP算法和通用SNMP算法的对比
[1]Aman Shaikh,Mukul Goyal,Albert Greenberg,et.An OSPF Topology Server:Design and Revolution[J].http://www.cis.ohio-state.edu/~mukul/jsac.pdf
[2]BruceLowekamp,DavidHallaron,ThomasR.Gross.Topology Discovery for Large Ethernet Networks[C].SIGCOMM 2001:237-248.
[3]郑海,张国清.物理网络拓扑发现算法的研究[J].计算机研究与发展,2002,39(3):264-268.
[4]James F.Kurose,Keith W.Rose.计算机网络:自顶向下方法与Internet特色[M].北京:机械工业出版社,2008.
[5]W.Richard Stevens.TCP/IP协议详解[M].北京:机械工业出版社,2008
[6]杨凯,马季兰.基于SNMP的网络拓扑发现算法的研究[J].电脑开发与应用,2008,21(3):64-66.
[7]刘亚莉,孙亚民.基于SNMP的网络拓扑结构自动发现研究[J].微型机与应用,2004.23(4):28-31.
[8]李琳,李杰.基于SNMP的网络层拓扑发现[J].计算机系统应用,2007(8):39-42.
[9]凌军,曹阳,李莉,等.基于ARP和SNMP的网络拓扑自动发现算法[J].武汉大学学报.2001,47(1):67-70.
[10]丘林,张建忠.基于端口流量的物理网络拓扑发现方法研究[J].计算机工程与应用.2002,38(22):17l-172.
[11]张伟明,罗军勇,寇晓蕤,蔡延荣.网络拓扑发现中的路由器别名识别[J].计算机工程与应用,2004,40(13):143-146.
[12]R.Siamwalla.Discovering Internet Topology[A].IEEE Proceeding-IEEE INFOCOM 1999[C].New York:IEEE Press.1999:50-66.