通信常見網絡故障處理_第1頁
通信常見網絡故障處理_第2頁
通信常見網絡故障處理_第3頁
通信常見網絡故障處理_第4頁
通信常見網絡故障處理_第5頁
已閱讀5頁,還剩46頁未讀 繼續免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

常見網絡故障處理網絡監控維護中心2021年1月【產品系統工程師】數據網技能培訓〔初階〕之二本課程解決的根本問題是故障處理的根本步驟及常用診斷工具?以上模塊都遵循課程設計的根本法那么:循序漸進、由淺入深課程總體思路圖關鍵問題課程模塊關鍵方法2內容介紹第一章故障處理技術概述第二章故障處理步驟第三章常用診斷工具介紹第一章故障處理技術概述第1節導言第2節故障分類導言能夠正確地維護網絡盡量不出現故障,并確保出現故障之后能夠迅速、準確地定位問題并排除故障,對網絡維護和管理人員來說是個挑戰。這不但要求對網絡協議和技術有著深入的理解,更重要的是要建立一個系統化的故障處理思想,并合理應用于實際中,以將一個復雜的問題隔離、分解或縮減排錯范圍,從而及時修復網絡故障。連通性問題硬件、媒介、電源故障配置錯誤不正確的相互作用性能問題網絡擁塞到目的地不是最正確路由路由環路網絡錯誤故障分類第二章故障處理步驟第1節導言第2節故障處理思路第3節故障處理實例故障處理系統化是合理地一步一步找出故障原因并解決的總體原那么。它的根本思想是系統地將由故障可能的原因所構成的一個大集合縮減〔或隔離〕成幾個小的子集,從而使問題的復雜度迅速下降。導言8故障處理步驟該處理流程是網絡維護人員所能夠采用的排錯模型中的一種網絡故障解決的處理流程是可以變化的,但故障處理有序化的思維模式是不可變化的下面我們以一個故障處理的實例來學習如何應用這些步驟。該案例組網如上:某校園網的三個局域網,其中為一個用戶網段,18為一個日志效勞器;是一個集中了很多應用效勞器的網段。用戶網段播送包過多造成該網段的效勞器FTP業務傳輸速度慢

