使用包分析软件排查网络故障

转载 2006年05月31日 20:22:00

作者:Yiming Gong
http://security.zz.ha.cn


声明:任何形式的摘抄必须保留上述作者和http地址

使用包分析软件排查网络故障

Oct 31,2002

作为IP网络的系统管理员,经常会遇到一些网络连接方面的故障,在排查这些接故障时,除了凭借经验外,使用包分析软件往往会起到事半功倍的效果。
常用的包分析软件非常多,常见的如tcpdump,sniffer,windump,ettercap等。我们今天就介绍通过包分析软件tcpdump排查网络故障的几个例子,关于tcpdump软件的介绍,安装,基本用法的资料非常多,读者可以查阅,这里不介绍了。

例1:arp故障
故障现象:局域网中的一台采用solaris操作系统的服务器A-SERVER网络连接不正常,从任意主机上都无法ping通该服务器。

排查:首先检查系统,系统本身工作正常,无特殊进程运行,cpu,内存利用率正常,无挂接任何形式的防火墙,网线正常。
此时我们借助tcpdump来进行故障定位,首先我们将从B-CLIENT主机上执行ping命令,发送icmp数据包给A-SERVER,如下:
[root@redhat log]# ping A-SERVER
PING A-SERVER from B-CLIENT : 56(84) bytes of data.
此时在A-SERVER启动tcpdump,对来自主机B-CLIENT的数据包进行捕获。
A-SERVER# tcpdump host B-CLIENT
tcpdump: listening on hme0
16:32:32.611251 arp who-has A-SERVER tell B-CLIENT
16:32:33.611425 arp who-has A-SERVER tell B-CLIENT
16:32:34.611623 arp who-has A-SERVER tell B-CLIENT
我们看到,没有收到预料中的ICMP报文,反而捕获到了B-CLIENT发送的arp广播包,由于主机B-CLIENT无法利用arp得到服务器A-SERVER的地址,因此反复询问A-SERVER的MAC地址,由此看来,高层的出问题的可能性不大,很可能在链路层有些问题,先来查查主机A-SERVER的arp表:
A-SERVER# arp -a
Net to Media Table
Device IP Address Mask Flags Phys Addr
------ -------------------- --------------- ----- ---------------
hme0 netgate 255.255.255.255 00:90:6d:f2:24:00
hme0 A-SERVER 255.255.255.255 S 00:03:ba:08:b2:83
hme0 BASE-ADDRESS.MCAST.NET 240.0.0.0 SM 01:00:5e:00:00:00
请注意A-SERVER的Flags位置,我们看到了只有S标志。我们知道,solaris在arp实现中,arp的flags需要设置P标志,才能响应ARP requests。
手工增加p位
A-SERVER# arp -s A-SERVER 00:03:ba:08:b2:83 pub
此时再调用arp -a看看
A-SERVER# arp -a
Net to Media Table
Device IP Address Mask Flags Phys Addr
------ -------------------- --------------- ----- ---------------
hme0 netgate 255.255.255.255 00:90:6d:f2:24:00
hme0 A-SERVER 255.255.255.255 SP 00:03:ba:08:b2:83
hme0 BASE-ADDRESS.MCAST.NET 240.0.0.0 SM 01:00:5e:00:00:00
我们看到本机已经有了PS标志,此时再测试系统的网络连接恢复正常,问题解决!

例2:netflow软件问题
故障现象:在新装的网管工作站上安装cisco netflow软件对路由设备流量等进行分析,路由器按照要求配置完毕,本地工作上软件安装正常,无报错信息,但是启动netflow collector却收不到任何路由器上发出的流量信息,导致该软件失效。 排查:反复检查路由和软件,配置无误。采用逐步分析的方法,首先先要定位出有问题的设备,是路由器根本没有发送流量信息还是本地系统接收出现了问题?
突然想到在路由器上我们定义了接收的client端由udp端口9995接收数据,可以通过监视这个端口来看路由器是否确实发送了udp数据,如果系统能够接收到来自路由的数据包,那么路由方面的问题可能行不大,反之亦然。
在网管工作站上使用tcpdump来看看:
nms#tcpdump port 9995
tcpdump: listening on hme0
18:15:34.373435 routea > nms.9995: udp 1464
18:15:34.373829 routea.50111 > nms.9995: udp 1464
18:15:34.374100 routea.50111 > nms.9995: udp 1464
马上我们就看到数据包确实从路由器上发过来了,问题出在路由器的可能性基本排除,重新核查系统,果然,网管工作站上安装了防火墙,udp端口9995是被屏蔽的,调整工作站上的防火墙配置,netflow工作恢复正常,故障排除!

例3:邮件服务器排障
故障现象:局域网新安装了后台为qmail的邮件服务器server,邮件服务器收发邮件等基本功能正常,但在使用中发现一个普遍的怪现象:pc机器上发邮件时连接邮件服务器后要等待很久的时间才能开始实际的发送工作。

