網絡故障分析：第四章 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-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廣播傳播途徑！
讓我們並肩攜手、羣策羣力，在最快的時間內排除目前的所有問題！