🎮 👧🏾 🙆🏽 NSX-V中的VXLAN-故障排除 😞 👩🏿‍🤝‍👨🏼 🕠

问候，首先是一点歌词。我有时会羡慕远程工作的同事-能够在互联网上的任何地方工作，随时假期，对项目和截止日期负责，而且不在办公室工作8到17，这真是太好了。我的职位和工作职责实际上不包括在内数据中心长期缺席的可能性。但是，类似以下所述的有趣情况偶尔会发生，并且我了解很少有这样的位置可以创造性地表达内部疑难解答的范围。

一个小的免责声明-在撰写本文时，此案尚未完全解决，但是鉴于供应商的响应速度，完整的解决方案可能还需要几个月的时间，我现在想分享一下我的发现。亲爱的读者，我希望您能原谅我这个仓促。但是足够的水-情况如何？

首先介绍：有一家公司（我在其中担任网络工程师）在VMWare的私有云中托管客户端解决方案。大多数新解决方案都连接到由NSX-V控制的VXLAN网段-简而言之，我不会评估该解决方案给了我多少时间。我什至设法培训了同事配置NSX ESG，并且在没有我参与的情况下部署了小型客户端解决方案。重要说明是具有单播复制的控制平面。系统管理程序通过两个接口冗余连接到不同的物理Juniper QFX5100交换机（组装在Virtual Chassis中），并且基于原始虚拟端口的时序策略路由是完整的。

客户端解决方案非常多样化：从Windows IIS（所有Web服务器组件都安装在一台计算机上）到相当大的组件-例如，负载平衡的Apache Web Fronts + Galera中的LB MariaDB +使用GlusterFS同步的服务器气球。几乎每个服务器都需要单独监视，并且并非所有组件都具有公用地址-如果您遇到此问题并拥有更优雅的解决方案，我将很乐意为您提供建议。
我的监视解决方案包括将防火墙（Fortigate）“连接”到每个内部客户端网络（+ SNAT，当然，还对允许的流量类型进行严格限制）并监视内部地址-这样，可以实现监视的某种统一和简化。监视本身来自PRTG服务器群集。监视方案如下所示：

虽然我们仅使用VLAN进行操作，但一切都很正常，并且可以像时钟一样正常地工作。实施后，NSX-V和VXLAN面临一个问题-是否可以继续使用旧方法进行监视？提出此问题时，最快的解决方案是部署NSX ESG并将VXLAN中继接口连接到VTEP网络。引号快速-由于使用GUI配置客户端网络，因此SNAT和防火墙规则可以在单个vSphere界面中统一管理，但我认为这相当麻烦，并且除其他外，限制了故障排除工具集。我认为，那些使用NSX ESG替代“真实”防火墙的人会同意。尽管这样的解决方案可能会更稳定-毕竟，所有事情都在一个供应商的框架内进行。

另一个解决方案是在VLAN和VXLAN之间以桥接模式使用NSX DLR。在这里，我认为一切都很清楚-使用VXLAN的好处是老旧的-因为在这种情况下，您仍然必须将VLAN拉到监视安装中。顺便说一句，在制定此解决方案的过程中，当DLR桥未将数据包发送到与之位于同一主机上的虚拟机时，我遇到了一个问题。我知道，我知道-在有关NSX-V的书籍和指南中，明确指出应该为NSX Edge分配一个单独的群集，但这在书籍中……无论如何，在几个月的支持下，我们未能解决问题。原则上，我理解该操作的逻辑-如果DLR和受监视的服务器位于同一主机上，则负责VXLAN封装的虚拟机管理程序核心模块不会被激活，因为流量不会离开主机，并且从逻辑上讲，它应该连接到VXLAN网段-不需要封装。在支持下，我们选择了虚拟接口vdrPort，该接口逻辑上组合了上行链路，并且还执行桥接/封装-注意到传入流量不匹配，我在当前情况下对此进行了研究。但是，正如我所说的，我并没有结束这个案例，因为它已经转移到另一个项目，并且分支最初是死胡同，并且没有开发它的特别愿望。如果我没记错的话，该问题在NSX版本以及6.1.4和6.2中已经观察到。因为它已经转移到另一个项目，并且分支最初是死胡同，所以没有开发它的特别愿望。如果我没记错的话，该问题在NSX版本以及6.1.4和6.2中已经观察到。由于已将其转移到另一个项目，并且分支最初处于死胡同，因此没有开发它的特别愿望。如果我没记错的话，该问题在NSX版本以及6.1.4和6.2中已经观察到。

