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

網(wǎng)站建設(shè)哪家好，找成都創(chuàng)新互聯(lián)！專注于網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、重慶小程序開發(fā)、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項(xiàng)目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了高邑免費(fèi)建站歡迎大家使用！

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

首先的我的實(shí)驗(yàn)環(huán)境的網(wǎng)絡(luò)架構(gòu)類似如下圖

圖一

該實(shí)驗(yàn)環(huán)境由5臺服務(wù)器構(gòu)成，包含3個集群，每個集群上分別放置EUC相關(guān)的產(chǎn)品組件。

因?yàn)槭菍?shí)驗(yàn)環(huán)境，有兩個集群managementcluster, Network Cluster只包含一臺服務(wù)器。當(dāng)然在生產(chǎn)環(huán)境中，一個集群至少要包含兩臺服務(wù)器才能保證高可用。

圖二

那么說一下我碰到的問題，某天下午我還在自己的實(shí)驗(yàn)環(huán)境中正常工作，比如可以從位于內(nèi)網(wǎng)192.168.100.0/24上的vm1正常地訪問外網(wǎng)192.168.99.0/24，到了晚上的時候，卻發(fā)現(xiàn)所有的位于內(nèi)網(wǎng)192.168.100.0/24上的虛擬機(jī)都不能訪問外網(wǎng)了。

事出突然，必有妖孽。第一反應(yīng)是南北方向的網(wǎng)絡(luò)通道上的路由可能被損壞了，因?yàn)樵摥h(huán)境還有別的同事正在做別的實(shí)驗(yàn)，先讓別的同事停止在該環(huán)境中的操作，排除其它因素的干擾。然后我梳理了一遍Distributed Logical Router以及Edge Gateway上的各項(xiàng)設(shè)置，沒有發(fā)現(xiàn)任何異常的地方。

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

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

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

回過頭來，又開始看東向西的通訊，想從某些虛機(jī)彼此能夠互相通訊，某些虛機(jī)彼此不能互相通訊的現(xiàn)象中找出一些規(guī)律出來。結(jié)果真找出來一個規(guī)律來： Management Cluster和Workload Cluster里面位于內(nèi)網(wǎng)192.168.100.0/24上的虛機(jī)彼此可以相互通訊，但是都不能和Network Cluster里面位于內(nèi)網(wǎng)192.168.100.0/24上的虛機(jī)通訊。如圖一中所示，vm1,vm3,vm4,vm5可以互相通訊，但是不能和vm2通訊。因?yàn)槟媳毕蛩械木W(wǎng)絡(luò)節(jié)點(diǎn)組件也都是位于vm2所在的物理服務(wù)器上，貌似是所有位于ESXi服務(wù)器192.168.99.12上的虛機(jī)都變成了網(wǎng)絡(luò)的孤島。從這個現(xiàn)象，開始合理地懷疑該機(jī)器上網(wǎng)絡(luò)接口出現(xiàn)了問題。

在我的實(shí)驗(yàn)環(huán)境中的每一臺服務(wù)器都有四個網(wǎng)卡接口，其中第一塊網(wǎng)口都用作ESXi的vmkernel接口，這一塊網(wǎng)卡肯定沒有壞，否則我根本不能通過vCenter來訪問vm2。

圖三

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

圖四

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

圖五

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

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

希望我這次故障分析，排查，解決的思考過程能夠?qū)Υ蠹矣兴鶐椭?/p>

關(guān)于作者：Sam Zhao，EUC解決方案部門經(jīng)理。在軟件開發(fā)，測試，項(xiàng)目管理,客戶項(xiàng)目實(shí)施，Technical marketing方面有15年IT從業(yè)經(jīng)歷，發(fā)表過七個專利以及合著書一部。