NSX 虛擬網絡故障分析經驗分享

今天的題目是關于NSX的虛擬網絡故障分析，問題排查定位的經驗分享，嚴格地說，不屬于終端用戶計算的范疇，但是終端用戶計算以及軟件定義的網絡已經結合得越來越密不可分，有越來越多的用戶開始使用NSX搭建EUC產品的專有網絡環境，例如給VDI的計算資源池分配專有的網絡空間，參見之前的博客利用NSX搭建專有子網。

筆者最近也搭建了一套基于NSX虛擬網絡的EUC實驗環境，通過使用NSX提供的logical network的能力，可以隨心所欲的構建自己的網絡，互聯互通，網絡微分段，分布式防火墻，完全不必麻煩公司的網絡管理員，真的是我的地盤我做主。既然是自己的地盤自己做主，當然出了問題也要自己搞定，不能麻煩網管了。在這里我就和大家分享一個我最近碰到的一個網絡故障，問題排查的過程還是蠻有趣的，希望給大家提供一點碰到虛擬網絡問題后的解決思路，可以舉一反三。

首先的我的實驗環境的網絡架構類似如下圖

圖一

該實驗環境由5臺服務器構成，包含3個集群，每個集群上分別放置EUC相關的產品組件。

因為是實驗環境，有兩個集群managementcluster, Network Cluster只包含一臺服務器。當然在生產環境中，一個集群至少要包含兩臺服務器才能保證高可用。

圖二

那么說一下我碰到的問題，某天下午我還在自己的實驗環境中正常工作，比如可以從位于內網192.168.100.0/24上的vm1正常地訪問外網192.168.99.0/24，到了晚上的時候，卻發現所有的位于內網192.168.100.0/24上的虛擬機都不能訪問外網了。

事出突然，必有妖孽。第一反應是南北方向的網絡通道上的路由可能被損壞了，因為該環境還有別的同事正在做別的實驗，先讓別的同事停止在該環境中的操作，排除其它因素的干擾。然后我梳理了一遍Distributed Logical Router以及Edge Gateway上的各項設置，沒有發現任何異常的地方。

沒有任何頭緒，我索性按照http://www.virtualizationblog.com/nsx-step-by-step-part-16-configuring-static-route/ 在相同的硬件環境上又重新搭建了一個類似的網絡環境，在這個新的網絡環境中，虛機依然不能訪問外網資源。

利用ping,tracert等工具，發現在內網的每一個虛機都能夠訪問內網網關192.168.100.1,也能夠訪問transition 網絡上的下行端口10.10.10.2，但是transition 網絡上的上行端口10.10.10.1就訪問不到了。這種現象讓我依然認為是南北向的路由出了問題，我試著定位路由在那里斷掉了，依然沒任何頭緒。

浪費了大半天時間，我又試著看一下東西向的網絡通訊。我發現同在一個內網192.168.100.0/24上的虛擬機之間有的彼此能夠互相通訊，有的卻彼此不能通訊，這讓我懷疑可能是NSX構建的虛擬網絡出問題了，例如VXLAN Tunnel End Point所用的IP被別人占用了之類的，查了一下也排除了這個可能。又開始讀官方的問題解決手冊https://pubs.vmware.com/NSX-62/topic/com.vmware.ICbase/PDF/nsx_62_troubleshooting.pdf ，塊頭太大，沒有完全讀完，也沒能按照其中的步驟去定位問題。事后想想這個文檔還是蠻有用的，按照其中的辦法挨個子系統分別排查，自底向上，應該能夠找到故障原因的。

回過頭來，又開始看東向西的通訊，想從某些虛機彼此能夠互相通訊，某些虛機彼此不能互相通訊的現象中找出一些規律出來。結果真找出來一個規律來： Management Cluster和Workload Cluster里面位于內網192.168.100.0/24上的虛機彼此可以相互通訊，但是都不能和Network Cluster里面位于內網192.168.100.0/24上的虛機通訊。如圖一中所示，vm1,vm3,vm4,vm5可以互相通訊，但是不能和vm2通訊。因為南北向所有的網絡節點組件也都是位于vm2所在的物理服務器上，貌似是所有位于ESXi服務器192.168.99.12上的虛機都變成了網絡的孤島。從這個現象，開始合理地懷疑該機器上網絡接口出現了問題。

在我的實驗環境中的每一臺服務器都有四個網卡接口，其中第一塊網口都用作ESXi的vmkernel接口，這一塊網卡肯定沒有壞，否則我根本不能通過vCenter來訪問vm2。

圖三

NSX的虛擬網絡都是架構在vSphere的分布式網絡交換機基礎之上的，分布式網絡交換機可以給加入其中的每一個物理主機分配不同的物理網卡作為上行接口。虛擬網絡192.168.100.0/24在Vm2所在的物理主機上使用第二個物理網口NIC2作為上行接口。

圖四

合理懷疑以后，就需要事實求證了。和Luke同學商量了一個反向求證的辦法：配置vm2所在的物理主機上的ESXi管理網絡的物理網絡接口，缺省的配置是NIC1,依次將網絡接口改成NIC2,NIC3,NIC4,然后觀察vCenter中ESXi主機的連接情況，如果該物理主機在vCenter顯示失去連接了，這就表明該物理網口出問題了。

圖五

一番求證工作做下來，果然證明該服務器上的NIC2,NIC3,NIC4三塊網卡都出問題了。三塊網卡硬件都出問題，這么邪門的事情都讓我碰上了,看來我可以去買×××了。不過不得不說，vmware的軟件還是靠譜的，一臺服務器上的硬件壞了，分布在其余服務器上的虛擬網絡依然正常工作。

剩下的工作就簡單了，抄起電話找IT工程師更換網卡，問題搞定，我又開始在我的地盤里折騰了。

希望我這次故障分析，排查，解決的思考過程能夠對大家有所幫助。

關于作者：Sam Zhao，EUC解決方案部門經理。在軟件開發，測試，項目管理,客戶項目實施，Technical marketing方面有15年IT從業經歷，發表過七個專利以及合著書一部。