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