1，問題描述
在某局點使用S5700作為接入交換機連接同網段的客戶端以及服務器,在使用過程中突然出現傳輸某種協議的時候比較慢,產生卡頓的現象,傳輸該業務延遲有的時候能夠達到3分鐘以上。現場工程師反饋之前使用HUB測試正常,只要換為S5700後就會產生卡頓現象。
2，處理過程
1. 獲取客戶的詳細組網信息,由於客戶的組網相對簡單,客戶端與服務器是直連在交換機上,並且同網段,客戶端地址192.168.1.20,服務器192.168.1.101;從客戶端ping服務器正常,大包ping正常,上網訪問其他業務正常;
2. 查看交換機的配置信息以及設備的DIAG診斷信息,交換機為出廠的默認配置,DIAG中無任何異常;
3. 嘗試關閉交換機的生成樹STP功能,仍然存在傳輸慢的現象;
4. 獲取客戶的業務傳輸的詳細信息,使用的TCP協議,目的端口5888,再進一步查看交換機display tcp status,此端口並沒有被佔用,並且目的地址也沒有配置在交換機上,交換機只做二層轉發;
5. 在交換機連接客戶端和服務器的兩個端口上同時抓包,進行報文比對分析,相關信息如下:
左為客戶端發出報文抓包,右邊為服務器端抓包。報文的延遲主要出現在最後紅框中的部分,前面的都正常,延遲都是ms級別;左邊124個報文顯示服務器May 23, 2016 15:05:46.906303000的時候回應了報文,而第488個報文的時候15:10:46.909455000才發起後續的報文,間隔了大約5分鐘,在右邊的設備上也可以看到收到時間間隔為約5分鐘,注意由於是在兩臺電腦上抓的包,時間上稍有差異(約30S,該差異可以忽略,因為所有的報文都相差30S,這是因為抓包的電腦本地時間有差異)。
從上面的分析可知交換機對報文做了MS級別的轉發,不應該出現現場兩三分鐘的延遲,建議可以攜帶其他的交換機進一步進行交叉測試。另外,注意上面報文中倒數第二個報文有大約5分鐘的延遲,該報文並不是首包,也就是前面報文的後續報文,為什麼後續報文會延遲發送,這個與之前抓到的報文現象一致,需要檢查一下該軟件的設置等問題。
通過多次抓包進行報文比較現象都是一致,可以確認交換機並沒有出現大的轉發延遲,而是客戶端在發起後續TCP請求的時候已經較前面的報文出現了大的延遲。
6. 通過以上的分析,再次使用其他交換機進行多次測試,發現仍然存在卡頓的現象,因此證明交換機不存在轉發異常的問題。
7. 協調客戶進行軟件排查發現軟件本身的錯誤設置導致後續報文的請求較前面報文的延遲較大。
3，根因
軟件本身的錯誤設置導致後續報文的請求較前面報文的延遲較大。
4，解決方案
由於交換機進行的無延時轉發,通過抓包進行對比說明此問題與中間設備交換機無關，需要客戶修改客戶端軟件的設置。
備註：客戶自身的軟件，與我司無關，無法提供具體的修改辦法。本案例主要是提供瞭如何在這類問題中對華為交換機進行排查、定位、故障排除的思路。
5，建議與總結
1. 對於交換機而言,交換機只進行數據包的快速轉發,不會對業務數據進行處理,因此理論上講不會導致業務出現大的延遲。本案例中提供的一種處理此類問題的思路,可以通過抓包進行對比,對比報文進入、轉發出交換機的延時進行排除;
2. 本案例的抓包是在兩臺電腦上進行的,為了防止電腦的時間不相同,可以通過將交換機的上下行接口全部鏡像到同一臺電腦上進行抓包比對,這樣就更有說服力。
閱讀更多 王海軍老師 的文章
