某公司网络PING延迟故障案例解析
案例分析-许昌某网吧网络故障诊断

案例阐发-许昌某网吧网络故障诊断故障描述故障地址:河南省许昌某网吧网络环境:网吧大要有200台电脑,采用双W AN出口〔电信和网通〕拜候互联网,网络布局较为简单,外网路由器主交换机二层交换机客户端。
故障详细描述:同时接上两个外网出口时,整个网络拜候通讯呈现异常,网络速度异常迟缓,很多用户甚至不克不及上网,在客户端进行ping包测试时发现,当地客户端严重丢包,断开网通的外网出口,网络却又恢复正常,ping包测试也无异常。
故障阐发由于在断开网通的线路后,网络拜候正常,初步疑心是网通线路问题,于是用笔记本单独接网通线路测试,一切正常,所以首先排除了网通线路的问题。
在排除线路问题后,我们将问题重点放在了内网主机查抄上。
由于网络速度迟缓而且呈现断网的情况,所以疑心网络中有主机传染ARP或其他蠕虫病毒攻击导致网络瘫痪,于是决定用科来网络阐发系统抓包阐发,在中心交换机上做好端口镜像,在笔记本上安装科来网络阐发系统,将笔记本接到中心交换机的端口上,启动科来网络阐发系统开始捕捉数据,约6分钟后遏制捕捉并阐发捕捉到的数据包。
我们首先了解网络的整体运行状态,在概要统计视图中可以看到:网络的总共流量为,而操纵率那么达到了近80%,这是网络迟缓的一个重要指示参数。
我们再看TCP的参数信息,此处,TCP的同步数据包与结束连接数据包别离是17796和9963个,由TCP的工作道理我们知道,TCP在工作时首先会通过三次握手成立连接,数据传输完成后,必需关闭连接,在成立握手的时候,会发生2个同步数据包,而关闭连接的时候,也会发生2个同步数据包,所以,理论情况下,1个TCP连接的同步数据包与结束连接数据包应该大致相等,如果二者的数据包相差较大,说明当前的网络传输不正常。
如图1。
图1选择端点视图,我们发现,IP地址为这台主机的网络连接数较多,而且流量也比较大,所以,我们定位这个IP,单独对其阐发。
在节点浏览器中选择,翻开矩阵连接视图,我们看到,该主机的通讯主机数达到了1000个,而且很大一局部为单向流量,如图2。
网络性能监测案例分析:如何解决用户访问卡顿问题?(八)

网络性能监测案例分析:如何解决用户访问卡顿问题?近年来,随着互联网的快速发展,我们对网络的依赖越来越深。
然而,随之而来的是网络性能问题的困扰,尤其是用户访问卡顿问题,成为了广大网络用户的心头之患。
本文将以案例分析的方式,探讨如何解决这一难题。
案例一:用户访问速度变慢的问题某公司的网站最近遇到了用户访问速度变慢的问题,这导致了用户体验的下降和客户流失的风险。
为了解决这个问题,该公司决定进行网络性能监测。
首先,他们使用了一款专业的网络性能监测工具来分析网络延迟、带宽利用率等指标。
通过监测结果,他们发现在访问高峰期,带宽利用率超过了80%。
为了解决这一问题,他们采取了多种措施:1. 增加带宽:通过与网络服务提供商合作,他们增加了带宽并优化了网络路由,从而提高了网络的传输速度,减少了卡顿问题的发生。
2. 压缩资源:为了减少网络传输的数据量,他们采用了资源压缩技术,对网页内容、图片等进行压缩,从而减少了网络传输的时间和带宽占用。
3. 内容分发网络(CDN):他们通过使用CDN来分发网站的静态资源,将这些资源缓存在全球各地的服务器上,使用户可以从离他们最近的服务器获取资源,从而缩短了访问时间,提高了用户的访问速度。
通过这些措施,该公司成功地解决了用户访问速度变慢的问题,提升了用户体验,进一步巩固了自身的市场地位。
案例二:网络拓扑问题导致的卡顿在另一个案例中,一家企业的内部网络出现了频繁的卡顿问题。
为了解决这一问题,他们进行了网络性能监测和分析。
首先,他们采用了网络流量分析工具,对网络中的流量进行了统计和分析。
通过监测结果,他们发现网络中存在大量的冗余流量和网络拓扑问题。
为了解决这一问题,他们采取了以下措施:1. 优化网络拓扑:通过重新规划网络拓扑结构,减少网络中的冗余路径和网络设备,从而提高了网络的传输效率。
2. 设置流量控制策略:他们使用网络流量控制技术,对网络中的流量进行限制和管理,避免了流量过载和拥堵问题的发生,从而减少了卡顿的情况。
网络排错-网络安全-运维真实案例-公司大厦局域网网速慢排查手册

