使用 ebpf 深入分析容器网络 dup 包问题

灵雀云

发布于 2020-02-17 13:13:47

1.2K0

发布于 2020-02-17 13:13:47

文章被收录于专栏：云原生技术社区云原生技术社区

来源：腾讯云容器团队

作者：杨玉玺

大家好，我是杨玉玺，2011年至今一直从事底层网络研发，先后就职于阿里云、金山云从事 VPC 虚拟化网络研发，对高性能网络优化，复杂网络问题排查有非常丰富的经验。目前就职腾讯云 TKE 团队，专注 K8S 底层网络。

本文主要讲述了借助 ebpf 工具 skbtracer 分析了容器网桥模式下出现 dup 包问题的根本原因， skbtracer 工具的使用使得原本比较复杂的分析过程变得非常高效且流程化。目前，skbtracer 工具正在不断打磨发展，后续会越来越傻瓜化智能化，希望能够借本次分享推广此分析方法及思路，让更多的人了解、使用 skbtracer 工具。

背景

云计算浪潮中，网络成为了跨越云端必不可少的一座桥梁，它给予人们便利，同时也带来了各种奇怪的困扰。这些困扰的奇怪之处，不仅仅在于你面对它时的束手无策，还在于当你直接或者间接解决了这些困扰时却又不知道为什么就解决了。究其本质的话，无外乎是我们不能够真正地去理清楚其中的门道儿。

但是，想要非常精通网络真的不是一件容易的事情。我们知道，内核技术门槛非常高，尤其是内核中最复杂的子系统——内核网络子系统，有了容器网络的加持使得该系统涉及到了 2 层转发，3 层转发，iptable，ipvs，NameSpace 交叉变化，面对如此复杂的环境，即使是专业的网络专家，解决问题的时候也是非常头大的。再加上由于业务的发展迅速使得网络问题变得更加频繁棘手，以及技术壁垒居高不下，开发运维人员在此花费重大人力也不一定能根治问题本身，更多时候只能绕道去尝试通过各种内核参数等等去解决问题。

既然把黑盒般的内核研究透彻是一件难于上青天的事情，那么我们是否可以尝试开发出一种工具旨在让 Linux 主机网络对一般开发运维人员来说成为一个彻底的白盒？答案是肯定的，本文正是利用这样的一款工具分析一个完全黑盒的容器网络问题。

1 问题描述

用户在使用 TKE 的过程中，发现同一个节点上的 Pod1 通过 Service（ ClusterIP ）访问 Pod2， Pod1 通过 UDP push 的每一条消息会在 Pod2 上出现两次。当尝试在 Pod1 eth0 <—> veth1 <—> cbr0 <—> veth2 <—> Pod2 eth0 路径上的每个网络接口上分别抓包后，发现在 Pod1 eth0，veth1 上数据包都仅有一个，但在cbr0，veth2，Pod2 eth0 都能抓到两个完全相同的包。

进一步扩展场景发现，当满足如下条件时，就会出现 dup 包：

1. Pod1 与 Pod2在同一个 Node 。

2. Pod1 通过 Service 访问 Pod2 。

3. 容器网络为桥接模式且需要桥打开混杂模式。如 TKE 网络的 cbr0 需要打开混杂模式。

并且，这些条件都很容易满足，从『一个 K8S 的 issue 』（1）可以看出，早在 1.2.4 版本，此问题就存在。

2 思路

实践发现，此问题百分之百复现，且不区分内核版本。从网页搜索结果看出，已经有人发现了这个问题并寻求帮助，但是遗憾的是还没有人能够分析出根本原因并给出解决方案：

Duplicate UDP packets between pods
https://github.com/kubernetes/kubernetes/issues/

Duplication of packets seen in bridge-promiscuous mode when accessing a pod on the same node through service ip
https://github.com/kubernetes/kubernetes/issues/

Resolve cbr0 hairpin/promiscuous mode duplicate packet issue
https://github.com/kubernetes/kubernetes/issues/

唯一找到一个似乎可以规避该问题的『方案』（2），也同样没有分析出原因，而是强行在 2 层通过 ebtable 丢包处理进行解决。

既然从当前掌握的情况中无法得知内核黑盒到底发生了什么，也就只能深入内核进行进一步分析了。当我们去分析内核数据包处理流程细节时，可以参考如下几种思路进行：

1.修改内核代码，在数据包经过的路径上跟踪处理细节

优点：实现比较直接。
缺点：不灵活，需要反复修改，重启内核；需要对协议栈非常熟悉，知道数据包处理的关键路径。

2.插入内核模块，hook 关键函数

优点：不用修改、重启内核。
缺点：不灵活。由于很多内部函数不能直接调用，通过该方式进行分析会导致代码量大，容易犯错。

3. 通过 Linux 内核提供的 ebpf 去 hook 关键路径函数

