ping丢包故障处理方法
ping丢包故障处理方法
&&& 1、Ping丢包故障定位思路故障分析
&&& Ping丢包是指Ping报文在网络中传输，由于各种原因（如线路过长、网络拥塞等）而产生部分Ping报文丢弃的现象。在使用Ping命令，出现Ping丢包的现象时，第一步需要确定Ping丢包的网络位置，其次是确定Ping丢包的故障原因，然后依据定位的故障原因再进行解决。
&&& 确认Ping丢包的网络位置时一般采用逐段Ping的方法，可以将Ping丢包故障最终确定在直连网段之间。
确认Ping丢包的故障原因一般采用流量统计的方法，通过流量统计可以知道丢弃报文的具体位置、判断故障原因。
&&& 导致Ping丢包的原因非常多，也非常复杂，实际故障定位中需要综合考虑各种因素。本文档针对常见Ping丢包故障分析，总结出以下几种常见故障：
&&& 物理环境故障；网络环路；ARP问题；ICMP问题。
&&& 需要注意并不是Ping丢包就一定表示网络质量差，某些情况下虽然Ping丢包，但是业务是正常的。分析Ping丢包时注意以下两点：
&&& 当设备对报文进行硬件转发，速度非常快，就不会丢包。例如，Ping设备端口下挂的电脑。当报文需要CPU进行处理时，CPU繁忙就会丢包。例如：Ping设备上的IP地址。
&&& 为了防止网络攻击对设备造成影响，设备具有CPU保护功能，对于超过CPCAR（Control
Plane Committed Access Rate）值的ARP、ICMP等报文进行丢弃，造成Ping丢包现象。此种现象不影响业务的正常运行。
&&& 2、Ping丢包故障定位
&&&&&&&&&&&&&&&&&&& &&图1 Ping测试组网图
&&&& 如上图1所示，以一个Ping丢包实例，介绍Ping丢包故障定位。
&&&& 3、Ping丢包故障现象
&&&& C:\Users& ping -n 100 192.168.4.41
&&& &正在 Ping
192.168.4.41 具有 32 字节的数据:
&&&& 请求超时。
&&& &请求超时。
&&& &来自 192.168.4.41 的回复: 字节=32 时间&1ms TTL=128
&&& &来自 192.168.4.41 的回复: 字节=32 时间&1ms TTL=128&
&&& &192.168.4.41 的 Ping 统计信息:
&&&& 数据包: 已发送 = 100，已接收 = 80，丢失 = 20 (20% 丢失)，
&&& &往返行程的估计时间(以毫秒为单位):
&&&& 最短 = 0ms，最长 = 0ms，平均 = 0ms
&&& 4、Ping丢包故障定位
&&& 依据故障发生的可能原因进行故障定位，故障定位方法如下：
&&& 1、配置Ping多包。
&&& 为了持续复现丢包现象，以便于故障处理，需要持续发送Ping报文。可以配置Ping的-c count参数，发送多个Ping报文。
&&& 2、缩小故障范围。
&&& 当在PC上直接Ping IP地址192.168.4.41丢包时，直接判定故障出现的原因将非常的困难。此时可以先缩小故障范围，在PC上分别Ping SwitchA、SwitchB、SwitchC和SwitchD，通过Ping结果可以判断出哪一段网络出现故障。本例假设PC上Ping SwitchB时也出现丢包，则可以初步判断丢包发生在SwitchA和SwitchB直连网段之间。
&&& 3、配置流量统计。
&&& 通过缩小故障范围最终将故障定位在SwitchA和SwitchB之间，为了进一步确认故障点，需要在SwitchA和SwitchB上配置流量统计功能，观察丢包情况。具体理论统计配置方法请参考各设备的说明手册。
&&& 4、分析统计结果。
&&& 在SwitchA上持续Ping
& &&如果离开SwitchA的报文数目多余进入SwitchB的报文数目，说明传输链路上存在丢包，请依照后面介绍的物理链路故障引起ping丢包进行处理。
&&& 如果离开SwitchA的报文数目等于进入SwitchB的报文数目，但是离开SwitchB的报文数目少于进入SwitchB报文数目，说明SwitchB上存在丢包。引起SwitchB设备丢包可能原因分为网络环路和ICMP问题。
&&& 登录设备，续查看CPU和接口利用率是否很高、查看是否出现MAC地址漂移。如果出现利用率高或MAC地址漂移现象，请依照后面的网络环路引起ping丢包进行处理。
&&& 登录设备，查看是否有ICMP报文被丢弃、查看ICMP报文限速的配置是否过小。如果出现报文被丢弃或ICMP报文限速配置得很小，请依照后面介绍的ICMP问题引起ping丢包进行处理。
&&& 如果离开SwitchA的报文数目少于Ping发送的报文数目，说明SwitchA上丢包。引起SwitchA丢包可能原因分为网络环路和ARP问题。
&&& 登录设备，查看CPU和接口利用率的情况，查看是否出现MAC地址漂移，如果出现利用率高或MAC地址漂移现象，请依照后面介绍的网络环路引起ping丢包进行处理。
&&& 登录设备，查看是否有ARP报文被丢弃。如果出现报文被丢弃现象，请依照后面介绍的ARP问题引起ping丢包进行处理。
&& &5、物理链路故障引起ping丢包分析
&&& 通过Ping丢包故障定位思路可以判断出是否由于物理链路故障引起的丢包。物理链路故障常见以下原因：
&&& 计算机网卡有问题、设备接口不正常、线缆接头接触不良或松脱、网线过长或出现破损、光纤弯曲度过大、光模块收发的光功率过低、电口协商不一致，如一端自协商一端非自协商。
&&& 在实际环境中设备未接地导致静电不能释放、风扇损坏导致设备过热等物理环境问题也会引起Ping丢包。
&&& 物理链路故障可以通过观察发现，如光纤弯曲度过大、物理连接线过长、设备或者电脑网卡指示灯显示不正常等。针对物理链路故障，故障的解决的办法一般是更换物理器件，器件更换后故障即可恢复。
&&& 6、网络环路故障引起ping丢包分析
&&& 以太网交换网络中为了进行链路备份，提高网络可靠性，通常会使用冗余链路。但是使用冗余链路会在交换网络上产生环路，引发广播风暴以及MAC地址表不稳定等故障现象，从而导致用户通信质量较差，甚至通信中断。网络环路会导致设备CPU和端口利用率高，Ping报文被丢弃。
&&& 当设备处于存在环路的网络中，设备的反应速度比较缓慢。环路问题判断方法如下：
&&& 1、通过display
interface brief | include up命令，查看所有UP接口下的流量，存在环路的接口上InUti和OutUti两个计数会逐步增加，甚至到接近100%，远远超过业务流量。
&&& 第一次查询：
&&& &SwitchA& display interface brief
| include up
&&& Interface&&&&&&&&&&&&&&&&&& PHY&& Protocol&
InUti OutUti&& inErrors& outErrors&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
&&& GigabitEthernet0/0/2&&&&&&& up&&&
up&&&&&&& 0.56%& 0.56%&&&&&&&&&
0&&&&&&&&& 0&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
&&& &...&&&&
&&& 第二次查询：
&&& &SwitchA& display interface brief
| include up
&&& Interface&&&&&&&&&&&&&&&&&& PHY&& Protocol&
InUti OutUti&& inErrors& outErrors&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
&&& GigabitEthernet0/0/1&&&&&&& up&&&
up&&&&&&&&& 76%&&& 76%&&&&&&&&&
0&&&&&&&&& 0&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
&&& 2、判断交换机是否存在MAC地址漂移。
&&& 可以执行display
trapbuffer命令，查看MAC地址漂移的日志来判断。
&&& 可以执行mac-address
flapping detection命令配置MAC地址漂移检测功能，然后通过display mac-address flapping record命令来判断是否出现MAC地址漂移。
可以多次执行display
mac-address来观察，若MAC地址在交换机不同的接口学习到，则存在mac地址漂移。
&&& 3、检查CPU的利用率。
&&& 通过命令display
cpu-usage查看CPU的利用率。网络环路会导致CPU利用率一直很高，Ping报文未来得及处理就被丢弃。
&&& 解决此种Ping丢包问题的方法是破除网络环路，可以在设备上部署RRPP、SEP、Smart Link、STP/RSTP/MSTP等协议，对环路进行处理。
&&& 7、ARP问题故障引起ping丢包分析
&&& 通过前面介绍的Ping丢包故障定位思路断是否由于ARP问题导致Ping丢包。ARP问题常见故障现象：开始（由于ARP学习失败）出现Ping丢包，然后（学习到ARP）在一段时间内（ARP表项老化时间）无丢包现象，后续（再出现ARP学习失败）会继续出现丢包。
&&& 常见ARP问题有以下两种：
&&& 设备配置了ARP安全功能，如ARP
Miss的源抑制、ARP速率抑制等，会导致ARP学习很慢，Ping丢包。
设备受到ARP报文攻击，上送CPU的ARP报文数超过CPCAR值，导致部分ARP报文被丢弃，Ping丢包。
&&& 常见问题判断及解决方法如下：
&&& 通过display arp
packet statistics命令，查看是否有ARP报文被丢弃，分析设备上ARP安全的配置情况，从而判断问题的原因。对于该问题需要重新配置ARP安全，使设备能够正常的处理ARP报文。
&&& 通过display
cpu-defend statistics命令，查看CPU对于ARP报文处理情况，是否存在报文丢弃。
对于该问题需要检查设备是否受到ARP攻击，正确配置ARP安全来防范攻击，同时增加ARP报文的CPCAR值。配置样例如下：
&SwitchA& system-view
[SwitchA] cpu-defend
policy arp
[SwitchA-cpu-defend-policy-arp] car packet-type arp-reply cir 32
Improper parameter settings may affect stable operating of the system. Use this
command under assistance of Huawei engineers. Continue? [Y/N]:y&&
[SwitchA-cpu-defend-policy-arp] car packet-type arp-request cir 32
Improper parameter settings may affect stable operating of the system. Use this
command under assistance of Huawei engineers. Continue? [Y/N]:y&&
[SwitchA-cpu-defend-policy-arp] quit
[SwitchA] cpu-defend-policy
arp global
&&& 8、ICMP问题故障引起ping丢包分析
&&& ICMP问题常见故障现象：
&&& Ping设备时，一旦Ping速度比较快就会丢包，速度慢下来就不会丢包。 Ping大包时出现规律性丢包。 Ping设备时，会出现Ping通几个报文后Ping不通，大约两分钟左右又可以Ping通，Ping通几个报文后又Ping不通。
&&& 常见ICMP问题有以下三种：
&&& 设备受到ICMP报文攻击，上送CPU的ICMP报文数超过CPCAR值，导致部分ICMP报文被丢弃，Ping丢包。 设备配置ICMP攻击防范，超过速度限制的ICMP报文被丢弃，Ping丢包。 设备配置ICMP限速功能，超过速度限制的ICMP报文被丢弃，Ping丢包。
&&& 常见问题判断及解决方法如下：
&&& 1、通过display icmp
statistics和display anti-attack statistics icmp-flood命令查看是否有ICMP报文被丢弃。
对于该问题需要重新配置ICMP安全，使设备能够正常的处理ICMP报文。
&&& 2、检查icmp rate-limit
total threshold threshold-value命令的配置情况，了解ICMP流量限速的阈值。
&&& 如果阈值过小，则可通过icmp
rate-limit total threshold threshold-value命令进行修改，使其允许更多的ICMP报文通过。配置样例如下：
&SwitchA& system-view
[SwitchA] icmp
rate-limit enable
[SwitchA] icmp
rate-limit total threshold 500
&&& 3、通过display
cpu-defend statistics packet-type icmp all命令，查看CPU对于ICMP报文处理情况，是否存在报文丢弃。
&&& 对于该问题需要检查设备是否受到ICMP攻击，正确配置ICMP安全来防范攻击，同时增加ICMP报文的CPCAR值。ICMP报文的CPCAR值配置样例如下：
&SwitchA& system-view
[SwitchA] cpu-defend
policy icmp
[SwitchA-cpu-defend-policy-icmp] car packet-type icmp cir 256
Improper parameter settings may affect stable operating of the system. Use this
command under assistance of Huawei engineers. Continue? [Y/N]:y&
[SwitchA-cpu-defend-policy-icmp] quit
[SwitchA] cpu-defend-policy
icmp global
&&& 还可以通过icmp-reply
fast命令使能Ping快回功能来解决CPU丢弃ICMP报文故障。
&您阅读这篇文章共花了：&
捐赠支持：如果觉得这篇文章对您有帮助，请鼓励作者！
技术交流：欢迎在本文下方留言或加入QQ群:4079428 互相学习。 &&&&
本文地址：
版权声明：若无注明，本文皆为“重庆网管”原创，转载请保留文章出处。S5700 ping DNS丢包故障求解答_百度知道天极传媒：天极网全国分站
您现在的位置：
& >&用回溯分析技术诊断网络异常丢包故障
利用回溯分析技术诊断网络设备异常丢包故障天极网云计算频道 14:51
　　案例背景
　　某大型集团公司县公司信息内网PC在访问省公司业务和市公司业务时间歇性出现访问连接非常慢的情况，以及使用内网PC对省公司DNS和市公司官网IP持续ping操作时出现不定时丢包现象，但县公司访问其内部服务器并无故障现象。访问连接慢严重影响信息内网的正常业务交互，尤其是营销部门对省公司服务器的请求访问。
　　网络拓扑图，如图1：
　　图 1某大型企业网络拓扑图
　　将科来网络回溯分析系统旁路接入到县公司信息内网的核心上，由于故障发生的间歇性需要对县公司到市公司的主干出口流量做长时间捕获。并利用不间断的捕获市公司核心交换机与C的下行接口流量。利用对比分析法，在故障发生时段，分别对两处捕获到的流量做精确分析。
　　案例分析
　　一、出口流量分析
　　通过科来网络回溯分析系统对通讯流量的长时间存储，我们对故障时段的通讯流量进行故障重现。我们在县公司捕获点，对故障时段数据进行回溯。选择4分钟分析窗口(流量统计精度为1秒)，未见突发流量和通讯流量为0的情况。广播与组播流量正常，TCP SYN比值属于正常范围。
　　对该时段的网络进行分析，流量占用最大网络应用为：HTTP、未知TCP、HTTP Proxy，属正常业务行为。网络应用中存在CIFS扫描，但该应用的通讯数据包少，对主干链路的传输影响不大，事件不是造成丢包的原因。
　　对县公司访问关键业务标准应用监控梳理，网络链路传输质量良好，排除链路拥塞造成丢包现象。但客户端访问10.176.X.X服务器的TCP会话中存在98次TCP重传，上行重传次数为97次。大量的TCP重传造成会话延迟确认，严重影响会话质量。TCP重传大部分发生在上行，说明丢包位置在县公司到省公司之间。
　　二、TCP会话解码
　　对应用请求的TCP会话进行解码以确定访问延迟的具体原因。选取故障时段，县公司信息内网PC主机10.178.x.x访问10.176.X.X的应用通讯流量，客户端10.178.x.x使用2487端口访问10.176.x.x的TCP 80端口，网络链路传输质量良好，无链路拥塞。
　　持续向下分析，我们发现县公司捕获点TCP会话的77号数据包在271ms后对73号数据包Seq进行了重传，73号数据包已达到县公司信息内网办公核心交换机出口。而同一会话在市公司捕获点客户端10.178.x.x发送的数据包中Seq的数据包只捕获了一次，该包并未出现在Seq与Seq之间，而是间隔200多毫秒后才出现了一次，说明在市公司只捕获到了重传的数据包，客户端10.178.x.x第一次发送的Seq数据包在县公司到市公司之间被丢弃。
　　我们对两次捕获TCP会话进行对比分析，如图2：
　　图 2捕获的两次TCP会话
　　该TCP会话中存在大量的TCP重传，通过对两处捕包点的TCP会话对比分析，确定造成丢包位置在县公司与市公司之间某一中间件网络设备。整个TCP会话过程中客户端和服务器响应时间未见异常，结合前面对网络链路传输质量的分析，确定县公司对省市公司的业务访问出现间歇性延迟的原因是由于中间件网络设备对数据包的丢弃造成。
　　三、故障定位
　　根据拓扑图，县公司到市公司核心交换机之间需要经过3台路由器进行转发。我们对故障发生时段接入B路由器的其他区县信息内网PC访问省市公司业务系统的TCP会话进行解码分析。三次握手时间7.9ms，网络传输质量良好，未见链路拥塞。TCP会话中未见丢包重传，客户端和服务器响应正常。说明故障时段，只有该县公司信息内网出现访问丢包现象。因此，故障范围缩小为县公司→A路由器→B路由器之间。
　　我们对县公司到B路由的各个路由接口进行逐一检查，发现A路由器与县公司连接的下行接口光模块在Input方向有大量CRC校验码错误日志。
　　CRC循环冗余校验码错误有三种可能：
　　1、 双方工作模式不同;
　　2、 链路通道信号衰减严重;
　　3、 网卡故障。
　　我们又对县公司至A路由上行接口进行检查，光模块工作模式与对端A路由器相同，排除第一种可能。对县公司与A路由器之间的通道进行衰减，通道正常。排除第二种可能。
　　CRC校验码错误日志是在A路由器与县公司的下行接口的Input方向上检查到，说明县公司的路由器的上行接口在对数据包进行CRC循环冗余校验码封装时出现间歇性故障，导致A路由器下行接口在对数据包进行CRC校验码解码时发现错误。对错误CRC校验码数据包丢弃。
　　四、故障处理
　　将县公司到A路由器的光模块进行更换，恢复通讯一段时间后，对A路由器下行接口进行检查，CRC循环冗余校验码数值不再增加。对县公司访问省市公司业务系统的TCP会话进行解码，双方通讯交互正常。TCP会话统计信息中无重传和丢包。县公司与省市公司之间的通讯恢复正常。
　　案例结论
　　1、县公司到市公司之间的链路流量值不大，流量趋势不稳定，对县公司至市公司之间的业务交互的TCP会话分析后，客户端RTT值正常，服务器RTT值正常，未见链路拥塞情况;
　　2、通过在县公司和市公司的对比抓包分析，发现业务交互的TCP会话存在严重丢包现象，经过定位分析，发现县公司边界路由器出口光模块存在CRC校验和错误;
　　3、将县公司边界路由器出口光模块更换以后，CRC校验和错误提示不再增加，对业务交互流量分析，未见丢包现象，业务通讯恢复正常。
（作者：案例责任编辑：王玉平）
天极新媒体&最酷科技资讯扫码赢大奖
* 网友发言均非本站立场，本站不在评论栏推荐任何网店、经销商，谨防上当受骗！
办公软件IT新闻整机 上传我的文档
 下载
 收藏
