网管日志-06.08.18
生活随笔
收集整理的這篇文章主要介紹了
网管日志-06.08.18
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
網絡改造的問題還沒有忙完,技術支持工程師在前沿給客戶解決網絡故障時遇到了些麻煩,需要我的支持,并且非常著急,我只好放下手中的工作全力支持他們,以客戶為中心,這可是公司的技術人員做事的中心原則。 大體了解了該客戶的網絡環境以及出現的故障,詳細內容如下:
??? 網絡環境:vdsl接入,2m獨享帶寬,一臺華為1820路由器,三臺華為3com交換機,大約50多臺客戶端計算機,加上兩臺服務器。
網絡故障:網絡斷斷續續,經常中斷,只能通過重啟路由器及vdslmodem設備才會有所改善,但時間不長,仍然出現中斷故障。
分析解決:
(1)首先排查客戶設備上端接入設備(我公司的設備)—vdsl交換機,通過進入vdsl交換機ios,查詢客戶的接入端口信息:crc錯誤包及丟棄包非常多,流量非常大。這個信息告訴我下一步測試端口、線路、帶寬、設備處理能力及客戶端數據包的分析等工作。
(2)從客戶處進行測試,首先在加網絡負載(即客戶網絡正常運轉)的情況下測試的,使用icmp(ping命令)測試,結果很明顯,到網關延時達到了100多ms(正常情況下應該是在3ms左右),并且丟包現象嚴重。然后再去掉任何負載的情況下進行測試,效果當然要好了許多,沒有丟包,但仍有幾十ms的延時,這個現象也不正常。
我想應該是中間節點或者中間線路接觸不良,也有可能是上端節點端口故障造成的。第一個反映就是檢查端口速率及工作模式并作了相應調整,都無濟于事,最后也更換了端口,還是不行,看來問題不是出在上端端口。
(3)我開始進行單機測試線路,從離上端設備最近的節點進行了測試,測試結果都正常,然后一個一個節點進行測試,最終確定線路也沒有問題。問題究竟出在哪里?難道是客戶端局域網問題,客戶端局域網是有問題,流量過大造成的,可以擴帶寬來解決,但為什么進行不加負載情況下,也有較大延時?
(4)客戶帶寬的問題,我已經解決了,為該客戶擴容到了4m獨享專線。但仍有問題,由于客戶的華為3com不支持span(端口鏡像和監控)又沒有hub等共享式設備,無法進行sniffer數據分析,很難判斷局域網內部狀況。還有一個非常重要的信息就是華為的這款1820路由器cpu負載到了92%以上,這個是非常不正常的,因為作為路由交換設備,cpu負載一般維持在60%以下,對網絡的影響還是可以接受的,但如果超過了這個值,網絡狀況將會很糟糕,甚至down掉的。從這里還可以分析出一個問題,這款路由器本身處理能力有限。
(5)在進行測試之前也考慮到了客戶局域網絡的p2p傳輸(bt迅雷電驢等下載)問題,也有可能是病毒原因,但由于不便于做限制,所以沒有從這方面進行解決,因為我也從側面了解到客戶的業務是做娛樂視頻方面的,需要經常使用p2p方面的軟件進行傳輸。
(6)考慮到這些情況,我認為應該做以下幾項工作:一是要更換處理能力更好的路由及交換設備;二是要進行數據包的分析與監測;三是以上如果還不能解決,就需要更換其他上網方式比如直接光纖接入,不走vdsl交換機。
(7)想到就要做到,我先把我測試使用的cisco3620路由器替換了客戶的華為路由器,進行測試,效果要好得多,延時減少了,丟包也很少發生,但根本問題仍沒有徹底解決,通過觀測,流量在急劇上漲,帶寬將超越4m帶寬,crc錯誤包減少了,但仍有相當數量的錯誤包。并且cisco3620的路由器處理能力還是相對比較強大的,但cpu占用率也達到了30%-40%左右,對于思科設備在這個網絡環境下能達到這個值,說明內網的確存在重大問題。
(8)之后,我又從公司取了兩款交換機,其中一款是cisco2924系列的,支持span,可以進行端口鏡像和監控,另一臺是cisco2950,現在要做的是替換下客戶的華為低端非網管交換機,看看是不是交換機處理能力在作怪,接上了cisco設備,也開啟了sniffer,首先開始對其內網進行分析,的確有大量機器進行p2p及其他大數據量的傳輸,并且更令人可怕的事情發生了,cisco兩臺交換機ios全部死機,無法進入,而交換機端口之間數據交換仍在進行,只是無法進入到交換機中,即使把所有負載去掉,交換機ios仍然無法進入,我意識到交換機ios徹底損壞了,可能需要重新灌入ios了。但客戶的網絡問題還沒有解決,我也試過其他方法,比如使用相應軟件如p2p終結者將其網內的p2p傳輸進行限制,只是網絡流量降下來了,延時小了些,但網絡故障依舊。
(9)這些方法只能緩解了部分網絡惡劣狀況,看來最根本的問題還是沒有解決,另外,我通過sniffer抓包分析發現,網絡內的超過1400byte的數據包占的比例最大,有的相當數量的數據接近mtu值,甚至超過了以太網的mtu值。根據這些,我想到剛才設備死機及cpu占用率過高的問題,在數據分析的時候,已經排除了病毒的問題,應該是數據巨幀過多,導致設備端口進行轉發時無法及時處理,導致端口堵塞造成的,并且這個不僅僅是內網的設備端口,同樣在上端設備端口(vdsl交換機)也受到影響,可能是上端vdsl交換機端口不能及時處理巨幀所致?也可是傳輸介質不能滿足數據傳輸要求(因為vdsl是通過2芯雙絞線跳轉到客戶端的)?
(10)那我就實施最后一種辦法,通過光纖直接入戶,并且跳過vdsl交換設備,直接接入邊界路由器接入互聯網。但由于客戶著急下班,又正值周五,明天就是周末,所以最后這項工作還沒有做,只好安排到了周一繼續。
?
??????? 在期間,這些工作都是由幾位工程師來配合我的思路完成的,要是一個人來做,頭腦都會炸個稀巴爛的。我也想好好休息個周末。
(未完待續)
??? 網絡環境:vdsl接入,2m獨享帶寬,一臺華為1820路由器,三臺華為3com交換機,大約50多臺客戶端計算機,加上兩臺服務器。
網絡故障:網絡斷斷續續,經常中斷,只能通過重啟路由器及vdslmodem設備才會有所改善,但時間不長,仍然出現中斷故障。
分析解決:
(1)首先排查客戶設備上端接入設備(我公司的設備)—vdsl交換機,通過進入vdsl交換機ios,查詢客戶的接入端口信息:crc錯誤包及丟棄包非常多,流量非常大。這個信息告訴我下一步測試端口、線路、帶寬、設備處理能力及客戶端數據包的分析等工作。
(2)從客戶處進行測試,首先在加網絡負載(即客戶網絡正常運轉)的情況下測試的,使用icmp(ping命令)測試,結果很明顯,到網關延時達到了100多ms(正常情況下應該是在3ms左右),并且丟包現象嚴重。然后再去掉任何負載的情況下進行測試,效果當然要好了許多,沒有丟包,但仍有幾十ms的延時,這個現象也不正常。
我想應該是中間節點或者中間線路接觸不良,也有可能是上端節點端口故障造成的。第一個反映就是檢查端口速率及工作模式并作了相應調整,都無濟于事,最后也更換了端口,還是不行,看來問題不是出在上端端口。
(3)我開始進行單機測試線路,從離上端設備最近的節點進行了測試,測試結果都正常,然后一個一個節點進行測試,最終確定線路也沒有問題。問題究竟出在哪里?難道是客戶端局域網問題,客戶端局域網是有問題,流量過大造成的,可以擴帶寬來解決,但為什么進行不加負載情況下,也有較大延時?
(4)客戶帶寬的問題,我已經解決了,為該客戶擴容到了4m獨享專線。但仍有問題,由于客戶的華為3com不支持span(端口鏡像和監控)又沒有hub等共享式設備,無法進行sniffer數據分析,很難判斷局域網內部狀況。還有一個非常重要的信息就是華為的這款1820路由器cpu負載到了92%以上,這個是非常不正常的,因為作為路由交換設備,cpu負載一般維持在60%以下,對網絡的影響還是可以接受的,但如果超過了這個值,網絡狀況將會很糟糕,甚至down掉的。從這里還可以分析出一個問題,這款路由器本身處理能力有限。
(5)在進行測試之前也考慮到了客戶局域網絡的p2p傳輸(bt迅雷電驢等下載)問題,也有可能是病毒原因,但由于不便于做限制,所以沒有從這方面進行解決,因為我也從側面了解到客戶的業務是做娛樂視頻方面的,需要經常使用p2p方面的軟件進行傳輸。
(6)考慮到這些情況,我認為應該做以下幾項工作:一是要更換處理能力更好的路由及交換設備;二是要進行數據包的分析與監測;三是以上如果還不能解決,就需要更換其他上網方式比如直接光纖接入,不走vdsl交換機。
(7)想到就要做到,我先把我測試使用的cisco3620路由器替換了客戶的華為路由器,進行測試,效果要好得多,延時減少了,丟包也很少發生,但根本問題仍沒有徹底解決,通過觀測,流量在急劇上漲,帶寬將超越4m帶寬,crc錯誤包減少了,但仍有相當數量的錯誤包。并且cisco3620的路由器處理能力還是相對比較強大的,但cpu占用率也達到了30%-40%左右,對于思科設備在這個網絡環境下能達到這個值,說明內網的確存在重大問題。
(8)之后,我又從公司取了兩款交換機,其中一款是cisco2924系列的,支持span,可以進行端口鏡像和監控,另一臺是cisco2950,現在要做的是替換下客戶的華為低端非網管交換機,看看是不是交換機處理能力在作怪,接上了cisco設備,也開啟了sniffer,首先開始對其內網進行分析,的確有大量機器進行p2p及其他大數據量的傳輸,并且更令人可怕的事情發生了,cisco兩臺交換機ios全部死機,無法進入,而交換機端口之間數據交換仍在進行,只是無法進入到交換機中,即使把所有負載去掉,交換機ios仍然無法進入,我意識到交換機ios徹底損壞了,可能需要重新灌入ios了。但客戶的網絡問題還沒有解決,我也試過其他方法,比如使用相應軟件如p2p終結者將其網內的p2p傳輸進行限制,只是網絡流量降下來了,延時小了些,但網絡故障依舊。
(9)這些方法只能緩解了部分網絡惡劣狀況,看來最根本的問題還是沒有解決,另外,我通過sniffer抓包分析發現,網絡內的超過1400byte的數據包占的比例最大,有的相當數量的數據接近mtu值,甚至超過了以太網的mtu值。根據這些,我想到剛才設備死機及cpu占用率過高的問題,在數據分析的時候,已經排除了病毒的問題,應該是數據巨幀過多,導致設備端口進行轉發時無法及時處理,導致端口堵塞造成的,并且這個不僅僅是內網的設備端口,同樣在上端設備端口(vdsl交換機)也受到影響,可能是上端vdsl交換機端口不能及時處理巨幀所致?也可是傳輸介質不能滿足數據傳輸要求(因為vdsl是通過2芯雙絞線跳轉到客戶端的)?
(10)那我就實施最后一種辦法,通過光纖直接入戶,并且跳過vdsl交換設備,直接接入邊界路由器接入互聯網。但由于客戶著急下班,又正值周五,明天就是周末,所以最后這項工作還沒有做,只好安排到了周一繼續。
?
??????? 在期間,這些工作都是由幾位工程師來配合我的思路完成的,要是一個人來做,頭腦都會炸個稀巴爛的。我也想好好休息個周末。
(未完待續)
總結
以上是生活随笔為你收集整理的网管日志-06.08.18的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 不同列同行的相同数据
- 下一篇: .net讀取指定節點的值