网络丢包现象分析处理指导书6

铁通某网络故障分析报告

xiong2127 51cto技术博客

一、所遇问题描述

xiong2127 51cto技术博客

xiong2127 51cto技术博客

如上图所示,交换机端口1：1－1：12、2：1－2：8在同一个VLAN中，网关指向CISCO7206的下行端口FA0/0的IP。另外1：13下接一个大客户，1：14下接一个大客户，他们的网关指向BIG400上本VLAN的IP，也就是说这两个大客户是在BIG400上作三层转发，所以他们的ARP广播是不会影响CISCO7206的。

xiong2127 51cto技术博客

客户运维工程师向我们反映一下问题：

xiong2127 51cto技术博客

问题一：在用户侧PC执行ping指令到BIG400上的VLAN的IP，出现ping几个包就会出现一个延时比较大的ICMP REPLY的报文。改ping上端CISCO路由器的IP有时也如此。

xiong2127 51cto技术博客

问题二：如图一所示，在BIG400上端连接的是CISCO7206路由器。一段时间以来先后两次发现下面的用户上网时出现丢包的情况，此时查看CISCO7206的ARP表发现ARP表满，他们清空ARP表后用户上网出现正常。

xiong2127 51cto技术博客

二、问题分析与逐一解答

xiong2127 51cto技术博客

问题一：在用户侧PC执行ping指令到BIG400上的VLAN的IP，出现ping几个包就会出现一个延时比较大的ICMP REPLY的报文。改ping上端CISCO路由器的IP有时也如此。

xiong2127 51cto技术博客

答：先看PING到BIG400的VLAN IP的情况：在交换机中为了保证设备转发正常业务流的高优先级，我们在设备中作了设置(系统出厂缺省)凡是PING CPU也就是本地Vlan IP的报文优先级比较低，优先保证设备转发用户底业务流。所以，PING本机VLAN的IP时出现一定的延时是正常的，用户不用担心。

xiong2127 51cto技术博客

再看客户提到的PING上端路由器的FA0/0的IP，有时也出现一定的延时的情况。当时我接到客户的这个问题后登陆到BIG400看了一下配置，发现BIG400上FDB（MAC地址表）老化时间改为10秒了，系统缺省为80秒。经咨询这个参数是当时开始测试BIG400时设置上的。8月17日修改到80秒系统缺省参数后，8月18日我们观察时就没有出现延时包。

xiong2127 51cto技术博客

再多说几句，如果您从BIG400上执行PING指令到CISCO7206，因为源IP仍未BIG400的CPU的IP，所以还是象刚才谈到的设备对这种数据的优先级问题，毕竟ICMP是一个双向协议。另外，执行这样的PING指令到CISCO7206的FA0/0即使出现偶尔的延时的情况，从技术角度讲也是正常的，因为宽带网络中难免有突发流，CPU的利用状况出现一定程度的抖动是常见的。

xiong2127 51cto技术博客

问题二：如图一所示，在BIG400上端连接的是CISCO7206路由器。一段时间以来先后两次发现下面的用户上网时出现丢包的情况，此时查看CISCO7206的ARP表发现ARP表满，他们清空ARP表后用户上网出现正常。可以看出是因为CISCO7206受到大量的“伪”ARP广播的影响导致CPU资源紧张，最终导致转发数据丢包。所以，找到和切断使CISCO7206的ARP表满的元凶是解决问题最好的方法！

xiong2127 51cto技术博客

（真实环境下实际上是两台路由器，铁通是采用了思科的HSRP热备份的技术，始终有一台保持激活工作状态。所以，对BIG400来说可以看作上端只有一台CISCO7206路由器。）

xiong2127 51cto技术博客

分析一：这些ARP广播表项是不是由BIG400产生的呢？让我们通过从现场用sniffer抓到的报文来找答案吧！
我此时在BIG400上作了一个端口镜像：把BIG400的上联端口1：1 镜像到端口1：5，在1：5端口上连接我的笔记本，打开sniffer程序开始抓包，然后查看抓到的报文。如图2所示：

xiong2127 51cto技术博客

xiong2127 51cto技术博客

 

xiong2127 51cto技术博客

就象图2这样，在sniffer抓到的报文中没有由BIG400发出的异常的大量的ARP报文。说明这些大量ARP并不是由于BIG400发出，再者，BIG400作为一台交换设备，对外发大数量级的“伪造”ARP广播的可能性从技术也讲不通。

xiong2127 51cto技术博客

