立足网络层 轻松排除网络故障

网络
局域网中大大小小、匪夷所思的网络故障考验着管理员的技术,也历练着他们的神经。面对诸多挑战,有人疲于应付,有人淡定自若。笔者认为,立足于网络层,然后配合网络分析软件进行网络故障的分析,往往能够透过现象看到本质,轻松解决网络故障。

下面将列举两个基于网络层的网络故障分析案例。

分析工具:科来网络分析系统6.0专家版(当然大家也可以用类似的工具)

一、巧用TTL值诊断网络故障

1、简介

TTL,全称是Time To Live,中文名为“生存时间”,它是IP报头中一个非常重要的参数。通过TTL的值,我们可以判断出当前网络IP层的工作状况。

TTL告诉网络中的路由器数据包在网络中的时间是否太长而应被丢弃,TTL的最初设想是确定一个时间范围,超过此时间就把包丢弃。由于数据包每经过一个路由器时,TTL值都会至少被路由器减1,所以TTL值通常表示包在被丢弃前还能最多经过的路由器个数。当TTL值为0时,路由器丢弃该数据包,并发送一个ICMP报文给数据包的最初发送者。

有很多原因会导致数据包在一定时间内不能被传递到目的地。例如,不正确的路由表配置可能导致数据包的无限循环,而解决方法就是在一段时间后丢弃这个数据包,然后给发送者发送一个报文,由发送者决定是否重发该数据包。当网络出现这种情况时,数据包就会在路由表中配置错误的路由器处重复发送,每发送一次,TTL值减1,直到TTL为0时路由器丢弃该数据包,造成网络中数据传输错误。

操作系统和传输协议不同,对应TTL的默认值也不同。图1列出了常见操作系统通过TCP和UDP协议传输时的TTL默认值。(图1) 

 立足网络层排除故障图1

2、查看数据包的TTL值并分析传输故障

网络中的网络设备,其内部都是由操作系统进行处理的(有些硬件设备将系统预装在了硬件芯片里面),在网络遇到传输故障时,我们可以使用网络检测软件,结合上表的信息对网络中流通的数据包进行检测,查看数据包的TTL值,以确定故障是否由错误的路由等原因引起。图2是使用科来网络分析系统5.0查看一个数据包TTL值的情况。(图2)  

立足网络层排除故障图2

图中的生存时间(TTL)是247,结合图1,确定出这个数据包在从源端(这里是61.139.2.69)到目的端(这里是192.168.10.44)共经历了255-247=8个路由器,且在传输过程中未出现故障。

注意:

1.确定数据包在网络中经历了多少个路由器,可用数据包源端设备的TTL默认值减去捕获到的数据包TTL值;

2.在不知道数据包源端设备的默认TTL时,一般用大于捕获数据包的TTL,且最接近这个TTL的默认值。

3.TTL字段长1个字节,所以TTL的最大值255;

通过查看数据包的TTL,可以确定网络传输是否正常。如果捕获到的数据包的TTL值过小,则表示网络中很可能存在传输故障,应及时检查网络中三层设备的路由表配置,以及各主机上的路由表信息。#p#

二、利用TCP标记分析故障

1、TCP标记简介

TCP,全称Transfer Control Protocol,中文名为传输控制协议;它工作在OSI的传输层,提供面向连接的可靠传输服务。

在TCP的报头中,有一个TCP标记字段,这个字段用来指出当前这个数据包的用途。TCP连接标记字段长6比特,共有6种不同的标记,在一个TCP连接中可能会使用其中的多个标记。这6种标记是:

(1).紧急(Urgent,简称URG):通知对方主机该TCP数据包中包含有紧急数据;

(2).确认(Acknowledgement,简称ACK):用来确认接收到对方主机的TCP数据包;

(3).急迫(Push,简称PSH):通知对方主机立即将该数据包送往上层协议;

(4).重置(Reset,简称RST):表示此TCP连接已被对方主机重新启动;

(5).同步(Synchronization,简称SYN):用来建立和对方主机的TCP连接;

(6).终止(Finish,简称FIN):用来关闭TCP连接。

不同数据包中的TCP 标记可能相同,也可能不同,通过数据包的解码,可以知道当前数据包正在进行的操作及其作用。如TCP三次握手的第一步会将同步位置为1;第二步会同时将确认位和同步位置为1;第三步会将确认位置为1。根据TCP标记的特性,我们可以利用它分析网络中常见的网络应用故障。

2、利用TCP标记分析网络故障

当遇到目标主机的某TCP服务不能访问时,我们可以通过对其访问的过程进行抓包分析,从而找出不能访问的原因,下面我们用科来网络分析系统6.0,以分析Telnet为例说明分析的方法。

图3是在Windows客户端(客户端主机名为lw)上使用Telnet命令访问其他主机的情况。从图3的返回结果可知,两台主机的Telnet服务都不能正常访问,但我们无法确定不能访问的原因,是因为网络不通,还是这台主机没有提供Telnet服务。(图3)  

