ＴＣＰ／ＩＰ　网络中故障节点的诊断方法.docVIP

ＴＣＰ／ＩＰ　网络中故障节点的诊断方法 　　摘要：本文描述了一种在TCP/IP网络中进行故障节点诊断的程序实现，该方法基于VxWorks操作系统的网络测试仪环境，但此程序算法的实现，并不依赖于底层的操作系统及硬件环境，经过少量修改可以在任何提供TCP/IP协议栈的操作系统中实现，比如Linux，Windows等。 　　关键词：ICMP；TCP；UDP；路由追踪 　　中图分类号：TP393文献标识码：A文章编号：1009-3044(2008)18-2pppp-0c 　　 　　1 背景 　　 　　网路故障的一般表现是网速变慢或者无法访问互联网或内网服务器，在现场进行网络故障诊断时，往往需要借助各种工具软件如Sniffer、ping、traceroute等进行逐步排查，最后经过分析，选择怀疑的网络节点，然后在局端或现场对怀疑的网络节点进行各种连通性、替代性测试，方法步骤繁杂，而且往往无法准确诊断。 　　经过分析，故障诊断的过程，可以使用专用的设备，并编写相应的诊断程序，自动完成网络故障节点的测试和判断。 　　 　　2 算法和设计 　　 　　当测试节点到达目的网络位置的链路存在问题时，一般可能是：物理链路断开（线缆或节点设备故障）；目的地址的相应端口没有开放，或者中间链路经过的设备（交换机，路由器等）禁止了协议或端口；终端设备故障。故，处理流程首先是找到测试节点到达连接服务器节点的路径，确定经过的网络节点位置，然后对节点中的各个位置实施连通性测试，最后根据测试结果判断故障节点位置和原因。 　　2.1 网络路由的查询 　　该部分的功能类似于Linux系统中提供的命令traceroute，不同的是，该部分功能进行路由诊断依赖的协议不仅仅是ICMP。 　　ICMP的原理是链路上的节点设备都要在转发该 ICMP 回显请求报文之前将报文头部的 TTL 值减 1，当报文的 TTL 值减少到 0 时，节点设备向源发回 ICMP 超时信息。该诊断实用程序通过向目的地发送具有不同生存时间 (TTL) 的 ICMP报文，确定至目的地的路由。通过发送 TTL 为 1 的第一个回显报文并且在随后的发送中每次将 TTL 值加 1，直到目标响应或达到最大 TTL 值，可以确定链路经过的路由。通过检查链路中间节点设备发回的 ICMP 超时信息，可以确定故障节点。 　　如果使用ICMP协议无法完成测试，则改为使用UDP协议和TCP协议分别进行路由侦测。源发出UDP数据包，源端口使用随机的大于32768的高段端口号，目的端口从33434开始依此递增，直至33434+29，同时TTL从1开始依此递增，直至1+29=30。节点设备送回的 ICMP超时报文，使得源可以侦测到链路上每一个节点。 　　2.2 网络节点诊断 　　向节点发送TCP握手信号，如果该节点可以通过connect连接成功，表示节点可以正常连接，如果回应RST，表示该节点禁止了该端口的访问，如果该节点长时间不回复SYN，也可以认为该节点禁止端口。 　　因此，依据上述现象可以很容易判断当前故障节点――离测试者最近的故障点，可以被认定为当前网络故障点。 　　2.3 故障节点位置的判断策略 　　如果路由寻找完整，一般能够找到节点。在所有不回应SYN包或者回应RST包的 　　节点中，应该是离源最近跳数的节点设备将端口关闭。 　　如果路由寻找不完整，有可能找不到所找的故障点。如果在找到的n个节点中，只有非最远离源的一个节点不回应，或回应RST包，则不能确定故障节点；如果是包括最远离源在内的一个或多个节点不回应或回应RST包，则最右端节点可能为故障节点，但并不能确定在整个路由中的故障节点所在，因为路由不完整。 　　2.4 不能覆盖的异常情况 　　如果使用ICMP和UDP都无法寻找到完整路由，则有可能找不到故障节点，但这种情况非常少，因为根据UDP的测试原理，除非中间节点将大于32768的端口全部封掉，否则都可以得到完整的路由路径。 　　 　　3 代码片段和程序流程 　　 　　3.1 整体框架代码 　　 　　int f_procon_scan_showerr(char *re_info) 　　{char err_node[16]; 　　inet_ntoa_b(info_scan.node[info_scan.err_num],err_node); 　　if(err_tcpscan == ERR_PORTSCAN_ROUTE_HALF){ 　　sprintf(re_info,路由信息不完整，故障点可能是：%s,err_node); 　　}else if(err_tcpscan == ERR_PORTSCAN_ROUTE_NO){ 　　sprintf(r