網云A:18/24C:20/24B:53/16D:3/16ETHERNETETHERNETETHERNET故障處理實例要想對網絡故障做出準確的分析,首先應該了解故障表現出來的各種現象用戶反映“日志效勞器與備份效勞器間備份發生問題。〞這就是一個不完整不清晰的故障現象描述。因為這個描述沒有講述清楚以下問題:這個問題是連續出現,還是間斷出現的?是完全不能備份,還是備份的速度慢〔即性能下降〕?哪個或哪些局域網效勞器受到影響,地址是什么?正確的故障現象描述是:在網絡的頂峰期,日志效勞器1到集中備份效勞器53之間進行備份時,FTP傳輸速度很慢,大約是0.6Mbps。故障處理實例—故障現象描述搜集有助于查找故障原因的詳細信息:向受影響的用戶、網絡人員或其他關鍵人員提出問題;根據故障描述性質,使用各種工具搜集情況,如網絡管理系統、協議分析儀、相關display和debug命令等;測試性能與網絡正常情況下的記錄進行比較。如上述案例,可以向用戶提問或自行收集以下相關信息:網絡結構或配置是否最近修改正,即問題出現是否與網絡變化有關?是否有用戶訪問受影響的效勞器時沒有問題?在非頂峰期日志效勞器和備份效勞器間FTP傳輸速度是多少?通過該步驟,我們收集到了下面一些相關信息:最近網段的客戶機不斷在增加;網段的機器與備份效勞器間進行FTP傳輸時速度正常為7Mbps,與日志效勞器間進行FTP傳輸時速度慢,只有0.6Mbps;在非頂峰期日志效勞器和備份效勞器間FTP傳輸速度正常,大約為6Mbps;故障處理實例—搜集相關信息利用前兩個步驟收集到的數據,并根據自己以往的故障處理經驗和所掌握的的知識,確定一個排錯范圍。通過范圍的劃分,就只需注意某一故障或與故障情況相關的那一局部產品、介質和主機。如上述案例,我們現在能夠確定是一個網絡性能下降問題。那么,是網段的性能問題?是中間網絡的性能問題?還是網段的性能問題呢?根據網段的機器與備份效勞器間進行FTP傳輸時速度正常為7Mbps這一事實,我們可以排除掉網段的性能問題。故障處理實例—經驗判斷和理論分析該步驟列出根據經驗判斷和理論分析后總結的各種可能原因。如上述案例,可能原因如下:網段的性能問題,其原因可能為:日志效勞器A的性能問題網絡的網關性能問題網絡本身的性能問題中間網絡性能問題,主要是到網絡的路由不是最正確路由故障處理實例—各種可能原因列表根據所列出的可能原因制定故障排查方案,分析最有可能的原因,確定一次只對一個變量進行操作,這種方法使你能夠重現某一故障的解決方法。如果有多個變量同時被改變,而問題得以解決,那么如何判斷哪個變量導致了故障發生呢?故障處理實例—對每種原因逐個實施排錯方案可能原因1:網絡到網絡的路由不是最正確路由。制定的方案:在網段的網關上使用“tracert53〞命令,發現探測報文返回時長僅為10ms,說明該可能原因并不是造成故障的原因。我們進入循環排錯過程。故障處理實例—循環排查過程可能原因2:日志效勞器A的性能問題。制定的方案:測試同一網段的主機C和日志效勞器間的FTP傳輸速度,是6Mbps,正常。可見問題與效勞器A無關。可能原因3:網絡的網關性能問題。制定的方案:測試主機C和備份效勞器B間FTP傳輸速度是7Mbps,正常。排除了網關因素,因為B、C在不同網段上而速度正常。可能原因4:網絡本身的性能問題。制定的方案:在網段的以太網交換機上使用命令“showmac〞,輸出如下:PortRcv-UnicastRcv-MulticastRcv-Broadcast----------------------------------------------------------------6/321031781208665PortXmit-UnicastXmit-MulticastXmit-Broadcast----------------------------------------------------------------6/3266679872866522474038(輸出的播送:輸出的單播比例為1:3,太大了。)PortRcv-OctetXmit-Octet---------------------------------------------------------------6/32140948293581516443041在網段上的以太網交換機上使用命令“showmac〞輸出如下:PortRcv-UnicastRcv-MulticastRcv-Broadcast-------------------------------------------------------------6/36557802870285PortXmit-UnicastXmit-MulticastXmit-Broadcast--------------------------------------------------------------6/3627879749190257119430〔播送:單播比例=1:270,屬于正常。〕PortRcv-OctetXmit-Octet---------------------------------------------------------------6/36671725870814998816809由此得知,網段上播送包和單播包比例為1:3,確實太大了。再次詢問用戶該網段主要運行的業務是什么,而得出了故障最終原因如下:是普通用戶網段,由于業務原因每個用戶需要發送大量播送包和多播包,隨著近期越來越多的用戶接入該網絡,在這個網段上的效勞器需要花費更多的資源來處理越來越多的播送和多播包,因此其效勞的傳輸速度自然減慢。這是一個網絡布局不恰當的問題,需要重新安排效勞器的位置,將效勞器移動網段后,故障解決。第三章常用診斷工具介紹第1節導言第2節命令介紹第3節案例分析ping命令tracert命令display命令debug命令抓包軟件sniffer/ethereal幾個常用診斷工具命令ping用于檢查IP網絡連接及主機是否可達。“ping〞這個詞源于聲納定位操作,指來自聲納設備的脈沖信號。ping命令的思想與發出一個短促的雷達波,通過收集回波來判斷目標很相似;即源站點向目的站點發出一個ICMPEchoRequest報文,目的站點收到該報文后回一個ICMPEchoReply報文,這樣就驗證了兩個節點間IP層的可達性--表示了網絡層是連通的。ping和tracert命令不僅是路由器平臺的常用網絡命令,也是windows平臺上常用的網絡命令PING命令在Quidway系列路由器上,ping命令的格式如下:ping[-Rdnqrv][-ccount][-ppattern][-spacketsize][-ttimeout]host-aping報文中使用的源IP地址-cping報文的個數,缺省值為5;-t設置ping報文的超時時間,單位為毫秒,缺省值為2000;-s設置ping報文的大小,以字節為單位,缺省值為56。在PC機上或WindowsNT為平臺的效勞器上,ping命令的格式如下:ping[-nnumber][-t][-lnumber]ip-address-nping報文的個數,缺省值為5;-t持續地ping直到人為地中斷,Ctr+Breack暫時中止ping命令并查看當前的統計結果,而Ctr+C那么中斷命令的執行。-l設置ping報文所攜帶的數據局部的字節數,設置范圍從0至65500。用ping命令進行故障處理工程師小L,在配置完一臺路由器之后執行ping命令檢測鏈路是否通暢。發現5個報文都沒有ping通,小L斷定是連通性問題。檢查雙方的配置命令并查看路由表,卻一直沒有找到錯誤所在。最后又重復執行了一遍相同的ping命令,發現這一次5個報文中有1個ping通了--原來是線路質量不好存在比較嚴重的丟包現象。案例一連通性問題還是性能問題?工程師小L又配置了一臺路由器,然后執行ping命令訪問Internet上某站點的IP地址,但沒有ping通。有了上次的教訓小L,再一次ping了20個報文,仍舊沒有響應。于是這次小L覺得能夠斷定是連通性故障。在費力周折檢查了配置鏈路之后仍沒有發現任何可疑之處,最后小L采取逐段檢測的方法對鏈路中的網關進行逐級測試,發現都可以ping通,但是響應的時間越來越長,最后一個網關的響應時間在1800ms左右。會不會是由于超時而導致顯示為ping不同呢?受此啟發,小L將ping命令報文的超時時間改為4000ms,這次成功ping通了,顯示所有的報文響應時間都在2200ms左右。用ping命令進行故障處理案例一連通性問題還是性能問題?建議和總結:真的是ping不通嗎?這個問題需要定位清楚,因為連通性問題和性能問題排錯的關注點是不一樣的――問題定位錯誤必然會導致排錯過程的周折。使用一般的ping命令,缺省是發送5個報文的,超時時長是2000ms。如果ping不通情況發生,最好能夠再用帶參數-c和-t的ping命令再執行一遍,如:ping-c20-t4000ip-address,即連續發送20個報文,每個報文的超時時長為4000ms,這樣一般可以判斷出到底是連通性問題還是性能問題。用ping命令進行故障處理案例一連通性問題還是性能問題?在RouterA上配置一條指向/8的靜態路由:

[Quidway]iproute-static在RouterA上ping路由器RouterB的以太網地址,RouterA的以太網地址,卻無法ping通。

E0:/8E0:/8S0:/8S0:/8RouterARouterB用ping命令進行故障處理案例二顯示可以正常ping通;但是在RouterB上ping路由器案例二A能ping通B,B就一定能ping通A嗎?原因分析:由于在RouterB上沒有相應的配置到/8路由,所以在RouterB上ping不通RouterA的以太網口。但是為何在A上可以ping通呢?同樣是沒有回程路由。翻開路由器上的IP報文調試開關發現,原來從RouterA上發出的ICMP報文的源地址填寫的是而不是,由于兩臺路由器的s0口處于同一網段,所以響應報文可以順利到達RouterB。用ping命令進行故障處理案例二A能ping通B,B就一定能ping通A嗎?建議和總結:A能夠ping通B那么B一定能夠ping通A〔不考慮防火墻的因素〕,這句話的對錯取決于A和B到底是指主機還是指路由器。如果是指兩臺主機,那么這句話就是正確的。如果是指兩臺路由器那就是錯誤的,因為路由器通常會有多個IP地址。現在就有如下問題:當從一臺路由器上執行ping命令它發出的ICMPEcho報文的源地址究竟選擇哪一個呢?實際情況是路由器選擇發出報文的接口的IP地址。用ping命令進行故障處理TRACERT命令tracert命令用于測試數據報文從發送主機到目的地所經過的網關,主要用于檢查網絡連接是否可達,以及分析網絡什么地方發生了故障。tracert利用IP報文的TTL域在每經過一個路由器的轉發后減一,當TTL=0時那么向源節點報告TTL超時這個特性。tracert首先發送一個TTL為1的UDP報文,因此第一跳發送回一個ICMP錯誤消息以指明此數據報不能被發送〔因為TTL超時〕,之后tracert再發送一個TTL為2的報文,同樣第二跳返回TTL超時,這個過程不斷進行,直到到達目的地,此時由于數據報中使用了無效的端口號〔缺省為33434〕此時目的主時機返回一個ICMP的目的地不可達消息,說明該tracert操作結束。tracert記錄下每一個ICMPTTL超時消息的源地址,從而提供給用戶報文到達目的地所經過的網關IP地址。在華為Quidway系列路由器上,tracert命令的格式如下:tracert[-aip-address][-f

first_TTL][-mmax_TTL][-pport][-q

nqueries][-w

timeout]host-a指定一個發送UDP報文的源地址;-f指定初始報文的TTL大小,缺省值為1;-m指定最大TTL大小,缺省值為30;-p目的主機的端口號,缺省值為33434;-q每次發送的探測報文的個數,缺省值為3;-w指明UDP報文的超時時間,單位為毫秒,缺省值為5000。在PC機上或WindwosNT為平臺的效勞器上,tracert命令的格式如下:tracert[-d][-hmaximum_hops][-jhost-list][-wtimeout]host-d不解析主機名;-h指定最大TTL大小;-j設定松散源地址路由列表;-w用于設置UDP報文的超時時間,單位毫秒;案例一使用tracert命令定位不當的網絡配置點某校園網中,RouterB和RouterC同屬于一個運行RIPv2路由協議的網絡,主機訪問數據庫效勞器,用戶抱怨訪問性能差。網云RIP域E1:/8/8E0:/8S0:/8S1:/8S0:/8s1:/8/8RouterARouterBRouterCtracert命令進行故障處理相關信息顯示登錄到RouterC,使用帶參數的ping遠端效勞器,顯示如下:[RouterC]ping-c10-s4000-t6000PING:4000databytes,pressCTRL_CtobreakReplyfrom:bytes=4000Sequence=0ttl=249time=552msReplyfrom:bytes=4000Sequence=1ttl=249time=5733msReplyfrom:bytes=4000Sequence=2ttl=249time=552msReplyfrom:bytes=4000Sequence=3ttl=249time=5714msReplyfrom:bytes=4000Sequence=4ttl=249time=552msReplyfrom:bytes=4000Sequence=5ttl=249time=5711msReplyfrom:bytes=4000Sequence=6ttl=249time=552msReplyfrom:bytes=4000Sequence=7ttl=249time=5709msReplyfrom:bytes=4000Sequence=8ttl=249time=552msReplyfrom:bytes=4000Sequence=9ttl=249time=5710ms案例一使用tracert命令定位不當的網絡配置點tracert命令進行故障處理原因分析上面的ping顯示出一個規律:奇數報文的返回時長短,而偶數報文返回時長很長〔是奇數報文的10倍多〕。可以初步判斷奇數報文和偶數報文是通過不同的路徑傳輸的。現在我們需要使用tracert命令來追蹤這不同的路徑。在RouterC上,tracert遠端RouterA的以太網接口。[RouterC]tracert-q8tracerouteto()30hopsmax,40bytespacket16ms4ms4ms4ms4ms4ms4ms4ms……520ms16ms15ms16ms16ms16ms16ms16ms630ms278ms25ms279ms25ms278ms25ms277msRouterC(config)# 從上面的顯示可看到,直至,UDP探測報文的返回時長都根本一致,而到時,那么發生明顯變化,呈現奇數報文時長短,偶數報文時長長的現象。于是判斷,問題發生在RouterB和RouterA之間。 案例一使用tracert命令定位不當的網絡配置點tracert命令進行故障處理原因分析通過詢問該段網絡的管理員,得知這兩路由器間有一主一備兩串行鏈路,主鏈路為2.048Mbps〔s0口之間〕,備份鏈路為128Kbps〔s1口之間〕。網絡管理員在此兩路由器間配置了靜態路由。RouterB上如下配置:[RouterB]iproute-static[RouterB]iproute-staticRouterA上如下配置:[RouterA]iproute-static[RouterA]iproute-static于是問題就清楚了。例如RouterB,由于管理員配置時沒有給出靜態路由的優先級,這兩條路由項的優先級就同為缺省值60,于是就同時出現在路由表中,實現的是負載分擔,而不能到達主備的目的。

