网管员掌握丢包排错 两例网络丢包排错案例
网络排错-网络安全-运维真实案例-公司大厦局域网网速慢排查手册
网络异常流量排查方法故障现象：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.周二收到用户反应住院部二楼汇聚下的几个网段，HIS应用慢，到达现场，测试网络发现不规则丢包，过一会时间后，发现没有出现掉包，HIS应用速度正常。
出现这种间歇性的故障，查看交换机配置和日志，没有发现错误，可以确定配置和交换机是正常的，和医院孙工商量决定做替换测试，由于模块没有备用，先准备替换跳线，替换跳线后，观察了一天网络工作正常。
2.周四下午又接到用户反向网络又出现掉包，而且用户说他已经把万兆模块调换过，这时远程发现核心的万兆模块发现很多INPUT错误。
咨询H3C工程师，说这个很大的可能性为光传输的问题（即光纤的问题），我问为什么不是模块的问题了，他给了我二条命令来判断光模块的问题。
首先使用：display transceiver interface gigabitethernet 1/1/3GigabitEthernet1/1/3 transceiver information:Transceiver Type : 1000_BASE_LX_SFPConnector Type : LCWavelength(nm) : 1310Transfer Distance(km) : 10(9um)Digital Diagnostic Monitoring : YESVendor Name : H3COrdering Name : SFP-GE-LX10-SM1310获取SFP模块的型号：SFP-GE-LX10-SM1310可以致电H3C，查询该模块的光功率，因为每个模块的光功率都不是一定的，在这里就不提供该值得范围。
然后使用这条命令来获取现在工作模块的光功率：display transceiver diagnosis interface gigabitethernet 1/1/2GigabitEthernet1/1/2 transceiver diagnostic information:Current diagnostic parameters:Temp(°C) Voltage(V) Bias(mA) RX power(dBM) TX power(dBM)36 3.31 6.13 -35.64 -5.19#上面的信息是我从网上获取，由于现场我忘记截图，上面的只是演示。
丢包排错(环路)
许多时候，我们可能都会碰到网络连接时断时续的故障现象，面对这种网络故障，不少网络管理员都会使用Ping命令对网络连通性进行测试，测试结果表明此时的网络传输线路数据丢包现象非常严重，那么究竟是什么因素导致了数据丢包现象比较严重呢？是连接线路接触不稳定？是网络病毒？还是其他的潜在因素？仔细对这类现象进行总结后，我们发现最容易造成数据丢包现象的因素就是网络环路，毕竟在规模稍微大一点的局域网环境中，网络管理员很容易把交换机之间的端口连接错误，从而引起网络环路现象，并且这种现象由于有比较强的隐蔽性，我们在排除这类故障的时候要是不留神的话很容易多走弯路！故障现象局域网网络使用的拓扑结构是星型百兆以太网结构，局域网主机房中使用了一台Cisco 三层路由交换机作为网络的核心交换机，单位五层大楼中的每个楼层都组建了子网段，每个网段中的所有工作站都使用D-Link品牌的普通交换机作为集线设备，并且各个楼层中的普通交换机通过双绞线缆直接接入主机房中的核心交换机，并通过核心交换机直接访问Internet网络。
单位局域网中同时安装、配置了多台服务器，例如有保存单位重要数据信息的文件服务器，有对外提供Web访问服务的Web服务器，有提供重要资料下载的FTP服务器等。
平时单位各个子网段中的所有工作站都能正常访问Internet网络，每个子网段中的工作站之间也能互相访问。
可是有一天，某一子网段中的用户通过手机向反映情况说，他们所在的子网工作站访问Internet网络时，有时正常有时不正常，并且同一子网段中的工作站之间相互进行Ping测试时，发现数据丢包现象非常严重；原以为这种故障仅是极个别现象，可谁曾想到，没有多长时间，分布在多个网段中的许多用户接二连三地向反映情况，并且描述的故障现象基本相同。
连续的故障求援让再也坐不住了，立即动身来到其中一个楼层，对该网段中的工作站进行上网测试，在上网过程中发现网页打开速度有时非常缓慢，几分钟也打不开一个页面，有时速度很快，只要输入地址敲下回车键后，网页内容立即就显示出来了，并且这种现象反反复复。
网络丢包分析案例解决方案
网络丢包分析案例解决方案网络丢包是指在数据传输过程中，部分数据包未能正常到达目的地。
网络丢包可能导致数据传输速度变慢、网络连接中断以及影响用户体验等问题。
本文将针对网络丢包分析一个案例，并提出解决方案。
案例分析：假设一个中小型企业，拥有自己的局域网和接入互联网的路由器，由于最近网络丢包问题频发，导致员工在办公过程中遇到了困难。
为了解决这个问题，我们需要进行以下步骤：1.判断丢包情况：首先，需要确定是否存在网络丢包问题。
可以通过ping命令检测网络丢包率。
在命令提示符中输入ping目标IP，可以观察到ping的结果，如果出现丢包，则说明存在丢包问题。
2.排除硬件故障：网络丢包问题可能是由于硬件故障引起的。
首先，需要确保路由器和交换机没有故障。
可以尝试更换网络设备进行排错。
3.检查网络拓扑结构：网络拓扑结构可能导致丢包问题。
过多的中转、线路负载不均衡等都可能导致丢包。
需要检查路由器、交换机和服务器的连接情况，确保没有物理障碍。
4.调整MTU和MSS：最大传输单元（MTU）和最大报文段长度（MSS）是数据包大小的两个参数。
过大的MTU或MSS可能导致网络丢包。
可以通过调整这两个参数，减小数据包的大小，以提高网络稳定性。
5.网络流量管理：网络流量过大可能导致网络拥堵和丢包。
可以限制特定应用程序的带宽使用，或者调整路由器的流量控制策略，以减少网络拥堵和丢包。
6.升级网络设备固件：网络设备的固件可能存在漏洞，导致网络丢包。
可以升级网络设备的固件，以修复已知的漏洞，并提高网络性能。
解决方案：针对上述分析结果，我们提出以下解决方案：1.网络设备故障：更换或修复故障的网络设备，确保网络设备正常运行。
2.优化网络拓扑结构：根据实际情况重新设计网络拓扑结构，减少中转节点，确保网络连接稳定。
3.调整MTU和MSS：根据网络情况调整MTU和MSS的参数，保证数据包大小合适。
4.网络流量管理：使用流量管理工具进行网络流量监控和控制，合理分配网络带宽资源，减少网络拥堵。
网络排错与案例分享
法，使用各种排查方法的目的要将故障可能的原因所构成的一
个大集合缩减（或隔离）成几个小的子集，从而使问题的复杂 度迅速下降。通过上述几种方法，常见网络故障细化为四类： 用户终端问题（网络配置错误、网卡异常，系统异常，应用 程序工作异常等）
服务器问题（网络配置错误、网卡异常，系统异常等）
网络设备问题（硬件故障、网络设备软件故障、配置问题等） 外界因素（出口带宽、病毒攻击等）
定位网络问题的过程，实质上是不断提出问题的过 程(问客户或问自己)。
第31页
定位网络问题时如何提问？
定位网络问题时如何提问？
提问通常应以这样一个顺序进行：
谁出了问题？ 是什么问题？ 问题何时发生的？
何处发生的故障？
第32页
定位网络问题时如何提问？
谁出了问题？
是单个用户、一组存在共性的用户还是网络中的所 有用户？ 对于单个用户的问题，下一步提问可能应关注下列 方面：
分层排错思想
4
高 层
3
2
网络 层
数据链路层 负责链路层协议、物 理寻址等二层协议
主要关注：MAC地址、 STP状态、STP根桥、端口速率 、VLAN、Etherchannel配置 、封装、中继状态、接口类型 、端口安全等
1
物理 层
分层排错思想
4 3 2 1
高 层 网络 层 数据链路层 物理 层 负责ＩＰ地址寻址、 三层路由协议等
系统化排错思想 系统化排错思想综述
单体故障还是网络整体故障
分层排错
系统化排错思想综述
一个系统化的故障处理思路是合理地一步一步找出故障原因并解
决的总体原则，工程师应向自己提出下述问题：
目前处于什么状况？弄清故障处于什么状态是一个起码的要求。
利用丢包排错法解决网络故障
原 因一 ～该 主机被黑 客植了木马， 然后远 程控制通过 ８ ８ 端 口向远 程拷贝文件。 ８８ 该主机 原本安装了杀毒软 件， 但不报毒， 因是攻击者做了免 杀处理 。 过手工 原 通 清 除木马 ， 将该主机 连接 到网络， 网络 丢包再 也没有
发生。
Ｉ和网关Ｍ Ｃ Ｐ Ａ 地址指 向正确。 因此 ， 通过上面的测试基
恢 复正常， 丢包故障排 除。
至 此 ， 过 层 层 排 错 找 到 了造 成 这 次 网络 丢 包 的 通
二、 故障分析
首先在一台主机上用Ｐｎ命令测试网关的连通性 ， ｉｇ
输人命令 “ｉｇ１２ １８ ２ １一 ０ ０ ， 送１ ０ 个 ｐｎ ９ ． ６ ． ． ｎ１０ ” 发 ０ ０ Ｐｎ 包测试 网关 。 试结果 是可１ ｉｇ 网关 ， ｉｇ 测 ￣Ｐｎ 通 但是 掉包现象很严重 ： ０ 个包 有７ ０ 包丢， ｌ０ ０ ２个 丢包 率为 ７％， ２ 持续掉包时间也很长 。 运行ａｐ～命令， ｒ ａ 发现网关
处事不惊， 有条不紊地解决问题。 随着网络的迅速发展，
在今后的工作 中会出现更多的问题， 只有不断学习进步，
提高自己Ｈ ＮＡＮｃ
ｃ Ｍ ｏ ＵＴ ＥＲ
ｌ９ ６
交 换 机 上 对 该 主 机 隔 离 ， 开 其 网 络 连 接 ， 个 网络 断 整
某天， 该公司的网络 突然出现严重堵塞 ， 主机间的 数据频频中断导致协同办公不能正常进行， 在线视频系 统经常掉线 。 另外， 无论是从文件服务器上传 还是下载 文件都异常缓慢 ， 有时会 因超时而中断。 主机能够连接 ￣Ｉｔ ｎ ｔ但是 网速缓慢 。 １ｎ ｒｅ， ］ ｅ
本排除网络设置错误 以及Ａ Ｐ Ｒ 欺骗。
常见网络丢包故障分析及处理
常见网络丢包故障分析及处理我们在管理维护网络的过程中经常会遇到数据包丢失的现象。
使用Ping命令进行连通性测试，则会发现Ping包延时远远超过正常值，甚至无法到达，同时还伴随着网络服务应用障碍，如打开网站速度很慢，严重时甚至打不开网页，在线浏览视频或者召开视频会议时话音断断续续、图像马塞克、断线等。
网络丢包是网络中常见的故障之一，它会引起网速降低甚至造成网络中断，本文就在日常的网络管理工作中常见的几种丢包故障现象进行了分析和探讨并提出了处理方法。
网络丢包概述所谓网络丢包是我们在使用ping命令（检测某个系统能否正常运行）对目的站进行询问时，数据包由于各种原因在信道中丢失的现象。
Ping命令使用了ICMP回送请求与回送回答报文。
ICMP回送请求报文是主机或路由器向一个特定的目的主机发出的询问，收到此报文的机器必须给源主机发送ICMP 回送回答报文。
这种询问报文用来测试目的站是否可到达以及了解其状态。
需要指出的是，ping命令是直接使用网络层ICMP协议的一个例子，它没有通过运输层的UDP或TCP协议。
网络丢包常见故障分析及处理方法发生网络故障在所难免，但是如何快速隔离和排除故障是网络管理人员应该具备的基本素质。
以下列举几种常见的网络丢包故障现象及处理方法。
故障一：网络数据包发送时通时断，丢包严重故障现象：通常故障发生时，该方向网络出现震荡性中断。
使用Ping命令测试，发现在一段时间内数据包发送延时比正常值略高，间隔一小段时间数据包又全部丢失，丢包率超过60%，丢包曲线成规则状，网络服务基本不可用。
故障分析：在局域网中引起网络发生振荡性时断时通，一般可能是由于互连的交换机中的某两个交换机间出现了环路，或者某个交换机的两个端口直接相连。
这样就会造成局域网的生成树协议构建失败，不断重复检查并试图构建新的生成树网络，从而导致网络振荡性通断，同时伴随着交换机间不断重复地发送广播包，就会形成“广播风暴”，使交换机负担过重，网络传输通道严重被堵塞，无法正常的处理通信数据。
丢包排错(双工问题)
丢包排错丢包排错录两个IDC机房托管的服务器之间通信不畅，经查，两个机房间的丢包率在8%左右。
这样的丢包率很容易引起TCP连接失败，由于网络在线业务异常重要，不得有片刻的停机。
所以刻不容缓，马上处理丢包问题。
1．判断丢包发生在哪里从办公室的计算机分别ping 两个机房的服务器，然后ping网关，通过对输出进行比较，发现问题出在办公地点—望京的机房。
再用路由跟踪的方式测试，得出一样的结论。
2．现场排查检查网段类服务器之间，服务器与交换机之间，以及交换机之间的网络通信情况时，发ping 包，没有丢包，但从网内ping 外部任何地址，都有丢包现象出现，路由跟踪有时不成功。
这些情况可以表明网段内的通信是完全正常的。
接下来要做的事情就是测试网关的状态。
网关是一个Cisco 6509交换机，是网通自己管理，方的交换机通过一条双绞线与Cisco 6509相连，它是所有服务器的外联接口。
通过技术手段，已经知道上联交换机的上联端口是Fa0/41。
（1）从网段内的某些服务器ping网关，发现丢包。
（2）从外网的某台计算机ping 这个网关，没有丢包发生。
（3）从外网的某些计算机执行到这个网关的路由跟踪，情况正常。
（4）用外网远程的交换机ping小包，情况正常。
（5）从网段内的交换机ping小包，发现丢包。
由上面的测试结果可以得出结论：交换机与网通交换机（方服务器的网关）间的链路出现故障。
前几天扩容在机架上施工，有可能碰到了线缆。
于是查看交换机指示灯状态。
发现有一个端口指示灯黄绿交替闪烁，是某个交换机的41号端口，而且网线上标明这条线是整个网段的上联线，即与网关相连的那条线，和先前测试出来的端口是一致的。
可能问题就出现在这个交换机上。
于是连上Console线，登录这台交换机，用命令“# show int f0/41”查看41号端口的输出，居然变成半双工了。
再查看其他一些端口的双工情况，均是自适应，询问IDC 机房的人，确认网关那个连接端口的双工配置，网关的端口为全双工。
网络视频会议丢包问题的排查及解决分析方法
网络视频会议丢包问题的排查及解决分析方法【摘要】本文针对视频会议中遇到的最典型的丢包问题进行了具体分析，并结合实际案例提出了分级分层次的排查问题、解决的问题的方法。
【关键词】网络视频会议；丢包；排查在视频会议项目中，广域网部分都是由运营商来承建。
一旦视频会议中出现因为网络丢包造成的图像或者声音效果不理想时，运营商方面除了通过ICMP协议中的ping包检查他们线路之外，基本没有其他更合适的解决办法。
并且当此网络上其他的非实时业务还在比较正常运行的时候，大家容易将问题归结到视频会议系统的设备上。
事实上，这类问题的原因一般是出在网络这一层面。
本文以一个典型案例来说明，出现因丢包而导致网络视频会议效果不理想时，对这种问题的排查分析方法。
1.案例背景在内蒙古某市工商管理局实施的网络视频会议项目中，视频会议主会场采用的是某视频设备生产商的视讯终端MG6050和视讯网关MCU ME5000且这两个设备都位于市局。
13个旗县的终端MG6050通过运营商的MSTP网络与市局相连。
如图1所示。
在项目实施初期便发现有3个旗县局点掉包严重，使得市局视讯网关MCU ME5000不断的发送异常报文，导致市局观看自己的图像以及下联旗县局的图像有很严重的停顿、马赛克现象。
旗县局观看市局图像同样停顿现象及马赛克现象也很严重。
在图像编解码算法中，媒体流中的视频图像是有I帧、P帧、B帧几种不同的视频帧组合而成。
I帧是关键帧，其它类型的视频帧以I帧为基础进行图像变化部分的编码，，I帧包含了一副图像的完整信息，其数据量很大，一般只在视讯终端刚加入会议、MCU切换广播会场、终端或MCU接收丢包等情况下产生。
P帧是一种以I帧或其它P帧为参考值、对图像的变化量进行编码的视频帧，其数据量较小，会议中一般以传送P帧为主。
B帧是以P帧为基础对图像运动预测进行的编码的双向预测帧，在视讯会议中并不常用。
在多点会议中，当有大量的终端接收数据产生丢包时，这些终端就会向MCU 产生大量的I帧请求，MCU如果不响应则这些丢包终端由于没有I帧作为参考帧，就会无法解码或者出现花屏。
精品案例_传输丢包引起的VoLTE丢包案例
传输丢包引起的VoLTE丢包案例目录一、问题描述 (3)二、分析过程 (4)三、解决措施 (4)四、经验总结 (5)传输丢包引起的VoLTE丢包案例【摘要】黄山屯溪区城区RCU拉网测试时发现Volte MOS质量差问题，数据显示无线环境良好，基站侧无告警，联系传输侧核查发现传输侧输入光功率过低，安排传输人员紧急排障后问题解决。
告警不仅存在于基站侧，也可能存在传输侧，所以在优化过程中需要对告警因素考虑其中。
【关键字】MOS值、丢包、误码【业务类别】优化方法、VoLTE一、问题描述黄山屯溪区城区RCU拉网测试时发现Volte MOS质量差问题，测试车辆行驶至滨江东路时，主叫UE占用HS-市区-喜来登酒店-HFTA-448842-54（PCI：40）信号RSRP=-66.44dbm左右，SINR=21.8db左右，无线环境良好，丢包率、误块率偏高且MOS值差。
二、分析过程从测试UE的RSRP以及SINR看无线环境良好，不存在无线方面的原因。
通过U2000网管进行告警查询，结果无告警，对现场多轮DT测试仍出现同样问题，排除终端问题，疑似设备存在隐形故障或者是传输方面问题。
下一步协调传输侧进行排查。
通知传输方核查，传输方反馈：与基站对接的PTN设备一切正常，没有告警；最后无线侧通过ping核心网用户面IP地址发现存在83.3%左右的丢包现象，PING查询脚本如下：PING:SN=7,SRCIP="7.183.53.22",DSTIP="192.168.0.49",CONTPING=DISABLE,APPTIF=NO;PING结果：三、解决措施通过传输方面通过逐级排查，确认为HS-市区-喜来登酒店1端口输入光功率过低（显示21.2dBm,参考值14.1dBm），安排传输人员紧急排障后问题解决。
效果验证：调整后上行丢包率从7.34%改善0.16%，MOS值从3.2左右提升至4.23左右，问题得到解决，复测图层如下：四、经验总结由于告警不仅存在于基站侧，也可能存在传输侧，所以在优化过程中需要对告警因素考虑其中，在问题优化处理起来更高效，网络保障更有力，才能实现未来Volte业务商用后的全面领先。
- 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软件下载视频——难怪会有这么大的流量。
其实引起网络丢包的原因有很多，除了上述网络攻击和病毒感染之外，连接线路、网卡、交换机、路由器等硬件故障也会造成网络的延迟、丢包。
因此，网络管理人员掌握丢包排错方法是非常重要的。
授人以鱼不如授人以渔，希望上述网络丢包排故障思路对大家有所帮助。