网络异常流量排查方法故障现象: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字节是空包了,没有数据信息。
汕头LTE网中兴设备PING时延不达标解决案例

I互联网+安全nternet Security 汕头LTE网中兴设备PING时延不达标解决案例□林琼璇中国电信股份有限公司汕头分公司【摘要】汕头LTE网中兴设备Ping时延不达标,通过无线侧到P设备再到核心网各段时延的对比,找出问题所在,最终定位在无线侧,通过更换调度模式,从而减少时延,最终Ping时延达到规定标准。
【关键字】Ping时延不达标解决方案一、问题描述根据上级部门下发的有关LTE-FDD单站验收标准中规定如下:单用户Ping包时延(32byte小包)小于30ms,成 功率大于95%。
汕头LTE网中兴设备已测试室外站点Ping时延(32byte 小包)均大于30m s,平均时延在30-36m s之间。
(图1 )二、 原因分析2.1汕头LTE站点到核心网E P C的拓扑如下图2:2.2无线侧(终端到基站)不同模式P in g时延对比:1、 基于收到S R置大的模拟BSR模式这是中兴设备V3.1版本的默认设置。
其基本原理是基于SR (Schedule Request)上报,根据前一•个TTI需要调度的U E个数,eNodeB主动下发一个较大的上行资源,使 得U E可以利用该资源发送上行数据,减少了U E发送BSR (Buffer Status Report,用来告诉基站有多少数据需要发送)然后eNodeB根据BSR进行调度流程。
2、 增强型混合调度模式混合调度模式是在预调度持续时间内,定时主动向UE 发送上行资源,U E利用该资源发送上行数据,由于基站是周期性的对U E分配上行资源,减少了U E发送S R的流程,因此使得Ping包时延缩短。
混合调度模式对所有的S R均做同样的处理,如果系统中用户量大,大量的上行资源预授权将导致基站反向干扰加重,严重影响基站反向解调性能。
为 了避免混合调度模式带来的负面影响,增强型混合调度模式能够对Ping的业务进行识别,识别出Ping业务的周期和大小之后,仅仅在Ping的周期到来时,给一定长度及相应大小的预授权即可。
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测试反馈与错误与故障排查

反馈信息Request timed outa.对方已关机:比如在上图中主机A中PING192.168.0.7,或者主机B关机了,在主机A中PING192.168.0.5都会得到超时的信息。
b.对方与自己不在同一网段内,通过路由也无法找到对方,但有时对方确实是存在的,当然不存在也是返回超时的信息。
c.对方确实存在,但设置了ICMP数据包过滤(比如防火墙设置)怎样知道对方是存在,还是不存在呢,可以用带参数-a的Ping命令探测对方,如果能得到对方的NETBIOS名称,则说明对方是存在的,是有防火墙设置,如果得不到,多半是对方不存在或关机,或不在同一网段内。
d.错误设置IP地址正常情况下,一台主机应该有一个网卡,一个IP地址,或多个网卡,多个IP地址(这些地址一定要处于不同的IP子网)。
但如果一台电脑的“拨号网络适配器”(相当于一块软网卡)的TCP/IP设置中,设置了一个与网卡IP地址处于同一子网的IP地址,这样,在IP 层协议看来,这台主机就有两个不同的接口处于同一网段内。
当从这台主机Ping其他的机器时,会存在这样的问题:A.主机不知道将数据包发到哪个网络接口,因为有两个网络接口都连接在同一网段。
B.主机不知道用哪个地址作为数据包的源地址。
因此,从这台主机去Ping其他机器,IP层协议会无法处理,超时后,Ping就会给出一个“超时无应答”的错误信息提示。
但从其他主机Ping这台主机时,请求包从特定的网卡来,ICMP只须简单地将目的、源地址互换,并更改一些标志即可,ICMP应答包能顺利发出,其他主机也就能成功Ping通这台机器了。
Destination host Unreachable对方与自己不在同一网段内,而自己又未设置默认的路由,或者网络上根本没有这个地址,比如上例中A机中不设定默认的路由,运行Ping192.168.1.4就会出现“Destination host Unreachable”。
PING时延不达标问题处理

