网络故障分析：第四章 4.21某运营商网络故障解决方案分析过程

一、所遇问题描述 如上图所示 , 交换机端口 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-f c-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 B 0800C 的设备（查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广播传播途径！
让我们并肩携手、群策群力，在最快的时间内排除目前的所有问题！