🔥 热搜 🔥
百度今日热点微信公众平台贴吧知乎opgg企查查dnf公益服whatsapp web百度贴吧
分类
社会娱乐国际人权科技经济其它
🔥 热搜 🔥
百度今日热点微信公众平台贴吧知乎opgg企查查dnf公益服whatsapp web百度贴吧
分类
社会娱乐国际人权科技经济其它
查看原文
其他

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

杨玉玺 腾讯云原生 2021-03-12

大家好，我是杨玉玺，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/26255

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/25793

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

唯一找到一个似乎可以规避该问题的『方案』（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 工具体验：

1. 运行镜像
docker run --privileged=true -it ccr.ccs.tencentyun.com/monkeyyang/bpftool:v0.0.1

2. 运行工具

root@14bd5f0406fd:~# ./skbtracer.py -h
usage: skbtracer.py [-h] [-H IPADDR] [--proto PROTO] [--icmpid ICMPID]
[-c CATCH_COUNT] [-P PORT] [-p PID] [-N NETNS]
[--dropstack] [--callstack] [--iptable] [--route] [--keep]
[-T] [-t]

Trace any packet through TCP/IP stack

optional arguments:
-h, --help show this help message and exit
-H IPADDR, --ipaddr IPADDR
ip address
--proto PROTO tcp|udp|icmp|any
--icmpid ICMPID trace imcp id
-c CATCH_COUNT, --catch-count CATCH_COUNT
catch and print count
-P PORT, --port PORT udp or tcp port
-p PID, --pid PID trace this PID only
-N NETNS, --netns NETNS
trace this Network Namespace only
--dropstack output kernel stack trace when drop packet
--callstack output kernel stack trace
--iptable output iptable path
--route output route path
--keep keep trace packet all lifetime
-T, --time show HH:MM:SS timestamp
-t, --timestamp show timestamp in seconds at us resolution

examples:
skbtracer.py # trace all packets
skbtracer.py --proto=icmp -H 1.2.3.4 --icmpid 22 # trace icmp packet with addr=1.2.3.4 and icmpid=22
skbtracer.py --proto=tcp -H 1.2.3.4 -P 22 # trace tcp packet with addr=1.2.3.4:22
skbtracer.py --proto=udp -H 1.2.3.4 -P 22 # trace udp packet wich addr=1.2.3.4:22
skbtracer.py -t -T -p 1 --debug -P 80 -H 127.0.0.1 --proto=tcp --kernel-stack --icmpid=100 -N 10000



3. 抓取10个UDP报文

root@14bd5f0406fd:~# ./skbtracer.py --proto=udp -c10
time NETWORK_NS INTERFACE DEST_MAC PKT_INFO TRACE_INFO
[12:51:01 ][4026531993] nil 00a8177f422e U:10.0.2.96:60479->183.60.83.19:53 ffff949a8df47700.0:ip_output
[12:51:01 ][4026531993] eth0 00a8177f422e U:10.0.2.96:60479->183.60.83.19:53 ffff949a8df47700.0:ip_finish_output
[12:51:01 ][4026531993] eth0 00a8177f422e U:10.0.2.96:60479->183.60.83.19:53 ffff949a8df47700.0:__dev_queue_xmit
[12:51:01 ][4026531993] nil 09c67eff9b77 U:10.0.2.96:56790->183.60.83.19:53 ffff949a8e655000.0:ip_output
[12:51:01 ][4026531993] eth0 09c67eff9b77 U:10.0.2.96:56790->183.60.83.19:53 ffff949a8e655000.0:ip_finish_output
[12:51:01 ][4026531993] eth0 09c67eff9b77 U:10.0.2.96:56790->183.60.83.19:53 ffff949a8e655000.0:__dev_queue_xmit
[12:51:01 ][4026531993] eth0 5254006c498f U:183.60.83.19:53->10.0.2.96:56790 ffff949a2151bd00.0:napi_gro_receive
[12:51:01 ][4026531993] eth0 5254006c498f U:183.60.83.19:53->10.0.2.96:56790 ffff949a2151bd00.0:__netif_receive_skb
[12:51:01 ][4026531993] eth0 5254006c498f U:183.60.83.19:53->10.0.2.96:56790 ffff949a2151bd00.0:ip_rcv
[12:51:01 ][4026531993] eth0 5254006c498f U:183.60.83.19:53->10.0.2.96:56790 ffff949a2151bd00.0:ip_rcv_finish