优点：轻量，安全，易于编写及调试。
缺点：ebpf 不支持循环，有些功能需要通过比较 trick 的方式实现；ebpf 当前属于比较新的技术，很多特性需要高版本内核的支持才更加完善，具体可参考『BPF Features by Linux Kernel Version』（3）。

考虑到以上分析思路，笔者已实现了基于『 bcc 』（4）的容器网络分析工具 skbtracer，旨在一键排查网络问题（主机网络，容器网络）。

3 工具说明

skbtracer 工具基于 bcc 框架，由 skbtracer.py 和 skbtracer.c 两个文件组成，C 代码是具体的 ebpf 代码，负责抓取过滤内核事件，Python 代码负责简单参数解析以及抓取事件的结果输出。该工具当前已支持跟踪路由信息、丢包信息以及 netfilter 处理过程，其中数据流跟踪功能正在完善，后续也将会在排查问题过程中不断完善强大，争取能够让一般用户也能把内核协议栈当作白盒观测。

本文提供的 skbtracer 需要 4.15 及以上内核才能正常运行，推荐使用 ubuntu18.04 或其他更高版本。你可以参照以下步骤进行 skbtracer 工具体验：

4 分析过程

4.1 环境说明

操作系统：ubuntu 18.01 4.15.0-54-generic
pod信息：
角色      nodeveth         eth0 mac地址          pod ip地址     node eth0地址
client    vethdfe06191     :0f::::ff     172.18.0.15    10.0.2.96
server    veth19678f6d     a::e:bb::b0     172.18.0.12    10.0.2.96
server2   vethe9f5bdcc     :f5:ce:8f::f6     172.18.0.66    10.0.2.138

node信息：
node    eth0 ip地址    eth0 mac地址        cbr0 ip地址     crb0 mac地址
node1   10.0.2.96      :::c::8f   172.18.0.1      e::df:::b
node2   10.0.2.138     :::b8::ae   172.18.0.65     e:::::e

service信息：
ubuntu@VM-2-138-ubuntu:~$ kubectl get svc
NAME             TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
kubernetes       ClusterIP   172.18.252.1     <none>        /TCP    d
ubuntu-server    ClusterIP   172.18.253.6     <none>        /UDP   d
ubuntu-server2   ClusterIP   172.18.253.158   <none>        /UDP   h41m

ubuntu-server 后端只有一个 pod，对应 pod 名为 server
ubuntu-server2 后端只有一个 pod，对应 pod 名为 server2

接下来用 skbtracer 工具分别输出如下场景数据包的处理细节：

1. cbr0 开启混杂模式：client 通过 Service 访问相同 Node 的 Pod

2. cbr0 开启混杂模式：client 通过 Service 访问不同 Node 的 Pod

3. cbr0 开启混杂模式：client 直接访问相同 Node 的 Pod

4. cbr0 关闭混杂模式：client 通过 Service 访问相同 Node的 Pod

5. cbr0 关闭混杂模式：client 通过 Service 访问不同 Node的 Pod

6. cbr0 关闭混杂模式：client 直接访问相同 Node 的 Pod

4.2 分场景输出处理细节

4.2.1. cbr0 开启混杂模式: client 通过 Service 访问相同 Node 的 Pod