立足网络层排除故障图3

注意:

(1).这里使用的Telnet命令是在假定目标服务器使用默认的端口配置,即Telnet服务器端口是TCP 23;

(2).可能有些用户想到使用Ping命令测试网络的连通性,但由于承载Ping命令的ICMP协议可以导致一些非法攻击,对网络的安全会造成一定的威胁,使得某些ISP厂商或者网络管理员都在他们的三层设备处禁用了ICMP协议的转发。在这种情况下,使用Ping命令便无法准确测试主机的连通性。

图4是在WINDOWS客户端使用Telnet命令访问192.168.2.10主机时,科来网络分析系统6.0捕获到的数据包信息。(图4) 

 立足网络层排除故障图4

从图4可知,使用Telnet命令访问192.168.2.10主机时,两主机间共有三个数据包通信,仔细查看数据包及其解码,发现三个数据包都是从客户端发往192.168.2.10主机的,三个数据包的确认号都是0,且都将TCP标记中的同步位置1,表明三个数据包都是TCP三次握手的第一步,即TCP同步数据包。没有从192.168.2.10发往客户端的数据包,说明此时客户端与192.168.2.10主机在物理链路上不通,可能是网络中没有IP地址为192.168.2.10这台机器,或者这台机器没有开机。#p#

图5是在WINDOWS客户端使用Telnet命令访问192.168.2.100主机时,科来网络分析系统6.0捕获到的数据包信息。(图5) 

 立足网络层排除故障图5

从图5可知,使用Telnet命令访问192.168.2.100主机时,两主机间共有6个数据包通信,仔细查看数据包及其解码,发现1,3,5这三个数据包是从客户端发往192.168.2.100主机的,这三个数据包的确认号是0,TCP标记是同步位置1,表明三个数据包都是TCP三次握手的第一步,即TCP同步数据包。2,4,6这三个数据包是从192.168.2.100主机发往客户端的,这三个数据包的确认号是确认号2643478089,TCP标记是确认位和重置位同时置1,表示这三个数据包都是192.168.2.100对客户端的确认数据包,同时它拒绝了客户端的建立连接的TCP同步请求,告诉客户端当前主机(这里是192.168.2.100)没有打开客户端请求的服务,并中断这个连接。

注意:我们发现在图4和图5中,客户端都向服务器(这里是192.168.2.10和192.168.2.100)发送了三次相同的TCP SYN请求,这是为什么呢?其实这是TCP的协议规定造成的,当客户端使用TCP SYN向服务器发起三方握手的第一步后,如果没有收到服务器的SYN/ACK响应,就会在等待一段时间后再次尝试对服务器进行连接,如果连接三次后仍然失败,则不会再重复此操作,所以我们在图中看到了三次完全一样的TCP SYN数据包。

通过对上面两种情况的抓包分析,我们可知道,192.168.2.10主机不能访问的原因是两台主机之间的物理链路不通,可能是不存在192.168.2.10这台机器,或者192.168.2.10处于关机状态等。而192.168.2.100不能访问的原因是192.168.2.100这台机器没有提供客户端请求的Telnet服务,即没有打开TCP 23端口。

总结

当然,笔者列举的两个应用案例只是个案。其实这种方法适用于中所有的TCP服务,用户在遇到不能访问某服务器(各种TCP应用的服务器)时,便可使用这种方法对数据包进行跟踪分析,帮助用户对故障进行排查。这样,管理员从网络层把握网络故障,就能够不受故障表象的影响,从而尽快排除故障,利于提高工作效率。

【编辑推荐】

  1. 专题:网络故障排除宝典
  2. 局域网常见网络故障及排除策略
责任编辑:许凤丽 来源: IT专家网
相关推荐

2011-08-10 10:54:12

PingPing命令

2010-08-26 15:11:19

2013-05-22 17:18:13

2015-08-06 09:49:54

网络故障负载均衡

2010-01-13 20:28:44

2011-08-10 11:02:14

2020-08-24 21:49:53

网络故障工具网络技术

2011-01-24 13:42:27

网络故障网络故障修复

2009-06-25 09:50:00

2018-08-17 15:48:38

网络故障操作系统PowerShell

2019-04-24 11:02:51

Wireshark网络故障

2009-04-09 13:37:59

网络测试命令故障

2009-12-23 10:50:51

网络故障诊断

2009-05-19 16:40:41

TTL网络故障科来软件

2015-03-17 13:06:36

2010-09-27 11:22:21

2011-02-21 15:48:19

2019-07-23 07:04:33

网络故障DNS服务器测试

2010-08-25 13:31:22

网络故障排除

2010-08-25 14:41:38

光纤网络故障
点赞
收藏

51CTO技术栈公众号