该文档贡献者很忙，什么也没留下。
 下载此文档
正在努力加载中...
PING大包丢包网络故障分析案例、解决方案-【word】可编辑
下载积分：100
内容提示：PING大包丢包网络故障分析案例、解决方案-【word】可编辑
文档格式：PDF|
浏览次数：127|
上传日期： 09:20:49|
文档星级：
该用户还上传了这些文档
PING大包丢包网络故障分析案例、解决方案-【word】可
官方公共微信查看:7225|回复：15
提示: 作者被禁止或删除 内容自动屏蔽
提示: 作者被禁止或删除 内容自动屏蔽
最有价值午饭
感谢分享过程:lol
中级工程师
感谢分享过程
顶 非常感谢分享:lol
高级工程师
不错，学习一下故障处理思路:(pdd_26):
楼主辛苦，其实正如楼主所说，很多问题都是出在链路上的，这个只需要细致耐心的多排查就会很容易找出的。
:(pdd_16):
中级工程师
很好很强大 感谢LZ 分享~~~~~~~:handshake
初级工程师
“传输设备业务板”这个是什么啊？&&楼主能介绍下啊？ 我不懂，请指教。。。
学无止境！！！
提示: 作者被禁止或删除 内容自动屏蔽
初级工程师
传输设备业务板是实实在在的名称吗
提示: 作者被禁止或删除 内容自动屏蔽
高级工程师
这帖子& &必须顶
:(mars_21): 又学习了
:(pdd_15):}