root@bd5f0406fd:~# ./skbtracer.py --route --iptable -H 172.18.0.15 --proto udp
time       NETWORK_NS   INTERFACE    DEST_MAC     PKT_INFO                                 TRACE_INFO
[:: ][] nil           U:172.18.0.15:->172.18.253.6:   ffff949a8d639a00.0:ip_output
[:: ][] eth0          U:172.18.0.15:->172.18.253.6:   ffff949a8d639a00.0:ip_finish_output
[:: ][] eth0          U:172.18.0.15:->172.18.253.6:   ffff949a8d639a00.0:__dev_queue_xmit
[:: ][] vethdfe06191 2e74df86964b U:172.18.0.15:->172.18.253.6:   ffff949a8d639a00.3:__netif_receive_skb
[:: ][] vethdfe06191 2e74df86964b U:172.18.0.15:->172.18.253.6:   ffff949a8d639a00.3:br_handle_frame
[:: ][] vethdfe06191 2e74df86964b U:172.18.0.15:->172.18.253.6:   ffff949a8d639a00.0:br_nf_pre_routing
[:: ][] cbr0         2e74df86964b U:172.18.0.15:->172.18.253.6:   ffff949a8d639a00.0:2.nat.PREROUTING.ACCEPT
[:: ][] cbr0         2e74df86964b U:172.18.0.15:->172.18.0.12:    ffff949a8d639a00.0:br_nf_pre_routing_finish
[:: ][] vethdfe06191 a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d639a00.0:br_handle_frame_finish
[:: ][] vethdfe06191 a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d639a00.0:deliver_clone
[:: ][] vethdfe06191 a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d639400.0:__br_forward
[:: ][] veth19678f6d a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d639400.0:br_nf_forward_ip
[:: ][] veth19678f6d a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d639400.0:2.filter.FORWARD.ACCEPT
[:: ][] veth19678f6d a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d639400.0:br_nf_forward_finish
[:: ][] veth19678f6d a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d639400.0:br_forward_finish
[:: ][] veth19678f6d a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d639400.0:br_nf_post_routing
[:: ][] veth19678f6d a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d639400.0:2.nat.POSTROUTING.ACCEPT
[:: ][] veth19678f6d a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d639400.0:br_nf_dev_queue_xmit
[:: ][] veth19678f6d a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d639400.0:__dev_queue_xmit
[:: ][] vethdfe06191 a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d639a00.0:br_pass_frame_up
[:: ][] cbr0         a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d639a00.0:br_netif_receive_skb
[:: ][] cbr0         a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d639a00.0:__netif_receive_skb
[:: ][] cbr0         a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d639a00.0:ip_rcv
[:: ][] cbr0         a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d639a00.0:ip_rcv_finish
[:: ][] cbr0         a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d639a00.0:2.filter.FORWARD.ACCEPT
[:: ][] cbr0         a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d639a00.0:ip_output
[:: ][] cbr0         a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d639a00.0:ip_finish_output
[:: ][] cbr0         a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d639a00.0:__dev_queue_xmit
[:: ][] cbr0         a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d639a00.0:deliver_clone
[:: ][] cbr0         a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d639000.0:__br_forward
[:: ][] vethdfe06191 a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d639000.0:br_forward_finish
[:: ][] vethdfe06191 a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d639000.0:br_nf_post_routing
[:: ][] vethdfe06191 a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d639000.0:__dev_queue_xmit
[:: ][] cbr0         a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d639a00.0:__br_forward
[:: ][] veth19678f6d a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d639a00.0:br_forward_finish
[:: ][] veth19678f6d a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d639a00.0:br_nf_post_routing
[:: ][] veth19678f6d a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d639a00.0:__dev_queue_xmit
[:: ][] eth0         a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d639400.0:__netif_receive_skb
[:: ][] eth0         a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d639400.0:ip_rcv
[:: ][] eth0         a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d639400.0:ip_rcv_finish
[:: ][] eth0         a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d639000.3:__netif_receive_skb
[:: ][] eth0         a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d639000.3:ip_rcv
[:: ][] eth0         a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d639a00.0:__netif_receive_skb
[:: ][] eth0         a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d639a00.0:ip_rcv
[:: ][] eth0         a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d639a00.0:ip_rcv_finish

4.2.2. cbr0 开启混杂模式: client 通过 Service 访问不同 Node 的 Pod

root@bd5f0406fd:~# ./skbtracer.py --route --iptable -H 172.18.0.15 --proto udp
time       NETWORK_NS   INTERFACE    DEST_MAC     PKT_INFO                                 TRACE_INFO
[:: ][] nil          ea63e937c U:172.18.0.15:->172.18.253.158: ffff949a8d639400.0:ip_output
[:: ][] eth0         ea63e937c U:172.18.0.15:->172.18.253.158: ffff949a8d639400.0:ip_finish_output
[:: ][] eth0         ea63e937c U:172.18.0.15:->172.18.253.158: ffff949a8d639400.0:__dev_queue_xmit
[:: ][] vethdfe06191 2e74df86964b U:172.18.0.15:->172.18.253.158: ffff949a8d639400.3:__netif_receive_skb
[:: ][] vethdfe06191 2e74df86964b U:172.18.0.15:->172.18.253.158: ffff949a8d639400.3:br_handle_frame
[:: ][] vethdfe06191 2e74df86964b U:172.18.0.15:->172.18.253.158: ffff949a8d639400.0:br_nf_pre_routing
[:: ][] cbr0         2e74df86964b U:172.18.0.15:->172.18.253.158: ffff949a8d639400.0:2.nat.PREROUTING.ACCEPT
[:: ][] cbr0         2e74df86964b U:172.18.0.15:->172.18.0.66:    ffff949a8d639400.0:br_nf_pre_routing_finish
[:: ][] vethdfe06191 2e74df86964b U:172.18.0.15:->172.18.0.66:    ffff949a8d639400.0:br_handle_frame_finish
[:: ][] vethdfe06191 2e74df86964b U:172.18.0.15:->172.18.0.66:    ffff949a8d639400.0:br_pass_frame_up
[:: ][] cbr0         2e74df86964b U:172.18.0.15:->172.18.0.66:    ffff949a8d639400.0:br_netif_receive_skb
[:: ][] cbr0         2e74df86964b U:172.18.0.15:->172.18.0.66:    ffff949a8d639400.0:__netif_receive_skb
[:: ][] cbr0         2e74df86964b U:172.18.0.15:->172.18.0.66:    ffff949a8d639400.0:ip_rcv
[:: ][] cbr0         2e74df86964b U:172.18.0.15:->172.18.0.66:    ffff949a8d639400.0:ip_rcv_finish
[:: ][] cbr0         2e74df86964b U:172.18.0.15:->172.18.0.66:    ffff949a8d639400.0:2.filter.FORWARD.ACCEPT
[:: ][] cbr0         2e74df86964b U:172.18.0.15:->172.18.0.66:    ffff949a8d639400.0:ip_output
[:: ][] eth0         2e74df86964b U:172.18.0.15:->172.18.0.66:    ffff949a8d639400.0:2.nat.POSTROUTING.ACCEPT
[:: ][] eth0         2e74df86964b U:172.18.0.15:->172.18.0.66:    ffff949a8d639400.0:ip_finish_output
[:: ][] eth0         feee1e1bcbe0 U:172.18.0.15:->172.18.0.66:    ffff949a8d639400.0:__dev_queue_xmit

