网络丢包原因及解决方案

运维 网络运维
许多时候,我们可能都会碰到网络连接时断时续的故障现象,那么究竟是什么因素导致了数据丢包现象比较严重呢?是连接线路接触不稳定?是网络病毒?还是其他的潜在因素?

网络丢包是我们在使用ping对目站进行询问时,数据包由于各种原因在信道中丢失的现象。ping 使用了ICMP 回送请求与回送回答报文。ICMP 回送请求报文是主机或路由器向一个特定的目的主机发出的询问,收到此报文的机器必须给源主机发送 ICMP 回送回答报文。这种询问报文用来测试目的站是否可到达以及了解其状态。

网络丢包

许多时候,我们可能都会碰到网络连接时断时续的故障现象,面对这种网络故障,不少网络管理员都会使用Ping命令对网络连通性进行测试,测试结果表明此时的网络传输线路数据丢包现象非常严重,那么究竟是什么因素导致了数据丢包现象比较严重呢?是连接线路接触不稳定?是网络病毒?还是其他的潜在因素?

原因一:物理线路故障

网管员发现广域网线路时通时断, 发生这种情况时, 有可能是线路出现故障, 也可能是用户方面的原因。为了分清是否是线路故障,可以做如下测试。

如果广域网线路是通过路由器实现的,可以登录到路由器,通过扩展 ping 向对端路由器广域网接口发送大量的数据包进行测试。如果线路是通过三层交换机实现,可在线路两端分别接一台计算机,并将 IP 地址分别设为本端三层路由交换机的广域网接口地址,使用 “ping 对端计算机地址 - t ”命令进行测试。

如果上述测试没有发生丢包现象, 则说明线路运营商提供的线路是好的, 引起故障的原因在于用户自身,需要进一步查找。

如果上述测试发生丢包现象, 则说明故障是由线路供应商提供的线路引起的, 需要与线路供应商联系尽快解决问题。

由物理线路引起的丢包现象还有很多,如光纤连接问题,跳线没有对准设备接口,双绞线及 RJ-45 接头有问题等。另外,通信线路受到随机噪声或者突发噪声造成的数据报错误,射频信号的干扰和信号的衰减等都可能造成数据包的丢失。我们可以借助网络测试仪来检查线路的质量。

原因二:设备故障

设备故障主要是指设备硬件方面的故障,不包含软件配置不当造成的丢包。如网卡是坏的,交换机的某个端口出现了物理故障,光纤收发器的电端口与网络设备接口,或两端设备接口的双工模式不匹配。

曾看过这样的例子,一交换机端口的光纤模块故障造成的丢包现象, 该交换机在通信一段时间后死机,即不能通信,重启后恢复正常。在经过一段时间观察后发现,某光纤模块存在问题,取一块新的模块替换,一切正常。

究其原因,交换机会对所有接收到的数据包进行 CRC 错误检测和长度校验,将检查出有错误的包丢弃,正确的包转发出去。但这个过程中有些有错误的包在 CRC 错误检测和长度校验中都均未检测出错误,这样的包在转发过程中不会被发送出去,也不会被丢弃,它们将会堆积在动态缓存中,永远无法发送出去,等到缓存中堆积满了,就会造成交换机死机的现象。最终结果是,数据包无法到达目的主机。

原因三:网络拥塞

网络拥塞造成丢包率上升的原因很多,主要是路由器资源被大量占用造成的。

如果发现网速慢, 并且丢包率呈现上升的情况, 这时应该 show process cpu 和 show process mem ,一般情况下发现 IP input process 占用过多的资源。接下来可以检查 fast switching 在大流量外出端口是否被禁用,如果是,则需要重新使用。

再看一下 Fast switching on the same interface是否被禁用,如一个接口配有多个网段并且这些网段间流量很大时,路由器工作在 process-switches 方式,这种情况下要在接口上执行命令“enable ip route-cache same- interface 。”

接下来,用 show interfaces 和 show interfaces switching 命令识别大量包进出的端口。一旦确认进入端口后,打开 IP accounting on the outgoing interface 看其特征,如果是攻击,源地址会不断变化但是目的地址不变,可以用命令 “access list ”暂时解决此类问题(最好在接近攻击源的设备上配置),最终解决办法是停止攻击源。

应用中遇到的造成网络拥塞的情况还有很多, 如大量的 UDP 流量, 可以用解决 spoof attack 的步骤解决此问题。大量的组播流、广播包穿越路由器,路由器配置了 IP NAT 并且有很多 DNS 包穿越路由器等。上述情况造成网络拥塞后,通信双方采取流量控制,丢弃不能传输的包。

原因四:MTU 配置不当

在关键设备上MTU设置不当,也会造成网络丢包(以太网:1500 字节,IEEE 802.3/802.2 1492字节)。查看网络中关键设备的 MTU 配置。

在了解了如何定位网络丢包的位置之后,网管需要进一步分析丢包发生的原因,以排除故障。打开网络分析软件以后,我们配置好网络档案,选择分析档案之后,就可以开始分析了。

首先我们可以在图表中添加利用率统计,可以看到,在14:38:05 之后,网络利用率突然升高,接近40% 。推荐利用率不高于15% ,当网络利用率超过了 30% ,就会产生1%的丢包,并且呈几何倍数的增长。这个网络中,利用率高达 40%,肯定存在着严重的丢包现象。

了解了有丢包就会有 TCP 数据包重传之后,网管可以在诊断中,找出 TCP 数据包重传比较严重的主机。

