恩佐注册恩佐娱乐恩佐平台【联盟认证】这是一个很有意思的排障经历，是一个触发条件非常复杂的 rare case，其坑人程度，不亚于当年我删了一个 VLAN 后交换机随机挑了另一个 VLAN 给我干了的 Bug...只不过当年C 记还能承认那可能是个 Bug，现在到了 ACI 里，那都不是 Bug了。那是 Feature，别问，亲爱的，问就是这么设计的。
上一次令人头秃的排障还是上一次：蓝莓的铲屎官：[Switch] 比中还难的交换机转控不一致故障
最近几天打开知乎，频繁的在网工相关话题下刷到一些辣眼睛的言论，什么网工同工不同酬啊，什么钱即正义啊，什么会英语就秒杀国内百分之九十的竞争对手所以竞争不激烈（不是，国外网工死绝了是吧？好岗位人家眼瞎看不到是吧？）...等等。看的我真的是浑身汗毛倒竖，我难以想象信了这些鬼话的人接下来的生活会是什么样子。
同工不同酬，这事儿需要加个前置条件“网工”吗？泥瓦工甚至宽带叔叔那也是国外挣得比较多啊，这种比较有什么意义呢？钱即正义的话，那么如果你侥幸得到了一份高收入工作轻松的岗位，你又如何百分之百的保证自己能守住它呢？这些“选择过的事实”，单拿出来没有一句话是错的，但是有意义吗？
总之，这些信息过于辣眼睛，所以吓得我赶紧打开文章，来写一篇硬核的排错记录给大家洗洗眼睛。
有一天，K8s组上报了这么一个事情：他们观察到每天GMT 0 点一过，就会有一些 POD连接 NFS 的时候 timeout，时间一长，POD 健康检查失败，POD 就会被 kill。K8s 组接到这个问题是因为应用监控在故障的时候监测到了大量的应用失败，只是那个时间点刚好是过了业务高峰没多久的时候，所以没有造成严重的业务问题。
因为问题发生的时间太过诡异，总是在 GMT 0 点之后，于是就不由得就会让人怀疑这是不是和某些定时任务有关（最后的结果确实跟一个定时的 information 有关，但是，要查到它，我们走了很远的路）
Compute组，Storage 组以及 K8s 组凑在一起查了很久，然后给我反馈了这么一个结论（锅甩了过来）：
在这组交换机下还有三组 UCS-FI，也就是 Cisco 为 UCS 服务器量身定制的“机头”，问题在所有UCS-FI下的计算节点上都有发生，因此可以基本排除 UCS-FI 有问题的可能性（总不能三组 FI 同时坏了吧）；
K8s 组和 Stroage 组一起做过抓包，在出现故障的时候，表现为 K8s Node 发出的包，Stroage 完全没收到，于是连接超时（但是在 K8s Node 和NFS 存储之间不只有交换机，还有 Hypervisor 的主机网络，还有 UCS-FI）。
这个锅的指向性非常明显了，指向一组交换机，但在我介入排障后，我发现了更奇怪的事情：
这看起来怎么都不像是个网络交换机的问题，交换机怎么会在特定时间丢特定目标 IP 的数据包几分钟，然后再自动恢复呢？这太不合理了。但是另一方面，又确实是只有一组交换机存在该问题，于是我必须要自证清白（当然既然有这篇文章的存在，结果自然是自证了自己不清白了...）
在这组交换机上下只有 19 台 K8s Node，其他服务器并不是 K8s 组的，并且只有 K8s 组在报告这个问题（这让这件事看起来更加扑朔迷离了）
在 K8s Node 上，我从历史的 Kernel log 里发现，NFS timeout 也不只是发生在 GMT 0 点之后，准确的说是，GMT 0 点之后一定会发生，但不代表其他时间没有问题（这又让交换机可疑的可能性上升了几分）。
由于现象过于诡异，以我的经验来说，我还真的是没见过交换机在特定时间丢弃特定目标 IP 的数据包几分钟，然后再自动恢复这种事情，我们组的美国的技术 leader 也觉得这个不太合理，他们一致怀疑是不是 K8s 组搞砸了什么事情。
但是甩锅无助于问题的解决，所以我就写了一个脚本，run 在了分布在三组UCS-FI 下面，非 K8s 组持有的计算节点上。这个脚本很简单，每隔一分钟，尝试打开所有 8 个 NFS IP 的 socket 端口。我的逻辑很简单，如果这是一个网络交换机的问题，则我理应在其他主机上重现该问题。
每天 GMT 0 点过了之后的那一个小时里，不定期的就会有一个 NFS IP 无法连接，在我测试期间，总是同一个 NFS IP 出问题，并且每次都是持续 4 分钟左右，偶尔在 GMT 1 点之后也会有一些连接失败的 Case，但也存在安静日，即完全没问题的日子。
如上图所示，SW10A/B 就是出问题的交换机，SW20A/B 则是作为对照组，没有问题的交换机，K8s 组告诉我只要 Node 挪到 SW20A/B，故障就会消失。SW30A/B 则是连接NFS 存储的交换机。
我用和 K8s Node 无关的 Test VM 复现了同样的故障（且在同一时间，K8s 的监控日志也监控到了故障）。现象依然很奇怪，但我成功排除了客户的嫌疑（K8s 组放心了）。
其实从看到这个测试结果开始，我已经可以基本断定，交换机确实出了的问题。虽然也有可能是交换机发出了包但是存储入口丢了的可能性...这个可能性其实更小。
由于测试已经覆盖了三组 UCS-FI，覆盖了不同的计算节点，所以只能把目光投向交换机了。我们同时开了 TAC Case，但TAC 表示这种情况只能抓包。所幸，运行于 ACI 模式下的交换机支持有强力的 ERSPAN能力。
通过配置 ERSPAN 同时抓取“可疑”的那一组交换机，和连接 Storage 的出换机，结果如下图所示：
这是我最不想看到的结果，对 Fabric 抓包会比较痛苦，因为有 6 台 Spine，在 ingress 和 egress 交换机之间有 24 条链路。所以，我把皮球踢回给了 TAC。
结果，TAC 也是踢球大师。此前分析日志信誓旦旦的说，没有发现问题，结果这次却告诉我，针对出现问题的目标 IP（这里假设为10.0.100.100），他们发现了这个 IP 漂移的日志（在 ACI 中，应该称为是 Endpoint Moving）。日志显示这个 IP飘到了另一组交换机（假设为 SW40A/B好了）去了。
更加奇怪的是，这个 IP/Endpoint（考虑到并不是所有读者都了解 ACI 中的概念，这里我统一使用两种语言来描述故障现象），不仅仅是飘了个位置这么简单，它连所对应的VLAN/EPG都发生了改变。
这次 TAC 谨慎多了，他没有下结论，而是只是说他怀疑从SW40A/B，有使用这个 IP 作为源IP 地址的数据包发出来了。我第一时间，自然是不信这个结论的，基于我对交换机软件可靠性的极度不信任，我怀疑是个 Bug。但后来证明，TAC 比我更加了解 ACI 的 feature，对，是个 feature。
我怀疑是个 Bug 的理由也很健壮：它对应的那个 VLAN/EPG 根本连 Subnet 都对不上，如果是在传统网络里，根本就不会引起漂移（后来证明，还真不能用传统网络的思路去思考 ACI，ACI 是有 feature 的。）
而且那组交换机是连接负载均衡器（关键点）的，我特意问了 Storage 组的同学，对方答他们是用不到负载均衡器的。
已经掌握了 ERSPAN 玩法的我，稍改了下配置，在另一组交换机的入口（SW40A/B）进行了抓包。
抓包前我还给老板立了个 Flag，我在想我怎么会抓到什么奇怪的包呢，不会的，存储的 IP 地址怎么会飘到负载均衡器去呢。
就在测试脚本报错的同时，这些数据包就在 Wireshark 上冒了出来（此前则一直没有捕获到任何数据包），说明它们之间存在强相关性。
我立刻就把 Stroage 组的兄弟 call 了上来，经过检查，目标 IP 是一个接收 SNMP 消息的服务器，它是我们的业务监控系统之一，这个服务器是依赖负载均衡器提供高可用性的，也就是说，SNMP 的目标 IP 是一个 VIP。与此同时，这个监控服务器还需要看到发送 SNMP 消息的真实源 IP，所以负载均衡器不能够通过 SNAT 的方式修改源 IP，而必须保留真实 IP 地址。
正如 TAC 所猜测的，真的有带有存储 IP 的数据包从负载均衡器那边发出来了。
但吊诡的是，这样的流量在普通的网络中并不会引发什么问题，但在 ACI 中它却导致了 IP/Endpoint 的漂移，甚至连对应的 VLAN/EPG 都改变了，而且，又为什么只有 SW10A/B 会有问题，而 SW20A/B 就没有问题呢？
ACI 里的每个主机都表示为了 Endpoint 这样一个逻辑对象，在 C记的白皮书中，对于 Endpoint 的定义如下：
看起来很合理对不对？但是，你要继续往下读，就会发现一些不和谐的地方：ACI 的 Endpoint Learning 分为 Local Endpoint Learning 和 Remote Endpoint Learning 两个机制，默认情况下，都是基于数据包里的源 IP/MAC 字段学习的。但是，它有一个吊诡的地方是，对于Local Endpoint，也就是直连在当前交换机下的主机，它才会同时学习 IP 和 MAC 的组合，对于 Remote Endpoint，也就是在其他远端交换机下的主机，它则只学习 IP 或者只学习 MAC！
所以对于三层转发，在入站交换机上，直接就会查对应 IP 的 Remote Endpoint 的学习结果。你可能会在这里陷入迷糊，传统网络不也是查目标 IP 的 FIB 么？但是我亲爱的读者，传统网络不会基于数据流量学习 IP 地址呀！
ACI 和传统网络区分的一个重大不同是对于主机的学习，我们知道交换机构建 MAC 地址表是根据入站数据帧的源 MAC 学习构建的，但是构建 IP 到 MAC 的映射就不是了，构建 IP-MAC 的映射需要依赖 ARP。简而言之，无错误的 ARP 则无错误的 ARP 表项。但是 ACI基于数据流从硬件中学习源 IP 这件事，让我极度怀疑，设计者是不是从来没用过负载均衡器？
当负载均衡器不修改源 IP 的时候，ACI 的行为就导致了 Remote Endpoint 中目标 IP 的学习错误。这也是为什么只有 SW10A/B 会有问题，因为经过SNMP VIP 转发后的目标就是 SW10A/B，所以只有 SW10A/B 的 Remote Endpoint会学错，但是这组交换机下又存在其他计算节点需要访问同样的存储 IP，于是就产生了故障。
NFS存储在一个特定的时间发送了 SNMP 数据包到 SNMP Server 的 VIP 上，这个 VIP托管在负载均衡器上。这个流量被转发到 SW10A/B 上，引起了 SW10A/B 上的 Remote Endpoint 的学习错误，进而导致了该交换机下其他主机访问这个特定的 NFS IP 的数据包送到了错误的交换机上而被丢弃。
首先被 Challenge 的是存储组，他们被问到的是为啥SNMP 这样一个明显是管理流量的东西和业务流量混在了一起。但我替存储组喊了个冤，因为在我看来，做不做 OOB 是人家的事，毕竟人不做 OOB，这样的流量在传统网络中也不会引起问题（因为传统网络并不会基于数据流量来学习 IP 在哪这件事，它始终是基于 ARP 的）。
其次为什么我曾经看到过其他时间点也有故障？这个特定时间点的 SNMP 流量到底是啥？
不过，这点没有深入去讨论，调查这个诡异的 Case 耗尽了大家的精力。我只能做一些猜测。
首先存储在固定时间发出的 SNMP 是 informRequest类型的消息，这类消息不会在 payload 中携带 agent的 IP 地址，可能就是为了兼容这类消息，SNMP Server 才要求 LB 必须要开启保留源 IP 的功能。这个 informRequest 看起来是存储上的某个管理性功能在特定的时间发出某种通知用的。
SNMP的另一种常见的通知就是 SNMP trap，不过，trap 消息是会在payload 中携带 agent 的 IP 地址的，因此 trap 消息可以支持 NAT。那些在其他时间点发生的故障，大概率是一些警报触发了 SNMP trap，因为 trap 的数量少，时间短，所以没有引起严重的问题。
所以，确实是某种定时任务，只不过是基于 SNMP informRequest 的定时任务。
至于那些无问题的安静日，大概是因为某些原因存储的 SNMP消息没发吧...由于完全不清楚存储发送 SNMP 消息的条件，存储组的兄弟也精疲力尽不想再查（查半天又查回到自己头上是挺绝望的）。
站在 ACI 的层面来说，一个在 5.2 版本新加入的 feature 可以解决这个问题：Disable IP Dataplane Learning。说白了就是 IP 的学习回退到 ARP 去了，基于数据流的学习针对某个 Scope，比如Bridge Domain 这个 level 给它关了。全网关掉也不现实，鬼晓得会不会发生什么别的事情，但是针对负载均衡器的网段特定的去关闭，倒是可以考虑。
因为这件事的触发条件复杂，读者们看上面的故障流量图也能看出来。所以最终，我们只是在存储端不再向 VIP 发送 SNMP 通知，而改为直接向 Backend Server 发送通知来暂时避免这个问题。因为也只有存储刚好使用自己提供 NFS 服务的 IP 发了 SNMP 通知才引起了问题，为一个小 Case 去大面积的改动底层网络配置，风险和收益不匹配。
如果你对比 VXLAN EVPN，会发现ACI 的不和谐之处在于，VXLAN 的主机路由表永远是带着 IP+MAC+VN 信息的（实际上还会有一份纯 MAC 路由用于支撑和模拟 Layer2 的网络转发），所以EVPN 中的主机路由是非常胖的。而 ACI 却要区分 Local 和 Remote，Remote 还要割开 IP 和 MAC，显而易见的是，ACI 这么做确实更省资源。
C记在 ACI 的白皮书中反复强调节省 TCAM 相关的信息，这引起了我的注意。为什么 ACI 要节省 TCAM，什么东西在消耗 TCAM？为什么 EVPN 可以放心大胆的存那么胖的信息？
因为 ACI 有 Contract，因为 ACI 在设计之初想把防火墙的事儿干了。
在一次与我的老师的午间闲谈中，我们曾经吐槽过这个事情，防火墙这事儿，你交换机不专业，你就不应该做。硬件资源是有限的，你要做 Contract，势必就要压缩正常的路由交换所消耗的资源。 ACI用着最好的硬件还要抠抠搜搜的节省，背后的原因其实就是 Contract 的编程会消耗大量的 TCAM，所以路由交换这边能省一点是一点。
