三大案例分析网络排错应从数据包分析开始

您当前所在位置：IT猫扑网 > 系统集成 > 网络故障 > 三大案例分析网络排错应从数据包分析开始

三大案例分析网络排错应从数据包分析开始 时间：2015-06-28 00:00 来源：IT猫扑网|http://www.itmop.com/ 作者：网管联盟 我要评论(0)

　　对于诸如断网、风暴等灾难性的网络故障，相信大多数管理员朋友能够比较快速地定位并进行排错。但网络是复杂的，在运维中经常会遇到诸如网络速度慢，时断时续，频繁丢包等故障，相对来说，这些故障的排错是比较麻烦的。笔者做技术支持多年，看到运维同仁在遇到此类故障时往往束手无策，此前屡试不爽的观察法、隔离法、替代法不仅太费时间，而且经常让大家走弯路，并且能否排除故障还是未知数。基于此，笔者和大家分享一些自己的经验，即通过捕获网络数据包并分析的手法对网络故障进行诊断，让网络排错从数据包分析开始。

　　1.数据包的捕获方式

　　要进行数据包分析，首先要在故障的网络的特定节点捕获数据包。因此，笔者先和大家谈谈数据包的捕获方式。数据包的捕获方式很多，最常见的是所谓的协议分析仪。它是针对OSI模型2-7层设计的，能够在2-7层上进行解码，解释450多种网络协议，采用剥洋葱方式，从低层开始，一直到第七层，甚至对oracle 数据库、SYBASE数据库都可以进行协议分析。协议分析仪有硬件和软件相结合的专门产品，也有纯软件产品。数据包捕获，当然首选是专门的硬件分析仪。不过对于一般的网络，网络管理员凭借自己的技术、经验，借助专门数据包捕获软件实施网络排错已经足够。笔者通常使用的工具主要是Sniffer，此外微软的Microsoft Network Monitor也不错，而科来网络分析工具相对容易上手，其图形化的界面也比较形象。数据包捕获和分析，大家灵活掌握其中的一两款工具足矣。

　　2.数据包捕获的工作原理

　　理解数据包捕获的工作原理，对于管理员来说是非常必要的，下面笔者就其工作原理做一简述。我们知道，通常在同一个网段的所有网络接口都有访问在物理媒体上传输的所有数据的能力，而每个网络接口都还应该有一个硬件地址，该硬件地址不同于网络中存在的其他网络接口的硬件地址，同时，每个网络还有广播地址(代表所有的接口地址)。在正常情况下，一个合法的网络接口应该只响应这样的两种数据帧：帧的目标区域具有和本地网络接121相匹配的硬件地址以及帧的目标区域具有&广播地址&。

　　在接收到上面两种情况的数据包时，网卡通过CPU产生一个硬件中断。该中断能引起操作系统注意，然后将帧中所包含的数据传送给系统进一步处理。而Sniffer就是一种能将本地网卡状态设成混杂(Promiscuous)模式状态的工具软件，当网卡处于这种&混杂&方式时，该网卡具备对遭遇到的每一个帧都产生一个硬件中断，以便提醒操作系统处理流经该物理媒体上的每一个报文包(绝大多数的网卡具备Promiscuous方式的能力)。

　　3.协议分析仪的功能

　　了解协议分析仪的主要功能，以便管理员在特定情景中利用分析仪进行数据捕获和分析是非常有帮助的，笔者也做一概括。(1).分析从硬件分析仪中捕捉的数据包，具有完整的七层包捕捉、过滤和解码能力。(2).实时监测网络利用率和误码率、帧大小分布、协议分布、最多发送者/接收者、对话矩阵、VLAN流量分析、应用程序响应时间分析等。(3).智能专家故障分析、诊断功能在监测实时流量时自动发现错误、快速指出问题所在并给出修改建议。(4).支持本地和远程网络分析。(5)支持特殊的协议：Extreme EDP、ESRP以及Cisco CDP和VTP等。(6).停止并保存捕捉会话、发送一个SNMP陷阱、发送Email或寻呼通知等。(7).在日志文件中保存告警消息、启动一个应用程序和过滤等。(8).协议分析仪上的功能延展就是加入网管功能、自动网络信息搜集功能等。

　　4.数据包分析排除网络故障案例

　　通过上面的介绍，大家对网络分析仪捕获数据的方式，以及其工作原理功能有了足够的了解。下面笔者列举三个案例，再现用数据包分析排除网络故障的过程。

　　案例一：交换机端口锁死

　　(1).故障现象

　　交换机的某一端13联接了一个HUB，HUB上面有DNS及web服务器。在没有任何征兆的情况下，交换机的这一端口突然出现故障，端口上的所有设备不能联网。

　　(2).故障检查

　　①换交换机另一个好的端口，约几分钟后重复上述故障。

　　②怀疑连接交换机的HUB有物理故障，换了一个好的以后，过一段时间后故障仍然存在，可以确定不是HUB故障引起的。

