記一次典型的故障排錯

    前兩天處理了一個網絡故障，整個過程雖然隻有10分鐘，但是我覺得很考驗排錯的思路，這裡寫出來分享一下。

    現場的拓撲結構十分簡單，一台堡壘機，一台網閘，都直接接在核心上，ip位址是兩個網段，網關也都在核心上，互相ping不通。

      問題就這麼簡單，我的排錯思路如下：

      1.在核心分别ping兩台裝置，測試線路及ip，結果：正常

      2.由于兩台裝置不是我負責的，無法直接登入檢查網關配置是否正确，這裡找了一台其他網段的電腦分别ping這兩台裝置，結果：正常

      3.雖然核心上我是沒有配置過任何acl來進行限制，我還是又檢查了一次，确認沒有任何過濾限制

      4.到了這一步，就必須要登到裝置上看一下了，這裡要到了網閘的資訊登入進去，檢查了網絡配置，都正确

      5.網閘是網頁操作，找到測試的頁面，ping堡壘機，不通；ping堡壘機的網關，不通；ping自己的網關，通。//到了這一步，大家如何進行下一步，可以先不看下面的過程，自己思考一下。

      6.兩種可能性，第一，ping包就沒從裝置發出來；第二，ping包發出來了，核心丢掉了。

      7.開啟了核心的debug抓包，然後再從網閘上ping，發現沒有提示，核心就沒收到包。包去哪了。

      8.再檢查網閘的配置，看看是否有限制，過濾一類的配置。看到了管理口配置，位址和堡壘機是一個段，詢問了一下，這個接口沒接線。按正常來說，接口沒接線，位址應該也就不生效，但是為了排除一切可能性，還是把這個位址改掉了。然後就通了，說明就是這個沒啟用的接口位址影響了。屬于産品自身的設計問題。

      上面這步大家是不是覺得很運氣，正好就看到了，然後也不确定就删了測一下，就測通了。從結果倒推出原因。那麼如果沒看到，下一步應該怎麼做。

      9.把筆記本接到核心上，位址先配成網閘一個段的，測一下到堡壘機通不通，還不放心可以把實體接口對調，最後還可以把網閘先斷一下，把位址給筆記本再測試，這樣就可以判斷出問題是在網閘這個裝置上。

      最後總結，這個問題的處理由于組網确實太簡單，又是産品本身原因導緻，思路如果不清晰，就會出現無從下手的情況。理清楚思路，是處理故障的首要。形成自己的方法論，解決問題才能事半功倍。