在这里-宾果游戏！ Fortinet annonsiruet本机支持VXLAN。不仅是点对点或IPSec上的VXLAN，也不是基于软件的VLAN-VXLAN桥接-他们从5.4版开始就实现了所有这些功能（并由其他供应商提供）），但真正支持单播控制平面。在实施该解决方案时，我遇到了另一个问题-受检查的服务器会定期“消失”，有时甚至出现在监视中，尽管虚拟机本身仍在运行。原来的原因是我忘记在VXLAN接口上启用Ping。在重新平衡群集的过程中，虚拟机已移动，vMotion以Ping结尾，以指示该计算机移至的新ESXI主机。我的愚蠢，但这个问题再次破坏了支持的可信度-在这种情况下是Fortinet。我并不是说与VXLAN有关的每种情况都以“您的设置中VLAN-VXLAN软交换在哪里？”开头。建议这次更改MTU-这是针对Ping的，它是32个字节。然后在策略中使用tcp-send-mss和tcp-receive-mss来“玩转”-对于VXLAN，封装在UDP中。 Fuf，很抱歉-沸腾了。总的来说，我自己解决了这个问题。

成功回滚测试流量后，决定实施此解决方案。在生产中，事实证明，在一两天后，通过VXLAN监视的所有内容都逐渐消失了。停用/激活界面有所帮助，但这只是暂时的。考虑到支持速度的下降，我开始对自己的部分进行故障排除-最终，我的公司，我的网络是我的责任。

扰流板下方是故障排除过程。谁讨厌信件和吹牛-跳过并进行后期分析。

故障排除

, — !

, , . . , Fortigate 5.6+, «diagnose debug flow» — . . , , RFC1918, . VXLAN ...15, ...254, VTEP.

VXLAN- . overlay ARP OVSDB, underlay ARP CAM. Fortigate VXLAN FDB OVSDB. :

 fortigate (root) #diag sys vxlan fdb list vxlan-LS
mac=00:50:56:8f:3f:5a state=0x0002 flags=0x00 remote_ip=...47 port=4789 vni=5008 ifindex=7

— MAC VTEP ...47. ESXI , , MAC , VTEP . CAM/ARP — ESXI :

fortigate (root) #get sys arp | grep ...47
...47 0 00:50:56:65:f6:2c dmz

— ? Juniper' — , — VLAN VTEP . DLR-, VDR — ESXI , VMWare. MAC «97:6e» , vmnic1 — , VTEP ...47 "--dir 2":

pktcap-uw --uplink vmnic1 --vni 5008  --mac 90:6c:ac:a9:97:6e --dir 2 -o /tmp/monitor.pcap

— ARP . ARP . , ...15 — ICMP ? , . , ( teaming policy), vNIC , , :

pktcap-uw --uplink vmnic4 --vni 5008  --mac 90:6c:ac:a9:97:6e --dir 2 -o /tmp/monitor.pcap

, . . — — VDR, . , , , . «» Ethernet underlay. - MAC VTEP IP. , , — , . ARP , . Ethernet :

fortigate (root) #get sys arp | grep ...47
...47 0 00:50:56:65:f6:2c dmz
fortigate (root) #get sys arp | grep ...42
...42 0 00:50:56:6a:78:86 dmz

因此，最终我们将拥有什么-迁移虚拟机之后，fortig尝试从（正确的）VXLAN FDB向VTEP发送流量，但是使用了错误的DST MAC，并且流量预计会被接收的管理程序接口丢弃。此外，在四分之一的情况下，此MAC属于原始虚拟机监控程序，从此虚拟机开始了迁移。

昨天我收到了Fortinet技术支持的来信-就我而言，它们打开了错误615586。我不知道如何欢喜或忧虑：一方面，问题不在设置中，另一方面，此修复仅与固件更新一起进行，在最好的情况下，是以下情况。该常见问题解答还激起了我上个月发现的另一个错误，尽管当时是在HTML5 GUI vSphere中。好吧，供应商的当地质量检查部门是直接的...

我敢建议以下几点：

1-组播控制平面很可能不会受到所描述问题的影响-毕竟，VTEP MAC地址是从该接口所预订的组的IP地址中获得的。

2-最有可能是网络处理器上的卸载会话中的前言问题（大约类似于CEF）-如果每个数据包都通过CPU，则将使用包含正确信息（至少在视觉上）的表。支持此假设的是有助于关闭/打开界面或等待一段时间（超过5分钟）的原因。

3-例如，将分组策略更改为显式故障转移，或引入LAG并不能解决问题，因为观察到MAC卡在封装数据包中的原始管理程序上。

有鉴于此，我可以分享最近发现的博客在其中一篇文章中指出，stetfull防火墙和缓存的数据传输方法是拐杖。好吧，我对IT的了解还不那么丰富，我并不立即同意博客文章的所有声明。但是，有一些事情告诉我，伊万的话中有些道理。

感谢您的关注！我将很高兴回答问题并听到建设性的批评。

NSX-V中的VXLAN-故障排除

More articles: