在日常運維中，總會遇到一些棘手的故障或問題，尤其面臨多系統融合的兼容性或一些融合節點可能存在未知bug等方面，排錯難度都會增加。
本文將從一次小事件為入口進行延伸，將宿主機esxi基礎系統的多融合節點故障的排錯歷程展開介紹，并結合排錯過程介紹esxi基礎系統穩定性所依賴的環境條件。
事件背景： 某職場一天下午現場反饋有幾個人無線網絡連接不上
事件原因： 無線連網認證的網絡認證服務器到某臺AD域控網絡不通，用戶無法獲取ad狀態拒絕連網
臨時措施： 重啟網絡認證服務器的網絡服務，恢復
問題現象：
網絡認證服務器到部分目標ip不通（其中一臺AD域控屬于其中）
網絡認證服務器到部分目標IP通（告警系統屬于通的ip，未產生服務器告警）
該esxi上部分虛擬機有類似問題，部分虛擬機正常
疑問：為什么會出現這個問題，如何能夠復現呢？
因為大部分核心業務系統都運行在esxi底層上，如何確認具體故障原因規避類似風險成為了重中之重。
1、抓包分析
與此同時，我們進行了該宿主機上的其他虛擬機詳細檢查，發現另一臺虛擬機也存在部分ip不通的情況（本地服務無遠程ip互通依賴，該虛擬機服務未受影響），根據該虛擬機進行了各鏈路節點抓包分析：
當時結論：級聯或上聯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因素之間有矛盾又有重合，而且復現的規律和頻率不固定，無法穩定復現，但最終確定并縮小了一定的條件范圍
當時結論：基本確定以下為觸發條件范圍（非最終）
疑問：在這些條件范圍中到底還有什么隱性因素可以決定故障能穩定復現呢？
在基本確定的觸發條件范圍中，有一項很特殊，為什么每次能復現故障的時候一定是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依然可以復現
通過完整的排錯下來，最終確定了引起該事件的根本原因，以下四個條件同時滿足會觸發該類故障
眼見不一定為實，在復雜的故障場景分析中，會有很多的干擾因素影響著我們的判斷，通過不斷的排列組合去在差異中找共性、在共性中找差異是一種剔除干擾信息的方法之一；抱著去偽存真精神找到問題背后的根源，才能提供更有效的解決方案。
JUN，現任IT專家
來源:微信公眾號:拍碼場
出處:https://mp.weixin.qq.com/s/pTX2LuqCZO46lqd9i6gsEw
Windows Server 2022中的網卡聚合（NIC Teaming）是一種技術，用于將多個物理網絡接口組合成一個邏輯接口，以實現更高的網絡性能和可靠性。這種技術可以在一個物理接口發生故障時保持網絡連接，從而提高網絡的可用性和穩定性。
網卡聚合的主要優點包括：
冗余：網卡聚合可以提供一個額外的物理網絡接口，以便在發生故障時提供冗余。
帶寬增加：通過將多個物理接口合并成一個邏輯接口，網卡聚合可以有效地增加帶寬，從而提高網絡性能。
更好的負載均衡：網卡聚合可以更好地分配網絡負載，從而提高網絡效率。
提高可靠性：網卡聚合可以提供一個額外的物理網絡接口，以便在發生故障時提供冗余，從而提高網絡的可用性和穩定性。
提高帶寬：通過將多個物理網絡接口合并成一個邏輯接口，網卡聚合可以有效地增加帶寬，從而提高網絡性能。
提高可靠性：網卡聚合可以提供一個額外的物理網絡接口，以便在發生故障時提供冗余，從而提高網絡的可靠性和穩定性。
更好的負載均衡：網卡聚合可以更好地分配網絡負載，從而提高網絡效率，并避免網絡擁堵。
更簡單的配置和管理：通過使用網卡聚合，可以簡化網絡配置和管理，從而減少網絡管理員的工作量。
更好的網絡容錯：網卡聚合可以提供一個額外的物理網絡接口，以便在發生故障時提供冗余，從而提高網絡的可靠性和穩定性。
更高的安全性：通過將多個物理網絡接口合并成一個邏輯接口，網卡聚合可以增強網絡安全性，從而保護網絡免受攻擊和入侵。
更高的性能：網卡聚合可以提供更快的數據傳輸速率，從而提高網絡性能。
更高的容量：通過將多個物理網絡接口合并成一個邏輯接口，網卡聚合可以支持更多并發連接，從而滿足高負載網絡環境的需求。
簡化網絡拓撲：網卡聚合可以簡化網絡拓撲，從而減少網絡中的節點數量和連接線數，從而降低網絡部署和維護的難度。
提高網絡擴展性：網卡聚合可以支持更多的并發連接，從而提高網絡擴展性，方便網絡規模的擴大。
提高網絡性能：網卡聚合可以提供更快的數據傳輸速率，從而提高網絡性能，滿足高負載網絡環境的需求。
更好的資源利用：網卡聚合可以更好地利用現有的硬件資源，從而降低網絡部署的成本。
更好的容錯能力：網卡聚合可以提供一個額外的物理網絡接口，以便在發生故障時提供冗余，從而提高網絡的容錯能力。
更高的安全性：通過將多個物理網絡接口合并成一個邏輯接口，網卡聚合可以增強網絡安全性，從而保護網絡免受攻擊和入侵。
簡化網絡管理：網卡聚合可以簡化網絡管理，從而降低網絡管理員的工作量，提高網絡管理的效率。
提高網絡可用性：網卡聚合可以提供一個額外的物理網絡接口，以便在發生故障時提供冗余，從而提高網絡的可用性和穩定性。
更好的網絡性能：網卡聚合可以提供更快的數據傳輸速率，從而提高網絡性能，滿足高負載網絡環境的需求。
更好的資源利用：網卡聚合可以更好地利用現有的硬件資源，從而降低網絡部署的成本。
更好的容錯能力：網卡聚合可以提供一個額外的物理網絡接口，以便在發生故障時提供冗余，從而提高網絡的容錯能力。
更高的安全性：通過將多個物理網絡接口合并成一個邏輯接口，網卡聚合可以增強網絡安全性，從而保護網絡免受攻擊和入侵。
簡化網絡部署：網卡聚合可以簡化網絡部署，從而降低網絡部署的難度和成本，提高網絡部署的效率。
提高網絡可靠性：網卡聚合可以提供一個額外的物理網絡接口，以便在發生故障時提供冗余，從而提高網絡的可靠性和穩定性。
更好的網絡管理：網卡聚合可以簡化網絡管理，從而降低網絡管理員的工作量，提高網絡管理的效率。
更好的網絡擴展性：網卡聚合可以支持更多的并發連接，從而提高網絡擴展性，方便網絡規模的擴大。
更好的網絡性能：網卡聚合可以提供更快的數據傳輸速率，從而提高網絡性能，滿足高負載網絡環境的需求。
更好的資源利用：網卡聚合可以更好地利用現有的硬件資源，從而降低網絡部署的成本。
更好的容錯能力：網卡聚合可以提供一個額外的物理網絡接口，以便在發生故障時提供冗余，從而提高網絡的容錯能力。
更高的安全性：通過將多個物理網絡接口合并成一個邏輯接口，網卡聚合可以增強網絡安全性，從而保護網絡免受攻擊和入侵。
簡化網絡布線：網卡聚合可以簡化網絡布線，從而降低網絡布線的時間和成本，提高網絡部署的效率。