路由故障在局域網(wǎng)中比較普遍,而且其影響的面也非常大,往往會導致大面積或者全局性的網(wǎng)絡癱瘓。對管理員來說,掌握路由排錯的思路和技巧是非常必要的。本文將和大家分享三例典型的不同類型路由排錯案例,希望對大家有所啟發(fā)。
案例1 不堪重負,路由器外網(wǎng)口關閉
1、網(wǎng)絡環(huán)境
某單位使用的是Cisco路由器,租用電信30MB做本地接入和l0MB教育網(wǎng)雙線路上網(wǎng),兩年來網(wǎng)絡運行穩(wěn)定,路由器也沒有發(fā)生故障。隨著網(wǎng)絡用戶數(shù)量增加,原來電信30MB已不能滿足需要,于是決定租用電信1OOMB來解決帶寬問題。電信采用光纖接入到單位機房后,使用百兆光電轉換器經(jīng)轉換后通過雙絞線接到路由器外網(wǎng)口上面,該路由器使用是千兆電口作為外網(wǎng)口,由于光電轉換器只有1O0MB,該端口連接后速度顯示100MB。
2、外網(wǎng)端口流量為零
經(jīng)過幾天的運行,管理員發(fā)現(xiàn)每天當路由器外網(wǎng)口流量超過50Mbps/s后,該端口就會
出現(xiàn)“Receive Errors” ,流量超大,錯誤信息很多。突然有一天,出現(xiàn)外網(wǎng)不能上了,
Telnet到路由器上面,發(fā)現(xiàn)電信對應的外網(wǎng)口沒有流量,顯示狀態(tài)為UP,路由器上其他端口工作正常。第一反映是電信的那邊出現(xiàn)問題了,是電話通知電信那邊查檢一下,對方很
快回應說沒有什么問題,并詢問是否光電轉換器死機了。
于是管理員將光電轉換器重啟后,故障依然。沒有辦法,只好將路由器重啟一下,故障排除。誰知,過了不到一個小時,故障又重現(xiàn)。Telnet到路由器后將該外網(wǎng)口執(zhí)行shutdown和undo shutdown后,故障排除。誰知,將所有有關病毒的安全策略應用到該端口,將tcp mss修改為2o48(廠商默認1460),故障依然出現(xiàn)。
3、故障分析
管理員發(fā)現(xiàn)在故障發(fā)生時,CPU顯示23%,Memory為33%,不算太高,關鍵是其他接口都正常工作,看樣子問題還是出現(xiàn)在這個端口上面?蛇@個端口已用了兩年了,升級擴容以前沒有出現(xiàn)端口不能正常通訊的情況,端口硬件應該是有什么問題。通過網(wǎng)管軟件對端口關閉前的流量檢測,發(fā)現(xiàn)該端口關閉前有很大的流量通過(超過80Mbps/s) ,顯示端口的錯誤信息也比較多。通過分析得知應該是網(wǎng)絡流量太大,利用率過高所致。流量超過80%后,造成端口不能正常。如果該端口能工作千兆模式下,100MB帶寬僅利用該端口10%,這樣端口可以輕松處理。
4、解決方案
在找到癥結后,推薦的解決方案是購買千兆光電轉換器代替原來的百兆設備,而且價格也比較便宜。但為了保證網(wǎng)絡運行的穩(wěn)定性,該單位決定直接購買一個千兆光口路由模塊,直接利用光纖進行通訊,減少網(wǎng)絡延時。電信則通過端口限速來控制保證提供百兆帶寬。通過一段時間運行,發(fā)現(xiàn)該端口除了有少量錯誤信息外,再沒有出現(xiàn)過端口無故關閉情況。
案例2路由器為何發(fā)包失敗
在路由器的配置過程中,經(jīng)常會碰到這樣的問題:網(wǎng)絡通信正常,路由器可以成功路
由數(shù)據(jù)包到目標網(wǎng)絡,但是從路由器發(fā)的數(shù)據(jù)包卻傳送失敗,故障表現(xiàn)為路由器ping目標網(wǎng)絡失敗,下面就是一個典型的案例。
(1).現(xiàn)象描述
某單位的網(wǎng)絡配置完成后,管理員在測試網(wǎng)絡連通性時發(fā)現(xiàn):從PC機(6.159.245.195) 向目標網(wǎng)絡(6.159.245.65/26)發(fā)送Ping時,路由器R1可以成功轉發(fā)數(shù)據(jù)包,然而從R1向目標網(wǎng)絡(6.159.245.65/26) 發(fā)送ping時,出現(xiàn)ping失敗。
(2).排錯過程
首先,跟蹤ping所經(jīng)過的路徑。檢查R1的路由表,目標地址6.159.245.65可以與路由表中0.0.0.0/0相匹配。檢查R2、R3、R4的路由表,均可以發(fā)現(xiàn)與目標地址匹配的路由表項。
然后,跟蹤ICMP回應應答數(shù)據(jù)包所經(jīng)過的路徑。為完成這一步驟,要明確回應數(shù)據(jù)包的源地址,PC發(fā)送ping時,回應應答數(shù)據(jù)包的目標地址就是 6.159.245.195。而路由器R1發(fā)送ping時,回應應答數(shù)據(jù)包的目標地址就是71.170.0.146。對照R4的路由表,發(fā)現(xiàn)與 6.159.245.195匹配的路由表項,而未發(fā)現(xiàn)與目標地址71.170.0.146相匹配的路由表項?磥,ICMP的回應應答數(shù)據(jù)包在R4處理時被丟棄了,所以從R1向目標網(wǎng)絡R4(6.159.245.65/26) 發(fā)送ping時,出現(xiàn)pmg失敗。
解決辦法是:在路由器R4上增加一條指向71.170.0.144/30的靜態(tài)路由,下一跳的地址為71.170.0.214。完成后,在R1向R4發(fā)送ping時,發(fā)現(xiàn)一切正常了。
此類網(wǎng)絡故障盡管不會影響網(wǎng)絡的正常通信,排除的過程也很簡單,但網(wǎng)絡故障的分析與排除時,我們要考慮完整的通信過程。
北京 | 天津 | 上海 | 江蘇 | 山東 |
安徽 | 浙江 | 江西 | 福建 | 深圳 |
廣東 | 河北 | 湖南 | 廣西 | 河南 |
海南 | 湖北 | 四川 | 重慶 | 云南 |
貴州 | 西藏 | 新疆 | 陜西 | 山西 |
寧夏 | 甘肅 | 青海 | 遼寧 | 吉林 |
黑龍江 | 內(nèi)蒙古 |