Welcome to the Black Parade

产生了一些疯狂且不成熟的想法: 1. 用 XDP + BPF_HASH 在内核做 cache service. 但是 TCP 连接状态是个大问题, 也许可以用 UDP 2. 用 ECMP 做透明三层 LB, 用 BGP 动态更新. 路由是天然的透明"代理" 3. 内核 iptables/netfilter/route 也许可以全部被 XDP + TC + cgroup 级别的 SOCK BPF 代替. 前两者 attach 设备, 后者 attach 进程.

我有个不太健康的习惯, 就是相比阅读代码, 我更相信 trace 的结果. 给两个例子. 第一个是 dockerd, 如果你去看代码研究 docker 容器在什么时候生成 veth 的话, 你也许能找到它调用 CNM 的链路, 但是你很可能不会注意到, 这条链路的调用起点不是 dockerd 不是客户端, 而是 runc prehook 用一个命令行回调. 第二个是 tcp time wait 的状态转化, 如果你直接在 torvalds/linux 里搜 ag '\s+=\s+TCP_TIME_WAIT', 会得到如图的结果. 不知道啥是 minisock 不过第二个搜索结果看起来靠谱多了, 去深入研究了一会儿就心满意足地离开了评论区, 但是如果你用 ftrace(1) 或者 kprobe 追溯一下就会发现, 其实 localhost 的连接调用的基本是第一处代码. 四年多以前侯老师批评我 debug 就知道打断点偷懒, 但我还是觉得, 用 debugger / tracing tools 来探索未知世界, 是更有效率更不容易出错的现代做法. (侯老师永远是我老师, 非黑) (第二题的更现代解法是用 BPF_PROG_TYPE_SOCK_OPS 类型的 bpf 程序追踪 socket 状态变化, 这样连 kprobe 都不用找)

今天围观了同事查问题, 大家还是喜欢用猜测式 debug, 猜一个可能的问题, 然后做点改动试试看, 然后继续猜. 比如网络问题, 顺着网线爬就行了. 实例内 ping 不同目标, 先看 arp 能不能解出来, 路由对不对, 然后一路顺着设备抓包, tap -> br-int -> ovs -> genev -> eth0, 如果是 br-int 流表不符合预期, 先用 oftrace 模拟流量, 然后查数据库元数据. 本应该是逐步收敛的过程, 但是很多人都喜欢猜. 排错次数多了, 遇到过类似的问题, 以后猜得越来越快, 美其名曰经验, 其实遇到新问题还是无头苍蝇, 我看就是狗屎. 不要盲目猜, 去搜集线索和证据, 排除可能性, 佐证假设.

希望大家都能背下来 谢谢

ICMP payload 可以随便塞东西, 震惊吧! 我本来还打算发 UDP 来着, 这倒是省事了. BPF_PROG_TYPE_SCHED_CLS 类型的 bpf 程序其实灵活性比 XDP 大多了, 然而 bcc 貌似只实现了 bpf_redirect_map, 只有 XDP 能用, 所以是残废的. bpf for network 这块迟早还是要用 libbpf, 和 uprobe-based debugger 不同, bcc 没有带来什么显著的好处, 却不能用众多的 bpf helpers. 我怎么觉得 hping3 是个垃圾软件, ping 能工作的时候它不能, 毕竟是给自己发 SIGALRM 来做进程内事件回调呢, 一种近亲结婚导致的低能感扑面而来.

我可能想出了 业界第 一个对 overlay upstream 彻底透明的透明代理方案, 容器和虚机都通用, 比 NGINX Plus / mmproxy 这些要侵入到 overlay 内部的方案高到不知道哪里去了. 然后过两天我发现了方案纰漏, 默默删掉了这条 - -

libvirtd 太恶心了, 虽然暂时还不知道它是怎么做到的, 但是可以确定的是, 有了它之后流量居然连 iptables nat 表都不进了, 整个 NAT 都被 bypass, 所以那些依赖 nat POSTROUTING 做 masquerade 的都挂了. 太邪恶了, 操你妈. 等我忙过这一阵腾出手整死这傻逼.

bpf map 的数据 expiration 一直很困扰我. 比如我用 XDP + TC 实现了一个 ICMP SNAT, 其中最重要的一步就是维护状态, icmp echo出去的时候记录 (icmp id, dst ipv4) -> (src ipv4) 这条映射, icmp reply 回来的时候查一下 bpf hash 才能找到原始 src ipv4. 那么问题来了, 记录在 map 里的数据多久 expire? 像我这么懒得思考的直接照抄内核参数 net.netfilter.nf_conntrack_tcp_timeout_established = 432000, 默认 5 天, 我知道这是 TCP SNAT 的, 不重要, 重要的是, 怎么实现计时器? 在用户态轮询 map 当然可以, 但是太愚蠢了, 能不能远离中世纪, 30 多年前的人类都已经不再用轮询的方式等事件了啊. 那就用一个额外的 ring buf 事件通知用户态 start / refresh 计时器来避免轮询, 但是这个额外的 daemon 也非常不美好. 你能想象 TCP 四大计时器跑在用户态吗? 我连想都不敢想. 更何况 ring buf 事件的丢失也总是带来惊喜. 搜了一下 bpf timer, 有几个 patch 都是试图在内核态注册 timer 和回调, 正是我想要的, 但是似乎都没有合并. 也不知道当前状态下有没有什么更好的办法.

Perl 还在凭借一己之力发展正则表达式, 光这一意孤行就值得全体起立掌声响起

没人觉得 virsh 默认的网络模式是煞笔吗? 好好的 tap-bridge 二层网络模型, 非要把 bridge 用成 router, 泥马 arp 都直接解析到对端了, 你害给我 SNAT 假装自己是个 gateway, 我真的八辈子没见过这么弱智的电子垃圾, 除了 openstack.

之前和波波讨论 Calico icmp 黑洞的问题, 对 Calico-felix watch iptables 的行为感到无奈. 在 Calico 的邪恶统治下, 在 iptables 一些关键表链里插入更高优先级的规则会被回滚收敛到 Calico 喜欢的状态. 路由也一样. 然而今天我才体会到相反的设计是多么狗屎: Openstack-OVN-Octavia 体系下的 LB, 要多智障有多智障! 按照文档, olb create && olb pool create && olb member create && olb listener create, 跑通了最简单的 lb, 长舒一口气, 开始探索更高级的姿势, 比如 logical switch-based lb 或者纯三层 RR LB, 起手一个 ovn-nbctl create load_balancer && ovn-nbctl set logical_router load_balancer, 新的 lb 跑不通就算了, 旧的 lb 连 arp 都不通了! 我仔细一查, 流表被 ovn-nbctl 改坏了, 已经够见鬼了, 按照文档走都这么僵硬, 更绝的是把新 lb 删掉也不会恢复, irreversible damage 是吧, 简直就是唐氏综合征. 这时候我才开始怀念 Calico 对 iptables / route table 的状态收敛, 确实是很有经验的工程师煞费苦心的设计, 用一句诗来形容恐怕是, 日月之行, 若出其中; 星汉灿烂, 若出其里.

这条命令的名字就叫: 这是我们最后一代谢谢