4.2.3. cbr0 开启混杂模式: client 直接访问相同 Node 的 Pod

root@bd5f0406fd:~# ./skbtracer.py --route --iptable -H 172.18.0.15 --proto udp
time       NETWORK_NS   INTERFACE    DEST_MAC     PKT_INFO                                 TRACE_INFO
[:: ][] nil           U:172.18.0.15:->172.18.0.12:    ffff949a8eb64b00.0:ip_output
[:: ][] eth0          U:172.18.0.15:->172.18.0.12:    ffff949a8eb64b00.0:ip_finish_output
[:: ][] eth0          U:172.18.0.15:->172.18.0.12:    ffff949a8eb64b00.0:__dev_queue_xmit
[:: ][] vethdfe06191 a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8eb64b00.3:__netif_receive_skb
[:: ][] vethdfe06191 a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8eb64b00.3:br_handle_frame
[:: ][] vethdfe06191 a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8eb64b00.3:br_nf_pre_routing
[:: ][] cbr0         a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8eb64b00.0:2.nat.PREROUTING.ACCEPT
[:: ][] cbr0         a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8eb64b00.0:br_nf_pre_routing_finish
[:: ][] vethdfe06191 a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8eb64b00.3:br_handle_frame_finish
[:: ][] vethdfe06191 a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8eb64b00.3:br_forward
[:: ][] vethdfe06191 a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8eb64b00.3:deliver_clone
[:: ][] vethdfe06191 a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8eb64900.3:__br_forward
[:: ][] veth19678f6d a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8eb64900.3:br_nf_forward_ip
[:: ][] veth19678f6d a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8eb64900.0:2.filter.FORWARD.ACCEPT
[:: ][] veth19678f6d a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8eb64900.0:br_nf_forward_finish
[:: ][] veth19678f6d a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8eb64900.3:br_forward_finish
[:: ][] veth19678f6d a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8eb64900.3:br_nf_post_routing
[:: ][] veth19678f6d a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8eb64900.0:2.nat.POSTROUTING.ACCEPT
[:: ][] veth19678f6d a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8eb64900.0:br_nf_dev_queue_xmit
[:: ][] veth19678f6d a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8eb64900.0:__dev_queue_xmit
[:: ][] vethdfe06191 a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8eb64b00.3:br_pass_frame_up
[:: ][] cbr0         a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8eb64b00.3:br_netif_receive_skb
[:: ][] cbr0         a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8eb64b00.3:__netif_receive_skb
[:: ][] cbr0         a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8eb64b00.3:ip_rcv
[:: ][] eth0         a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8eb64900.0:__netif_receive_skb
[:: ][] eth0         a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8eb64900.0:ip_rcv
[:: ][] eth0         a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8eb64900.0:ip_rcv_finish

4.2.4. cbr0 关闭混杂模式: client 通过 Service 访问相同 Node 的 Pod

