前兩天，有一個同事跑來找我幫忙。說他們項目現場出現了一個奇怪的事情。在做性能測試的時候，發現偶爾會出現消息延遲增大的問題，有時候一條消息發出去，需要5秒鐘才能夠被對方收到。如此長的延遲已經嚴重影響了性能測試的結果。由於負責現場測試的同事對網絡不是十分的熟悉，所以想讓我幫忙排查一下。事情緊急，二話不說，動手。
首先看了一下他們的日誌，發現並不是所有的消息延遲都很大，只有一小部分會出現這種情況。而且出現延遲的消息從業務功能上來講沒有什麼關聯性。再加上他們之前在實驗室進行性能測試的時候，並沒有出現這種問題。因此排除了是軟件的原因。那麼終點需要懷疑的就是網絡的問題了。
於是，第一感覺，可能有網絡丟包，於是ping了一下對方服務器，果然，在長ping之下，有大約30%的包丟失了。那麼問題的解決就有了方向。下一步就是看爲什麼會出現丟包了。
緊接着按照原則分段定位。現場的網絡結構大致是這樣的，我方服務器->我方交換機->客戶交換機->客戶服務器。 於是，分段ping一下，發現從我方服務器到對端服務器丟包，從我方服務器到我方交換機不丟包。 從我方交換機到對端服務器也不丟包。 這下基本可以確定問題出現在我方服務器到我方交換機這一段了。 丟包的原因有很多，有簡單的又複雜的。 自然先從簡單的開始排查了。 先排除硬件問題。 換端口，換交換機，換網線，換網卡，換換換換能換的統統換了一遍。結果呢，問題依舊。那麼久排除了硬件問題了。
下一步考慮網絡配置的問題，由於現場採用了兩臺交換機堆疊成一臺交換機的技術，以前堆疊交換機都是專門的三方網絡工程師配置的，而這次是自己人配置的，這位同事是新學的網絡配置，新手按照手冊配置的。 因此懷疑這裏可能有問題。於是關閉了堆疊交換機中的一臺，問題依舊。
原本想按照最小化原則，把交換機上的其他東西都拔掉，但是考慮到現場還有其他系統再測試，再加上主要懷疑對象是在交換機配置上，所以就沒有動手拔線。
這個時候想到了檢測一下服務器的路由信息是不是有問題，於是用traceroute 命令探測了一下到對端服務器的地址。多次運行後發現，tranceroute居然給出了2中不同的路由。 第一跳有時候是網關，有時候不是網關而是一個未知的 * * *. 這就怪了，網關有問題？
ping了一下網關，發現到網關卻沒有丟包。由於網關是配置在交換機上的，所以還是懷疑交換機的配置有問題。於是想看一下網關的MAC地址，看看網關是怎麼配置的。於是在服務器上用arp 命令查看了網關，我暈，這一看不要緊，發現網關的MAC地址居然在不斷的變化，一會兒是交換機管理地址的MAC一會兒是另外一個MAC. 同一個IP MAC居然會變，難道是ARP攻擊？ 可這是客戶內網啊，而且是新建系統，arp共計的可能性不大。 那麼最大的可能就是 IP地址衝突！！！
我們的設備都是我們自己配置的IP自然不可能是我們自己導致的。於是又回到了先前的路上，最小化原則。 通知了其他測試系統暫停一下。 先拔掉了和客戶交換機連接的網線，問題依舊。然後拔掉了和下面一個設備廠商的子網對接的網線，果然，問題消失了。 然後呢？然後再插上，問題又出現了。 就是他們呀，總算是逮到他們了。於是趕緊找他們的負責人一問，無語呀無語，他們爲了自己方便，沒有按照我們的網絡規劃，自己在下面接了一個路由器，還配了一個和網關一模一樣的地址。於是乎，麻煩就出現了。
其實本次解決問題沒有什麼特別的技術含量。只是網絡丟包這種常見的問題，真的要算起來，原因太多，查起來比較麻煩。所以把這次的排查過程記錄一下，留個紀念，也給需要的人一點參考。
總結一下，基本的排查原則：首先是定位，分段去查找，找到問題存在的那一段。然後是最小化(這個應該先做的，這次被其他因素影響後做了，不然早就就決問題了)，這兩步的目的呢，都是把問題減少到最小的範圍，然後再去檢查。就比較容易了。定位到最小範圍後，首先考慮硬件(因爲這個容易查)，然後呢就是配置部分的問題了。