网管员掌握丢包排错 两例网络丢包排错案例
网络排错-网络安全-运维真实案例-公司大厦局域网网速慢排查手册
网络异常流量排查方法故障现象：2015.2.2—2.6连续4天，XXX大厦网络延时高，且有丢包现象。
从核心交换机z8905上ping 直连路由器接口地址丢包，如图：图中的点即为丢包。
正常情况下，XXX大厦网络为（从电脑pingDNS服务器）：联系广域网回复说从路由器往上ping石油网正常。
排查过程：一、在电脑使用tracert命令查看哪条路由延时高：二、查看网络出口情况：查看z8905的端口Gei_1/3端口利用率以及有无CRC错包：结论：网络出口正常。
三、查看核心交换机直连路由器链路情况：1、示意图为：z8905（端口G1/3）——H3C（端口G8/0），更换连接网线后，问题依旧。
2、在z8905上使用show vct int Gei_1/3查看线路质量，显示网线质量很好，如图：结论：核心交换机上联直连路由器网线正常。
四、查看核心交换机至用户链路情况：排查下行链路：从电脑ping网关（网关在接入交换机上）正常，从网关ping核心交换机正常。
结论：局域网链路正常。
四、查看局域网用户情况：1、在z8905的端口Gei1/3上做端口镜像（源），在z8905的端口Gei5/48上做端口镜像（目的），在电脑上安装wireshark，将电脑连接z8905的端口Gei5/48，同时ping路由器172.16.127.194，延时高时，进行抓包。
配置为：int gei_1/3monitor session 1 sourceint gei_5/48sw ac vl 801no shutmonitor session 1 destination查看是否配置成功：2、分析抓包：点击source进行排序，发现这一段包里面一大半都是源地址为172.16.120.17的会话，172.16.120.17的TCP window 都特别小只有60多个字节。
正常的回话都是比较大的。
大量低于64字节的包不是太正常。
有可能是那个地址造成的，大量60字节的包占用了很多tcp连接资源，60字节是空包了，没有数据信息。
PING大包丢包网络故障分析案例、解决方案
PING大包丢包故障分析
1.1. 故障描述
1. 故障环境
网络结构如下图所示：
如上图所示，两边网络通过光纤相连，中间设备只有光电转换器，到单位B的内部网络有一台防火墙
2. 故障描述
单位B在进行网络测试时，在单位B的出口路由器处PING单位A的出口路由器时，PING大包会出现丢包现象，但是PING小包正常。
1.2. 故障分析
1. 分析方法
主要通过专有的网络分析工具（科来网络分析系统）将故障时相应的数据包捕获下来进行深度分析，并通过分析发现相应的异常，从而定位故障原因的方法。
2. 部署科来网络分析系统
我们在单位B的光电转换器和路由器之间串连一个交换机，利用交换机的端口镜像功能，镜像两个端口的流量，并将科来网络分析系统部署在交换机的镜像口，如下图所示：
3. 分析数据包
通过故障重现，即在路由器接口处进行PING测试，并同时捕获数据包，得到的数据包如下图所示：
如上图所示，我们在使用大包PING对端时，对端返回了一个超时的数据包，查看它具体的数据包解码，如下图：
造成该故障的原因是因为，我们在网络中传输大包时，由于网络中“最大传输单元”的限制，大数据包会发生分片，当分片数据包都到达目的端时会发生重组，一旦有一个分片丢失就会造成数据报重组超时，所以会发送超时的差错提示。
4. 分析结论
我们在进行PING测试时，数据包只经过了光电转换器和中间链路，所以造成该故障的原因就是光电转换器或中间链路丢包造成的。
1.3. 总结
当我们在分析数据包时，发现通信的数据包中有异常的数据包，那么我们就需要关注它是何种应用的数据包，通过分析异常的数据包可以帮助我们快速的找到故障原因，从而解决故障。
案例-某局PING网关丢包分析、解决方案
某局PING网关丢包分析某局的网管人员最近遇到了奇怪的事情，就是在PING网关的时候时常会出现严重的丢包，却始终无法找到丢包的原因，通过科来技术交流版抓包之后发给我看了一下，我来说一下分析的过程。
首先看到概要之中，发现平均包长只有88.76字节，远远小于正常时候的500-800字节，，再看大小包分布，1024以上的大包没有几个，但是64字节一下的数据包占了将近一半，明显是不正常的，通常小包多的情况，都会伴随有病毒或者攻击的出现。
再来看地址：物理地址数188个，IP地址数69080！差了好几百倍！本地的IP地址数居然有35000多个，实际上该局的主机不超过200台，怎么算都对不上。
如此多的地址，那么很有可能是分布式的方式。
再往下看，找到大概的原因了：TCP同步发送高达28161次，但是同步确认发送只有可怜的668个，难道是有蠕虫！我们可以进一步进行分析。
DNS查询也高达864次，却没有回应。
打开安全分析界面，来初步确定TCP同步发送的源头在哪儿。
发现了172.16.20.3、21.7、21.224、22.217、22.220、22.71、22.218这几台疑似中了蠕虫病毒，再回到全面分析内，进行取证。
拿20.3来进行观察：发现了，20.3在不停地使用随机端口对各主机的445端口进行TCP SYN包的发送，每次都只有发送2个数据包，没有回应。
这也就导致了大量的TCP SYN包和大量的IP地址的出现。
通过对数据包的解码发现，基本上所有的数据包都是有同步位的数据包。
由此证明，该机中了蠕虫病毒，需要及时查杀。
类似的，在其他几台主机上也发现了蠕虫病毒。
这些蠕虫病毒大量的发包，导致了网络的拥塞，使得用户体验就是网速很慢，表现出来的症状就是PING网关大量丢包。
经过查杀病毒之后，丢包现象没有再出现。
然后我们来查看DNS的查询的异常。
将协议定位到DNS上，我们再来查看数据包：发现172.16.21.15一直在查询的主机，怀疑是中了木马，需要到本机上进行进一步的查杀工作。
PING大包丢包网络故障分析案例解决方案
PING大包丢包网络故障分析案例解决方案网络故障是在使用网络过程中经常会出现的问题，其中大包丢包是一种常见的网络故障。
大包丢包指的是在网络传输过程中，发生了传输较大包的数据丢失的情况。
接下来我将进行一个关于大包丢包的网络故障分析案例，并提供相应的解决方案。
案例分析：公司A部门反馈在办公网络中使用视频会议时，经常出现画面卡顿和断流的问题。
在进行网络故障排查的过程中，发现了存在大包丢包的情况。
问题分析：大包丢包会导致网络传输不稳定，影响视频会议等带宽需求较高的应用。
造成大包丢包的原因主要有以下几点：1.网络拥塞：当网络带宽使用过高时，可能会造成网络拥塞，从而引发大包丢包问题。
2.路由器配置错误：路由器可能会存在配置错误，导致无法正确转发大包数据，从而引发大包丢包问题。
3.网络设备故障：路由器、交换机等网络设备可能存在故障，导致无法有效处理网络数据，从而引发大包丢包问题。
解决方案：针对以上问题，可以采取以下解决方案：1.网络监控与优化：通过网络监控工具对网络流量进行实时监控，及时发现网络拥塞问题。
在网络拥塞时，可以考虑对网络带宽进行扩容，以保证网络的稳定性。
2.检查路由器配置：对路由器进行检查，确保其配置正确。
可以参考厂商提供的配置文档，根据网络需求合理设置路由器参数。
同时，也可以考虑升级路由器固件，以确保设备的正常工作。
3.检查网络设备故障：定期对网络设备进行巡检，发现故障及时进行修复或更换。
例如，使用专业的网络测试工具对路由器、交换机等设备进行故障检测，确保其正常运行。
4.优化网络拓扑：对网络拓扑结构进行优化，确保网络中的数据传输路径短且流畅。
通过优化网络拓扑，可以减少数据传输的时延，从而降低大包丢包的发生概率。
5.加强网络安全：网络安全问题也可能导致大包丢包问题。
加强网络安全措施，防范网络攻击与入侵。
例如，使用防火墙、入侵检测系统等安全设备，对网络数据进行过滤和监测。
总结：大包丢包是一种常见的网络故障，可能会对网络传输稳定性产生严重影响。
网络丢包现象分析与解决方案
网络丢包现象分析与解决方案作者：张武帅,王东飞来源：《电脑知识与技术》2011年第25期摘要：网络丢包是局域网中经常见到的故障之一，它会引起网速甚至造成网络中断，本文对造成网络丢包现象的原因进行了分析和探讨，并就几种常见的故障现象提供了相应的解决方案。
关键词：局域网；网络丢包；解决方案中图分类号：TP393文献标识码：A文章编号：1009-3044(2011)25-6127-02Network Lost Package Phenomenon Analysis and SolutionZHANG Wu-shuai, WANG Dong-fei(The Chinese people's liberation army of 95949 troops, Cangzhou 061736, China)Abstract: Network lost package is often seen in the local area network fault, it can cause a slow speeds and even damage network interruption. In this paper, the cause of the phenomenon of the network lost package were analyzed and discussed, and some common trouble to provide the corresponding solution.Key words: LAN; network lost package; solutions在我们对局域网进行管理的过程中，经常会碰到网络传输不畅而导致上网时断时续，或者网速非常缓慢，出现这种现象很多情况下都是由于网络丢包引起的，网络丢包是指数据包由于各种原因在信道中发生丢失的现象。
1 引起网络丢包的原因1.1 线路出现故障当网管员发现网络传输时常中断时，要考虑两种情况，第一种是线路出现了故障，第二种情况是用户设置方面的原因。
医院局域网丢包实例解析
故障 的再次 发生或能即时有效地处理此类故障
１ 网 络 丢 包 的 定 义
当 网 络 中发 生 故 障 时 ．我们 经 常 使 用 的 用 于 检 查
一
了． 这种故障一般容易发现和解决 。 另一种情况就不太
好 解 决 了 ． 际工 作 中 ． 们 经 常会 碰 到 八根 网 线 中有 实 我 根 通 过 测 线 器 测 下来 没 有 信 号 ．于 是 就 在 连 接 电脑
２２ 网线过 长或 网线 质 量 影 响 网络 性 能 ．
一
般而言 ． 五类以上网线 质量有保 障 ， 传输距 离能
达到 １０ ． ０ 米 如果采用 劣质杂牌 网线 ． 信号 传输 会衰减 很厉 害 ， 的在六 十米左右信号 就不稳定 。 有 当然 ． 如果 用 了好的 网线 ．终端 到交换 机的距 离最好 也不要超过 １０米川 ０ 。我院一礼堂就 出现过 因距离太长而发生信号
络 管 理人 员 的 一 大 挑 战 ． 网管 人 员应 当具 备 处理 这 种 网络 丢 包故 障 的 能 力 列 举 工 作 中遇
到 的 几 种 丢 包案 例 ． 结 出故 障 解 决 的 经 验 与 心 得 ． 望 能 够提 高 大 家 的分 析 能 力 和 解 决 总 希
此 类 网 络 故 障 的 能 力
网卡那头 ．将没信号 的那根 与闲置有信 号的某根对调
一
下 ，我们都知道实 际数据信息 只用 了其 中的 １２和 、
３ ６两 对 线 ， 时 ， 忘 了 ， 入交 换 机 的那 头 也 要 同样 、 这 别 插
对调一下线序才能 正常连 网 ． 可以将交换机那 头 ． 也 和 墙 上的模块两头对调 。当然 ，最好是从交换机 到配线 架 ， 到墙上 的模 块和 到终 端 电脑 的跳线 ， 再 逐一排查 ．
核心网链路丢包引起通话质量差处理案例
核心网链路丢包引起通话质量差问题的分析和处理案例摘要：2月11日，天长市许多用户向当地局方工作人员反映使用c网手机时无论主被叫语音质量均较差，排查完无线侧设备故障后，发现问题基站均归属同一BHS，最终与核心网工程师配合将问题定位在核心网链路丢包引起的，及时处理后改善了用户使用感知关键字：CDMA BPH 丢包误码 call shutdown 47 语音质量差【故障现象】：2月11日，天长区域内许多用户向当地局方工作人员反映使用c网手机时无论主被叫语音质量均较差，通话时收听到对方的声音总是断断续续的；【告警信息】：通过OMP网管查看用户申告较多的县城及铜城等地基站，未发现任何告警信息；【原因分析】：1、网管指标性能分析：当天障碍现象表征最明显的基站是RCS565天长中行基站，该站覆盖范围较广，话务量较高，障碍出现当天该站2扇区出现了分集告警，底噪输出值较高，如下图：底噪抬升除与天馈系统内部隐性故障相关以外与外部干扰的影响关联性也很大，因天长中行基站下问题现象较严重，网优人员在确认底噪异常告警后立即前往天长县城处理天长中行2扇区底噪异常问题，并排查外部干扰源；由于天长电信局位于天长中行1扇区覆盖范围内，处理问题初期，我们曾将1扇区CBR板件关闭，1扇区CBR板件关闭后，现场进行拨打测试，通话效果有一定改善，所以造成了一种属于单站硬件干扰引起的假象；上图标记处即为天长市电信局位置然而在1扇区关闭后查看网管内基站其他两个扇区的话统指标发现，掉话次数也非常高，而且越来越多的地方有用户反映同样的障碍情况，所以问题并不只是因为1个扇区的影响而产生的，需要针对高掉话次数的具体掉话类型进行分析；首先查看了RCS565基站的当天ROP信息，发现一种call shutdown类型为47的系统掉话所占比例较大，数据与语音相加合计有81次，具体ASSERT CODE说明有两种21590和21740；使用OMP网管内的ropsearch.sct脚本搜索11号当天出现过call shutdown 47类型的所有基站信息及之前一天记录以确定影响范围及具体开始出现的时间，分析输出发现存在以下问题：1）2月10日全天ROP内无该类型系统掉话出现，2月11日首次出现，且最早一次产生于凌晨3时15分，出现扇区为来安半塔基站2扇区；2）除天长市区中行基站外，有用户申告反映的天长汊涧、铜城等基站也有较多次数的call shutdown47产生，也说明了出现语音质量问题的区域和这种新出现的掉话类型是有一定关联的；3）问题基站空间位置上是零散的，所以产生同样的系统掉话类型且反复出现的原因说明他们在网络结构内部存在一定的逻辑相关性，或者从属于同一个网元，AP、SM等；4）出现call shutdown47的基站全部是来安县、天长市基站，其它县、市均未发现，出现频率与基站话务量相关，问题最严重基站就是天长中行基站，而来安县并未有大面积使用感知恶化情况申告；callshutdown47汇总.xlsx至此无线侧原因已基本排除，需进一步弄清call shutdown47的具体解释及产生原因和所有问题基站的关联性；2、核心侧问题分析：在确认问题可能与核心侧设备相关后第一时间联系了本地网网络操作维护中心维护C 网核心网的工作人员，确认2月11日当天核心侧设备是否出现新增告警信息等，并进一步确定问题基站内部联系；在查看数据库信息发现来安、天长基站同时归属于同一SM下,与其他各县不同，SM即为交换模块，它的作用有以下几点：基站的SM归属是根据区域来进行划分的，并在基站的cell2表里配置对应的BHS信息，实现基站和SM及BPH对应关系，来安、天长所归属的SM2下总共下挂了129个基站，出现call shutdown47告警的基站总共有34个，故判断问题可能来自于SM2内部，SM的内部网元结构如下：语音呼叫占用的MGW资源查看565基站的BHS配置，其BHS归属为2-0-2：继续查看铜城、汊涧基站BHS配置，发现也是2-0-2，使用DBsurvey命令取出了所有基站的BHS配置，并查询出有问题的34个基站的BHS配置，发现均为2-0-2，而SM2的2-0-2总共映射了35个基站，其中有34个存在异常，（唯一未出现异常的RCS925翁家集基站属省际边界基站，话务量偏低），所以更加怀疑是SM2内部隐性故障引起此次障碍；此时从核心侧得到反馈结果，C网核心网维护人员查看了MGW网管，网管无告警且没有相应历史告警记录，然后查看了7750设备，也未发现任何告警信息，将问题基站归属于同一BHS问题告知其，并请核心网工程师对SM2及2-0-2对应的BPH进行性能观察和分析；核心网工程师通过7750设备长ping对应2-0-2的BPH板卡的ip地址；发现对应0-09板卡ping时存在严重丢包问题，丢包率为9%，而1-02则正常无丢包问题，至此可以确定因SM2下挂2-0-2的BPH板卡至7750链路丢包导致其映射基站下用户出现通话感知较差、掉话等问题；【解决方法】：现网MGW的SM配置，有两个BPH服务器互为主备用，一块PHV处理器，每个SM间通过CM进行通信，并且可以进行一定资源的共享，而此次问题已确定为BPH板件至7750链路丢包引起的通话异常，为更明确问题诱因，决定将BPH服务器的主备用倒换，倒换完毕后如果现场测试使用正常，ROP里该类型系统掉话消失，则问题明确；BPH服务器之间的倒换是无缝倒换的，倒换期间并不影响业务使用，有两种倒换方式：自动倒换和人工倒换，自动倒换每天凌晨自动操作一次；在将BPH服务器人工倒换完毕后，联系现场天长局方人员进行拨打测试，无异常，使用ropsearch脚本搜索call shutdown 47，倒换完毕1小时内均为出现，观察stone表指标问题较严重的天长中行等基站指标均恢复问题；确认障碍现象恢复正常后，核心网工程师前往核心网主设备机房对原长ping存在丢包的0-09板卡与7750设备间各段连接线进行检查处理，发现一处接头网线存在一定松动，插紧检查完毕确认无告警后，重新从7750设备对该板卡进行长ping，无丢包；2月13日SM2的2-0-2BPH对应的两个服务器自动倒换后观察指标，类似异常未再出现，call shutdown 类型为47的系统掉话也没有出现，由此看出，此次天长、来安语音通话质量差、掉话问题主要是因为BPH与7750设备间一条链路丢包引起的；【经验教训或建议与总结】：1、CDMA网络的无线侧设备与核心侧网元是一个整体，无线侧问题往往只影响部分特定区域用户，而核心网的隐性故障可能影响大范围的用户使用；2、网络问题的发现往往从一个点发展到一个面的，针对大范围区域出现的问题，需排查本身设备侧问题及外部干扰问题外及时与核心网工程师配合排查核心侧隐性故障，提高问题处理效率和及时性；3、朗讯设备的掉话类型主要有两大类：lost call和call shutdown，系统侧掉话call shutdown类型较多，在系统统计到大量同一类型call shutdown掉话时，往往也表征着网络的某一环节存在着较大疏漏，在分析突发性大范围用户障碍时，及时通过ROP找到对应新增的call shutdown 类型，有助于更及时找到问题的“疑点”和“共性”；。
网络丢包经典分析案例
网络丢包，请离我远去1 网络丢包-烦恼网络是多种设备的集合体，一个较为完善的网络除去网络终端大量的客户机以外，有众多的设备穿插集中，包括二层交换机、三层交换机、DSLAM、BAS、路由器、服务器、存储设备等。
而涉及到的网络协议、技术更为繁杂，要维护这么庞大以及技术复杂的网络，很多时候是雾里看花，总是看不清楚问题的实质，尤其是网络丢包问题，让多少网络专家为之彻夜难眠却又束手无策。
本案例汇集了经常遇到的网络丢包案例，希望这些小的案例能够为我们的日常网络维护提供一些启发。
2 网络丢包惨案-案例1某客户的服务器端局部网络连接图（图中略去了交换机上行连接设备）如下：两台服务器连在分别连接在S5100交换机的g1/0/3和g1/0/4端口。
服务器是第三方网管服务器,两台服务器之间有数据调用。
客户反馈访问网管服务器速度很慢，两台服务器之间ping大包时有大量丢包。
网络故障范围已经缩小至两台服务器之间的丢包，问题就变得比较简单，这种情况下，首先确认是故障点，那么我们看两台服务器PING报文的转发流程，总体上可以分为三部分：有两部分是服务器与交换机之间的转发、另外一部分是交换机之间的数据转发。
那么要排除该问题我们采取逐段分析排查的方法：1：首先在两台交换机之间互相Ping各自的管理IP地址，测验结果为不丢包，因此这两台交换机之间的问题可以排除在外；2：排查服务器与交换机之间问题：这部分的问题又可以细分为三个点：服务器、网线、交换机端口。
而这三个点的排查难度是由难到易，因此我们先排查交换机端口的问题；3：首先更换左端服务器与交换机连接的端口，更换后，丢包问题依然存在，可以排除左端交换机端口的问题，用同样的办法测试右端服务器与交换机端口，依然可以排除交换机端口的问题；4：那么接下来排查网线的问题，如果是线路的问题，那么在交换机的端口一定会产生大量的CRC错误，那么首先登录到左边交换机上查看端口G1/0/3的状态，没有发现有CRC错误，然后等到右边交换机上查看端口G1/0/4的状态，发现端口有大量CRC错误，而且CRC错误包的数量还在增长，因此初步怀疑该接口下的网线有问题，于是更换一条生产发货的网线更换后，丢包问题解决。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
远程商业窃密引发丢包
中天设计院是甘肃省建设厅直属单位，网络规模不大。
152台主机根据单位职能部门分为5个子网，分别由Hub连接到交换机。
由于公司内部的协同办公比较频繁，除了一个在线视频系统外还部署了一台文件服务器，单独为一个子网提供数据的共享和交流。
单位对外的Internet需求不是很大，通过路由器连接到Internet，网络拓扑见图1。
故障现象
某天，该单位的网络突然出现严重堵塞，主机间的数据频频中断导致协同办公不能正常进行，在线视频系统经常掉线。
另外，无论是从文件服务器上传还是下载文件都异常缓慢，有时会因超时而中断。
主机能够连接到Internet，但是网速缓慢。
初步判断
首先在一台主机上用ping命令测试到网关的连通性，输入命令“ping 192．168．2．1 -n 1000”发送1000个Ping包测试网关。
测试结果是可以ping通网关，但是掉包现象很严重：1000个包有720个包丢了，丢包率为72%，持续掉包时间也很长。
运行arp -a命令，发现网关IP和网关MAC地址指向正确。
通过上面的测试基本排除网络设置错误以及ARP欺骗。
监控分析
于是在核心交换机上做镜像，用Sniffer对整个内网（五个子网）进行监控。
首先进入“dashboard”（仪表面板），发现网络利用率达到了97%，这是很不正常的现象。
笔者判断以该单位的网络规模以及日常业务量，网络利用率应该在20%~30%之间，有较大的网络冗余。
这样我们可以断定，造成网络丢包的根源应该是异常流量占用大量的网络带宽所致。
那这些异常流量来自何处呢？
切换到“matrix”（矩阵面板），发现MAC为00-0A-E6-98-84-B7的主机占了整个网络流量的57．87%。
于是初步把目标锁定在该主机上，然后切换到“hosttable”（主机列表）继续分析。
从该面板中，没有发现大量的广播包，因此完全排除了广播风暴影响。
找到00-0A-E6-98-84-B7，对此主机分析，发现该主机的网络活动非常可疑，进入该主机的数据包才700多个，而出去的数据包在10多分钟内就有了几十万个包。
故障解决为了确认上述主机在进行什么网络活动，笔者在交换机上对它单独抓包分析。
对数据包解码后发现，该主机通过UDP协议项向外网的一个IP为60．164．82．185主机进行数据拷贝。
这个IP怎么这么眼熟，这不是本地的一个IP吗？另外，还发现该主机与文件服务器的连接也十分频繁。
笔者根据网段和MAC地址，在交换机上对该主机隔离，断开其网络连接，整个网络马上就恢复了正常，丢包故障排除。
至此，我们通过层层排错找到了造成这次网络丢包的原因——该主机被黑客植了木马，然后远程控制通过8888端口向远程拷贝文件。
另外，该主机正在从文件服务器上下载大量文件，估计攻击者正在通过该主机窃取文件夹服务器上的资料。
该主机本来安装了杀毒软件，但不报毒应该是攻击者做了免杀处理。
手工清除木马，将该主机连接到网络，网络丢包再也没有发生。
事后机主回忆可能是中了移动硬盘中的木马，因为当天他曾经将工程规划书拷贝到客户的移动硬盘中。
丢包排错中引出商业窃密这是大家都没有想到的。
循环自动扫描攻击引起丢包
笔者所在地某中学的局域网约有电脑1000台，通常情况下同时在线的有600台左右，网络一直很稳定。
期末放假前网络出现异常，具体症状为：整个校园网突然出现网络通信中断，内部用户均不能正常访问互联网。
在机房中进行ping包测试时发现，中心机房客户机对中心交换机管理地址的ping包响应时间较长且出现随机性丢包，主机房客户机对二级交换机的通信丢包情况更加严重。
深入分析
笔者初步判断这种现象可能是交换机ARP表更新问题、广播或路由环路故障、病毒攻击等引起的。
为此，需要进一步获取ARP信息、交换机负载、网络中传输的原始数据包等信息。
配置抓包。
在中心交换机上做好端口镜像配置操作，并将分析用笔记本电脑接到此端口上，启动网络分析工具捕获分析网络的数据通信，约10分钟后停止捕获并分析捕获到的数据包。
查看连接，定位攻击源。
在停止捕获后，笔者在网络分析系统主界面左边的节点浏览器中发现，内部网络同时在线的IP主机达到了6515台，这表示网络存在许多伪造的IP主机，网络中可能存在伪造IP地址攻击或自动扫描攻击。
选择连接视图，发现在10分钟内，网络中共发起了12108个连接，且状态大多都是客户端请求同步。
据此，我们断定校园网中存在自动扫描攻击。
详细查看连接信息，发现这些连接大多都是由192．168．5．119主机发起，即连接的源地址是192．168．5．119。
选中源地址是192．168．5．119的任意一个连接，单击鼠标右键，在弹出的右键菜单中选择“定位浏览器节点→端点1 IP”，这时节点浏览器将自动定位到192．168．5．119主机。
通过协议，确定攻击方式。
选择数据包视图查看192．168．5．119传输数据的原始解码信息，我们发现192．168．5．119这台机器正在主动对网络中主机的TCP 445端口进行扫描攻击，原因可能是192．168．5．119主机感染病毒程序，或者是人为使用扫描软件进行攻击。
通过分析图表视图，进一步确定192．168．5．119主机肯定存在自动扫描攻击。
找到问题的根源后，对192．168．5．119主机进行隔离，经过一段时间的测试，网络丢包现象有所缓解，但没有从根本上解决问题。
难道，还有漏网之鱼仍在兴风作浪？于是再次启动网络分析系统捕获并分析网络的数据通信，在网络中又发现了3台与192．168．5．119相似情况的主机。
通过这个情况，我们可以肯定192．168．5．119和新发现的三台主机都是感染了病毒，且该病毒会主动扫描网络中其他主机是否打开TCP 445端口，如果某主机打开该端口，就攻击并感染这台主机。
如此循环，即引发了上述的网络故障。
解除故障
立即对新发现感染病毒的3台主机进行隔离，网络通信立刻恢复正常。
另外，在分析中笔者还发现，192．168．101．57主机占用的流量较大，其通信数据包的源端和目的端都使用UDP 6020端口，且与192.168.101.57通信的地址227.1.2.7是一个组播IP地址。
鉴于此，我们推测192．168．101．57可能在使用在线视频点播之类的应用，因此耗费了网络资源。
定位到该主机原来是学校机房的一台服务器被配置成了一个在线视频服务器为客户端提供视频服务，而该主机正在用P2P软件下载视频——难怪会有这么大的流量。
其实引起网络丢包的原因有很多，除了上述网络攻击和病毒感染之外，连接线路、网卡、交换机、路由器等硬件故障也会造成网络的延迟、丢包。
因此，网络管理人员掌握丢包排错方法是非常重要的。
授人以鱼不如授人以渔，希望上述网络丢包排故障思路对大家有所帮助。