root@bd5f0406fd:~# ./skbtracer.py --route --iptable -H 172.18.0.15 --proto udp
time       NETWORK_NS   INTERFACE    DEST_MAC     PKT_INFO                                 TRACE_INFO
[:: ][] nil          dc486eebf45 U:172.18.0.15:->172.18.253.6:   ffff949a2151b100.0:ip_output
[:: ][] eth0         dc486eebf45 U:172.18.0.15:->172.18.253.6:   ffff949a2151b100.0:ip_finish_output
[:: ][] eth0         dc486eebf45 U:172.18.0.15:->172.18.253.6:   ffff949a2151b100.0:__dev_queue_xmit
[:: ][] vethdfe06191 2e74df86964b U:172.18.0.15:->172.18.253.6:   ffff949a2151b100.3:__netif_receive_skb
[:: ][] vethdfe06191 2e74df86964b U:172.18.0.15:->172.18.253.6:   ffff949a2151b100.3:br_handle_frame
[:: ][] vethdfe06191 2e74df86964b U:172.18.0.15:->172.18.253.6:   ffff949a2151b100.0:br_nf_pre_routing
[:: ][] cbr0         2e74df86964b U:172.18.0.15:->172.18.253.6:   ffff949a2151b100.0:2.nat.PREROUTING.ACCEPT
[:: ][] cbr0         2e74df86964b U:172.18.0.15:->172.18.0.12:    ffff949a2151b100.0:br_nf_pre_routing_finish
[:: ][] vethdfe06191 a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a2151b100.0:br_handle_frame_finish
[:: ][] vethdfe06191 a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a2151b100.0:br_forward
[:: ][] vethdfe06191 a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a2151b100.0:__br_forward
[:: ][] veth19678f6d a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a2151b100.0:br_nf_forward_ip
[:: ][] veth19678f6d a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a2151b100.0:2.filter.FORWARD.ACCEPT
[:: ][] veth19678f6d a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a2151b100.0:br_nf_forward_finish
[:: ][] veth19678f6d a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a2151b100.0:br_forward_finish
[:: ][] veth19678f6d a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a2151b100.0:br_nf_post_routing
[:: ][] veth19678f6d a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a2151b100.0:2.nat.POSTROUTING.ACCEPT
[:: ][] veth19678f6d a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a2151b100.0:br_nf_dev_queue_xmit
[:: ][] veth19678f6d a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a2151b100.0:__dev_queue_xmit
[:: ][] eth0         a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a2151b100.0:__netif_receive_skb
[:: ][] eth0         a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a2151b100.0:ip_rcv
[:: ][] eth0         a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a2151b100.0:ip_rcv_finish

4.2.5. cbr0 关闭混杂模式: client 通过 Service 访问不同 Node 的 Pod

root@bd5f0406fd:~# ./skbtracer.py --route --iptable -H 172.18.0.15 --proto udp
time       NETWORK_NS   INTERFACE    DEST_MAC     PKT_INFO                                 TRACE_INFO
[:: ][] nil           U:172.18.0.15:->172.18.253.158: ffff949a8e655b00.0:ip_output
[:: ][] eth0          U:172.18.0.15:->172.18.253.158: ffff949a8e655b00.0:ip_finish_output
[:: ][] eth0          U:172.18.0.15:->172.18.253.158: ffff949a8e655b00.0:__dev_queue_xmit
[:: ][] vethdfe06191 2e74df86964b U:172.18.0.15:->172.18.253.158: ffff949a8e655b00.3:__netif_receive_skb
[:: ][] vethdfe06191 2e74df86964b U:172.18.0.15:->172.18.253.158: ffff949a8e655b00.3:br_handle_frame
[:: ][] vethdfe06191 2e74df86964b U:172.18.0.15:->172.18.253.158: ffff949a8e655b00.0:br_nf_pre_routing
[:: ][] cbr0         2e74df86964b U:172.18.0.15:->172.18.253.158: ffff949a8e655b00.0:2.nat.PREROUTING.ACCEPT
[:: ][] cbr0         2e74df86964b U:172.18.0.15:->172.18.0.66:    ffff949a8e655b00.0:br_nf_pre_routing_finish
[:: ][] vethdfe06191 2e74df86964b U:172.18.0.15:->172.18.0.66:    ffff949a8e655b00.0:br_handle_frame_finish
[:: ][] vethdfe06191 2e74df86964b U:172.18.0.15:->172.18.0.66:    ffff949a8e655b00.0:br_pass_frame_up
[:: ][] cbr0         2e74df86964b U:172.18.0.15:->172.18.0.66:    ffff949a8e655b00.0:br_netif_receive_skb
[:: ][] cbr0         2e74df86964b U:172.18.0.15:->172.18.0.66:    ffff949a8e655b00.0:__netif_receive_skb
[:: ][] cbr0         2e74df86964b U:172.18.0.15:->172.18.0.66:    ffff949a8e655b00.0:ip_rcv
[:: ][] cbr0         2e74df86964b U:172.18.0.15:->172.18.0.66:    ffff949a8e655b00.0:ip_rcv_finish
[:: ][] cbr0         2e74df86964b U:172.18.0.15:->172.18.0.66:    ffff949a8e655b00.0:2.filter.FORWARD.ACCEPT
[:: ][] cbr0         2e74df86964b U:172.18.0.15:->172.18.0.66:    ffff949a8e655b00.0:ip_output
[:: ][] eth0         2e74df86964b U:172.18.0.15:->172.18.0.66:    ffff949a8e655b00.0:2.nat.POSTROUTING.ACCEPT
[:: ][] eth0         2e74df86964b U:172.18.0.15:->172.18.0.66:    ffff949a8e655b00.0:ip_finish_output
[:: ][] eth0         feee1e1bcbe0 U:172.18.0.15:->172.18.0.66:    ffff949a8e655b00.0:__dev_queue_xmit

