前言
在日常運維中，總會遇到一些棘手的故障或問題，尤其面臨多系統融合的相容性或一些融合節點可能存在未知bug等方面，排錯難度都會增加。
本文将從一次小事件為入口進行延伸，将主控端esxi基礎系統的多融合節點故障的排錯曆程展開介紹，并結合排錯過程介紹esxi基礎系統穩定性所依賴的環境條件。
排錯階段一：故障初現，随機複現
一、故障初現
事件背景： 某職場一天下午現場回報有幾個人無線網絡連接配接不上
事件原因： 無線連網認證的網絡認證伺服器到某台AD域控網絡不通，使用者無法擷取ad狀态拒絕連網
臨時措施： 重新開機網絡認證伺服器的網絡服務，恢複
問題現象：
網絡認證伺服器到部分目标ip不通（其中一台AD域控屬于其中）
網絡認證伺服器到部分目标IP通（告警系統屬于通的ip，未産生伺服器告警）
該esxi上部分虛拟機有類似問題，部分虛拟機正常
二、随機複現
疑問：為什麼會出現這個問題，如何能夠複現呢？
因為大部分核心業務系統都運作在esxi底層上，如何确認具體故障原因規避類似風險成為了重中之重。
1、抓包分析
與此同時，我們進行了該主控端上的其他虛拟機詳細檢查，發現另一台虛拟機也存在部分ip不通的情況（本地服務無遠端ip互通依賴，該虛拟機服務未受影響），根據該虛拟機進行了各鍊路節點抓包分析：
- 1、級聯switch抓到了伺服器發送的icmp reply包，但在上聯核心switch未發現該reply包
- 2、為了排除server發出的包構造異常，使用了tcpreplay工具（一種pcap包的重放工具，可以将用ethreal、wireshark等工具捕獲的網絡資料包原樣或經過任意修改後重放回去）在實驗環境中進行了重寫和重放，資料包正常發送接收證明了包構造正常（其實當時實驗環境和故障環境有其他差異）
- 3、重新開機了交換機端口後，故障虛拟機恢複
當時結論：級聯或上聯switch有問題導緻丢失資料包（該結論是誤判）
2、複現嘗試
雖有簡單的結論，但需要複現故障才能确定具體問題環節！
在Esix排查過程中發現了故障時間節點有一條異常日志可能有關聯性
Ixgben：indrv_uplinkreset：vmnic0 device reset started
查閱vmware相關論壇資料，發現了一條指令可以觸發相同的日志出來（重要節點一）
VMkernel Sys Info Shell：vsish -e set /net/pNics/vmnic0/reset 1
使用該指令在故障環境中成功的進行了複現，但在測試環境中無法複現
當時結論：vmnic0的reset動作觸發了故障，但滿足故障發生的其他因素仍是未知
排錯階段二：環環相扣，錯綜複雜
疑問：到底是什麼場景下，vmnic的reset動作會觸發這個故障呢？
為了測試滿足故障觸發的X因素有哪些，我們嘗試枚舉了至少十幾種有可能關聯的條件，排列組合了十多套測試場景，用于測試确認
枚舉X因素： 實體機型号、網卡型号、esxi版本、NLB模式、端口組配置、VSwitch配置、交換機型号、交換機系統版本、虛拟機OS、虛拟機數量，虛拟機角色，網段、伺服器跳線等
在進行了不下于50次的排列組合測試後，不同的X因素之間有沖突又有重合，而且複現的規律和頻率不固定，無法穩定複現，但最終确定并縮小了一定的條件範圍
當時結論：基本确定以下為觸發條件範圍（非最終）
- 伺服器：Dell R740xd
- 網卡：Intel(R) Ethernet Controller 10G X550
- 驅動：ixgben網卡驅動
- 交換機：35系列交換機
- 虛拟機：linux
排錯階段三：穩定複現，找到關鍵
一、穩定複現
疑問：在這些條件範圍中到底還有什麼隐性因素可以決定故障能穩定複現呢？
在基本确定的觸發條件範圍中，有一項很特殊，為什麼每次能複現故障的時候一定是linux虛拟機，而windows從未複現過。針對這一特殊性我們在排查過程中進行了重點關注，在多次組合測試後發現一個特征，出現問題的虛拟機在esxi底層顯示虛拟機網絡資訊中SubType類型均為“6”（重要節點二）
經過資料查詢确認了subtype=6代表虛拟網卡類型為vlance（ ”[AMD] 79c970 [PCnet32]” ），出現vlance類型的原因是早期建立linux虛拟機向導中選擇了“其他linux系統”，esxi就會自動建立虛拟機網卡為vlance類型網卡
在實驗環境中準備vlance類型網卡的虛拟機進行測試，最終“DELL機型+基于IP哈希+vlance”在reset vmnic動作觸發下可以穩定複現，并且複現的虛拟機到多個目标網絡的測試是一半通一半不通，其中非“基于IP哈希”的NLB模式無法複現
二、找到關鍵
疑問：穩定複現後，如何确定是哪一環節導緻部分通部分不通呢？
與此同時，網絡組在更新cisco廠家售後工單等級後，在資深售後的協助下，通過EPC（Embedded Packet Capture，一種嵌入式的抓包工具，有更強的靈活針對性，特别适用于網絡排障和線上抓包的情況）多次抓包分析得到一個重要資訊，當虛拟機出現問題的目标ip到達switch接收包vlan tag為0，當虛拟機的正常目标ip到達時vlan tag則為正常的id号（重要節點三）
當時結論：出現故障時因接收到的是沒有正确标注VLAN ID的資料包導緻三層交換無法轉發
排錯階段四：撥雲見日，水落石出
一、撥雲見日
1、确認故障因素：
疑問：是什麼因素導緻了vlan tag異常？
有了vlan tag丢失這個關鍵因素，我們對比了vmware官網中各個esxi版本的更新介紹，其中在6系列相關版本中均提到了有vlan tag相關的bug描述，并給出了臨時處理方案，另在7.0版本中說明修複了該bug
在實驗環境中複現故障後，根據vmware的臨時方案如願恢複了故障
針對該方案指令的一些參數進行分析研究，指令效果是在esxi的底層網絡部分将vlan相關的功能重新開機了一下（類似我們重新開機了網卡或交換機端口等操作）
另外我們将實驗環節中的esxi更新為7.0後，該故障也無法複現了
當時結論：驗證了vlan tag丢失導緻問題，但該bug暫無詳細說明
2、确認故障環節：
疑問：問題好像找到原因了，但是到底哪個環節導緻vlan tag丢失了呢？
從虛拟機到switch還要經過Esxi層多個網絡環節：虛f拟機，端口組，vswitch，實體網卡
通過esxi底層的pktcap-uw抓包工具（進階版的抓包及分析工具，主要應用在ESXi 5.5以後的版本中）對esxi底層三段網絡鍊路進行了同時抓包
| 測試場景 | 結果 |
| 虛拟機到端口組 | 資料包正常，vlan tag正常 |
| 端口到vswitch | 資料包正常，vlan tag正常 |
| vswitch到實體網卡 | 資料包正常，vlan tag正常 |
| 實體網卡到交換機 | 資料包正常，vlan tag異常 |
當時結論：實體網卡導緻了vlan tag丢失
二、水落石出
1、确認故障原因：
疑問：實體網卡為什麼會導緻vlan tag丢失？
根據DELL機器所搭配的萬兆網卡X550的特性進行資料搜尋，我們在lenovo的官方論壇中找到了一篇關于10G ixgben網卡在1.8.7驅動版本中修複了vlan tag相關bug的說明，我們的版本是：1.7.10(重要節點四)
于是我們将故障主控端的網卡驅動更新到了高版本進行測試，故障場景無法再複現
為了進一步确認關聯性，又進行了多次組合測試
| 測試場景 | 結果 |
| 将故障主控端的綁定線路換到千兆網卡 | 無法複現 |
| 将esxi6.*更新到8.0（此時網卡驅動自動升為1.13.10） | 無法複現 |
| 将esxi8.0的網卡驅動降級為1.7.10 | 故障複現 |
| 将萬兆X550（1.7.10）網卡安裝在HP伺服器中 | 故障複現 |
至此，在整個排錯過程中不同環節的疑問都得到了合理的解釋
疑問1、 為什麼同樣的DELL主控端型号和vmware配置和網絡配置，有的複現，有的不能複現？
此類故障影響的是網卡為vlance類型的虛拟機
疑問2、 為什麼同一台主控端linux出故障，windows不出故障
故障linux屬于vlance類型網卡（當安裝作業系統時選擇版本“其他”引起），windows屬于E1000網卡
疑問3、 為什麼将負載均衡模式調整為其他非“基于ip哈希+trunk”模式，就不能複現
因為“基于ip哈希+trunk”工作模式涉及網絡層打vlan tag，觸發ixgben1.7.10版本驅動bug問題，其他的搭配如：基于ip哈希+access，基于源虛拟端口，基于源mac等負載均衡模式均不涉及網絡層vlan tag
疑問4、 為什麼虛拟機出現故障時到目标ip是一半通一半不通
基于ip哈希的算法會對源及目标ip進行哈希計算配置設定不同的實體鍊路，當reset其中一塊網卡時，一半目标受影響
疑問5、 為什麼hp的主控端不能複現
hp主控端沒有搭配x550的萬兆網卡（ixgben1.7.10）
疑問6、 為什麼将esxi的tagging設定為開啟不作為根本解決方案
因為開啟後，類似于開啟混雜模式。将會暴露更多的安全風險
疑問7、 為什麼本次遇到的vlan tag丢失不屬于esxi6.7的版本bug（官方有說7.0修複類似bug）
因為采用esxi高版本搭配ixgben1.7.10依然可以複現
總結：
通過完整的排錯下來，最終确定了引起該事件的根本原因，以下四個條件同時滿足會觸發該類故障
- 條件一： 使用驅動ixgben 1.7.10的X550網卡
- 條件二： 采用“基于IP哈希”的負載均衡模式
- 條件三： 虛拟機虛拟網卡型号為“vlance”
- 條件四： ESXI的vmnic發生reset動作
眼見不一定為實，在複雜的故障場景分析中，會有很多的幹擾因素影響着我們的判斷，通過不斷的排列組合去在差異中找共性、在共性中找差異是一種剔除幹擾資訊的方法之一；抱着去僞存真精神找到問題背後的根源，才能提供更有效的解決方案。
作者介紹
JUN，現任IT專家
來源:微信公衆号:拍碼場
出處:https://mp.weixin.qq.com/s/pTX2LuqCZO46lqd9i6gsEw