計算機網絡故障診斷排查探討

李光燦

（重慶三峽中心醫院信息科，重慶 404000）

0 引言

在網絡的管理運維過程中，可以說故障是不可避免的。因為網絡故障有太多的隨機性和偶然性，何況還有人為因素。所以，管理員要做的是掌握網絡排查技巧，積累經驗培養敏銳的嗅覺，少走彎路，快速定位并排除故障。下面介紹兩例網絡排查案例。

1 案例一：病毒引起的網絡故障

1.1 故障現象

局域網出現網絡不穩定故障，172.16.38.0子網中的計算機上網明顯不正常，有的計算機在訪問172.16.12.0子網中的服務器系統時，網絡連接很不穩定，經常有掉線現象，但有些計算機訪問卻很正常。更為奇怪的是，先前訪問不穩定的計算機，有時也能訪問服務器系統，不過這個時候，以前訪問正常的計算機，卻不能穩定上網了。在172.16.38.0子網中的計算機，相互之間進行共享訪問時，網絡傳輸速度很快，沒有一點異常之處。還有一點比較奇怪的是，到了晚上下班的時候，上面的故障現象立即消失不見了，第二天上班的時候，上網不穩定的現象又會出現。

1.2 故障診斷排查

難道是對應工作子網的樓層交換機出現了問題？使用telnet命令，遠程登錄該樓層交換機的后臺系統，查看了各項網絡配置，看到它們沒有任何改動。會不會是交換機的緩存有問題呢？趕到對應樓層交換機現場，斷開該設備的輸入電源，過一段時間后，接通電源重新啟動一下交換機后臺系統，這樣交換機緩存中的內容就被清除干凈了。這時，在故障計算機中進行上網測試，發現上網訪問都很穩定了，不過，持續幾天后，上網不穩定故障再次發生。

為了判斷樓層交換機自身是否正常，筆者找來一臺備用設備進行替換，之后在172.16.38.0子網中，任意找了幾臺計算機進行測試，剛開始的時候，沒有看出一點異常，幾天后，相同的故障現象又出現了。嘗試在其中一臺故障計算機系統中，使用Ping命令測試172.16.38.0子網的網關地址，看到命令返回的結果很正常，也沒有明顯的數據丟包現象。無意中運行了“arp -a”命令，看到對應子網的默認網關MAC地址為8C-A5-89-DF-70-AA。而在網絡不通的時候，繼續執行“arp -a”命令，查看默認網關地址時，該地址已經變成了02-4F-AE-3D-0B-65。在172.16.38.0子網中，又找了幾臺計算機進行同樣的測試，測出172.16.38.254地址在可以被正常Ping通的情況下，網關默認MAC地址都為8C-A5-89-DF-70-AA，而在無法Ping通的情況下，測出的網關默認MAC地址都為02-4F-AE-3D-0B-65。事實上，172.16.38.0子網的網關真實MAC地址為8C-A5-89-DF-70-AA。

為什么在不能上網的情況下，網關默認MAC地址發生了變化呢？很顯然，172.16.38.0子網中有ARP地址欺騙攻擊現象，也就是說，該子網中的某臺計算機感染了ARP病毒或木馬程序。當病毒計算機開機運行時，它會搖身成為病毒網關，影響其他計算機的上網訪問，而將病毒計算機關閉時，其他計算機的上網連接經過修復后，又能使用以前的默認網關，進行上網連接了。

1.3 故障解決

弄清楚故障原因后，筆者找來nbtscan工具，使用“nbtscan-r 172.16.38.0/24”命令，獲得對應子網中所有計算機IP地址和MAC地址的列表，從中找到了IP地址為172.16.38.121這臺計算機，它的網卡物理地址為02-4F-AE-3D-0B-65，很明顯，就是這臺計算機影響了整個子網上網不穩定。將該計算機從網絡中斷開，繼續在172.16.38.0子網中的多臺計算機中進行一個小時的上網測試，果然故障現象再也沒有發生。

后來，使用最新版本的殺毒軟件，對帶毒計算機進行全面查殺病毒時，還真掃描到一些病毒，可是殺毒軟件無法直接刪除它們。筆者只好對病毒計算機的硬盤進行格式化操作，并重新安裝了操作系統，再將該計算機接入到172.16.38.0子網中時，看到網絡工作一切正常。

1.4 排查總結