4.2.6. cbr0 关闭混杂模式: client 直接访问相同 Node 的 Pod

root@bd5f0406fd:~# ./skbtracer.py --route --iptable -H 172.18.0.15 --proto udp
time       NETWORK_NS   INTERFACE    DEST_MAC     PKT_INFO                                 TRACE_INFO
[:: ][] nil           U:172.18.0.15:->172.18.0.12:    ffff949a8d570300.0:ip_output
[:: ][] eth0          U:172.18.0.15:->172.18.0.12:    ffff949a8d570300.0:ip_finish_output
[:: ][] eth0          U:172.18.0.15:->172.18.0.12:    ffff949a8d570300.0:__dev_queue_xmit
[:: ][] vethdfe06191 a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d570300.3:__netif_receive_skb
[:: ][] vethdfe06191 a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d570300.3:br_handle_frame
[:: ][] vethdfe06191 a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d570300.3:br_nf_pre_routing
[:: ][] cbr0         a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d570300.0:2.nat.PREROUTING.ACCEPT
[:: ][] cbr0         a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d570300.0:br_nf_pre_routing_finish
[:: ][] vethdfe06191 a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d570300.3:br_handle_frame_finish
[:: ][] vethdfe06191 a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d570300.3:br_forward
[:: ][] vethdfe06191 a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d570300.3:__br_forward
[:: ][] veth19678f6d a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d570300.3:br_nf_forward_ip
[:: ][] veth19678f6d a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d570300.0:2.filter.FORWARD.ACCEPT
[:: ][] veth19678f6d a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d570300.0:br_nf_forward_finish
[:: ][] veth19678f6d a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d570300.3:br_forward_finish
[:: ][] veth19678f6d a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d570300.3:br_nf_post_routing
[:: ][] veth19678f6d a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d570300.0:2.nat.POSTROUTING.ACCEPT
[:: ][] veth19678f6d a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d570300.0:br_nf_dev_queue_xmit
[:: ][] veth19678f6d a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d570300.0:__dev_queue_xmit
[:: ][] eth0         a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d570300.0:__netif_receive_skb
[:: ][] eth0         a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d570300.0:ip_rcv
[:: ][] eth0         a475ebb26b0 U:172.18.0.15:->172.18.0.12:    ffff949a8d570300.0:ip_rcv_finish

5 数据处理流程结合内核代码现象分析解释

对比各种场景的处理流程，发现 br_handle_frame_finish 函数关键处理流程在不同场景有不同的处理结果，首先分析下这个函数：

/* note: already called with rcu_read_lock */
int br_handle_frame_finish(struct net *net, struct sock *sk, struct sk_buff *skb)
{
	struct net_bridge_port *p = br_port_get_rcu(skb->dev);
	enum br_pkt_type pkt_type = BR_PKT_UNICAST;
	struct net_bridge_fdb_entry *dst = NULL;
	struct net_bridge_mdb_entry *mdst;
	bool local_rcv, mcast_hit = false;
	const unsigned char *dest;
	struct net_bridge *br;
	u16 vid = ;

	if (!p || p->state == BR_STATE_DISABLED)
		goto drop;

	if (!br_allowed_ingress(p->br, nbp_vlan_group_rcu(p), skb, &vid))
		goto out;

	nbp_switchdev_frame_mark(p, skb);

	/* insert into forwarding database after filtering to avoid spoofing */
	br = p->br;
	if (p->flags & BR_LEARNING)
		br_fdb_update(br, p, eth_hdr(skb)->h_source, vid, false);
    //关键点，如果桥设备开启混杂模式，则local_rcv设置为true
	local_rcv = !!(br->dev->flags & IFF_PROMISC);
	dest = eth_hdr(skb)->h_dest;
	if (is_multicast_ether_addr(dest)) {
		/* by definition the broadcast is also a multicast address */
		if (is_broadcast_ether_addr(dest)) {
			pkt_type = BR_PKT_BROADCAST;
			local_rcv = true;
		} else {
			pkt_type = BR_PKT_MULTICAST;
			if (br_multicast_rcv(br, p, skb, vid))
				goto drop;
		}
	}

	if (p->state == BR_STATE_LEARNING)
		goto drop;

	BR_INPUT_SKB_CB(skb)->brdev = br->dev;

	if (IS_ENABLED(CONFIG_INET) &&
	    (skb->protocol == htons(ETH_P_ARP) ||
	     skb->protocol == htons(ETH_P_RARP))) {
		br_do_proxy_suppress_arp(skb, br, vid, p);
	} else if (IS_ENABLED(CONFIG_IPV6) &&
		   skb->protocol == htons(ETH_P_IPV6) &&
		   br->neigh_suppress_enabled &&
		   pskb_may_pull(skb, sizeof(struct ipv6hdr) +
				 sizeof(struct nd_msg)) &&
		   ipv6_hdr(skb)->nexthdr == IPPROTO_ICMPV6) {
			struct nd_msg *msg, _msg;

			msg = br_is_nd_neigh_msg(skb, &_msg);
			if (msg)
				br_do_suppress_nd(skb, br, vid, p, msg);
	}

	switch (pkt_type) {//当前的处理场景pkt_type只可能为BR_PKT_UNICAST
	case BR_PKT_MULTICAST:
		mdst = br_mdb_get(br, skb, vid);
		if ((mdst || BR_INPUT_SKB_CB_MROUTERS_ONLY(skb)) &&
		    br_multicast_querier_exists(br, eth_hdr(skb))) {
			if ((mdst && mdst->host_joined) ||
			    br_multicast_is_router(br)) {
				local_rcv = true;
				br->dev->stats.multicast++;
			}
			mcast_hit = true;
		} else {
			local_rcv = true;
			br->dev->stats.multicast++;
		}
		break;
	case BR_PKT_UNICAST: //根据数据包的目的mac地址查询该发往哪个设备
		dst = br_fdb_find_rcu(br, dest, vid);
	default:
		break;
	}

	if (dst) {
		unsigned long now = jiffies;

		if (dst->is_local) //目的mac地址是桥设备（cbr0），则把数据包往3层协议栈传递
			return br_pass_frame_up(skb);

		if (now != dst->used)
			dst->used = now;
		br_forward(dst->dst, skb, local_rcv, false); //目的mac地址是桥接的其他port，则在桥上直接转发出去
	} else {
		if (!mcast_hit)
			br_flood(br, skb, pkt_type, local_rcv, false);
		else
			br_multicast_flood(mdst, skb, local_rcv, false);
	}

	if (local_rcv) //关键点：开启混杂模式的情况下，此包再次被送入3层协议栈
		return br_pass_frame_up(skb);

out:
	return ;
drop:
	kfree_skb(skb);
	goto out;
}