那么我们分析看，BIG400下面的Vlan yazhou和Vlan shilongtv两个VLAN的用户因为是通过BIG400作三层交换的，所以他们的ARP广播不会透过三层本VLAN的。

xiong2127 51cto技术博客

最后再来看看图1的网络拓扑，大家可以看到从端口1：1－1：12、2：1－2：8下面连接了大量的铁通机房用户，而这些端口和上面的CISCO7206路由器的FA0/0端口都属于一个VLAN，也就是处于一个广播域内。大家思考一下，如果BIG400上这些端口上的用户设备发出大量ARP广播时，因为BIG400对于这些用户来说是二层，所以BIG400上不会生成这些ARP表项，而作为他们网关（或路由下一跳）的CISCO7206来说将生成大量的ARP表项。

xiong2127 51cto技术博客

从上面的分析看到如果这些异常的ARP广播是在Vlan uplink这个大的广播域里产生的，那么CISCO7206的ARP表就会受到冲击。那么，是不是的确这些ARP广播是从这里发起的？如果是从这里发起的的话，那么是计算机中了病毒还是有人蓄意攻击？这两个问题我不敢武断的判断！需要铁通的维护工程师们最后确定！毕竟这些ARP广播正如铁通机房的维护工程师所说并不是总发，我去现场的偶然时间里也没有发现狂发ARP的设备。但我的怀疑是建立对在实际的网络拓扑的分析以及对当时抓的包的分析基础上的。那好，让我们先看看当时在Vlan uplink这个大广播域中抓到的包吧！

xiong2127 51cto技术博客

我此时把刚开始在BIG400上作的端口镜像功能删掉了，也就是说从端口1：5上抓到的包就是充斥整个Vlan uplink当然还包括CISCO7206的FA0/0端口的数据包。我截取一个典型的情况给大家看：如下图3

xiong2127 51cto技术博客

xiong2127 51cto技术博客

 

xiong2127 51cto技术博客

 

xiong2127 51cto技术博客

大家看到了，这是一个“扫描程序”！

xiong2127 51cto技术博客

从报文的源IP、目的IP可以看出，这些包都是从一个IP地址为63.230.122.145的主机发出，目的IP是采用“遍历”方法针对211.98.168.0网段扫描，这个网段是属于广州铁通。另外，从sniffer的rel. time一栏可以看出发包的频率是相当的快！大家再看图3中sniffer的分析中（上图点黑处）指示这些遍历搜索的端口号是TCP的1433端口，也就是MS-SQL-Server的通信端口。可见这是在利用MS－SQL－Server的漏洞进行的搜索。

xiong2127 51cto技术博客

这时，你不禁要问了：“这个包来自那里呢？”

xiong2127 51cto技术博客

分析：首先假设这些包不是有人制造出来的的，那么63.230.122.145这个IP就是一个真实存在的主机的IP地址，我们利用Trace跟踪的手段就能查询出这个IP的来源。我当时用跟踪软件跟踪的结果如下图4所示：

xiong2127 51cto技术博客

xiong2127 51cto技术博客

 

xiong2127 51cto技术博客

显示IP为63.230.122.145的主机是位于美国卡罗拉多州的某个地方。但，这些报文这是从这里发出的吗？答案是“否”！

xiong2127 51cto技术博客

让我们从图3中sniffer抓到的包中找原因。回头看看图3中的MAC地址部分，可以看到在这条报文中，目的MAC为00-e0-fc-02-12-b7，源MAC为00-d0-63-52-d0-00；经过查询BIG400的FDB表和CISCO7206的ARP表源MAC是CISCO7206的，然而目的MAC却是这个一个不存在的MAC地址，而且翻阅sniffer抓到的包，发现这个目的MAC有时变为：00-e0-fc-02-12-b6，显然是人为制造的一个在此网络并不存在的MAC地址，所以这个包不可能是路由器的外部发出的，因为对于一个并不存在的MAC地址，路由器作三层转发时是无法完成二层MAC地址部分的再次封装的。所以说这些报文是在Vlan uplink下面连接的这个大广播域中发出的。这些报文势必对处在一个广播域中的CISCO7206路由器造成一定的影响。

xiong2127 51cto技术博客

这只是我当时偶然在抓到的报文发现的一个问题。在此提出希望能引起铁通维护工程师的注意！当然从抓到的报文看这些搜索IP的报文并没有产生大量的ARP广播，但大家想想看如果这个搜索IP的软件或病毒等换成了那个产生ARP广播的软件或工具，CISCO7206的ARP表项突然变满也就不奇怪了。

