單位網絡結構圖如圖1所示。爲了確保重要設備的穩定性和冗餘性，核心層交換機使用兩臺Cisco 4507，通過Trunk線連接。在接入層使用了多臺Cisco 3560交換機，圖示爲了簡潔，只畫出了兩臺。在覈心交換機上連接有單位重要的服務器，如DHCP、E-MAIL服務器、WEB服務器等。單位IP地址的部署，使用的是C類私有192網段的地址。DHCP服務器的IP地址爲192.168.10.1，E-MAIL服務器的IP地址是192.168.3.1。Cisco 4507和Cisco 3560之間也是Trunk連接。
圖1 單位網絡結構圖
公司根據部門性質的不同，把它們劃入到不同的VLAN中。服務器都位於VLAN 2至VLAN 10中，對應的網絡號是192.168.2.0~192.168.10.0，如DHCP服務器位於VLAN 10中，流媒體服務器位於VLAN 2中。服務器的IP地址、默認網關和DNS都是靜態配置的。VLAN 11至VLAN 100是屬於業務部門使用的，對應的網絡號是192.168.11.0~192.168.100.0。VLAN 101至VLAN 200是屬於辦公部門使用，對應的網絡號是192.168.101.0~192.168.200.0。VLAN號和網絡號之間都是對應的。VLAN中的PC都是通過Cisco 3560接入到網絡中，3560都是二層配置，三層的配置都在Cisco 4507上，也就是VLAN間的路由都是通過4507完成的。PC的IP地址、默認網關和DNS都是自動從DHCP服務器上獲得的，不用手工靜態配置。
一、故障發生的過程
公司流媒體服務器位於VLAN 2中，IP地址爲192.168.2.8/24。網絡中有權限的用戶可以進入到服務器中下載、上傳和編輯一些視頻剪輯。一天早上，業務網VLAN 12中的很多用戶反映它們部門的人員都不能訪問流媒體服務器，也不能進入服務器中流媒體應用系統的Web界面。
但是VLAN 12中的用戶訪問其它VLAN中服務器上的應用，都很正常中，如都能正常訪問VLAN 3中的E-MAIL服務器。而且辦公網和業務網中除了VLAN 12，其它VLAN中的用戶，都能正常訪問流媒體服務器，也就是隻有VLAN 12中的用戶訪問不了。因爲流媒體應用是單位業務中一項很重要的應用，若長時間不能用的話，可能會影響到公司業務正常運轉，所以必須儘快排除故障。
二、排查故障的步驟
1、通過對故障信息的收集，我們確定了網絡故障的大概示意圖，如圖2所示。不能訪問流媒體服務器的用戶IP地址的網絡號都是 192.168.12.0/24。他們訪問流媒體服務器的路徑先是到Cisco 3560，通過Cisco 4507，最後到達服務器。
圖2 存在故障的網絡示意圖
2、我們到不能訪問流媒體服務器的部門，查看了用戶的PC，發現電腦上的IP地址，默認網關、DNS都是正確的。然後我們在用戶電腦的“命令行”中執行“ping 192.168.2.8”命令，結果ping不通。然後又執行了ping VLAN 12網關地址的命令“ping 192.168.12.254”，發現能ping通。爲了確定出具體的故障部位，又在“命令行”中執行了“tracert 192.168.2.8”命令，顯示的結果如下所示：
C:\ >tracert 192.168.2.8
Tracing route to 192.168.2.8 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 192.168.12.254
2 * * * Request timed out.
3 * * * Request timed out.
上面命令的顯示結果還有27行省略了，因爲數據包不能到達目的地，後面27項和第2、3項的內容一樣。
從上面的結果可以看出，用戶訪問流媒體服務器時，數據包只能到達192.168.12.254，再往下路徑就發生了故障，不能到達目的地。從前面的介紹知道Cisco 3560上是沒有IP地址配置的，它們都是作爲二層交換機接入到網絡中的，所有三層的地址都是在Cisco 4507上配置的。也就是用戶訪問流媒體服務器的數據能到達4507，然後再往下就不知道哪出現了故障。可能是流媒體服務器故障，也可能是連接流媒體服務器和核心交換機4507之間的鏈路發生了故障。
3、爲了確定是服務器故障，還是服務器和4507之間鏈路的故障。我們把連接服務器的千兆網線接頭拔下來，然後把接頭接入到一臺狀態良好的PC上，PC上的IP地址、默認網關、DNS的配置和流媒體服務器上的配置完全一樣。接着，再次在不能訪問流媒體應用的用戶電腦上執行了“ping 192.168.2.8”，結果一切正常，網絡是通的。
4、到現在就能確定，問題出現在流媒體服務器上。不過，現在還不能確定是服務器上流媒體的應用系統有問題，還是服務器上的網絡設置方面有問題。接着我們查看了服務器上網絡方面的設置，如圖3所示，是在服務器“命令行”中執行“ipconfig /all”顯示出的結果。
圖3 流媒體服務器的IP地址配置
到這裏已基本確定引起網絡故障的原因，就是因爲在流媒體服務器的網卡上配置了兩個IP地址，其中192.168.12.18/24就是引起故障的錯誤配置。
5、在流媒體服務器控制面板的“網絡連接”中，找到和IP地址192.168.2.8對應的“本地連接”，然後雙擊“本地連接”圖標，在“屬性”→“Internet協議(TCP/IP)，屬性”→“高級”，找到了添加錯誤IP地址192.168.12.18的地方，如圖4所示。
圖4 添加/刪除IP地址示意圖
在圖4中，選中IP地址192.168.12.18，然後點擊“刪除”按鈕，就把網卡上錯誤的IP地址刪除了。這時，VLAN 12中的用戶也可以正常訪問流媒體服務器中的應用了。
三、總結
1、如圖5所示，是網絡故障期間，在流媒體服務器的“命令行”中執行“route print”命令得到的結果。其中，紅線標出的，就是上面在用戶的電腦上執行“tracert 192.168.2.8”命令後，數據包不能從流媒體服務器返回到VLAN 12用戶PC的原因所在。
圖5 流媒體服務器中的路由表
因爲在VLAN 12中的用戶PC上執行“tracert 192.168.2.8”的命令後，Tracert數據包中的目的IP地址是192.168.2.8，PC根據電腦中的默認網關地址192.168.12.254，先把數據包傳輸到Cisco 3560，然後再到達Cisco 4507。4507查看了Tracert數據包中的目的IP地址是192.168.2.8，知道它是要去往VLAN 2中的，然後4507把Tracert數據包傳輸到流媒體服務器。
當流媒體服務器收到Tracert數據包後，發現數據包的目的IP地址正是自己的IP地址，它把數據包收下後。然後根據Tracert命令的約定，它還要給VLAN 2中的用戶PC返回一個Tracert數據包，這時返回的這個數據包的目的IP地址，對應的網絡地址就是192.168.12.0/24，接着流媒體服務器就在自己的路由表查找到達目的網絡192.168.12.0/24的路由，結果它就在自己的路由表中就找到了圖5中紅線標出的路由項目，在其中它找到網絡192.168.12.0/24，是和自己的鏈路，也就是網卡直接相連的，因爲路由項目中顯示的“網關”對應項是“在鏈路上”。這種情況下流媒體服務器就不會把要返回的Tracert數據包路由到VLAN 2之外。結果VLAN 12中的用戶也就不會收到返回的Tracert數據包。
2、通常在計算機網卡、交換機和路由器的端口上都能配置兩個或多個IP地址，在前兩者上的主要作用是爲了實現連接在同一局域網上不同網段之間的通訊。一般由於一個網段中所包含的IP地址對於用戶來說不夠用，就可以採用配置多個IP地址的辦法來擴大接入到局域網中用戶的數量。而在路由器的端口上配置兩個或多個IP地址主要是實現連在同一路由器端口的不同網段的通訊，但這時要注意啓用端口上的IP重定向功能，因爲一般路由器不允許從同一端口進來的IP數據包又發回到原端口中。啓用了重定向功能，就允許在同一端口進入路由器的IP數據包由原端口再發送回去。但是在計算機網卡、交換機和路由器的端口上配置多個IP地址常常會給網絡帶來意想不到的故障，所以一般沒有特殊需求，不要在同一端口上配置多個IP地址。
3、這次公司流媒體服務器的故障也是因爲，在故障的前一天晚上，負責流媒體應用系統軟件開發的廠商在公司調試軟件，因爲軟件測試的需要，要在流媒體服務器的網卡上臨時再配置一個IP地址，技術人員就隨便配置了192.168.12.18這個地址。測試完成後，技術人員離開公司時忘了把這個IP地址刪除掉，結果就導致了第二天早上的網絡故障。
按照單位的規定，對機房服務器上每一步重要的操作，都要記錄在服務器日誌登記本上。完成操作後，要逐項查看登記本，是否把服務器恢復到了初始的正常狀態。但因爲雙方的技術人員都沒有嚴格執行機房房管理規定，從而造成了意外的疏漏。看來網絡管理無小事，必須從點滴做起，從我做起。