如何解决网络丢包问题（网络中丢包分析案例）
如何解决网络丢包问题（网络中丢包分析案例）3：首先更换左端服务器与交换机连接的端口，更换后，丢包问题依然存在，可以排除左端交换机端口的问题，用同样的办法测试右端服务器与交换机端口，依然可以排除交换机端口的问题；2：排查服务器与交换机之间问题：这部分的问题又可以细分为三个点：服务器、网线、交换机端口。而这三个点的排查难度是由难到易，因此我们先排查交换机端口的问题；两台服务器连在分别连接在S5100交换机的g1/0/3和g1/0/4端口。服务器是第三方网管服务器 两台服务器之间有数据调用。客户反馈访问网管服务器速度很慢，两台服务器之间Ping大包时有大量丢包。网络故障范围已经缩小至两台服务器之间的丢包，问题就变得比较简单，这种情况下，首先确认是故障点，那么我们看两台服务器PING报文的转发流程，总体上可以分为三部分：有两部分是服务器与交换机之间的转发、另外一部分是交换机之间的数据转发。那么要排除该问题我们采取逐段分析排查的方法：1：首
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错误包的数量还在增长，因此初步怀疑该接口下的网线有问题，于是更换一条生产发货的网线更换后，丢包问题解决。
TIPS：做网线是网络工程师的基本技能，甚至任何一个IT卖场的售货人员都会做网线，但是网线的质量却千差万别，由网线引发的网络丢包无计其数，千里之堤毁于蚁穴，日常网络维护中不可忽视小小的网线。而对于线路引发的丢包，如果交换机或者路由器接口上收到runts，giants，throttles，CRC，frame等错帧而且错帧的数量在不断的增长，那么需要检查对端设备或者中间的传输链路是否存在问题；如果收到overruns等错帧，需要确定本端的链路带宽是否足够。
3网络丢包惨案-案例2
某客户全国网项目在在北京中心通过配置CPOS板卡通过拆分E1连接下面31个省中心实现省节点与中心节点的互联，某局点与中心节点连接示意图如下：
在S省节点，客户反馈访问总部的业务很慢，通过Ping检测发现网络有不规律丢包，工程师查看S省节点路由器E1接口上有大量的CRC错误，如下：
<RT_3016_1>disp int ser 5/1
。。。。。。
Last clearing of counters: Never
Last 300 seconds input rate 0.00 bytes/sec 0 bits/sec 0.00 packets/sec
Last 300 seconds output rate 0.00 bytes/sec 0 bits/sec 0.00 packets/sec
Input: 57433 packets 2314250 bytes
0 broadcasts 0 multicasts
57338 errors 0 runts 0 giants
46901 CRC 23 align errors 0 overruns
0 dribbles 0 aborts 0 no buffers
10414 frame errors
Output:211 packets 49547 bytes
0 errors 0 underruns 0 collisions
0 deferre
根据如上的输出信息，工程师认定是线路问题，于是客户协调运营商排查线路，但是运营商经过一个星期的艰苦卓绝的辛苦工作，非常确认线路没有问题。运营商为了证实自己的线路没有问题，自己携带了一台新的路由器替换S省节点客户的MSR路由器，替换的结果让所有的人意外，替换后，网络不再有丢包！看起来CRC错误并不一定是线路的问题？难道问题是MSR路由器引发的？工程师仔细检查了两台设备环境的不同之处，发现最大的区别是MSR路由器接地了，而新替换的路由器没有接地而且客户机房中的光端机以及其他传输设备都没有接地，那么意味着MSR与网络中的其他设备不共地，由于电磁干扰对E1线路影响较大，因此工程师确认是接地因此的丢包问题，于是在现场将MSR路由器上的接地取消后，网络不再丢包。
TIPS：对于网络设备，最好全部共地，避免由于不共地而引起的丢包，而在雷雨较多的南方城市，接地更是强制的，而在北方地区由于气候干燥，那么静电引起的丢包或者其他问题对网扩设备影响较大；对于E1线路引发的丢包问题，一般可以从三方面着手，一是可以通过打环，二是确认E1或者CPOS的时钟设置、三是接口CRC或者是其他字段的参数设置是否一致；而如果是POS链路问题，那么要查看Pos接口的字段C2、j0以及加扰设置是否一致。
4 网络丢包惨案—案例3
某客户的对外服务办公网络通过大量二层交换机连接终端，这些终端对外提供实时服务，而所有的二层交换机都通过双上行的方式连接到核心交换机上，客户网络示意图如下：
客户的网络是局域网典型网络结构，整个网络通过STP来避免环路并实现双上行链路备份，整个网络设计合理规范，但是突然有段时间客户反馈下面的终端业务办理很慢，而且有时断时续的现象。工程师首先明确网络现象，确认网络中所有的终端业务都受到影响，因此工程师怀疑网络中有环路导致引发广播风暴从而影响网络的正常转发。因此工程师将处于备份状态的一台S7500下行连接业务的端口都断开，断开后，终端业务恢复，因此可以确认为网络环路导致了业务丢包，但是依然不能具体的问题点在那里。接下来工程师在晚上网络没业务流量的情况下，对S7500下行连接的L2交换机进行逐个排查，也即逐个将下行的L2交换机上行恢复到双上行结构同时开通过个Ping窗口对业务进行监测。果不其然，再将某台L2交换局恢复到双上行结构时，Ping业务出现丢包现象。工程师对该接入L2交换机的接口状态进行查看，发现两个上行端口都处于STP Forwarding状态。这种情况下必然导致网络环路。最后工程师确认是光模块硬件问题导致状态错误而引起STP计算错误。
TIPS：对于局域网的问题，由于局域网有大量的L2交换局、HUB以及接入很多终端，因此局域网的问题要特别注意广播风暴引发的全网振荡，而广播风暴的引发的局域网问题，可能是由于环路产生，而ARP Flooding、病毒、非法软件也都有可能引发局域网振荡，对于局域网网络问题建议如下;
à 尽可能将L3网关下移，增加路由L3层次的报文处理，减少L2交换层次的连接；
à 避免网络中单个VLAN下交换机或者HUB级联层次太多，减少广播风暴以及网络环路的影响；
à 在接入终端服务器或者PC的交换机端口上配置STP 边缘端口、BPDU保护；
à 全网部署EAD，对接入网络的用户终端强制实施企业安全策略，严格控制终端用户的网络使用行为，有效地加强用户终端的主动防御能力
5 总结
丢包的问题是网络中最常见的问题也是耗费时间最久定位时间较长的问题，以上三个案例基本上涵盖了常见的丢包问题的处理思路，我们在日常的网络维护过程中需要慢慢积累经验，也许丢包也并不那么惹人烦！
