廈大學生公寓故障排查

廈大學生公寓故障排查

把主要的排故過程進行概括總結：

     爲了確保ME60上沒有問題，咱們決定先在美仁宮進行測試，再去廈大排故

·    測試方法：在美仁宮8505下掛一臺3505三交換機再接PC進行測試

·    測試結果：正常（打開網頁響應快、延遲小）

確保在美仁宮測試沒有問題以後，先在賽爾辦公室進行測試，看下客戶端目前撥號狀況。

在客戶端測試的狀況：

·    撥號前先ping 112.5.66.69(ME60上的地址）延遲1ms正常

·    完成撥號須要時間10s左右，打開網頁慢

·    撥號後pingDNS延遲53ms

這個明顯有問題，因此爲了確保走的路徑是正確的，所以進行了tracert LNS地址（112.5.66.66）如圖

 

而這個路徑明顯是有問題的，經過查詢便可知道在撥號前到達該地址是走了教育網出去了，這樣問題其實就基本解決了。

 

致使這個問題就是校方在思科6509上沒有把去往ME60的LNS的靜態路由重分發至其內網，致使下面用戶沒路由但經過教育網也可以到達LNS（從上面Tracert可知），而這樣繞一圈確定速度慢不少，從而出現撥號慢、上網慢的問題。

 

 

解決的方法有二個：

·    校方在思科6509上把指向LNS地址的靜態路由下發至網部內部

·    把ME60的LNS的地址配置成69（由於校方已經把直連的下發到內部了）

 

爲了少麻煩到校方，所以咱們把ME60上的LNS地址改爲69，再進行測試撥號正常、打開網頁正常！

·    撥號前先ping 112.5.66.69(ME60上的地址）延遲1ms正常

·    完成撥號須要時間5s左右，打開網頁正常

·    撥號後pingDNS延遲6ms

 

 到這裏其實已經排故成功！

但這讓我更莫名其妙的感受，由於我一開始就懷疑繞路問題，但我沒有依據，由於我印象很深，我前兩天作過的tracert66、69跟今天tracert是徹底不一樣的結果，咱們tracert結果以下圖，只通過三跳！

 

 

任何事情知其然，更應該知其因此然，而後結合前面咱們測試的時候出現網絡不穩定的狀況，時好時壞而非一直都是慢！所以我更加確信確定有別的緣由致使這樣，而究竟是什麼緣由的問題呢？請你們結合上面拓撲跟我一塊兒進行分析如下幾個問題：

 

 

第一點：在思科6509上下掛PC測試正常，這個很容易迷惑，就認爲整個廈大學生公寓內網都有去往LNS的路由，並且老師強調他們已經在6509下發了，這樣就更加的肯定內部有學習到去往LNS的路由（當時不知道老師所下發的是直連路由，覺得是下發靜態路由）

 

若是光是第一點，咱們若是在客戶端Tracert路由也一下就發現了，可是爲何咱們撥號前tracert時的路徑是三跳是對的(跟今天的tracert不一樣，今天的是繞了一圈）？因此我在排故後一直在想緣由，這個很奇怪，後來決定再問校方它的具體拓撲鏈接狀況，雖然老師講得很含糊，但我瞭解到廈大學生公寓這塊網絡連至廈大校園網的接法，並非只有一條經過6509到校園網，而是有二條作自動流量負載分擔（基於什麼方式分流，沒有具體問，有可能在流量比較小的時候走上面一條，若是超過必定的流量的時候就超出部分的走下面的一條，這樣對核心設備也能夠啓到分流功能）而這樣一分析就明白了爲何那天早上8點測試的時候是正常的，而到11點後測試就不正常了。

由於正常的時候是走上面一條的，不正常時是走下面一條，而爲何選擇走上面一條時會是正常的呢？？？（注：這裏的正常包含：撥號正常3-4s,下載正常220左路、打開網頁速度快！）

流量走上面與走下面的區別在於：走上面那條是有通過思科6509，而在6509上有配置了靜態路由，而走下面的沒有通過6509，且沒有去LNS的路由，可是經過繞教育網也可以到達ME的LNS，所以撥號慢！

也能夠簡單的說在沒有把LNS地址重分發到內網時，只要有通過思科6509就能夠正確的路由到LNS（6509上沒有作策略）．若是這麼分析這就取決於這個流量的路徑是如何走，直接影響到撥號的路徑及創建隧道後的速度。

 

而當時咱們一直是認爲只有一個出口（老師大概跟咱們講的三層結構，由於他們認爲校園網跟這次項目關係不大，沒有必要說這些），而且有出現同一臺電腦在不一樣時段出現情況徹底不一樣的狀況。由於是同臺電腦、同個環境tracert，正常時tracert66與tracert69結果都同樣三跳，而致使後面一直錯誤的認爲ME60上66跟69同樣，認爲tracert69與tracert66同樣，這個是潛意識，但仔細分析就知道是徹底不一樣的。（直連分發了，靜態沒有分發）而以前就一直認爲是網絡不穩定、加之說聯通同樣環境是正常，因此又把思惟轉到去想是否是距離太遠了？光模塊不兼容等等其它因素。

 

 

總結心得：

l  不能以篇蓋全；

雖然在正常狀況（直連和靜態路由都在作重分發的狀況下），Tracert112.5.66.69與Tracert112.5.66.66這兩個地址的跳數是同樣的（66、69是在同一臺ME60上的地址，通常狀況下同一臺設備上的地址，tracert都是同樣的），但不能由於這樣就認爲Tracert66與69都同樣，事實證實在沒有下發靜態路由而只下發直連路由的時候，Tracert這兩個地址是徹底不一樣的，而這也是最大的迷惑點，由於都在同一個ME60上的地址，咱們就是由於開始去tracert這兩個地址，都是同樣是三跳，從而致使咱們認爲每次去tracert 69就認爲夠了，使得開始判斷方向就錯誤了。

l  思路要清晰、目的要明確；

特別是這種很是重要的大客戶、大項目，在關鍵時候出問題，時間又很是有限，真的會叫人茶不思、飯不香，我想這個文濤應該跟我在這幾天深會頗深，而這也是考驗咱們的時候，越在這種關鍵時候，越不能急、慌，相反思路要清晰、目標要明確，須要要作好更多的準備工做，甚至包含備用方案，假如問題尚未解決，要如何應對，也就是緩兵之計，儘可能給咱們爭取更多的時間。由於對於客戶來講是要把問題解決，而對於這次項目咱們也是同樣，在這麼短的時間裏極可能尚未排故出來，就可能須要採用備用方案。

l  多嘗試、多變換;

固然任何故障、問題在排解成功後，都會認爲就這麼簡單，其實這就跟腦筋緊轉彎同樣，在你沒有知道結果前都是很迷惑，感受到好難，當你知道答案時候就會有一種恍然大悟的感受；可能會去感嘆本身前面作了這麼多的無用功，沒有什麼意義！就像此次項目，前面作了光路、設備兼容性、模塊兼容性、方案的可行性、抓包分析、距離太長等一系列的工做，去確保任何一個環節是沒有問題的，在如今看來都是無用功，沒意義！可是在沒有找出緣由以前卻不是這麼認爲的，而在分析須要嘗試的狀況下這一切咱們能夠想到的、要嘗試的都有意義，這是一我的的技能經驗提升的一個過程！固然這個嘗試須要進行分析，不能盲目性。

還有在排查故障時要多變換,此次項目，若是測試的方式、測試的地點、測試的時間點、多變換，進行橫向、縱向的對比！可能就更快的排查出來了！

l  多討論、多溝通；

這點讓我感悟較深，之前我碰到問題就本身一我的在思考、在作實驗、找資料，其實不少時候碰到問題的時候就是要多溝通、多討論，由於每一個人都有本身的思惟方式、想法、每一個人的知識面涵蓋的範圍不一樣，可能討論、溝通並不必定能直接幫助你解決問題，但也許他說所的東西可能就啓發了你，讓你找到解決問題的方法！

 

因此經過此次項目寫這個報告但願能給你們帶來點幫忙，這些都是我的的一些見解、觀點，若有不一樣觀點、見解，也但願你們共享下，之後多多交流、溝通！相互提升！