PING时延不达标处理一、问题描述在泉州电信FDD-LTE网络新开站点单验时,出现测试PING业务时延不达标。
二、问题影响影响单验进度,不能真实有效测量出该站点用户面时延三、问题分析在进行ping业务测试中,出现ping时延过大,无法达到验收标准,面对问题,先确保设备连接正常,再通过观察时延情况,一步一步进行原因排查常见时延表现有以下几种情况:1. 第一次时延过大,随后的时延正常,导致平均时延不达标;2. 时延远远大于标准值,查看电脑速率监控,排除有大流量业务存在的问题;3. 时延较大或者ping不断失败,更换服务器做ping业务,排除服务器问题;4. 时延跳动较大,查看该点信号变动情况,排除信号不稳定问题;5. 时延稍微大于标准值,查看mifi的DRX是否关闭,排除设备设置问题;6. 时延及上传下载业务不正常,感受电脑及mifi温度,排除测试设备过热问题;7. 排除设备、服务器、测试方法没问题后,测试该站点其它RRU及同BBU下其它站点的RRU是否正常,进一步确认问题所在。
四、问题处理1、因为第一次ping的时候,需要寻址和寻找路由,这中间需要消耗点时间,建议重新做ping业务;2、先关闭大流量业务,再重新做ping业务;3、测试之前准备几个服务器,更换服务器或者使用外网地址重新做ping业务;4、重新找点,不要求找极好点,但尽量找稳定的点,就是在同一个点,信号跳动较小,然后再重新做ping业务;5、关闭mifi的DRX功能(关闭方法见附件1),然后再重新做ping业务;6、重启电脑及mifi,重新连接设备,然后再重新做ping业务;7、联系工程督导协助排查。
8、问题解决,PING时延业务合格,请及时向有关人员反馈进度。
五、总结建议排除问题时由简单到繁琐,将整个过程分为一步步去排除,首先要确保自己测试方法没问题,再排除测试设备、服务器和测试点等外部因素,最后再考虑是基站设备问题。
PING大包丢包网络故障分析案例解决方案