简单捋了下流程，简化如下图：

5.1 为何 client 通过 Service 访问相同节点 Pod 有 dup 包？

对比内核函数 br_handle_frame_finish 和 br_forward 以及 4.2.1 中工具的输出结果，可知流程如下：

在 br_handle_frame_finish 函数内已经做完 DNAT 处理，目的 mac 地址是同 Pod 的 mac 地址，数据包有两条并行路线。

路线1：br_forward() —> deliver_clone() —> br_forward() —> 直接发给了 Service 后端的 Pod。

路线2：br_pass_frame_up()—>__netif_receive_skb(cbr0)—>ip_rcv()—>ip_output()—>发给 Service 后端的 Pod 。

5.2 为何 client 直接访问相同节点 Pod 没有 dup 包？

仔细对比可以发现，4.2.3 这条数据的处理与 4.2.1（访问 Service ）类似，数据包也有两条路径，第一条路径完全一致，第二条路径基本一致，只不过是在 ip_rcv() 函数处的 skb->pkt_type 有区别：

4.2.1 的 skb->pkt_type == PACKET_HOST
4.2.3 的 skb->pkt_type == PACKET_OTHERHOST

而 ip_rcv() 函数入口处会直接丢弃 skb->pkt_type == PACKET_OTHERHOST 的包，因此导致第二条路径就断了。

从以下代码片段可以看出，内核函数 ip_rcv() 丢弃了 skb->pkt_type == PACKET_OTHERHOST 的数据包：

/*
 * 	Main IP Receive routine.
 */
