一个周末

对于一个创业狗来说，一个普通的周末本身就是很不普通的事情。

周四 QA 报了一个大概算是能直接毁掉我前两周工作成果的 Bug，现象是虚拟机“随机”的会产生网络不通的情况，神奇的是这种现象带有一种“污染”的特质，也就是如果一个宿主机之前好好的，一旦其上有一台虚拟机网络不通，那么之后在这个宿主机上创建的所有虚拟机都会将不通——宿主机被污染了，哪怕重启也无济于事。

更麻烦的是这个事情在手动测试时没有出现过，只有自动化测试会发生。

晚上找到一个上游厂商记录的一个内核 Bug，怀疑是这个 Bug 引起的——老板蛮紧张的，我？

我当晚居然还有心情更新博客。

..

第二天也就是周五中午老板把几个在新版本上要发布新功能的同志召集在一起开了个会，对我手上这个 Bug 表现的很重视，直接问我如果 Bug 搞不定或者确认是上游的不好解决的 Bug，Plan B 是什么？

我挺懵的，这也就开始分析了一天多，这就要研究 Plan B 了吗？

考虑到新版本的发布时间，真实答案其实是没有 Plan B。

带着这么大的 Bug 发布显然是不负责任，即使安慰自己手动测试没跑出来那也是在赌运气。

换开发方向的话哪怕我赶工两个星期也不一定能搞定——考虑到质量，新驱动带了的一系列适配工作和安装设置等等。

..

会上老板当然还是设置了一个 Plan B，但是我心里非常非常不希望 B 的发生的，午饭后没有休息继续开始投入 research。

反复测试后发现，这个被污染后的宿主机的配置如果由我自己手配的话，是可以工作的，但要是代码下发的话，就毁了。

难道是控制端的问题？

反复比对后终于在 FDB 表——这是一个正常开发者都不想去看的表，在交换机中这个表叫做 CAM，对于模块化交换机，一张线卡可能会有 128k 个条目，如果插了 6 张线卡就是 76.8w 个条目，条目内容只有 MAC 地址、IP 地址、网口一些基础信息。

测试中的虚拟交换机当然没这么大规模，但是鉴于原始信息之简陋和 Linux 中 VXLAN Interface 的行为之古怪，原本我也是不想去看这个的。

但奈何最终就是在这里发现了问题。

其实之前看内核日志就有提示收到来自自己发送的报文，就应当引起注意，但当时以为这是内核 Bug 的现象，而为触因，而且在网上搜不到有用的信息，就放过去了。

最后发现这个日志其实就是答案了。

VXLAN 网络配置时需要知道对端（VTEP）都有些谁，这些对端通、不通、丢包都没有问题——谁叫 VXLAN 基于不可靠的 UDP 协议。

但如果这个对端设置为自己就不好了，系统会直接懵逼掉，自挂东南枝，并打一条日志。

而且此时不仅 VXLAN 会有问题，本地的二层传输也挂掉了——这就是这个 Bug 的神奇与不合理之处。

..

作为一名爱笑青年的我运气自然不会差，周五下午就基本锁定了问题所在并修复掉了，其实我在代码里放了两张网避免这种情况——虽然我不知道这个 Bug，但小心谨慎又不是错，可自动化测试时将这两层网全部打碎突破了——这就是为什么手动测试没有复现。

晚上吃过饭，拿到了 QA 测试通过的日志，虽然渔网被我加固了，但我还是想看看是什么样的鱼，把之前的两层小网给突破了？

这一看不要紧——

可能是我的代码还有 Bug！

简单地讲，从日志里看，代码可能会主动将过来的鱼群规模 x 3、并压缩到极高的密度自己攻击自己。

以之前的小网这怎么可能不漏？

..

不过到这里已是晚上八点多，收拾收拾还是回家了，毕竟周末还有事要做，将 research 做的笔记一并带回家准备回去有空搞。

写到这儿怎么觉得画风有点往 Geek 悬疑上歪了？

本是想说说这个周末的。

怎么工作乱入了进来？

好吧先睡觉了，欲知后事如何，且听下回分解。