网络丢包现象分析处理指导书9(出处：www.ipdata.cn)

铁通某网络故障分析报告

一、所遇问题描述

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

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

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

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

二、问题分析与逐一解答

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

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

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

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

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

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

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

 

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

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

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

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

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

 

 

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

从报文的源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的漏洞进行的搜索。

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

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

 

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

让我们从图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路由器造成一定的影响。

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

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

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.

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

 

还是在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）也发出类似的这种广播报文。

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

 

三、建议解决方案

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

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

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

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

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

0人

了这篇文章

类别： 网络┆阅读( 0)┆评论( 0) ┆ 返回博主首页┆ 返回博客首页

上一篇 网络丢包现象分析处理指导书8(出处：www.ipdat.. 下一篇 网络丢包现象分析处理指导书10(出处：www.ipda..

相关文章

• 网络丢包现象分析处理指导书2(出处：www.ipd..
• 网络丢包现象分析处理指导书10(出处：www.ip..
• 网络丢包现象分析处理指导书7(出处：www.ipd..

职位推荐

• 网络工程师
• 高级网络运维工程师
• 网络运维主管工程师 - 无线领域
• 网络运维工程师
• 网络工程师

文章评论

 

 

发表评论            

昵  称：

登录  快速注册

验证码：

点击图片可刷新验证码请点击后输入验证码博客过2级，无需填写验证码

内  容：

同时赞一个

每日博报 精彩不止一点

Copyright By 51CTO.COM 版权所有