xiong2127 51cto技术博客

附：BIG400当时的FDB表（MAC地址表）
tietong(config)# sh fdb
------- Begin of Mac Address Table Information (all)-------

xiong2127 51cto技术博客

Mac address        Port  Vlan name                      Flags     
------------------ ---- ------------------------------ --------------------
00:05:3b:18:02:e5  <0:0> default                        System CPU Permanent
00:07:eb:9b:5a:34  <1:13> yazhou                         Age
00:05:3b:18:02:e5  <0:0> yazhou                         System CPU Permanent
00:b0:d0:d1:f7:36  <1:14> shilongtv                      Age
00:b0:d0:d1:29:a8  <1:14> shilongtv                      Age
00:b0:d0:d1:29:ab  <1:14> shilongtv                      Age
00:b0:d0:d1:29:a1  <1:14> shilongtv                      Age
00:05:3b:18:02:e5  <0:0> shilongtv                      System CPU Permanent
00:e0:63:9b:ab:fd  <1:14> shilongtv                      Age
00:e0:4c:55:0b:60  <1:14> shilongtv                      Age
00:20:78:02:b3:3d  <1:14> shilongtv                      Age
00:90:0b:01:53:f0  <1:14> shilongtv                      Age
00:50:ba:29:3d:98  <2:5> uplink                         Age
00:02:a5:6b:c8:fe  <2:1> uplink                         Age
00:50:ba:09:2a:c7  <2:5> uplink                         Age
00:e0:fc:02:12:b4  <2:5> uplink                         Age
00:b0:d0:bc:e5:dc  <2:5> uplink                         Age
00:e0:fc:02:04:e8  <2:5> uplink                         Age
00:02:a5:f3:59:36  <2:1> uplink                         Age
02:01:00:00:00:00  <1:11> uplink                         Age
00:c0:49:10:e2:02  <1:8> uplink                         Age
00:e0:1e:68:6a:64  <1:9> uplink                         Age
00:04:27:8c:5a:41  <2:1> uplink                         Age
00:02:a5:f3:4e:5c  <2:1> uplink                         Age
00:e0:fc:01:3c:0a  <2:5> uplink                         Age
00:10:a4:17:e1:f5  <2:1> uplink                         Age
00:e0:fc:02:54:ec  <2:1> uplink                         Age
00:10:7b:7f:05:6b  <2:1> uplink                         Age
00:e0:4c:72:b6:42  <2:1> uplink                         Age
00:00:21:f2:86:32  <1:11> uplink                         Age
00:d0:b7:b6:7d:f6  <2:1> uplink                         Age
08:00:20:a8:5f:bd  <2:1> uplink                         Age
00:00:21:f2:6c:b0  <1:11> uplink                         Age
00:02:b3:33:61:3f  <2:1> uplink                         Age
00:04:4d:06:87:41  <2:1> uplink                         Age
00:03:47:97:fb:2f  <1:6> uplink                         Age
00:d0:63:52:d0:00  <1:1> uplink                         Age
00:d0:b7:a7:51:7a  <2:1> uplink                         Age
00:e0:fc:02:12:ce  <2:5> uplink                         Age
00:d0:b7:89:c6:c5  <2:1> uplink                         Age
00:80:c8:f6:04:b2  <2:1> uplink                         Age
00:b0:d0:b0:80:0c  <2:1> uplink                         Age
00:e0:fc:02:12:3d  <2:5> uplink                         Age
00:00:b4:bf:de:20  <2:1> uplink                         Age
00:03:47:c1:95:0e  <2:1> uplink                         Age
00:90:8f:00:b5:03  <2:1> uplink                         Age
00:05:3b:18:02:e5  <0:0> uplink                         System CPU Permanent
00:02:a5:6b:a0:ee  <2:1> uplink                         Age
00:10:78:00:03:b4  <2:1> uplink                         Age
00:00:ba:41:8d:37  <2:1> uplink                         Age
00:90:27:e6:6a:5e  <2:1> uplink                         Age
00:00:0c:07:ac:01  <1:1> uplink                         Age
00:02:17:6b:ac:00  <1:3> uplink                         Age
00:c0:49:10:df:24  <1:7> uplink                         Age
00:90:27:a7:e5:7e  <2:1> uplink                         Age
00:02:c3:10:03:29  <2:1> uplink                         Age
00:02:c3:10:03:28  <2:1> uplink                         Age
00:e0:fc:00:00:04  <2:1> uplink                         Age
00:01:af:00:96:6c  <2:3> uplink                         Age
00:02:b3:09:39:44  <2:1> uplink                         Age
00:02:a5:6b:bd:c8  <2:1> uplink                         Age
00:d0:b7:a7:ce:98  <2:1> uplink                         Age
00:08:02:01:26:ee  <2:1> uplink                         Age
00:d0:b7:89:23:d8  <2:1> uplink                         Age
------------------ ---- ------------------------------ --------------------
Total 64 mac address entry showed.

