一、 故障現象
近日，單位採購了一套“藥房藥庫管理系統”，該系統基於WEB模式、採用JAVA語言開發，運行在×××環境：即數據庫在本部的服務器上，分支機構通過×××訪問。在試用了一段時間後，分支機構的員工反映：軟件運行的速度很慢，有時幾乎打不開網頁進行操作。馬上聯繫軟件開發工程師趕到現場，排查故障。
軟件開發工程師現場測試後，認爲不是軟件設計的問題，他們的系統採用JAVA語言，基於WEB模式，每一頁的數據傳輸量不超過30K，而且在數據上傳的模塊已作了相應的技術處理。看來，問題是出在本部或者是分支機構的網絡上。
二、 網絡結構分析
中心本部的局域網是二層結構，沒有劃分VLAN，採用靜態IP的ADSL方式上互聯網，帶寬爲4M，並在ADSL MODEM後面加了個“網神”防火牆（F3型），通過防火牆的路由功能共享上網；分支機構的網絡結構與本部的差不多，也部署了“網神”防火牆（F2型），是動態IP的ADSL，帶寬爲2M 。分支機構與本部是通過兩個防火牆建立的×××相聯，所有的應用系統的數據庫都部署在本部的服務器上。網絡拓撲圖見附圖。
三、 故障點排查
我單位的×××是通過硬防火牆建立的，硬防火牆的速度比軟防火牆的快得多，但其傳輸速度、質量仍取決於ADSL的帶寬 。因此，決定先檢查分支機構的網速：在分支機構的收費電腦上PING南寧的電信服務器A（筆者平時測網速都以PING南寧電信服務器的值爲標準） ，得到的PING值讓人大吃一驚，居然達到了3000MS,這樣的網速無疑是很慢的。於是在F2防火牆上關閉了其它用戶，只留下收費、藥房、藥庫三個用戶。此時三個用戶使用2M的帶寬，應該是足夠了。運行單位的內部網站，運行速度很快，幾乎沒有停頓感。再次運行藥房藥庫系統，雖然系統可使用了，但其速度仍然不能令人滿意。會不會是連接服務器的網線有問題？立刻打電話叫在本部的同事更換一條網線。可更換網線後，系統運行的速度仍無根本上的改變。難道是本部的服務器性能不能滿足需求？可服務器是2006年底才購買的四路服務器IBM X460，有2個CPU，4G內存，並做了RAID5，在×××環境下運行“藥房藥庫管理系統” 應該是毫無問題的。仔細想想，恍然大悟：本單位的內部網站是瀏覽型的，其傳輸的數據量很小，在2M的帶寬下訪問是毫無困難的；而“藥房藥庫管理系統”則不同，在分支機構的三個用戶在錄完數據後都要向本部的服務器上傳數據，其傳輸量大概是30K/S，而2M的ADSL的上傳速度是80K/S。難道要增加分支機構的帶寬才能解決問題？這太浪費了，不是解決問題的最佳辦法。看來，只有繼續排查了。
爲了從根本上解決問題，仔細研究起網絡拓撲圖，將網絡拓撲圖分成了4段鏈路，逐段分析：PING分支機構的網關，PING值是1MS，說明①段鏈路沒問題，又PING南寧的電信服務器，PING值是20MS，很正常，②段鏈路也沒問題。看來，問題不是出在分支機構的網絡上。再對③段鏈路進行測試，此時的數據流向是①②③，先PING B，這是電信局分配給本部的網關，所得的PING值爲20MS，且無斷行、丟包的現象，這說明了從分支機構到電信局端是沒有問題的；再PING C。這個IP是本地電信局分配給本部的靜態IP，它需要設置在本部防火牆F3的外網口f2上，f2通過一根網線與ADSL MDOEM相聯。所得的PING值爲30MS，應該說這個PING值是很正常的，但斷行、丟包的現象很嚴重。可以斷定，故障就出現③鏈路上。在這段鏈路上的傳輸介質是ADSL MDOEM、網線、防火牆，本着先易後難的處理原則，先檢測網線。於是，又打電話給本部的同事更換網線，然後再PING，情況照舊，這說明了不是網線的問題。現在只剩下ADSL MODEM、防火牆了，而防火牆的質量是沒問題的，因此決定檢測ADSL MODEM。致電本部的同事，叫他將ADSL MODEM與防火牆斷開，直接聯入一臺PC機，並將電信局分配的IP及網關IP填在PC的“本地連接”上，此時，PC便可直接使用互聯網。再PING D，PING值達到了20MS，幾乎沒有斷行、丟包的現象，這證明了DASL MODEM也是沒問題的。這可奇怪了，難道真的是防火牆有問題？想來想去，不得其解，萬般無奈中，決定再仔細檢查一上防火牆的配置。於是叫同事再接上防火牆，在分支機構遠程登錄防火牆F3的管理界面，仔細檢查F3的設置，當檢查到“端口設置”時，看到：內網口f3（防火牆與交換機的聯接口）設置爲強制全雙工、100M，而外網口f2（防火牆與ADSL MODEM的聯接口）爲默認設置——自適應。心裏一亮，會不會是兩個端口的工作模式不一致引起了故障？試着把外網口f2改成強制全雙工、100M，再PING D，驚喜地看到情況有了根本上的改變：PING值達到了40MS，而且幾乎沒有了斷行、丟包的現象了；又PING本部的服務器，PING值達到了60MS，也幾乎沒有了斷行、丟包的現象了。立刻運行藥房藥庫管理系統，速度快了許多，只需一分半鐘就可處理完一單業務，現在的速度完全達到了設計要求。哈，終於真正解決了故障。爲杜絕隱患，將分支 機構的防火牆F2的LAN口、WAN口都設置爲強制全雙工、100M模式。
四、故障原因解析
當初在配置本部防火牆F3的端口時，由於本部交換機的所有端口都設置爲強制全雙工、100M，所以也將防火牆內網口f3強制全雙工、100M的模式，但卻忘了將外網口f2也設置爲強制全雙工、100M的模式，而是保留了默認設置，致使外網口f2在工作中不能向強制全雙工、100M的模式適應而自動協商爲半雙工模式。我們知道，全雙工100M鏈路模式中，數據發送、接收可同時進行；而半雙工100M鏈路模式中，數據發送、接收不能同時進行。在分支機構運行藥房藥庫管理系統後，發出的數據請求經外網口f2流向本部服務器，取得的數據再經外網口f2返回分支機構，此時的數據流量將近爲30K/S，此時對本部而言，是上行流量；同時，在本部有70多臺電腦在使用互聯網，其下行流量之大是可想而知的。由於外網口f2自動協商爲半雙工，導致了數據請求、數據返回不能同時進行，數據流不對稱，造成了外網口f2很繁忙，傳輸效率低，致使藥房藥庫管理系統運行速度很慢。