案例一使用tracert命令定位不當的網絡配置點tracert命令進行故障處理處理過程,可以有兩種處理方法:繼續使用靜態路由,進行配置更改RouterB上進行如下更改:[RouterB]iproute-static〔主鏈路仍使用缺省優先級60〕[RouterB]iproute-static100〔備份鏈路的優先級降低至100〕RouterA上進行如下更改:[RouterA]iproute-static[RouterA]iproute-static100這樣,只有當主鏈路發生故障,備份鏈路的路由項才會出線在路由表中,從而接替主鏈路完成報文轉發,實現主備目的。在兩路由器上運行動態路由協議,如OSPF等,但不要運行RIP協議〔因為RIP協議僅以hop作為Metric的〕案例一使用tracert命令定位不當的網絡配置點tracert命令進行故障處理建議和總結本案例的目的不是為了解釋網絡配置問題,而是用來展示ping命令和tracert命令的相互配合來找到網絡問題的發生點。尤其在一個大的組網環境中,維護人員可能無法沿著路徑逐機排查,此時,能夠迅速定位出發生問題的線路或路由器就非常重要了。案例一使用tracert命令定位不當的網絡配置點tracert命令進行故障處理DISPLAY命令display命令是用于了解路由器的當前狀況、檢測相鄰路由器、從總體上監控網絡、隔離因特網絡中故障的最重要的工具之一。幾乎在任何故障處理和監控場合,display命令都是必不可少的。這里僅介紹局部最常用的、全局性的display命令,而與各協議相關的display命令,將在后面章節相應的協議故障處理中詳細介紹。DisplayVersion該命令將幫助用戶收集以下信息:VRP軟件版本是哪一系列的路由器設備運行時間處理器的信息RAM的容量配置存放器的設置固件的版本引導程序的版本不同型號的設備顯示的內容可能會略有差異[Quidway]displayversionHuaweiVersatileRoutingPlatformSoftwareVRP(tm)software,Version1.44Release0006Copyright(c)1997-2002HUAWEITECHCO.,LTD.Compiled20:42:52,Jun122003,QuidwayR2511uptimeis0days7hours40minutes13seconds,SystemreturnedtoROMbypower-on.QuidwayR2511with168360ProcessorRouterserialnumberis00E0FC05D5C76A4016MbytesDRAM4608KbytesFlashMemoryhardwareversionis1.0displaycurrent-configuration