输出结果说明
第一列：ebpf抓取内核事件的时间
第二列：skb当前所在namespace的inode号
第三列：skb->dev 所指设备
第四列：抓取事件发生时，数据包目的mac地址
第五列：数据包信息，由4层协议+3层地址信息+4层端口信息组成（T代表TCP，U代表UDP，I代表ICMP，其他协议直接打印协议号）
第六列：数据包的跟踪信息，由skb内存地址+skb->pkt_type+抓取函数名（如果在netfilter抓取，则由pf号+表+链+执行结果构成）

第六列，skb->pkt_type含义如下（\include\uapi\linux\if_packet.h）：
/* Packet types */
#define PACKET_HOST 0 /* To us */
#define PACKET_BROADCAST 1 /* To all */
#define PACKET_MULTICAST 2 /* To group */
#define PACKET_OTHERHOST 3 /* To someone else */
#define PACKET_OUTGOING 4 /* Outgoing of any type */
#define PACKET_LOOPBACK 5 /* MC/BRD frame looped back */
#define PACKET_USER 6 /* To user space */
#define PACKET_KERNEL 7 /* To kernel space */
/* Unused, PACKET_FASTROUTE and PACKET_LOOPBACK are invisible to user space */
#define PACKET_FASTROUTE 6 /* Fastrouted frame */

第六列，pf号含义如下（\include\uapi\linux\netfilter.h）：
enum {
NFPROTO_UNSPEC = 0,
NFPROTO_INET = 1,
NFPROTO_IPV4 = 2,
NFPROTO_ARP = 3,
NFPROTO_NETDEV = 5,
NFPROTO_BRIDGE = 7,
NFPROTO_IPV6 = 10,
NFPROTO_DECNET = 12,
NFPROTO_NUMPROTO,
};


4  分析过程

4.1 环境说明

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