PING大包丢包网络故障分析案例解决方案网络故障是在使用网络过程中经常会出现的问题,其中大包丢包是一种常见的网络故障。
大包丢包指的是在网络传输过程中,发生了传输较大包的数据丢失的情况。
接下来我将进行一个关于大包丢包的网络故障分析案例,并提供相应的解决方案。
案例分析:公司A部门反馈在办公网络中使用视频会议时,经常出现画面卡顿和断流的问题。
在进行网络故障排查的过程中,发现了存在大包丢包的情况。
问题分析:大包丢包会导致网络传输不稳定,影响视频会议等带宽需求较高的应用。
造成大包丢包的原因主要有以下几点:1.网络拥塞:当网络带宽使用过高时,可能会造成网络拥塞,从而引发大包丢包问题。
2.路由器配置错误:路由器可能会存在配置错误,导致无法正确转发大包数据,从而引发大包丢包问题。
3.网络设备故障:路由器、交换机等网络设备可能存在故障,导致无法有效处理网络数据,从而引发大包丢包问题。
解决方案:针对以上问题,可以采取以下解决方案:1.网络监控与优化:通过网络监控工具对网络流量进行实时监控,及时发现网络拥塞问题。
在网络拥塞时,可以考虑对网络带宽进行扩容,以保证网络的稳定性。
2.检查路由器配置:对路由器进行检查,确保其配置正确。
可以参考厂商提供的配置文档,根据网络需求合理设置路由器参数。
同时,也可以考虑升级路由器固件,以确保设备的正常工作。
3.检查网络设备故障:定期对网络设备进行巡检,发现故障及时进行修复或更换。
例如,使用专业的网络测试工具对路由器、交换机等设备进行故障检测,确保其正常运行。
4.优化网络拓扑:对网络拓扑结构进行优化,确保网络中的数据传输路径短且流畅。
通过优化网络拓扑,可以减少数据传输的时延,从而降低大包丢包的发生概率。
5.加强网络安全:网络安全问题也可能导致大包丢包问题。
加强网络安全措施,防范网络攻击与入侵。
例如,使用防火墙、入侵检测系统等安全设备,对网络数据进行过滤和监测。
总结:大包丢包是一种常见的网络故障,可能会对网络传输稳定性产生严重影响。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
某公司网络PING延迟故障案例解析
一、故障描述
故障地点:
石家庄某公司
故障描述:
网络通讯严重阻塞,用户访问外网服务器以及互联网的速度均非常缓慢,甚至不能访问,PING 网关延期。
如图:
二、故障详细分析
1. 前期分析
初步判断引起问题的原因可能是:
●ARP病毒
●网络病毒攻击
开始实际工作配差
1、登录到各交换机,查看内存及CPU的利用率,均正常。
2、通过OMNIPEEK捕获并分析网络中传输的数据包,具体过程如下。
在核心交换机上做好端口镜像,启动OMNIPEEK,约3.08分钟后停止捕获并分析捕获到的数据包。
XX公司网的主机约为300台,一般情况下,有200台左右上网,等停止分析后,我们在OMNIPEEK主界面左边的节点浏览器中发现的主界面查看,在EXPERT的Hierarchy中查看,诊断tcp connection refused时间竟然达到了5731个,感觉很是不对。
如图:
进行定位查看,发现有一台计算机极为不正常如图:
由以上看到,可能被外部的DDOS攻击,可能是此计算机感染病毒,进一步查看如图:
可以看到外网计算正在通过135端口正在扫描此计算机,因此可以断定正在被DDOS攻击,此计算机一定感染了木马之类的蠕虫病毒。
找到问题的根源后,正准备对CAI2主机进行隔离,过了一会儿,再次PING网关,还是延迟,但不是太严重了,感觉还是有计算机感染病毒或有ARP攻击,随即再次分析此包,但最终没
有找到可疑的计算机,其间也关闭了几个流量有问题的计算机,但问题还是不能解决,正在百思不得其解时,突然脑子一动:何不尝试着通过分析我自己的计算机,再排查故障呢?
于是笔者选择了科来网络分析系统6.7试用版啊?(笔者只有50个用户的抓包,因此刚开始选择了OMNIPEEK。
)设置好过滤条件,这里为什么选在192.168.1.1呢,笔者怀疑是不是有人设置了和网关相同的IP地址呢?选择如下图:
打开自己的计算机进行PING,然后用科来进行抓包,58秒后如下图:
其中8c:68是笔者计算机的MAC,09:37为网关MAC,突然多出了一个A9:4D.查看分析如图:
怎么A9:4D会作为网关呢?请教此公司管理员,得知核心交换机到网关在无其他设备了,因此感觉此计算机是自己设错了IP地址,将自己计算机的IP地址设为了网关IP地址。
三、解决与心得分
解决:
1、找到此计算机,果然是设置了与网关相同的IP地址,管理员对其进行了严重警告。
2、先前CAI2的计算机感染了木马病毒,通过360进行扫描,查杀后问题解决。
然后打包PING网关,一些OK
心得:
对于网络出现的问题,要认真分析,相信自己判断,多用几款协议分析软件是很用用的啊!
以上便是笔者使用科来和OMNIPEEK诊断该公司网故障的全过程,在网络出现速度慢、时断时续、不能访问时,网管人员均可使用这种方法对故障进行诊断排查。
飞雪
2008-5。