從上面的故障排查過程來看，在對付由ARP病毒引起的各類網絡故障時，不妨巧妙利用Windows系統自帶的arp、Ping命令，同時配合nbtscan之類的網管小工具，來進行診斷，這樣或許能大大提升網絡管理維護效率。

2 案例二：網絡訪問丟包之謎

2.1 故障現象

局域網中一臺計算機上網訪問時，上網速度沒有以前那樣順暢了，在使用MSN在線交流時，也遇到了無法登錄的現象。嘗試使用Ping命令測試局域網網關地址時，看到雖然能夠正常Ping通，但偶爾會出現延遲現象。使用大容量的Ping數據包進行持續測試時，會看到網絡訪問存在明顯的丟包現象。

2.2 故障診斷排查

用隨身攜帶的筆記本電腦，連接到故障計算機所用的物理線纜上，使用大容量的Ping數據包對局域網網關地址進行測試，發現數據包丟失現象已經消失了，這說明物理線路及交換端口工作狀態正常。看來問題出在故障計算機自身身上。筆者認為網絡配置出錯或網卡設備有問題。進入網卡設備屬性對話框，在其常規標簽頁面中，看到該設備工作狀態正常。此時已到中午下班時間，就在準備關機回家的那一刻，持續的Ping測試操作突然出現了轉機，原先的數據丟包現象，現在竟然自動消失了，網絡速度也恢復了正常。連續測試了半個小時，發現數據丟包現象再也沒有發生過，看來問題已經解決了。

2.3 故障解決

可是，第二天上班的時候，在那臺故障計算機中又看到了相同的現象，這是怎么回事呢？肯定有人搶用了故障計算機的IP地址，造成了地址沖突。不過，如果發生IP地址沖突現象時，應該會彈出沖突提示，而且發生該現象時，計算機一般都不能正常上網，但現在沒有看到這些不正常的現象！以管理員身份登錄故障計算機所連接的樓層交換機后臺系統，使用“system-view”命令進入系統全局視圖模式，在該狀態下執行“display mac”命令，所有連接到當前交換機上的計算機網卡物理地址都被顯示出來了。看到有兩臺計算機的網卡物理地址竟然一模一樣。將MAC地址相同的兩個交換端口號碼、VLAN號碼等信息記錄下來，再通過查看已有的組網資料，終于找到了與故障計算機MAC地址相同的另外一臺計算機。打開這臺計算機的網絡連接屬性對話框，查看到它的IP地址，果然與故障計算機的IP地址完全一樣，看來局域網中真的存在地址沖突現象。找到問題根源后，修改另外一臺計算機的IP地址和MAC地址。之后，在故障計算機中再次使用大容量的Ping數據包進行持續測試時，發現數據丟包現象終于消失了。

2.4 原因探究

為什么局域網中的兩臺計算機IP地址相同時，系統沒有及時彈出提示呢？通過上網查詢有關資料了解到，當兩臺計算機的IP地址和MAC地址都相同時，系統就不會產生IP地址沖突提示。而且發生地址沖突的計算機都能上網，只是會有不明顯的數據丟包現象而已，惡意用戶經常會用這種方法來竊取更高級別用戶的權限。詢問另外一臺計算機用戶得知，他就是想嘗試通過修改IP地址和MAC地址方法，看能不能突破局域網服務器對IP地址與MAC地址綁定的限制。

2.5 故障防范

對于上述故障現象，僅僅將計算機IP地址與MAC地址相互綁定在一起，根本不能防止有經驗的惡意用戶訪問單位局域網，而應該將計算機的MAC地址和IP地址與對應的交換端口進行綁定。以H3C Quidway S8500核心路由交換機為例，要將IP地址為192.168.12.156、MAC地址為53-26-4D-3C-7F-8A的計算機，綁定到核心路由交換機以太網端口Ethernet 3/2/1上時，可以在核心路由交換機后臺系統的全局視圖模式下，使用“interface ethernet 3/2/1”命令，進入指定端口視圖模式狀態，再執行“am user-bind ip-addr 192.168.12.156 mac-addr 5326-4d3c-7f8a”命令即可。

3 結束語

在信息系統的日常運行中，網絡故障在所難免，需要信息技術人員不斷積累網絡運維實踐經驗，提高解決網絡故障的效率，保障計算機網絡的正常運行。