int ip_rcv(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt, struct net_device *orig_dev)
{
	const struct iphdr *iph;
	struct net *net;
	u32 len;

	/* When the interface is in promisc. mode, drop all the crap
	 * that it receives, do not try to analyse it.
	 */
	if (skb->pkt_type == PACKET_OTHERHOST)
		goto drop;

那么，为什么 4.2.1 和 4.2.3 两种情况中 skb->pkt_type 会有差异呢？原因在于，函数 br_handle_frame 会根据数据包的目的 mac 地址进行如下判断并重新给 skb->pkt_type 赋值：

如果目的 mac 地址是 cbr0（ Pod 的默认网关），则 skb->pkt_type = PACKET_HOST；
否则skb->pkt_type = PACKET_OTHERHOST。

5.3 开启混杂模式与否的哪些处理差异会导致出现 dup 包？

内核中有这样一处注释，如下：

static int br_pass_frame_up(struct sk_buff *skb)
{
....
	/* Bridge is just like any other port.  Make sure the
	 * packet is allowed except in promisc modue when someone
	 * may be running packet capture.
	 */
.....

cbr0开启混杂模式后，内核处理逻辑认为当前正在进行 cbr0 抓包，需要让数据包经过 cbr0，因此调用 br_pass_frame_up 把包 clone 一份传给 cbr0 设备（原始包是直接转发给对应 port ），cbr0 收到包后，从 2 层协议栈转 3 层协议栈走到 ip_rcv 函数（如 5.2 所述，ip_rcv 在 skb->pkt_type == PACKET_HOST 时会继续往后处理），而后 3 层协议栈继续走 IP 转发，又再次把这个 clone 的包发给了目的 Pod 。

5.4 为何在 netfilter 处理处，skb dev 会发生突变？

内核有一处注释如下：

/* Direct IPv6 traffic to br_nf_pre_routing_ipv6.
 * Replicate the checks that IPv4 does on packet reception.
 * Set skb->dev to the bridge device (i.e. parent of the
 * receiving device) to make netfilter happy, the REDIRECT
 * target in particular.  Save the original destination IP
 * address to be able to detect DNAT afterwards. */
static unsigned int br_nf_pre_routing(unsigned int hook, struct sk_buff *skb,
				      const struct net_device *in,
				      const struct net_device *out,
				      int (*okfn)(struct sk_buff *))

该注释表明，在 netfilter 处理处 skb dev 发生突变，是由于桥模式下调用 iptable 规则，会让规则认为当前的处理接口就是 cbr0 。

5.5 为何有时候能抓到两份包，有时候只能抓到一份？

关于抓包的问题，本次不做具体场景分析。抓包原理是应用层开启抓包后动态往协议栈注册 tpacket_rcv 回调函数，回调函数内部调用 bpf filter 判断满足抓包条件后会 clone 一份 skb 放到 ring buffer，此回调函数会在如下两点被调用：

dev_hard_start_xmit （抓接口发出包的点）
__netif_receive_skb_core（抓接口收包的点）

只要数据包经过这两个函数，就会被 tcpdump 抓取到。

以上即是所有可疑点的分析解释，如果读完本文还有其他质疑点，可以提出，一起分析讨论。

6 解决方案

经过以上分析发现，当前问题是开启混杂模式后，目的端收到了两份 UDP 报文（其实 TCP 也是两份，只不过是 TCP 协议栈在接收端做了处理，并认为是重传报文）。出现该问题的关键点在于，为了使 cbr0 能够抓到数据包，br_handle_frame_finish 多 clone 出了一份 skb，往上走到了 Node 节点的 ip_rcv 。

因此，要解决这个问题，只需要把这个包提前丢掉，不让其进入目的 Pod 即可。当前 KBS 社区有人提出使用『 ebtable规则丢包』（5），通过在 veth 设置 ebtable 规则，把源地址是 Pod 网段，源 mac 是cbr0 的包丢掉：

ebtables -t filter -N CNI-DEDUP
ebtables -t filter -A OUTPUT -j CNI-DEDUP
ebtables -t filter -A CNI-DEDUP -p IPv4 -s 2e:74:df:86:96:4b -o veth+ --ip-src 172.18.0.1 -j ACCEPT
ebtables -t filter -A CNI-DEDUP -p IPv4 -s 2e:74:df:86:96:4b -o veth+ --ip-src 172.18.0.1/24 -j DROP

经测试，该方式能够有效防止目标 Pod 收到两份报文。也许有人会疑问：为何这个 patch 很早就被合并进了 Kubernetes 的 master 主分支，现在这个问题又冒出来了呢？原因是 Kubernetes 后来引入了网络 CNI 插件机制，把原本放到 Kubenet 中实现的网络功能移植到 CNI 插件实现，而对应的插件并没有把这个特性移植过去。

总结

本文借助 ebpf 工具 skbtracer 分析了容器网桥模式下出现 dup 包问题的根本原因并讨论了解决方案，整个分析过程工具的输出内容信息量较大，但是能够简化原本复杂的分析过程。本文仅涉及到了与问题相关的部分结论，并没有覆盖所有网络处理细节，但是工具的输出结果可以多多交叉对比，能从中收获很多惊喜，你会发现：哦~原来如此。

引用

此处所展示的链接，为正文中带有『』符号的内容所对应的扩展入口，你可以通过这些入口进一步深入阅读。

. 这个 K8S 的 issue
   https://github.com/kubernetes/kubernetes/issues/

. 方案
   https://github.com/kubernetes/kubernetes/pull/


. BPF Features by Linux Kernel Version
   https://github.com/iovisor/bcc/blob/master/docs/kernel-versions.md


. bcc
   https://github.com/iovisor/bcc

. ebtable 规则丢包
   https://github.com/containernetworking/plugins/pull//commits/e17bdf609ff76a5f7b382e3e58b561e4db1736b

本文参与腾讯云自媒体分享计划，分享自微信公众号。

原始发表：2020-01-16，如有侵权请联系 cloudcommunity@tencent.com 删除

node.js