解析雙向路由怪象 換思路巧妙解決路由故障
一，雙向路由信息的意義：
數據包的通訊是需要有兩個方向的，在發送數據的同時也承擔著接收數據的任務。因此當A計算機與B計算機進行正常網絡通訊時，網絡中一定擁有相關路由實現從A指向B的條目，同時也一定擁有相關路由實現B指向A的條目。一旦缺少其中一個方向的條目，那么兩臺計算機是無法通訊的，即使是最普通的PING命令檢測也是超時time out的結果。
正因為這種數據通訊的雙向性使得很多網絡管理員在配置網絡路由交換設備時頻繁出現問題，忘記雙向路由條目設置原則而造成網絡故障。所以在解決網絡故障時核對路由表以及雙向性方面的設置準確與否是非常重要的手段。
二，親身經歷網絡路由故障：
近日筆者在對旗下一個分公司的網絡進行維護時發現該下連網絡的WWW服務無法順利訪問，在IE瀏覽器里通過https加密協議通訊顯示“該頁無法打開”。(如圖1)
該子公司的網絡結構是這樣的內網計算機的IP地址范圍是XX.XX.91.1-XX.XX.91.126，其中XX.XX.91.126是出口路由器連接內網的LAN0接口IP地址，XX.XX.91.120是子公司的WWW服務器，對外提供WWW服務。(如圖2)
#p#
接下來按照傳統的辦法ping XX.XX.91.120該地址發現提示超時，但是登錄到子公司的出口路由器上PING該內網計算機卻沒有任何問題，PING完全是通的。(如圖3)
使用tracert命令跟蹤數據路由轉發情況后發現數據包到達第18跳后就出現了request timed out的錯誤提示，看來問題出在這個環節。(如圖4)
然而筆者PING該子公司出口路由器內網接口XX.XX.91.126時卻沒有任何問題，PING是正常的，而且速度和穩定性都很好。(如圖5)
#p#
三，步步為營解決路由故障：
為什么內網接口能夠PING通但是內網主機卻無法PING通呢?開始筆者也曾經懷疑是路由表條目的設置問題，但是經過判斷從外網是可以PING通XX.XX.91.126這個地址的，這說明網絡中存在著到達XX.XX.91.126所在網段的路由，路由信息應該是全的。
接下來就要從其他方面考慮了，筆者準備在子公司路由器上做設置，通過NAT實現數據轉發，同時將XX.XX.91.120這個地址以NAT SERVER的方式對外宣告出去，這樣理論上講數據包就能夠順利到達XX.XX.91.120了，畢竟經過宣告只要數據可以到達路由器外網接口就能夠順利轉發到內網相關NAT SERVER中。筆者使用nat server global XX.XX.91.120 any inside XX.XX.91.120 any ip命令完成宣告服務的任務。(如圖6)
同時利用nat outbound 2001 interface命令在外網接口上開啟NAT服務，保證nat server的順利宣告。(如圖7)
然而通過宣告NAT SERVER后問題依舊，至此筆者就再也不懷疑路由器相關路由表問題了。接下來冷靜分析發現只要在外網PING XX.XX.91.120都是不通的，而在內網或出口路由器上PING XX.XX.91.120卻沒有任何問題。筆者繼續嘗試其他主機的連通性，發現除了XX.XX.91.120有這個問題外，其他IP地址都不存在無法PING通的問題。看來故障的根源再于這臺主機。經過排查發現這臺安裝了PANABIT流量管控程序的freebsd系統自身網絡設置存在問題，沒有設置網關地址為XX.XX.91.126，使用ifconfig命令添加完畢后故障解決。
四，總結：
實際上在本次路由故障解決的全過程中筆者走了一些彎路，首先由于我是上級網絡管理者，所以無法對該子公司內網計算機的設置狀況有一個清晰的了解，在出現PING不通無法訪問的問題時也沒有及時的通過PING其他主機是否暢通來判斷是網絡問題還是主機問題，因為我自己無法判斷到底該子公司哪臺機器處于開機狀態可以PING通;另外筆者在進行tracert XX.XX.91.120時在第18跳時發現了request timed out的錯誤提示，這點迷惑了我，認為是網絡問題，路由問題。而后來的結果證實了這個推斷的錯誤性，看來以后在進行網絡維護時Tracert的結果并不能太過分相信，本例中應該再執行tracert XX.XX.91.120后再執行tracert XX.XX.91.126來判斷他們在tracert路徑上是否存在差異來快速定位故障。
【編輯推薦】
