F5内網大二層負載均衡業務通路故障解析（CISCO OTV+LISP-MTU問題導緻）

一、問題現象

    最近在某客戶由于假期出現核心CISCO 6509硬體故障當機問題，進而發現F5釋出的3個應用通路問題，出現一部分人通路應用出現不可用的問題，時好時壞，内網使用F5 GTM+LTM進行域名雙活，内部同城雙活DC通過三層路由使用CISCO的大二層技術OTV+LISP技術建構；

    F5上面檢查應用不管是VS還是pool member都是正常，health check or monitor算法采用TCP；通過将LTM雙機上面對端DC業務member 進行offline，GSLB的跨DC member disable解析隻導流到主DC，此時業務通路正常，形成單活進行排查

    問題表象是跨DC通路後業務就通路異常，但是神奇的是隻有部分vlan有問題，大部分跨DC的vlan沒有問題！

    通過初步排查，應用人員表示應用無問題，網絡人員表示網絡無問題（可以從主中心ping通備中心應用IP，可以跨DCtelnet通業務應用端口，而且其它vlan沒有問題），F5人員也表示F5日志各方面正常，無異常日志！

二、問題原因

    F5人員建議對跨DC通路的443端口進行直接通路（不經過F5負載）測試與抓包，檢查資料包通信情況

    通過抓包，發現TCP三向交握正常，但是SSL協定握手異常，用戶端發送了client hello之後，伺服器端回送了一個1050byte左右的ssl data（非server hello)包且提示前導段丢失！然後接着用戶端FIN掉了連接配接！

    再通過對本DC正常應用通路抓包，明确SSL協商正常，SSL握手包最多幾百byte，是以這是應用層面的異常問題，并不是簡單的網絡層面的問題

    但是否是應用的問題呢，讓應用人員更換一個vlan後，通路正常！證明并不是應用層面的配置異常問題！很可能是網絡影響應用的一個問題！

    鑒于硬體故障當機，路徑變化，應用ssl協定互動資料包大小異常，并提示previos fragment前導段丢失等網絡問題，F5人員建議檢查MTU設定，然後客戶管理人員以及網絡人員才說出之前也出現過MTU問題，讓CISCO TAC進行檢查，通過幾個小時檢查，終于确認是由于CISCO 6509當機導緻部分VLAN OTV路徑變換，MTU沒有改為9216位元組的MTU導緻！

    更改後業務通路正常！

三、解決方法

    更換路徑中的OTV MTU後解決，F5相關配置還原，應用測試正常！

本文轉自 Bruce_F5 51CTO部落格，原文連結:http://blog.51cto.com/zenfei/2051358