如何确定网络丢包的存在

通常我们利用 PING x.x.x.x -t 这个命令来进行测试网络中是否存在丢包。

在上图中可以看到,在本机上向 192.168.122.2 这个不存在的地址进行长时间 PING 的时候,发送出去的 ICMP 包都丢失了,丢失率达到 100% 。即从本机到 192.168.122.2 这个实际不可达地址的路径上存在丢包。

定位网络丢包的分析步骤

在网络丢包发生的情况下,用户会明显感受到网络速度变慢,这时候网管首先需要做的就是进行 PING X.X.X.X –t 来进行大致是哪个网段的诊断。在发现确实有丢失率存在的情况下,我们可以利用科来软件进行进一步分析。

在分析之前,我们有必要学习一下前置知识。

TCP协议的特点之一就是保障数据传输的可靠性,即确保数据能够正确完整传输。那么TCP究竟是如何来保障的?可以看到,TCP 在传输时,有着传输确认—重传机制,即发送数据一方在传输数据时为每一个分段编制序列号( Sequence Number ),接收方会向发送方发送接收到分段数据的确认(Acknowledgment),通过这种方式确认数据是否准确传送,在无法确认某分段数据被准确传送或确认某分段数据没有被准确传送时重新进行传输。

所以,在网络丢包发生的情况下,必定会有 TCP 数据包重传的出现。

1. 解决方案

  • 针对网络设备故障:通过分段捕获的方法,在网络中关键设备的两端,使用科来网络分析系统进行抓包,确定该设备是否丢包,从而准确定位丢包设备。
  • 针对网络拥塞:在核心交换机上配置镜像,使用科来网络分析系统抓包。

分析关键链路(一般是出口链路) 的流量占用情况, 查看网络利用率是否过高,每秒数据包是否过多,数据包大小分布是否合理、TCP会话是否正常等。

当然最根本的方法就是限制用户流量,就是针对每个上网的用户进行流量控制,比如禁止访问视频网站和其他与工作内容无关的网站,同时又能针对每个用户做出精准的流量限制,防止其对有限网络带宽的过度占用。

还可以针对一些流量做出服务质量保证( QOS),比如可以将与工作关系比较大的流量:如网页访问、邮件流量等的流量优先级提高,从而可以在一定程度上缓解网络拥塞,保证高优先级业务可以优先得到转发。 (治标不治本的方法)

2. 另外关于 ping IP 老是丢包的问题:

通常有以下几种原因:

  • 由于服务器的 IIS 中运行了非法或者没有独立进程池的原因 , 找到这个站点 , 给他一个独立的进程池 .
  • 如果服务器上捆绑了一个主机头为空的站点的话 , 容易造成这个问题 , 最好把这个主机为空的站点给删除了 , 或者把这个站点的进程池给独立起来 , 就可以解决问题。
  • 由于对服务器的带宽和流量限制的太低问题 , 一般有一些机房的IDC服务商为了获得更多的托管的用户 , 十分的苛刻的限制用户托管的服务器 , 造成流出去的十分少 , 请求的多 , 就造成丢包问题。
  • 由于交换机的交换口的问题:首先使用 Ping 命令测试,发现不定时的有数据包丢失的现象,初步认为是物理层的原因。重做网线的 RJ45头后,故障依旧,换根网线也不行。怀疑是网卡接口或者交换机端口的问题。经查看网卡驱动无误,网卡接口也没有任何异常。再查看交换机端口, 发现与服务器连接的交换 机端口工作指示灯在绿与黄之间闪烁, 这说明端口工作不正常。使用超级终端登录交换机,查看此端口的参数,发现此端口是工作在100Mbyte/s全双工模式,回到服务器前查看本地连接状态,网卡是工作在 10Mbyte/s 全双工模式。 交换机的端口与网卡的传输速率和双工模式不一致。将网卡工作模式改为 100Mbyte/s 全双工模式后测试,一切正常,故障解决。
  • 由于被 DDOS或者洪水猛兽攻击造成的大量丢包 , 这个时候没有什么好说的 , 赶快加上硬件防火墙吧

3. 总之一般排除故障的方法是:

  • 带宽有没有占满
  • 换个交换机端口试试
  • 换个网线试试
  • 网卡及主板驱动是不是没装 ( 一般不会是这个问题 )
  • 交换机上设置是100M的还是10M的 , 与机器设置成一样的
责任编辑:赵宁宁 来源: 厦门微思网络
相关推荐

2019-05-22 09:51:28

网络故障

2022-05-26 16:51:07

网络丢包网络故障网络

2011-05-24 11:26:11

2009-07-22 17:37:06

ASP.NET Ses

2010-08-27 14:35:37

IEFirefox兼容

2011-08-22 15:31:51

SQL Servermssqlserver数据库复制

2022-08-12 13:26:14

内联崩溃TV 端插件化

2024-11-08 13:47:35

中文乱码配置

2013-02-27 10:39:41

网络丢包故障

2010-12-24 12:49:39

2020-03-05 09:09:18

缓存原因方案

2023-12-01 15:58:00

Kubernetes集群DevOps

2024-08-05 10:40:58

2009-07-31 16:47:53

网络线缆定位

2010-04-26 16:31:09

Oracle SQL

2009-10-27 15:35:08

2010-07-29 15:56:04

FlexSocket

2019-10-08 16:05:19

Redis数据库系统

2015-05-12 16:31:22

Elasticsear开源分布式搜索引擎

2018-12-12 15:50:13

点赞
收藏

51CTO技术栈公众号