node信息：
node eth0 ip地址 eth0 mac地址 cbr0 ip地址 crb0 mac地址
node1 10.0.2.96 52:54:00:6c:49:8f 172.18.0.1 2e:74:df:86:96:4b
node2 10.0.2.138 52:54:00:b8:05:ae 172.18.0.65 6e:41:27:22:69:0e

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> 443/TCP 10d
ubuntu-server ClusterIP 172.18.253.6 <none> 6666/UDP 10d
ubuntu-server2 ClusterIP 172.18.253.158 <none> 6667/UDP 5h41m

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@14bd5f0406fd:~# ./skbtracer.py --route --iptable -H 172.18.0.15 --proto udp
time NETWORK_NS INTERFACE DEST_MAC PKT_INFO TRACE_INFO
[02:05:54 ][4026532282] nil 000000000000 U:172.18.0.15:48655->172.18.253.6:6666 ffff949a8d639a00.0:ip_output
[02:05:54 ][4026532282] eth0 000000000000 U:172.18.0.15:48655->172.18.253.6:6666 ffff949a8d639a00.0:ip_finish_output
[02:05:54 ][4026532282] eth0 000000000000 U:172.18.0.15:48655->172.18.253.6:6666 ffff949a8d639a00.0:__dev_queue_xmit
[02:05:54 ][4026531993] vethdfe06191 2e74df86964b U:172.18.0.15:48655->172.18.253.6:6666 ffff949a8d639a00.3:__netif_receive_skb
[02:05:54 ][4026531993] vethdfe06191 2e74df86964b U:172.18.0.15:48655->172.18.253.6:6666 ffff949a8d639a00.3:br_handle_frame
[02:05:54 ][4026531993] vethdfe06191 2e74df86964b U:172.18.0.15:48655->172.18.253.6:6666 ffff949a8d639a00.0:br_nf_pre_routing
[02:05:54 ][4026531993] cbr0 2e74df86964b U:172.18.0.15:48655->172.18.253.6:6666 ffff949a8d639a00.0:2.nat.PREROUTING.ACCEPT
[02:05:54 ][4026531993] cbr0 2e74df86964b U:172.18.0.15:48655->172.18.0.12:6666 ffff949a8d639a00.0:br_nf_pre_routing_finish
[02:05:54 ][4026531993] vethdfe06191 7a475ebb26b0 U:172.18.0.15:48655->172.18.0.12:6666 ffff949a8d639a00.0:br_handle_frame_finish
[02:05:54 ][4026531993] vethdfe06191 7a475ebb26b0 U:172.18.0.15:48655->172.18.0.12:6666 ffff949a8d639a00.0:deliver_clone
[02:05:54 ][4026531993] vethdfe06191 7a475ebb26b0 U:172.18.0.15:48655->172.18.0.12:6666 ffff949a8d639400.0:__br_forward
[02:05:54 ][4026531993] veth19678f6d 7a475ebb26b0 U:172.18.0.15:48655->172.18.0.12:6666 ffff949a8d639400.0:br_nf_forward_ip
[02:05:54 ][4026531993] veth19678f6d 7a475ebb26b0 U:172.18.0.15:48655->172.18.0.12:6666 ffff949a8d639400.0:2.filter.FORWARD.ACCEPT
[02:05:54 ][4026531993] veth19678f6d 7a475ebb26b0 U:172.18.0.15:48655->172.18.0.12:6666 ffff949a8d639400.0:br_nf_forward_finish
[02:05:54 ][4026531993] veth19678f6d 7a475ebb26b0 U:172.18.0.15:48655->172.18.0.12:6666 ffff949a8d639400.0:br_forward_finish
[02:05:54 ][4026531993] veth19678f6d 7a475ebb26b0 U:172.18.0.15:48655->172.18.0.12:6666 ffff949a8d639400.0:br_nf_post_routing
[02:05:54 ][4026531993] veth19678f6d 7a475ebb26b0 U:172.18.0.15:48655->172.18.0.12:6666 ffff949a8d639400.0:2.nat.POSTROUTING.ACCEPT
[02:05:54 ][4026531993] veth19678f6d 7a475ebb26b0 U:172.18.0.15:48655->172.18.0.12:6666 ffff949a8d639400.0:br_nf_dev_queue_xmit
[02:05:54 ][4026531993] veth19678f6d 7a475ebb26b0 U:172.18.0.15:48655->172.18.0.12:6666 ffff949a8d639400.0:__dev_queue_xmit
[02:05:54 ][4026531993] vethdfe06191 7a475ebb26b0 U:172.18.0.15:48655->172.18.0.12:6666 ffff949a8d639a00.0:br_pass_frame_up
[02:05:54 ][4026531993] cbr0 7a475ebb26b0 U:172.18.0.15:48655->172.18.0.12:6666 ffff949a8d639a00.0:br_netif_receive_skb
[02:05:54 ][4026531993] cbr0 7a475ebb26b0 U:172.18.0.15:48655->172.18.0.12:6666 ffff949a8d639a00.0:__netif_receive_skb
[02:05:54 ][4026531993] cbr0 7a475ebb26b0 U:172.18.0.15:48655->172.18.0.12:6666 ffff949a8d639a00.0:ip_rcv
[02:05:54 ][4026531993] cbr0 7a475ebb26b0 U:172.18.0.15:48655->172.18.0.12:6666 ffff949a8d639a00.0:ip_rcv_finish
[02:05:54 ][4026531993] cbr0 7a475ebb26b0 U:172.18.0.15:48655->172.18.0.12:6666 ffff949a8d639a00.0:2.filter.FORWARD.ACCEPT
[02:05:54 ][4026531993] cbr0 7a475ebb26b0 U:172.18.0.15:48655->172.18.0.12:6666 ffff949a8d639a00.0:ip_output
[02:05:54 ][4026531993] cbr0 7a475ebb26b0 U:172.18.0.15:48655->172.18.0.12:6666 ffff949a8d639a00.0:ip_finish_output
[02:05:54 ][4026531993] cbr0 7a475ebb26b0 U:172.18.0.15:48655->172.18.0.12:6666 ffff949a8d639a00.0:__dev_queue_xmit
[02:05:54 ][4026531993] cbr0 7a475ebb26b0 U:172.18.0.15:48655->172.18.0.12:6666 ffff949a8d639a00.0:deliver_clone
[02:05:54 ][4026531993] cbr0 7a475ebb26b0 U:172.18.0.15:48655->172.18.0.12:6666 ffff949a8d639000.0:__br_forward
[02:05:54 ][4026531993] vethdfe06191 7a475ebb26b0 U:172.18.0.15:48655->172.18.0.12:6666 ffff949a8d639000.0:br_forward_finish
[02:05:54 ][4026531993] vethdfe06191 7a475ebb26b0 U:172.18.0.15:48655->172.18.0.12:6666 ffff949a8d639000.0:br_nf_post_routing
[02:05:54 ][4026531993] vethdfe06191 7a475ebb26b0 U:172.18.0.15:48655->172.18.0.12:6666 ffff949a8d639000.0:__dev_queue_xmit
[02:05:54 ][4026531993] cbr0 7a475ebb26b0 U:172.18.0.15:48655->172.18.0.12:6666 ffff949a8d639a00.0:__br_forward
[02:05:54 ][4026531993] veth19678f6d 7a475ebb26b0 U:172.18.0.15:48655->172.18.0.12:6666 ffff949a8d639a00.0:br_forward_finish
[02:05:54 ][4026531993] veth19678f6d 7a475ebb26b0 U:172.18.0.15:48655->172.18.0.12:6666 ffff949a8d639a00.0:br_nf_post_routing
[02:05:54 ][4026531993] veth19678f6d 7a475ebb26b0 U:172.18.0.15:48655->172.18.0.12:6666 ffff949a8d639a00.0:__dev_queue_xmit
[02:05:54 ][4026532360] eth0 7a475ebb26b0 U:172.18.0.15:48655->172.18.0.12:6666 ffff949a8d639400.0:__netif_receive_skb
[02:05:54 ][4026532360] eth0 7a475ebb26b0 U:172.18.0.15:48655->172.18.0.12:6666 ffff949a8d639400.0:ip_rcv
[02:05:54 ][4026532360] eth0 7a475ebb26b0 U:172.18.0.15:48655->172.18.0.12:6666 ffff949a8d639400.0:ip_rcv_finish
[02:05:54 ][4026532282] eth0 7a475ebb26b0 U:172.18.0.15:48655->172.18.0.12:6666 ffff949a8d639000.3:__netif_receive_skb
[02:05:54 ][4026532282] eth0 7a475ebb26b0 U:172.18.0.15:48655->172.18.0.12:6666 ffff949a8d639000.3:ip_rcv
[02:05:54 ][4026532360] eth0 7a475ebb26b0 U:172.18.0.15:48655->172.18.0.12:6666 ffff949a8d639a00.0:__netif_receive_skb
[02:05:54 ][4026532360] eth0 7a475ebb26b0 U:172.18.0.15:48655->172.18.0.12:6666 ffff949a8d639a00.0:ip_rcv
[02:05:54 ][4026532360] eth0 7a475ebb26b0 U:172.18.0.15:48655->172.18.0.12:6666 ffff949a8d639a00.0:ip_rcv_finish

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

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

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

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

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

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

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

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

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

