尧图网页设计 
简介一份面向网络虚拟化项目前期验证的VMware NSX POC测试报告适合企业IT架构师、网络工程师和解决方案顾问在规划NSX部署或撰写技术方案时参考。文档基于实际POC项目整理完整覆盖测试目的、人员分工、时间安排、测试环境搭建以及逻辑交换、逻辑路由、分布式防火墙等核心功能验证并包含NSX控制器可用性等关键可靠性检查。其中逻辑交换覆盖逻辑交换机创建逻辑路由包含分布式路由配置、动态路由通告与控制分布式防火墙还细分了基于安全组、基于身份及统一管理等场景能够帮助读者建立从环境准备到功能验收的完整测试思路。资源为单一docx文档包体大小约3.05MB便于直接阅读和二次编辑。目前已有136人学习下载适合需要快速理解NSX POC实施重点或借鉴测试报告编写结构的专业人士。1. NSX POC 测试报告那份 docx 里最值得抠的验证逻辑POC 的难点从来不是功能列表够不够长而是怎么证明“虚拟化层的网络能力”在真实流量路径上有效。这份 NSX POC 测试报告验证了从逻辑交换、分布式路由到分布式防火墙的完整链路其中最有价值的两个结论逻辑交换机可以横跨物理三层提供二层连接启用分布式路由后同主机跨子网流量不再绕到 Edge 上“发卡”。做类似验证的团队可以直接按这份报告的脉络复现不用从零设计用例——它把标准 POC 的测试场景、准备步骤和预期结果已经排列好了。即便后续迁移到 NSX-T 4.1.x 时代这份 6.1.2 报告里的传输区域规划、单播复制验证、DFW 规则顺序排查依然是同一套思维模型。下面从环境基线开始逐项拆解。2. 环境搭建与一次性安装验证从 vCenter 5.5 到 NSX 6.1.22.1 测试拓扑与软硬件基线原报告采用三集群拓扑计算集群 A、计算集群 B以及一个由 vCenter 统一管理的“管理 边缘”集群。控制面与管理组件全部集中在管理和边缘集群两个计算集群承载业务虚拟机。值得注意的是网络规划——计算集群 A 和 B 位于 192.168.250.0/24管理边缘集群位于 192.168.150.0/24物理网络本身就是跨网段的这为验证“逻辑交换横跨物理三层”提供了前提。硬件基线按原报告整理如下设备配置虚拟化服务器 x5四路 4 核至强 CPU32GB 内存RAID54 口千兆网卡存储阵列12TB 光纤存储阵列SAS 盘RAID5 71至少 2 块热备盘扩展网卡每台服务器扩 2 块双口千兆网卡交换机Cisco 6509R-E / N7K软件版本锁定为 vSphere 5.5 企业增强版、vCenter Server 5.5、NSX for vSphere 6.1.2。原报告强调如果条件有限凑不齐五台物理服务器可以在计算集群 A 以及管理和边缘集群各减掉一台这样做会牺牲 Edge HA 主备分离和 ECMP 的完整效果但基本功能验证不受影响。这一阶段的设备安装与普通 VMware 虚拟机安装没有区别主要工作是提前把 vCenter 建好、增加 Cluster、配置好分布式交换机为后续 NSX 组件投放做准备。实际经验是把 ESXi 的安装镜像先放到共享存储上避免五台服务器一台台插 U 盘的低效操作。2.2 一次性安装验证为什么“不用二次安装”NSX Manager 通过导入 ova 部署输入 IP、密码后启动虚拟机访问https://NSX-Manager-IP:5480用 admin 账号配置 NTP 和 vCenter 注册。原报告有一个细节值得注意通过 vCenter 部署 ova 时安装向导会要求输入 vCenter Server 的 IP 地址如果是直接通过 ESXi 部署这个输入项不会出现部署完成后必须手动补配 vCenter 连接。注册完成后vCenter 左侧出现 NSX 菜单栏代表控制通道打通。接着在 “Installation → Host Preparation” 里对集群执行主机准备操作这一步会在每台 ESXi 上安装网络虚拟化内核模块包括 VXLAN、分布式防火墙和分布式路由。一次性安装的验证方法是原报告最实用的部分提示准备测试环境时先预留一台物理主机不要加入集群。等集群内既有主机全部完成 Host Preparation 后再把预留主机拖进集群观察该主机是否自动出现 VXLAN、DFW 等模块状态。正常情况下 2~3 分钟内状态自动变为绿色不需要在该主机上重新执行安装动作。不要手动在这台主机上执行esxcli software vib install之类命令一旦手动安装 VIB控制器侧的版本比对逻辑会认为该主机处于“非受管”状态反而破坏了自动同步机制。一次性安装的本质是NSX 的数据面模块通过 vCenter 对集群做持续同步主机只是加入集群而触发模块投放。2.3 VTEP 配置与单播模式下的 VXLAN 准备在 “Logical Network Preparation → VXLAN Transport” 中配置 VTEP 地址池。计算集群的 VTEP 落在 192.168.250.0/24管理和边缘集群的 VTEP 落在 192.168.150.0/24。在 ESXi 上确认 VTEP 状态esxcli network vxlan vtep list Name VMkernel NIC Gateway VNI range vxlan-1 vmk1 192.168.250.1 5000-6000vtel 输出中 vmk1 是专门为 VXLAN 流量划分的 VMkernel 端口网关指向物理网络三层地址。VNI 范围来自传输区域内定义的网络池逻辑交换机创建时从这个池里分配 VXLAN 网络标识符。注意跨集群 VXLAN 流量在物理网络上表现为普通 UDP 报文目的端口 4789因此物理交换机不需要开启多播协议交换机上对应 VLAN 的 SVI 配置正确即可。原报告特别说明了一个在 6.x 时代反复被客户问到的点VXLAN 是否必须依赖物理网络的多播支持。答案是否定的NSX 提供控制器主导的单播复制模式广播、未知单播和组播报文由控制器复制给相关 VTEP。验证方式很简单——创建传输区域时不填写任何多播地址创建逻辑交换机后直接做跨主机 ping通就说明单播复制工作正常。所有集群必须确认在同一个传输区域内逻辑交换机本质上是传输区域内的一个网段实例传输区域先于逻辑交换机存在这个顺序不能反。3. 逻辑交换与分布式路由消除发卡效应与 OSPF 邻居调试3.1 跨物理三层的逻辑二层创建逻辑交换机创建名为Prod_Logical_Switch的逻辑交换机连接到 NSX Edge 服务网关然后把 web-sv-03a 和 web-sv-04a 两块虚拟网卡接入该逻辑交换机。这两台 Web 虚拟机分别位于不同计算集群、不同物理网段但对它们而言彼此处于同一个二层网络。验证二层连通性ssh adminweb-sv-04a-ip ping -c 4 web-sv-03a能收到 ICMP 回复即证明逻辑交换机跨物理三层提供了二层连接。此时抓包的观察点在 VTEP 端口上可以看到 VXLAN 封装后的报文外层源目 IP 是两台物理主机的 VTEP 地址内层则是虚拟机的 MAC 与 IPtcpdump-uw -i vmk1 -s 0 -c 100 port 4789如果 ping 不通先查逻辑交换机状态和虚拟机 vNIC 的端口组是否已经切换到该逻辑交换机对应端口再查 VTEP 通信是否正常这一步用 ESXi 的vmkping验证即可。3.2 分布式路由与“发卡”流量发卡效应是本份报告教学价值最高的一部分。初始状态下Web、App、DB 三层各在不同逻辑交换机三层之间全部依赖 NSX Edge 路由。数据包路径是App 虚拟机 → 物理出口 → 管理集群上的 Edge → 回到原主机 → DB 虚拟机所在主机。App 和 DB 明明在同一台 ESXi 上流量却要绕到管理集群再回来这就是典型的发卡hairpin流量。创建分布式路由器DLR后把 App 和 DB 的接口从 Edge 迁移到分布式路由器上。关键在于 DLR 的每一个接口配置会自动推送到集群内所有 ESXi 主机的内核模块中路由决策不再经过外部设备。在 ESXi 上查看分布式路由模块状态是常见做法/opt/vmware/nsx-cli/bin/nsxcli -c get logical-router该命令列出本机分布式路由器的接口和邻居信息能看到 App 子网与 DB 子网的路由表项即为正常。验证优化效果时在 App 虚拟机上对 DB 虚拟机执行 traceroute路径应只包含宿主主机内部一跳不再出现 Edge 的 IP 地址。如果 traceroute 仍然经过 Edge IP说明虚拟机 vNIC 没接到 DLR 的逻辑接口上或者 DLR 接口在 vCenter 中未正确关联到该主机。实践提醒DLR 只处理东西向流量南北向流量仍由 Edge 承担。把 Edge 接口移除之前务必确认 DLR 的网关地址规划已经完成否则 IPv4 网关地址或下一跳变化会导致虚拟机短暂断流。3.3 OSPF 动态路由通告与邻居排错逻辑路由只解决逻辑网络内部互通。要让物理核心交换机感知到这些逻辑网段需要动态路由协议参与。原报告在分布式路由器和 Edge 之间启用了 OSPF 动态路由验证命令如下ssh adminedge-ip show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 10.0.10.2 1 Full/Backup 00:00:36 10.0.10.2 uplink-1 show ip route OSPF 192.168.100.0/24 [110/2] via 10.0.10.2, uplink-1OSPF 配置有三个关键点。第一Edge 与分布式路由器之间连接的接口网段必须宣告进 OSPF 进程否则邻居关系建立不起来。第二外部物理路由器的 network 语句必须覆盖连接网段同时注意区域 ID 一致性示例中全部在 Area 0 内。第三验证通告是否成功不要只看邻居状态要切换至show ip route观察 OSPF 前綴是否出现在 Edge 路由表中。如果邻居状态卡在 EXSTART 或 EXCHANGE最常见的诱因是 MTU 不一致。分布式路由器和 Edge 连接的逻辑交换机 MTU 是 1500物理交换机三层接口也应为 1500把某一边改成 9000 会导致 OSPF DD 报文过大而无法建立完整邻居。这类问题在 POC 验证中容易被忽视但却是后续上线排障的高频点。4. 分布式防火墙从默认规则到基于 AD 身份的安全组策略4.1 修改防火墙默认规则分布式防火墙默认规则在新建逻辑交换机后是全部允许放行。POC 第一步先修改默认规则为丢弃再逐步增加显式允许规则。与物理防火墙最大的区别在于执行位置——分布式防火墙的每条规则都作用在虚拟机 vNIC 的数据路径上规则检查发生在虚拟机发送报文的瞬间即使两台虚拟机在同一台 ESXi 主机的同一个 dvSwitch 上流量同样会被过滤。在 vCenter 的 NSX 管理界面修改默认规则后可以用 API 核对规则是否下发curl -k -u admin:admin -H Content-Type: application/xml \ https://nsx-manager/api/4.0/firewall/globalroot-0/config返回的 XML 中包含规则列表、动作以及最后修订时间戳。把修改时间与 vCenter 操作时间对比可以确认本次变更已经同步到所有传输节点。注意修改默认规则前至少保留一条允许管理网络的规则否则 NSX Manager 与 ESXi 主机之间的通信会被拦断后续排错会变得很被动。4.2 基于安全组的防火墙规则安全组的价值在于把动态成员关系与规则解耦。典型的三层应用规则设计如下规则名源目标服务动作Web-Allow-App安全组 Web安全组 AppTCP 8080允许App-Allow-DB安全组 App安全组 DBTCP 3306允许Web-Deny-Other安全组 Web任意任意丢弃创建安全组时成员来源建议选择“虚拟机名称前缀”或“安全标签”而不是手工添加固定 IP。原报告把安全组规则作为基本功能验证的核心原因在于 POC 客户后续生产环境里虚拟机会频繁迁移基于 IP 地址的策略维护成本极高而安全组可以通过动态匹配随虚拟机迁移自动生效。验证时对 Web 虚拟机发起对 App 8080 端口的访问能通发起对 Web 虚拟机 SSH22 端口的访问被丢弃。两个结果同时成立说明规则已生效。还有一种容易误判的情况规则动作正确但目标虚拟机自身操作系统防火墙拦截了流量导致验证失败。测试前先确认虚拟机内部防火墙没有叠加影响。4.3 基于 AD 身份的用户组规则基于身份的防火墙规则是将 Active Directory 用户组作为规则源或目标比安全组更细粒度。前提条件是 vCenter 和 NSX Manager 已经加入域且 NSX 服务账号具备读取 AD 组信息的权限。配置完成后在防火墙规则中源选择 Active Directory 用户组即可。验证时用该域组内的账户登录虚拟机发起访问规则会依据 vSphere 收集到的登录用户信息来判定是否匹配。若域内账户被丢弃而其他来源放行说明身份规则生效。这部分的坑点在于身份识别依赖 VMware Tools 的登录信息同步。如果虚拟机内 Tools 未运行或登录的是本地账户而非域账户身份字段会为空规则容易发生误判。POC 验证时至少登录一个域用户等待 30 秒让 Tools 心跳同步完成后再测试不要登录后立刻发起访问。4.4 Edge 防火墙与分布式防火墙的统一管理原报告所谓“两种防火墙的统一管理”是指在同一个 UI 中同时管理 Edge 服务网关防火墙和分布式防火墙规则。两者定位不同Edge 防火墙过滤南北向流量规则链可以覆盖 NAT、负载均衡等服务分布式防火墙做基于五元组的东西向过滤规则执行在每台 ESXi 主机内核中。统一管理的实际收益是两个组件可以复用同一套安全组对象避免在 Edge 和主机上维护两套安全对象定义。部署策略上建议把面向虚拟机默认防护的规则放分布式防火墙把对外端口映射和 NAT 相关的规则放 Edge 防火墙规则数量较多的场景优先拆分安全组避免人工审查长规则列表时发生顺序误判。5. 可用性与高级功能控制器集群、Edge HA、ECMP 与 VXLAN 桥接5.1 控制器集群的可用性验证NSX 6.1.2 中三个控制器组成集群一台故障后其余节点接管控制面职责。原报告的验证方式是直接关闭一台控制器虚拟机观察逻辑交换和路由功能是否持续正常。控制器集群状态检查ssh admincontroller-1 show control-cluster status三个控制器节点应显示 ACTIVE且 API、管理、控制器三种角色分布均衡。关闭一台后日志会出现 Leader 切换记录但既有的 VXLAN 隧道不受影响。这是面试级概念控制器不在数据面转发路径上它只处理 VTEP 信息同步、ARP 泛洪复制、分布式路由配置下发等控制报文。因此“关掉一台控制器业务断不断”不是控制器高可用的真正指标指标是新增逻辑交换机、新增主机等控制面操作是否仍然正常。5.2 Edge 服务网关的高可用性Edge HA 的验证重点在主备切换收敛时间。配置 Edge 时勾选 HA 选项系统会创建一个备用 Edge常态下不对流量生效主 Edge 故障时由备用 Edge 接管 IP 地址和路由表。ssh adminedge-ip show service ha HA Status: MASTER模拟故障的推荐动作是直接关停主 Edge 虚拟机因为生产环境最常见的就是主机宕机或 Edge 进程崩溃而优雅关停反而无法体现故障场景。观察备用 Edge 的状态从 BACKUP 变为 MASTER同时持续从外部 ping 业务虚拟机的浮动 IP记录切换期间的丢包数。如果业务 IP 的 MAC 地址没有回切到物理网络设备说明虚拟 MAC 保持有效符合预期。提示Edge HA 主备必须位于不同的物理主机否则物理主机故障时主备同时失效。POC 环境如果只有三台物理服务器一定要把两个 Edge 分别规划在计算集群和边缘集群的不同主机上。5.3 等价多路径ECMP提供的高可用ECMP 让多个 Edge 实例同时承载南北向流量相比 HA 的一主一备它的可用性更高。原报告通过多个 Edge 连接同一个上行链路验证流量被散列到多条路径。配置 ECMP 的步骤包括创建多个 Edge 实例并接入同一逻辑交换机在 Edge 和分布式路由器上启用等价多路径协议再让物理核心交换机同时学习到多条等价路由。验证用 iperf 产生持续流量更直观iperf -c 192.168.250.100 -P 4 -t 30-P 4开启四条并发连接观察各 Edge 的流量速率是否均匀分布。关停其中一个 Edge活跃连接会短暂中断后在新连接中恢复新建连接立即投递到剩余 Edge说明 ECMP 路径自动收敛。ECMP 的价值不在单条连接的负载均衡而在链路的冗余和带宽聚合。单条 TCP 连接只会哈希到一条物理路径因此验证时必须开多并发否则看到一个 Edge 流量很高另一个空闲就误判为负载不均衡。5.4 逻辑负载均衡验证逻辑负载均衡在 Edge 服务网关上配置向导包含三件事定义虚拟服务器VIP、定义服务池、定义健康检查。配置项推荐值说明VIP 地址192.168.10.100与虚拟机服务同逻辑网段或 NAT 后外部网段池成员web-sv-03a, web-sv-04a按业务角色分组健康检查TCP 80间隔 5 秒失败后自动摘除成员验证负载均衡是否生效从外部反复访问 VIPcurl http://192.168.10.100/连续请求多次并观察后端虚拟机访问日志请求分布在两台后端说明轮询算法生效。如果请求始终落在同一台后端重点检查池成员权重设置和健康检查结果。常见问题是后端虚拟机的系统防火墙拦截了来自 Edge 网关 IP 的健康检查报文导致后端被判离线全部流量被导向剩余成员。5.5 VXLAN 与 VLAN 的桥接机制VXLAN 与 VLAN 之间的桥接用于逻辑网络和现有物理服务器共存的过渡场景。在 Edge 上创建桥接接口一边连接逻辑交换机另一边连接物理 VLANEdge 在两层之间执行二层转发。ssh adminedge-ip show bridge Bridge Domain: VXLAN-1000 - VLAN-100桥接功能适合小流量过渡不适合大规模生产流量。原因是所有桥接流量都要经过 Edge 虚拟机的数据路径单台 Edge 的吞吐上限就是瓶颈。原报告把这项功能放在高级验证里目的是证明 NSX 能兼容现有物理网络而不是鼓励长期依赖桥接。真正合理的演进路径是逐步把物理服务器迁移进逻辑交换机最终拆掉桥接。6. 验证 NSX 数据面转发的三个实用技巧6.1 确认 VTEP 二层互通逻辑交换机建好后跨主机 ping 不通先用最简单的方法排除物理问题esxcli network vxlan vtep list vmkping -I vmk1 192.168.250.2vmkping -I vmk1指定从 vmk1 这个 VMkernel 接口发起 ICMP 请求目标是另一台主机的 VTEP 地址。如果 ping 不通检查 vmk 所在 VLAN 和物理交换机端口是否为 trunk 模式并允许了对应 VLAN。VXLAN 端口 4789 通常不需要物理设备额外放行但部分网络 ACL 会拦截非知名 UDP 端口这是最容易遗漏的点。6.2 抓一个 VXLAN 封装包确认隧道身份数据面异常时抓包是最快的定位手段。ESXi 上抓取虚拟机的 dvPort 流量pktcap-uw --port dvport-id -c 50 -o /tmp/vxlan.pcap--port指定虚拟机的分布式端口 ID-c 50限定抓取报文数量。抓到包后重点观察外层 IP 的源目地址是否为主机 VTEP内层 MAC 是否为虚拟机网卡地址。外层地址正确、内层地址混乱通常是逻辑交换机在传输区域中的 VNI 分配错误完全抓不到包问题应定位在虚拟机 vNIC 到 dvPort 的路径而不是 VXLAN 本身。把 pcap 拉到本地用 Wireshark 的 VXLAN 解码器可以直接看到内层协议头和原始以太网帧比在 ESXi 上做十六进制分析效率高得多。6.3 观察分布式防火墙的规则命中序列修改规则后不生效常见原因是安全组没有正确匹配到目标虚拟机。分布式防火墙的规则执行顺序按从上到下的优先级排列一条规则不匹配时继续向下匹配这与物理防火墙“首条匹配即停止”的行为不同安全组规则之间可以叠加。因此在 vCenter 防火墙界面勾选会话日志记录发起测试流量后回查日志日志中标明的规则序号可以精确对应到具体规则条目由此判断流量是被“允许”还是被“丢弃”及在哪一条规则处被处理。排错时按这个顺序走一遍大部分“声称不通”的逻辑交换机问题都能定位到具体环节比反复重启服务有效率得多。本文还有配套的精品资源点击获取 NSX POC测试报告：逻辑交换、分布式路由与防火墙验证指南
简介一份面向网络虚拟化项目前期验证的VMware NSX POC测试报告适合企业IT架构师、网络工程师和解决方案顾问在规划NSX部署或撰写技术方案时参考。文档基于实际POC项目整理完整覆盖测试目的、人员分工、时间安排、测试环境搭建以及逻辑交换、逻辑路由、分布式防火墙等核心功能验证并包含NSX控制器可用性等关键可靠性检查。其中逻辑交换覆盖逻辑交换机创建逻辑路由包含分布式路由配置、动态路由通告与控制分布式防火墙还细分了基于安全组、基于身份及统一管理等场景能够帮助读者建立从环境准备到功能验收的完整测试思路。资源为单一docx文档包体大小约3.05MB便于直接阅读和二次编辑。目前已有136人学习下载适合需要快速理解NSX POC实施重点或借鉴测试报告编写结构的专业人士。1. NSX POC 测试报告那份 docx 里最值得抠的验证逻辑POC 的难点从来不是功能列表够不够长而是怎么证明“虚拟化层的网络能力”在真实流量路径上有效。这份 NSX POC 测试报告验证了从逻辑交换、分布式路由到分布式防火墙的完整链路其中最有价值的两个结论逻辑交换机可以横跨物理三层提供二层连接启用分布式路由后同主机跨子网流量不再绕到 Edge 上“发卡”。做类似验证的团队可以直接按这份报告的脉络复现不用从零设计用例——它把标准 POC 的测试场景、准备步骤和预期结果已经排列好了。即便后续迁移到 NSX-T 4.1.x 时代这份 6.1.2 报告里的传输区域规划、单播复制验证、DFW 规则顺序排查依然是同一套思维模型。下面从环境基线开始逐项拆解。2. 环境搭建与一次性安装验证从 vCenter 5.5 到 NSX 6.1.22.1 测试拓扑与软硬件基线原报告采用三集群拓扑计算集群 A、计算集群 B以及一个由 vCenter 统一管理的“管理 边缘”集群。控制面与管理组件全部集中在管理和边缘集群两个计算集群承载业务虚拟机。值得注意的是网络规划——计算集群 A 和 B 位于 192.168.250.0/24管理边缘集群位于 192.168.150.0/24物理网络本身就是跨网段的这为验证“逻辑交换横跨物理三层”提供了前提。硬件基线按原报告整理如下设备配置虚拟化服务器 x5四路 4 核至强 CPU32GB 内存RAID54 口千兆网卡存储阵列12TB 光纤存储阵列SAS 盘RAID5 71至少 2 块热备盘扩展网卡每台服务器扩 2 块双口千兆网卡交换机Cisco 6509R-E / N7K软件版本锁定为 vSphere 5.5 企业增强版、vCenter Server 5.5、NSX for vSphere 6.1.2。原报告强调如果条件有限凑不齐五台物理服务器可以在计算集群 A 以及管理和边缘集群各减掉一台这样做会牺牲 Edge HA 主备分离和 ECMP 的完整效果但基本功能验证不受影响。这一阶段的设备安装与普通 VMware 虚拟机安装没有区别主要工作是提前把 vCenter 建好、增加 Cluster、配置好分布式交换机为后续 NSX 组件投放做准备。实际经验是把 ESXi 的安装镜像先放到共享存储上避免五台服务器一台台插 U 盘的低效操作。2.2 一次性安装验证为什么“不用二次安装”NSX Manager 通过导入 ova 部署输入 IP、密码后启动虚拟机访问https://NSX-Manager-IP:5480用 admin 账号配置 NTP 和 vCenter 注册。原报告有一个细节值得注意通过 vCenter 部署 ova 时安装向导会要求输入 vCenter Server 的 IP 地址如果是直接通过 ESXi 部署这个输入项不会出现部署完成后必须手动补配 vCenter 连接。注册完成后vCenter 左侧出现 NSX 菜单栏代表控制通道打通。接着在 “Installation → Host Preparation” 里对集群执行主机准备操作这一步会在每台 ESXi 上安装网络虚拟化内核模块包括 VXLAN、分布式防火墙和分布式路由。一次性安装的验证方法是原报告最实用的部分提示准备测试环境时先预留一台物理主机不要加入集群。等集群内既有主机全部完成 Host Preparation 后再把预留主机拖进集群观察该主机是否自动出现 VXLAN、DFW 等模块状态。正常情况下 2~3 分钟内状态自动变为绿色不需要在该主机上重新执行安装动作。不要手动在这台主机上执行esxcli software vib install之类命令一旦手动安装 VIB控制器侧的版本比对逻辑会认为该主机处于“非受管”状态反而破坏了自动同步机制。一次性安装的本质是NSX 的数据面模块通过 vCenter 对集群做持续同步主机只是加入集群而触发模块投放。2.3 VTEP 配置与单播模式下的 VXLAN 准备在 “Logical Network Preparation → VXLAN Transport” 中配置 VTEP 地址池。计算集群的 VTEP 落在 192.168.250.0/24管理和边缘集群的 VTEP 落在 192.168.150.0/24。在 ESXi 上确认 VTEP 状态esxcli network vxlan vtep list Name VMkernel NIC Gateway VNI range vxlan-1 vmk1 192.168.250.1 5000-6000vtel 输出中 vmk1 是专门为 VXLAN 流量划分的 VMkernel 端口网关指向物理网络三层地址。VNI 范围来自传输区域内定义的网络池逻辑交换机创建时从这个池里分配 VXLAN 网络标识符。注意跨集群 VXLAN 流量在物理网络上表现为普通 UDP 报文目的端口 4789因此物理交换机不需要开启多播协议交换机上对应 VLAN 的 SVI 配置正确即可。原报告特别说明了一个在 6.x 时代反复被客户问到的点VXLAN 是否必须依赖物理网络的多播支持。答案是否定的NSX 提供控制器主导的单播复制模式广播、未知单播和组播报文由控制器复制给相关 VTEP。验证方式很简单——创建传输区域时不填写任何多播地址创建逻辑交换机后直接做跨主机 ping通就说明单播复制工作正常。所有集群必须确认在同一个传输区域内逻辑交换机本质上是传输区域内的一个网段实例传输区域先于逻辑交换机存在这个顺序不能反。3. 逻辑交换与分布式路由消除发卡效应与 OSPF 邻居调试3.1 跨物理三层的逻辑二层创建逻辑交换机创建名为Prod_Logical_Switch的逻辑交换机连接到 NSX Edge 服务网关然后把 web-sv-03a 和 web-sv-04a 两块虚拟网卡接入该逻辑交换机。这两台 Web 虚拟机分别位于不同计算集群、不同物理网段但对它们而言彼此处于同一个二层网络。验证二层连通性ssh adminweb-sv-04a-ip ping -c 4 web-sv-03a能收到 ICMP 回复即证明逻辑交换机跨物理三层提供了二层连接。此时抓包的观察点在 VTEP 端口上可以看到 VXLAN 封装后的报文外层源目 IP 是两台物理主机的 VTEP 地址内层则是虚拟机的 MAC 与 IPtcpdump-uw -i vmk1 -s 0 -c 100 port 4789如果 ping 不通先查逻辑交换机状态和虚拟机 vNIC 的端口组是否已经切换到该逻辑交换机对应端口再查 VTEP 通信是否正常这一步用 ESXi 的vmkping验证即可。3.2 分布式路由与“发卡”流量发卡效应是本份报告教学价值最高的一部分。初始状态下Web、App、DB 三层各在不同逻辑交换机三层之间全部依赖 NSX Edge 路由。数据包路径是App 虚拟机 → 物理出口 → 管理集群上的 Edge → 回到原主机 → DB 虚拟机所在主机。App 和 DB 明明在同一台 ESXi 上流量却要绕到管理集群再回来这就是典型的发卡hairpin流量。创建分布式路由器DLR后把 App 和 DB 的接口从 Edge 迁移到分布式路由器上。关键在于 DLR 的每一个接口配置会自动推送到集群内所有 ESXi 主机的内核模块中路由决策不再经过外部设备。在 ESXi 上查看分布式路由模块状态是常见做法/opt/vmware/nsx-cli/bin/nsxcli -c get logical-router该命令列出本机分布式路由器的接口和邻居信息能看到 App 子网与 DB 子网的路由表项即为正常。验证优化效果时在 App 虚拟机上对 DB 虚拟机执行 traceroute路径应只包含宿主主机内部一跳不再出现 Edge 的 IP 地址。如果 traceroute 仍然经过 Edge IP说明虚拟机 vNIC 没接到 DLR 的逻辑接口上或者 DLR 接口在 vCenter 中未正确关联到该主机。实践提醒DLR 只处理东西向流量南北向流量仍由 Edge 承担。把 Edge 接口移除之前务必确认 DLR 的网关地址规划已经完成否则 IPv4 网关地址或下一跳变化会导致虚拟机短暂断流。3.3 OSPF 动态路由通告与邻居排错逻辑路由只解决逻辑网络内部互通。要让物理核心交换机感知到这些逻辑网段需要动态路由协议参与。原报告在分布式路由器和 Edge 之间启用了 OSPF 动态路由验证命令如下ssh adminedge-ip show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 10.0.10.2 1 Full/Backup 00:00:36 10.0.10.2 uplink-1 show ip route OSPF 192.168.100.0/24 [110/2] via 10.0.10.2, uplink-1OSPF 配置有三个关键点。第一Edge 与分布式路由器之间连接的接口网段必须宣告进 OSPF 进程否则邻居关系建立不起来。第二外部物理路由器的 network 语句必须覆盖连接网段同时注意区域 ID 一致性示例中全部在 Area 0 内。第三验证通告是否成功不要只看邻居状态要切换至show ip route观察 OSPF 前綴是否出现在 Edge 路由表中。如果邻居状态卡在 EXSTART 或 EXCHANGE最常见的诱因是 MTU 不一致。分布式路由器和 Edge 连接的逻辑交换机 MTU 是 1500物理交换机三层接口也应为 1500把某一边改成 9000 会导致 OSPF DD 报文过大而无法建立完整邻居。这类问题在 POC 验证中容易被忽视但却是后续上线排障的高频点。4. 分布式防火墙从默认规则到基于 AD 身份的安全组策略4.1 修改防火墙默认规则分布式防火墙默认规则在新建逻辑交换机后是全部允许放行。POC 第一步先修改默认规则为丢弃再逐步增加显式允许规则。与物理防火墙最大的区别在于执行位置——分布式防火墙的每条规则都作用在虚拟机 vNIC 的数据路径上规则检查发生在虚拟机发送报文的瞬间即使两台虚拟机在同一台 ESXi 主机的同一个 dvSwitch 上流量同样会被过滤。在 vCenter 的 NSX 管理界面修改默认规则后可以用 API 核对规则是否下发curl -k -u admin:admin -H Content-Type: application/xml \ https://nsx-manager/api/4.0/firewall/globalroot-0/config返回的 XML 中包含规则列表、动作以及最后修订时间戳。把修改时间与 vCenter 操作时间对比可以确认本次变更已经同步到所有传输节点。注意修改默认规则前至少保留一条允许管理网络的规则否则 NSX Manager 与 ESXi 主机之间的通信会被拦断后续排错会变得很被动。4.2 基于安全组的防火墙规则安全组的价值在于把动态成员关系与规则解耦。典型的三层应用规则设计如下规则名源目标服务动作Web-Allow-App安全组 Web安全组 AppTCP 8080允许App-Allow-DB安全组 App安全组 DBTCP 3306允许Web-Deny-Other安全组 Web任意任意丢弃创建安全组时成员来源建议选择“虚拟机名称前缀”或“安全标签”而不是手工添加固定 IP。原报告把安全组规则作为基本功能验证的核心原因在于 POC 客户后续生产环境里虚拟机会频繁迁移基于 IP 地址的策略维护成本极高而安全组可以通过动态匹配随虚拟机迁移自动生效。验证时对 Web 虚拟机发起对 App 8080 端口的访问能通发起对 Web 虚拟机 SSH22 端口的访问被丢弃。两个结果同时成立说明规则已生效。还有一种容易误判的情况规则动作正确但目标虚拟机自身操作系统防火墙拦截了流量导致验证失败。测试前先确认虚拟机内部防火墙没有叠加影响。4.3 基于 AD 身份的用户组规则基于身份的防火墙规则是将 Active Directory 用户组作为规则源或目标比安全组更细粒度。前提条件是 vCenter 和 NSX Manager 已经加入域且 NSX 服务账号具备读取 AD 组信息的权限。配置完成后在防火墙规则中源选择 Active Directory 用户组即可。验证时用该域组内的账户登录虚拟机发起访问规则会依据 vSphere 收集到的登录用户信息来判定是否匹配。若域内账户被丢弃而其他来源放行说明身份规则生效。这部分的坑点在于身份识别依赖 VMware Tools 的登录信息同步。如果虚拟机内 Tools 未运行或登录的是本地账户而非域账户身份字段会为空规则容易发生误判。POC 验证时至少登录一个域用户等待 30 秒让 Tools 心跳同步完成后再测试不要登录后立刻发起访问。4.4 Edge 防火墙与分布式防火墙的统一管理原报告所谓“两种防火墙的统一管理”是指在同一个 UI 中同时管理 Edge 服务网关防火墙和分布式防火墙规则。两者定位不同Edge 防火墙过滤南北向流量规则链可以覆盖 NAT、负载均衡等服务分布式防火墙做基于五元组的东西向过滤规则执行在每台 ESXi 主机内核中。统一管理的实际收益是两个组件可以复用同一套安全组对象避免在 Edge 和主机上维护两套安全对象定义。部署策略上建议把面向虚拟机默认防护的规则放分布式防火墙把对外端口映射和 NAT 相关的规则放 Edge 防火墙规则数量较多的场景优先拆分安全组避免人工审查长规则列表时发生顺序误判。5. 可用性与高级功能控制器集群、Edge HA、ECMP 与 VXLAN 桥接5.1 控制器集群的可用性验证NSX 6.1.2 中三个控制器组成集群一台故障后其余节点接管控制面职责。原报告的验证方式是直接关闭一台控制器虚拟机观察逻辑交换和路由功能是否持续正常。控制器集群状态检查ssh admincontroller-1 show control-cluster status三个控制器节点应显示 ACTIVE且 API、管理、控制器三种角色分布均衡。关闭一台后日志会出现 Leader 切换记录但既有的 VXLAN 隧道不受影响。这是面试级概念控制器不在数据面转发路径上它只处理 VTEP 信息同步、ARP 泛洪复制、分布式路由配置下发等控制报文。因此“关掉一台控制器业务断不断”不是控制器高可用的真正指标指标是新增逻辑交换机、新增主机等控制面操作是否仍然正常。5.2 Edge 服务网关的高可用性Edge HA 的验证重点在主备切换收敛时间。配置 Edge 时勾选 HA 选项系统会创建一个备用 Edge常态下不对流量生效主 Edge 故障时由备用 Edge 接管 IP 地址和路由表。ssh adminedge-ip show service ha HA Status: MASTER模拟故障的推荐动作是直接关停主 Edge 虚拟机因为生产环境最常见的就是主机宕机或 Edge 进程崩溃而优雅关停反而无法体现故障场景。观察备用 Edge 的状态从 BACKUP 变为 MASTER同时持续从外部 ping 业务虚拟机的浮动 IP记录切换期间的丢包数。如果业务 IP 的 MAC 地址没有回切到物理网络设备说明虚拟 MAC 保持有效符合预期。提示Edge HA 主备必须位于不同的物理主机否则物理主机故障时主备同时失效。POC 环境如果只有三台物理服务器一定要把两个 Edge 分别规划在计算集群和边缘集群的不同主机上。5.3 等价多路径ECMP提供的高可用ECMP 让多个 Edge 实例同时承载南北向流量相比 HA 的一主一备它的可用性更高。原报告通过多个 Edge 连接同一个上行链路验证流量被散列到多条路径。配置 ECMP 的步骤包括创建多个 Edge 实例并接入同一逻辑交换机在 Edge 和分布式路由器上启用等价多路径协议再让物理核心交换机同时学习到多条等价路由。验证用 iperf 产生持续流量更直观iperf -c 192.168.250.100 -P 4 -t 30-P 4开启四条并发连接观察各 Edge 的流量速率是否均匀分布。关停其中一个 Edge活跃连接会短暂中断后在新连接中恢复新建连接立即投递到剩余 Edge说明 ECMP 路径自动收敛。ECMP 的价值不在单条连接的负载均衡而在链路的冗余和带宽聚合。单条 TCP 连接只会哈希到一条物理路径因此验证时必须开多并发否则看到一个 Edge 流量很高另一个空闲就误判为负载不均衡。5.4 逻辑负载均衡验证逻辑负载均衡在 Edge 服务网关上配置向导包含三件事定义虚拟服务器VIP、定义服务池、定义健康检查。配置项推荐值说明VIP 地址192.168.10.100与虚拟机服务同逻辑网段或 NAT 后外部网段池成员web-sv-03a, web-sv-04a按业务角色分组健康检查TCP 80间隔 5 秒失败后自动摘除成员验证负载均衡是否生效从外部反复访问 VIPcurl http://192.168.10.100/连续请求多次并观察后端虚拟机访问日志请求分布在两台后端说明轮询算法生效。如果请求始终落在同一台后端重点检查池成员权重设置和健康检查结果。常见问题是后端虚拟机的系统防火墙拦截了来自 Edge 网关 IP 的健康检查报文导致后端被判离线全部流量被导向剩余成员。5.5 VXLAN 与 VLAN 的桥接机制VXLAN 与 VLAN 之间的桥接用于逻辑网络和现有物理服务器共存的过渡场景。在 Edge 上创建桥接接口一边连接逻辑交换机另一边连接物理 VLANEdge 在两层之间执行二层转发。ssh adminedge-ip show bridge Bridge Domain: VXLAN-1000 - VLAN-100桥接功能适合小流量过渡不适合大规模生产流量。原因是所有桥接流量都要经过 Edge 虚拟机的数据路径单台 Edge 的吞吐上限就是瓶颈。原报告把这项功能放在高级验证里目的是证明 NSX 能兼容现有物理网络而不是鼓励长期依赖桥接。真正合理的演进路径是逐步把物理服务器迁移进逻辑交换机最终拆掉桥接。6. 验证 NSX 数据面转发的三个实用技巧6.1 确认 VTEP 二层互通逻辑交换机建好后跨主机 ping 不通先用最简单的方法排除物理问题esxcli network vxlan vtep list vmkping -I vmk1 192.168.250.2vmkping -I vmk1指定从 vmk1 这个 VMkernel 接口发起 ICMP 请求目标是另一台主机的 VTEP 地址。如果 ping 不通检查 vmk 所在 VLAN 和物理交换机端口是否为 trunk 模式并允许了对应 VLAN。VXLAN 端口 4789 通常不需要物理设备额外放行但部分网络 ACL 会拦截非知名 UDP 端口这是最容易遗漏的点。6.2 抓一个 VXLAN 封装包确认隧道身份数据面异常时抓包是最快的定位手段。ESXi 上抓取虚拟机的 dvPort 流量pktcap-uw --port dvport-id -c 50 -o /tmp/vxlan.pcap--port指定虚拟机的分布式端口 ID-c 50限定抓取报文数量。抓到包后重点观察外层 IP 的源目地址是否为主机 VTEP内层 MAC 是否为虚拟机网卡地址。外层地址正确、内层地址混乱通常是逻辑交换机在传输区域中的 VNI 分配错误完全抓不到包问题应定位在虚拟机 vNIC 到 dvPort 的路径而不是 VXLAN 本身。把 pcap 拉到本地用 Wireshark 的 VXLAN 解码器可以直接看到内层协议头和原始以太网帧比在 ESXi 上做十六进制分析效率高得多。6.3 观察分布式防火墙的规则命中序列修改规则后不生效常见原因是安全组没有正确匹配到目标虚拟机。分布式防火墙的规则执行顺序按从上到下的优先级排列一条规则不匹配时继续向下匹配这与物理防火墙“首条匹配即停止”的行为不同安全组规则之间可以叠加。因此在 vCenter 防火墙界面勾选会话日志记录发起测试流量后回查日志日志中标明的规则序号可以精确对应到具体规则条目由此判断流量是被“允许”还是被“丢弃”及在哪一条规则处被处理。排错时按这个顺序走一遍大部分“声称不通”的逻辑交换机问题都能定位到具体环节比反复重启服务有效率得多。本文还有配套的精品资源点击获取