我是VMWARE的認證講師，前段時間在上“NSX-T 3.0-安裝配置和管理”的課程中，碰到學員問到一個有趣的問題，由此聯想到目前使用SDDC的企業客戶越來越多了，軟體定義的資料中心的确給虛拟中心管理者和應用開發人員在部署使用資源時以極大的靈活和彈性，但同時分布式計算也給排錯增加了複雜性。在遇到問題時，理清排錯思路，由表及裡地系統排錯是提高效率的關鍵，在這個基礎上熟悉SDDC的相關元件及熟練使用排錯工具當然也是前提條件之一。
這個問題是：我們已經為下圖紅色的租戶配置好了對應的T1網關和T0 VRF網關， 用BGP和外部實體路由器正确建立的鄰居關系，路由表交換正常，從外部也能正常ping通紅色租戶的虛機Ubuntu-01a(IP:172.16.40.11),但是從T1-GW-VRF-Red 所在的Edge裝置上，确無法ping通該虛機，這台虛機所在的主控端是ESXi-04，同時當然也是Transport Node之一。如下圖示。（拓撲圖檔來源：VMWARE NSX-T ICM實驗手冊）
我們先用putty工具登上網關所在的Edge-1 VM上嘗試複現這個“問題”，首先檢視所有的T0/T1網關裝置，從中看到 VRF 7和VRF 8分别是對應為紅色租戶服務的T0和T1網關，用vrf 7或者vrf 8指令進入對應DR元件裡，的确無法ping通Ubuntu-01a這台虛機（如上圖示）。這裡先說答案：從Ubuntu-01a所在Segment連接配接到的DR-T1-GW-VRF-Red上ping 這台虛機,源IP是使用該虛機所在的網關位址 172.16.40.1，因為這是分布式路由元件，是以加入這個Segment的所有Transport Node上都會有對應的分布式路由元件，并且預設被配置設定同一個MAC位址：02-50-56-56-44-52，這樣一來，從Edge node上ping出去的包，回應是直接到Ubuntu-01a虛機所在的主控端上，是以Edge 節點上看不到任何回應。
下面我們開始抓包印證：
1.檢視 vrf 7 （DR-T1-GW-VRF-Red) 對應的接口，準備在連接配接虛機所在的Segment的接口抓包：
2.可以看見的确有出去的 ICMP Echo request,但是沒任何回應。注意這裡用到的源MAC：02-50-56-56-44-52.
3.接下來ping出去的包應該是通過edge VM的fp-eth0出去的，這裡eth0是管理接口，fp-eth0是對應的是Edge連接配接其他Transport Node,傳輸生産資料的接口，是以我們再針對該接口抓包：
4.通過在該Edge VM上的接口fp-eth0上抓包，可以看到ping包的确通過該接口出去，也正常經過了GENEVE封裝，這裡172.20.11.155和172.20.11.151分别是Edge VM和Ubuntu-01a所在主控端ESXi-04的TEP IP，但仍然沒有回應：
5.因為這個目标VM在esxi-04上運作，對應的Segement使用的上聯網卡是VMNIC4. 是以下一步直接到這台主控端上針對對應的上聯網卡繼續抓包，這裡可以看到，仍然沒有任何回應：