root@14bd5f0406fd:~# ./skbtracer.py --route --iptable -H 172.18.0.15 --proto udp
time NETWORK_NS INTERFACE DEST_MAC PKT_INFO TRACE_INFO
[02:09:36 ][4026532282] nil 000000000000 U:172.18.0.15:41067->172.18.0.12:6666 ffff949a8d570300.0:ip_output
[02:09:36 ][4026532282] eth0 000000000000 U:172.18.0.15:41067->172.18.0.12:6666 ffff949a8d570300.0:ip_finish_output
[02:09:36 ][4026532282] eth0 000000000000 U:172.18.0.15:41067->172.18.0.12:6666 ffff949a8d570300.0:__dev_queue_xmit
[02:09:36 ][4026531993] vethdfe06191 7a475ebb26b0 U:172.18.0.15:41067->172.18.0.12:6666 ffff949a8d570300.3:__netif_receive_skb
[02:09:36 ][4026531993] vethdfe06191 7a475ebb26b0 U:172.18.0.15:41067->172.18.0.12:6666 ffff949a8d570300.3:br_handle_frame
[02:09:36 ][4026531993] vethdfe06191 7a475ebb26b0 U:172.18.0.15:41067->172.18.0.12:6666 ffff949a8d570300.3:br_nf_pre_routing
[02:09:36 ][4026531993] cbr0 7a475ebb26b0 U:172.18.0.15:41067->172.18.0.12:6666 ffff949a8d570300.0:2.nat.PREROUTING.ACCEPT
[02:09:36 ][4026531993] cbr0 7a475ebb26b0 U:172.18.0.15:41067->172.18.0.12:6666 ffff949a8d570300.0:br_nf_pre_routing_finish
[02:09:36 ][4026531993] vethdfe06191 7a475ebb26b0 U:172.18.0.15:41067->172.18.0.12:6666 ffff949a8d570300.3:br_handle_frame_finish
[02:09:36 ][4026531993] vethdfe06191 7a475ebb26b0 U:172.18.0.15:41067->172.18.0.12:6666 ffff949a8d570300.3:br_forward
[02:09:36 ][4026531993] vethdfe06191 7a475ebb26b0 U:172.18.0.15:41067->172.18.0.12:6666 ffff949a8d570300.3:__br_forward
[02:09:36 ][4026531993] veth19678f6d 7a475ebb26b0 U:172.18.0.15:41067->172.18.0.12:6666 ffff949a8d570300.3:br_nf_forward_ip
[02:09:36 ][4026531993] veth19678f6d 7a475ebb26b0 U:172.18.0.15:41067->172.18.0.12:6666 ffff949a8d570300.0:2.filter.FORWARD.ACCEPT
[02:09:36 ][4026531993] veth19678f6d 7a475ebb26b0 U:172.18.0.15:41067->172.18.0.12:6666 ffff949a8d570300.0:br_nf_forward_finish
[02:09:36 ][4026531993] veth19678f6d 7a475ebb26b0 U:172.18.0.15:41067->172.18.0.12:6666 ffff949a8d570300.3:br_forward_finish
[02:09:36 ][4026531993] veth19678f6d 7a475ebb26b0 U:172.18.0.15:41067->172.18.0.12:6666 ffff949a8d570300.3:br_nf_post_routing
[02:09:36 ][4026531993] veth19678f6d 7a475ebb26b0 U:172.18.0.15:41067->172.18.0.12:6666 ffff949a8d570300.0:2.nat.POSTROUTING.ACCEPT
[02:09:36 ][4026531993] veth19678f6d 7a475ebb26b0 U:172.18.0.15:41067->172.18.0.12:6666 ffff949a8d570300.0:br_nf_dev_queue_xmit
[02:09:36 ][4026531993] veth19678f6d 7a475ebb26b0 U:172.18.0.15:41067->172.18.0.12:6666 ffff949a8d570300.0:__dev_queue_xmit
[02:09:36 ][4026532360] eth0 7a475ebb26b0 U:172.18.0.15:41067->172.18.0.12:6666 ffff949a8d570300.0:__netif_receive_skb
[02:09:36 ][4026532360] eth0 7a475ebb26b0 U:172.18.0.15:41067->172.18.0.12:6666 ffff949a8d570300.0:ip_rcv
[02:09:36 ][4026532360] eth0 7a475ebb26b0 U:172.18.0.15:41067->172.18.0.12:6666 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 = 0;

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


   引  用


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

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

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


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


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

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




    您可能也对以下帖子感兴趣

    文章有问题？点此查看未经处理的缓存