排查:网络连接没有问题,邮件服务器server和下面的pc性能都没有问题,问题可能出在哪里呢?为了进行准确的定位,我们在pc机client上发送邮件,同时在邮件服务器server上使用tcpdump对这个client的数据包进行捕获分析,如下:
server#tcpdump host client
tcpdump: listening on hme0
19:04:30.040578 client.1065 > server.smtp: S 1087965815:1087965815(0) win 64240 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]> (DF)
19:04:30.040613 server.smtp > client.1065: S 99285900:99285900(0) ack 1087965816 win 10136 <nop,nop,timestamp 20468779 0,nop,[|tcp]> (DF)
19:04:30.040960 client.1065 > server.smtp: . ack 1 win 64240 (DF)
顺利的完成三次握手,目前为止正常,往下看
19:04:30.048862 server.33152 > client.113: S 99370916:99370916(0) win 8760 <mss 1460> (DF)
19:04:33.411006 server.33152 > client.113: S 99370916:99370916(0) win 8760 <mss 1460> (DF)
19:04:40.161052 server.33152 > client.113: S 99370916:99370916(0) win 8760 <mss 1460> (DF)
19:04:56.061130 server.33152 > client.113: R 99370917:99370917(0) win 8760 (DF)
19:04:56.070108 server.smtp > client.1065: P 1:109(108) ack 1 win 10136 <nop,nop,timestamp 20471382 167656> (DF)

这里有问题了,我们看到server端试图连接client的113 identd端口,要求认证,然而没有收到client端的回应,server端重复尝试了3次,费时26秒后,才放弃认证请求,主动发送了reset标志的数据包,开始push后面的数据,而正是在这个过程中所花费的26秒时间,造成了发送邮件时漫长的等待情况。
问题找到了,就可以对症下药了,通过修改服务器端的qmail配置,使它不再进行113端口的认证,再次抓包,看到邮件server不再进行113端口的认证尝试,而是在三次握手后直接push数据,问题解决!

总结:
上面我们通过实际的例子演示了包分析软件在故障解决中起到的作用,通过这些例子,我们不难发现,用好包分析软件,对系统管理员快速准确定位网络故障,分析网络问题有不可替代的作用

计算机网络连接故障六个排查的基本步骤

网络管理员会经常遇到网络连接故障,假如没有工具常常不知道如下手进行故障排除,下面介绍六个排查的基本步骤。   可以了解如何通过正确的工具并按照6个简单的步骤操作来简化识别、隔离和解决边缘交换机和用户...
  • u013428650
  • u013428650
  • 2014年02月19日 14:58
  • 870

网络故障大排查

作为一个刚入门的IT技术人员,我曾经有好多疑惑,后来下载了根叔的云图 APP,由于采用移动互联方式,它可以方便维护工程师随时随地定位设备问题,为百种错误现象提供问题定位方法,并能连线求助。《根叔的云图...
  • xun1992
  • xun1992
  • 2016年12月20日 09:53
  • 420

CentOS故障排除详解(3): 网络环境

在这篇文章中,我们将会学到一些常用的命令诸如ping/dig/host/traceroute/mtr/ss/tcpdump等,同时如何使用这些命令进行简单的网络故障确认。...
  • liumiaocn
  • liumiaocn
  • 2017年01月26日 08:09
  • 804

linux网络故障排查

当linux操作系统产生网络故障时,应先从硬件到软件、从自身到全局。 1,检查网线、网卡。 到机房里检查网线两端是否都亮灯,普通服务器的话应该是绿灯常亮为正常,交换机绿灯闪烁表示正在传输数据。 ...
  • sinat_20415509
  • sinat_20415509
  • 2017年03月23日 15:40
  • 2729

排查网络故障的步骤

排查故障的5个步骤: 1、Ping 127.0.0.1 检查IP协议栈 2、Ping 当前主机IP 检查网卡 3、Ping 默认网关   检查本地网络  4、Ping 远程服务器 检查远程物理...
  • lmj1436140682
  • lmj1436140682
  • 2017年03月30日 08:47
  • 96

网络故障的排查过程。

单位里有2个Internet出口,最近的其中一根线路有点不正常,局域网不管哪台电脑用outlook还是foxmail,接收单位的邮箱出现故障,现象是:收邮件时候,可以登录成功并看到有多少封邮件,但是遇...
  • china2wto
  • china2wto
  • 2005年12月05日 15:48
  • 1332

Linux网络故障排查总结

1.检查网络设备 要能连网,网络设备首先必须保证处于工作状态,如果网卡没有开启,则肯定不能上网的,假设我们使用eth0网卡上网,首先检查该网卡是否处于up状态,使用ip命令: su...
  • li_101357
  • li_101357
  • 2017年04月20日 12:09
  • 1658

大型网站典型故障案例分析

写日志也会引发故障故障现象:某应用服务器集群发布后不久就出现多台服务器相继报警,硬盘可用空间低于警戒值,并且很快有服务器宕机,登录到线上服务器,发现log文件夹里的文件迅速增加,不断消耗磁盘空间。 原...
  • Edwingu
  • Edwingu
  • 2015年03月09日 23:04
  • 1561

怎样用Ping命令轻松解决检测网络故障+排除网络故障从Ping命令开始

網絡 故障 排除
  • fengqingtao2008
  • fengqingtao2008
  • 2010年12月16日 12:54
  • 5236

mtr分析网络情况

mtr分析网络情况, 遇到的问题, 怎么解决的。 这也是个曲折的故事。
  • Dcatfly
  • Dcatfly
  • 2017年07月16日 13:53
  • 1975
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:使用包分析软件排查网络故障
举报原因:
原因补充:

(最多只允许输入30个字)