與displaysaved-configurationDisplaycurrent-configuration用于查看當前的配置信息。Displaysaved-configuration用于顯示NVRAM或Flash中的路由器配置文件,即路由器下次上電啟動時所用的配置文件。Current-configuration是路由器目前正在運行的配置文件,當更改某一配置時,current-configuration會立即改變;如果不使用save命令將改變保存到啟動配置文件saved-configuration中,路由器重啟時該改動將喪失。因此請注意到修改運行配置并驗證正確后,應當將之保存到啟動配置文件中。Displayinterfacesdisplayinterfaces命令可以顯示所有接口的當前狀態,如果只是想查看特定接口的狀態,請在該命令后輸入接口類型和接口號,例如:displayinterfacesserial0命令將查看串口0的運行狀態和相關信息。[Quidway]displayinterfacesserial0Serial0isdown,lineprotocolisdownphysicallayerissynchronous,baudrateis64000bpsinterfaceisDCE,clockisDCECLK,cabletypeisV35MaximumTransmissionUnitis1500Link-protocolisPPPLCPinitial,IPCPinitial,IPXCPinitial,CCPinitial,BRIDGECPinitial5minutesinputrate0.00bytes/sec,0.00packets/sec5minutesoutputrate0.00bytes/sec,0.00packets/secInputqueue:(size/max/drops)

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論