xiong2127 51cto技术博客

另外，在我看来网络中还有些“不太干净”的地方。当然，这些也许是铁通用户设备的某些特殊应用。本着负责的态度在此提出和铁通运维技术工程师共同探讨一下。

xiong2127 51cto技术博客

xiong2127 51cto技术博客

 

xiong2127 51cto技术博客

还是在BIG400的1：5端口上抓的包。看到一个MAC地址为02-01-00-00-00-00的设备向网络中发大量广播包，这个MAC地址通过核查BIG400的FDB表看到连接在端口1：11上，数以Vlan uplink，所以这些广播包肯定也会传到上面的路由器FA0/0口。而且在后面的Ethertype以太网类型中显示“unknown”。同时，大家可以从图5看到有一个DELL B0800C的设备（查sniffer中的报文后得知MAC地址为00-b0-d0-b0-80-0c）也发出类似的这种广播报文。

xiong2127 51cto技术博客

综述：通过上面的分析可以看到，在BIG400的与上端直联的联路由器所处的大广播域（Vlan uplink）中存在一些值得铁通运维人员们关注的东西。特别是目前已经碰到的ARP大量冲击CISCO7206的问题，更提醒我们必须考虑一些解决的方法！

xiong2127 51cto技术博客

 

xiong2127 51cto技术博客

三、建议解决方案

xiong2127 51cto技术博客

1、如果能找到是谁产生了大量的ARP广播，导致了CISCO7206路由器的ARP表异常，就可以灭绝造成破坏的源头了。
当再次出现ARP表异常时，抓下某些具有代表性的ARP表。查看其MAC地址是什么，在根据这些MAC查找这些设备在何处。从而查找是何种原因向外发送异常的ARP广播，有针对性的采取措施加以制止。

xiong2127 51cto技术博客

在查找设备的时候可以充分利用BIG400的一下指令协助您的工作：show fdb(查询MAC地址表)、show arp、show cpu us（查询BIG400的CPU利用率）。

xiong2127 51cto技术博客

2、如果能切断ARP广播的“路径”，也可以起到保护CISCO7206的作用。

xiong2127 51cto技术博客

此方法就是改变现有的BIG400上的拓扑，只保留上联端口1：1在Vlan uplink中，其余的用户全部通过划分VLAN加以隔离，在BIG400上作三层转发。这样作优点在于：保护了CISCO7206免受这些用户的任何广播包；同时，不好的地方在于：并没有从根源上制止这些ARP异常广播的产生，虽然对CISCO7206来说异常ARP广播是没有了，但在BIG400上却同样会出现类似的影响。

xiong2127 51cto技术博客

所以，最好上述两种方法同时结合使用。从根本上制止并切断任何潜在的，异常的ARP广播传播途径！
让我们并肩携手、群策群力，在最快的时间内排除目前的所有问题！

某油田网络故障分析报告

xiong2127 51cto技术博客

一、网络拓扑图示意图

xiong2127 51cto技术博客

xiong2127 51cto技术博客

 

xiong2127 51cto技术博客

 

xiong2127 51cto技术博客

二、网络存在问题

xiong2127 51cto技术博客

big400出口在网络高峰期时上网速度慢、严重丢包，但big400直连网段之间用户通信正常。

xiong2127 51cto技术博客

 

xiong2127 51cto技术博客

三、检查信息中心网络的健康状况发现的问题
1、Big400与直连出口设备NetScreen100之间的端口问题

xiong2127 51cto技术博客

Big400端口port3:15状态：auto off，100M，full；

xiong2127 51cto技术博客

出口防火墙NS100端口trust状态：auto on，100M，half。

xiong2127 51cto技术博客

两边状态不一致，是造成大流量丢包的原因之一。

xiong2127 51cto技术博客

目前已将Big400和Netscreen100之间的端口状态设为100M，全双工。