　　， ③关掉交换机电源，重新加电后，原来出故障的端口恢复正常，但过一段时间后故障再次出现。由此判断端口故障很可能是因某种原因锁死，并非烧坏。依此，初步判断故障是由DNS或WEB服务器的硬件或软件异常引起的。

　　④使用Sniffer协议分析仪接入该网段，测试后发现，DNS通过HUB接入一个好的交换机端口后，很快产生了几个广播风暴，之后交换机的端口就锁死。广播风暴是造成交换机端121锁死的直接原因。

#p#副标题#e#

　　⑤通过解读捕捉到的数据包内容，可以看到，广播风暴产生的原因，是本地DNS(主)服务器，与一台远程DNS(从)服务器之间产生了大量通信，通信内容是远程DNS服务器向本地DNS服务器查询一个主机的名字解析，而本地DNS服务器没有设置该主机所在域的DNS服务器地址，从而造成异常的通信过程。

　　⑥从协议分析仪还可以看出，在1秒钟内，2台DNS之间有1155个这样的包来回.这种数据包产生了一个广播风暴，造成了交换机端口锁死。

　　(3).故障排除

　　将http://www.*.net/(基于保密用*代替)所在域的DNS服务器的地址定义在本地DNS上，故障排除。

　　(4).排错总结

　　在这个例子中，远程DNS向本地DNS查询http://www.*.net/的地址解释，本地DNS答复找不到以后，理论上远程DNS不应再发出查询请示，但由于软件BUG的问题，造成了DNS系统异常，产生了一个广播风暴，使交换机出现了故障。

　　案例二：广域网传输极慢

　　(1).故障现象

　　在DDN线路上，正常情况下Ping一个远端的IP，回包时间从三十几毫秒到几百毫秒。有一

　　次回包时间达到3000～5000毫秒之间，远程访问速度极慢。

　　(2).故障检查

　　按笔者的经验，这种情况是由于DDN线路有大文件在传输的缘故。将Sniffer协议分析仪接入广域口，可以看到上行带宽被占用了50%，下行带宽被占用了近100%。再分析捕捉到的包内容，发现大部分的包的交换是在地址192.128.96.23和192.3.54.133之间进行，协议主要是HTTP。从一台Pc浏览192.3.54.133，发现是一个个人网站，上面有大量游戏程序，192.128.96.23用户正是使用了NetAnts在该网页上下载大量的游戏程序，造成了线路堵塞。

　　(3).故障排除

　　在路由器上用访问控制列表将该个人游戏网站过滤，禁止任何用户通过路由器对该网站进行HTTP访问，通信恢复正常。

　　案例三：局域网广播风暴故障

　　(1).故障现象

　　局域网任意两台主机之间互相PING时，掉包非常严重，访问各种服务器非常缓慢。

　　(2).故障检查

　　①查看局域网中心交换机的CPU使用率，竞高达99%(平时<10%)，说明其负载非常重。

　　②将Sniffer接入网络中，发现平均的带宽利用率达20%(平时<5%)，说明网络的的数据流量非常大。

　　③什么原因造成了如此巨大的流量?通过Sniffer捕捉数据包分析，可以明显看到有一台主机发出大量的IPX的数据包每秒大约1000个包，这显然是不正常的。

　　④该主机为何会发出IPX数据包呢?对数据包的详细解码发现，该主机发出的都是SMB(ServerMessageBlock)协议的数据包，数据包的源地址和目的地址都相同，且为IPX地址，数据包的内容是不断地向网络宣告该计算机名(HGF)。SMB协议用于实现局域网中计算机之间文档、打印设备和其他计算机资源的共享，它可以用在TCP/IP协议之上，也可以用在IPX和NetBEUI之上。在SMB协议中，计算机为了访问网络资源，就需要了解网络上存在的资源列表，这个机制称为浏览，维护网络中当前资源列表的任务由网络上的几个特殊计算机完成的，这些计算机被称为Browser。SMB协议的Browser通过广播方式了解当前的网络资源情况。由此判断，该主机可能有基于IPX协议的一些应用，且被当作Browser。

　　⑤查找到主机，发现只是一台用于办公，没有任何复杂的应用和程序。但在网络协议处发现安装了&IPX/SPX/NetBIOS兼容传输协议&，该协议的错误配置使得主机被当作SMB协议中的Browser，并不断向外发出大量的广播包，导致整个局域网的拥塞。

　　(3).故障排除

　　卸载该主机的&IPX/SPX/NetBIOS兼容传输协议&，经20多分钟后(广播包在网络中会存在一定时间)，局域网恢复正常。

　　多掌握一种工具，在网络排错中就会多一种选择。基于网络分析工具，通过网络抓包，网络协议分析的方法进行排错的无疑是非常有效的，而且非常高效，这是其它传统的技术方法所无法比拟的。希望网络运维的同仁们能够尽快掌握这种方法，但愿本文能够帮助到你。

关键词标签：网络排错

文章评论

查看所有0条评论>>