我是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. 所以下一步直接到这台宿主机上针对对应的上联网卡继续抓包，这里可以看到，仍然没有任何回应：