xiong2127 51cto技术博客

2、Big400、NS100路由配置问题
Big400作为全网的核心交换，上面存在全网路由信息，包含：

xiong2127 51cto技术博客

172.16.0.0/24――172.16.31.0/24直连路由

xiong2127 51cto技术博客

默认缺省路由，下一跳指向NS100。

xiong2127 51cto技术博客

NS100作为出口设备，包含路由信息：

xiong2127 51cto技术博客

172.16.0.0/16(汇聚路由），下一跳指向big400

xiong2127 51cto技术博客

默认缺省路由，下一跳指向internet。

xiong2127 51cto技术博客

从上面两设备的路由配置，可以发现，当big400下连用户发wins报文（目的IP为172.16.255.255）或进行主机扫描（目的IP为172.16.32.0－－－172.16.255.255 ）时，会造成报文在big400和NS100之间循环转发，直到TTL为0才将报文丢弃！因此，大量的垃圾报文拥塞big400与Netscreen之间的链路，而且NetScreen需要为这些报文做会话连接，加重了NetScreen的负载。

xiong2127 51cto技术博客

见下图，在Big400出口链路用协议分析仪sniffer捕获的报文：

xiong2127 51cto技术博客

 

xiong2127 51cto技术博客

xiong2127 51cto技术博客

 

xiong2127 51cto技术博客

以上Big400和NG100路由存在的问题，可以在Big400上添加一条汇聚路由172.16.0.0/16指向一个空接口来解决。因为，根据路由最长匹配原则，172.16.0.0/16网段中包含的具体路由如果在Big400上不存在，则会匹配到该汇聚路由，从而将相应报文丢弃，不再往NS100转发。消除了非法报文循环转发的隐患。

xiong2127 51cto技术博客

四、网络目前存在问题
以上两问题已得到解决。但是在网络高峰期，Big400出口仍有丢包。

xiong2127 51cto技术博客

怀疑NS100的处理能力有限所致。测试时抛开Big400，NS100直连用户在网络高峰期上网出现严重丢包。此时，重启NS100，网络一切恢复正常。9月14日晚上10：20左右重启NS100后，经过24小时监控，直到9月15日晚上11：00网络运行一切正常。在9月15日晚，网络高峰期（出口流量21Mbps），网络未发现异常。

xiong2127 51cto技术博客

因此，需要特别关注NS100的处理能力、数据流的处理机制，为彻底解决中原油田信息中心的网络问题找出根源！

xiong2127 51cto技术博客

五、信息中心网络问题处理建议

xiong2127 51cto技术博客

1、尽快跟NetScreen厂家联系，查找NetScreen100存在的问题

xiong2127 51cto技术博客

从测试中发现，每当网络出现故障时，重启NS100，则网络恢复正常。因此值得怀疑NS100作为网络中心的出口防火墙，其会话处理能力、数据转发能力是否足够？NS100上面配置的策略是否合适？针对目前信息中心的网络情况是否有更优的解决方案？这都需要跟NetScreen厂家做深入的探讨。

xiong2127 51cto技术博客

2、做好网络规划，使得网络具有良好的伸缩性

xiong2127 51cto技术博客

由于信息中心的网络规模不断的扩大，需要对整网做远景的规划，使得网络具有良好的伸缩性。其中路由规划是重点，网络从原来的平面结构变成多层次的结构为以后的建设迈出了重要的一步。

xiong2127 51cto技术博客

Big400作为核心三层交换机，具有全网的路由信息，其他设备接入到核心网络时，路由需要详细的配置，以防出现上述发现的路由环路问题。

xiong2127 51cto技术博客

3、与Big400互连的设备注意端口的工作状态

xiong2127 51cto技术博客

为了使设备的端口工作于最佳状态，Big400上的所有端口已将自协商关闭。因此，当有新的设备接入到Big400时，将注意对端设备的端口状态，确保设备之间的端口状态一致。

某企业“不可能”网络故障分析报告

xiong2127 51cto技术博客

xiong2127 51cto技术博客

 

xiong2127 51cto技术博客

该网络为电信营业点，营业终端通过hub接入，上行链路采用以太口接入到机房的cisco2513路由器上，访问网络核心的数据库。

xiong2127 51cto技术博客

故障描述及排障过程

xiong2127 51cto技术博客

电信营业点处于住宅区内，在运行一段时间之后，出现故障：所有终端连续几天从晚上7时许开始不能连接数据库。接到报障后感到不可思议，当天晚上同事到现场排除故障，终端不能ping通网关。

xiong2127 51cto技术博客

检查路由器的配置，没有问题。晚上进行故障排除。到现场的终端用：ping 192.168.2.14 �Ct连续ping 网关，出现一个奇特的现象：大约一分钟之内，timeout；之后偶儿能ping通，随着时间的增加，能ping通的次数越来越多，到后来（大约3分钟）全都ping通，没有timeout。

xiong2127 51cto技术博客

用控制口登陆路由器，检查配置文件，接口状态、内存、路由器负载，一切正常。用show arp，发现所有活跃的终端地址在路由器的arp表中的生存时间一致，都很短（一分钟左右，大约是终端PING通网关后的时长）；是否在没有PING通之前，路由器没有存在活动终端的ARP表？若是这样，表明在不通之时，路由器没有收到终端的ARP广播，或者终端根本没有发ARP请求？

xiong2127 51cto技术博客

在路由器上debug arp，发现始终三台终端（192.168.2.3）120秒发ARP请求，网关给以回答，另一台长时间没有发ARP请求。在终端ping通网关之后，业务受理正常，故障没有出现。

xiong2127 51cto技术博客

为此进行人工故障重现：切断路由器与HUB的连线，在路由器上clear arp，debug arp；重启动所有终端，启用sniffer进行捕捉,在终端启动之后，将路由器与hub的连线接上，在终端连续ping网关，timeout，在这期间，sniffer没有捕捉到数据包，路由器的debug没有输出，过一段时间，有几个包能ping通网关，sniffer捕捉到这几个包，ARP的debug有输出。在过一段时间，所有的包都能PING通网关。

xiong2127 51cto技术博客

该故障重现证明了终端PING不通网关的原因：路由器没有受到ARP请求。为什么？根据在终端没有ping 通网关时候，sniffer没有捕捉到包，对于HUB ，终端发的包sniffer应该捕捉到，捕捉不到有：HUB问题、线问题、终端问题。再进行故障重现，用笔记本与自己的连线连接HUB，故障重现；将笔记本直接接在路由器，PING通网关没有timeout，故障定位在HUB。

xiong2127 51cto技术博客

故障的可能是HUB的热稳定性问题，当加电时间长，HUB出现不稳定，故障出现。营业点在更换HUB之后，故障依旧；再次分析sniffer捕捉数据包（ICMP），发现终端向网关正常发ICMP 的eoch包，有时网关没有回复。既然sniffer与终端、路由器接在同一个HUB上，sniffer能捕捉到终端发的数据包，说明HUB与终端、工作站的连接正常；根据反映，工作站之间的连接是正常的；问题出在哪？

xiong2127 51cto技术博客

从分析结果，终端发94个包，路由器回45个，有49个包没有回复。为什么路由器没有回复这49个包？是路由器问题，还是其他问题？可以通过以下进行测试：

xiong2127 51cto技术博客

断开路由器与HUB的连接，对路由器clear ip accounting。重启终端，启用sniffer进行数据包的捕捉，连接路由器与HUB，在终端用连续ping网关，若路由器进出的记数一致，但终端有timeout，sniffer捕捉到的数据包不一致，则表明路由器没有问题，问题可能出现在路由器与HUB的连接上，可能是AUI转换器。若路由器进出数据包不一致，则表明路由器接口或路由器有问题。经过测试，进出路由器接口数据包一致，但数据包的数量比终端发出的数据包少，这表明路由器没有问题，问题在AUI转换器或HUB。

xiong2127 51cto技术博客

更换AUI，故障仍存在，再次更换HUB，故障不变；在白天按在晚上故障重现方法进行故障重现，故障不能重现。结合故障发生都在晚上7点前发生，很有规律性，因此判断最大可能是网络运行环境问题。由于整个营业点设备使用的电源都经过稳压器进行稳压后供电，所以对于电源问题一直认为可靠。但是根据这几天对故障的分析排查，我们认为营业点的稳压器仅对电源进行稳压，没有进行浪涌吸收、过滤处理，在晚上7点前，刚好是用电高峰，大量电器的开启，使电源存在大量尖峰脉冲，会对逻辑门电路造成影响。

xiong2127 51cto技术博客

基于以上分析判断，考虑到UPS具有过滤电源与浪涌吸收的能力，增加一台UPS对HUB、路由器进行供电，故障立即消除。该“不可能”的故障表明在住宅区内连接网络，要重视网络运行环境，尤其是电源质量。