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

最新推荐文章于 2024-06-28 11:05:11 发布
最新推荐文章于 2024-06-28 11:05:11 发布
阅读量903 收藏 1
点赞数 1

本文主要讲述了借助 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 需要打开混杂模式。

并且，这些条件都很容易满足，从一个 Kubernetes 的 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 丢包处理进行解决。

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

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

    • 优点：实现比较直接。

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

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

    • 优点：不用修改、重启内核。

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

  • 通过 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 数据处理流程结合内核代码现象分析解释

对比各种场景的处理流程，发现 brhandleframe_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 包？

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

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

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

路线2：brpassframeup()—>netifreceiveskb(cbr0)—>iprcv()—>ip_output()—>发给 Service 后端的 Pod 。

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

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

  • 4.2.1 的 skb->pkttype == PACKETHOST

  • 4.2.3 的 skb->pkttype == PACKETOTHERHOST

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

从以下代码片段可以看出，内核函数 iprcv() 丢弃了 skb->pkttype == 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->pkttype 会有差异呢？原因在于，函数 brhandleframe 会根据数据包的目的 mac 地址进行如下判断并重新给 skb->pkttype 赋值：

  • 如果目的 mac 地址是 cbr0（ Pod 的默认网关），则 skb->pkttype = PACKETHOST；

  • 否则skb->pkttype = PACKETOTHERHOST。

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，因此调用 brpassframeup 把包 clone 一份传给 cbr0 设备（原始包是直接转发给对应 port ），cbr0 收到包后，从 2 层协议栈转 3 层协议栈走到 iprcv 函数（如 5.2 所述，iprcv 在 skb->pkttype == 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，此回调函数会在如下两点被调用：

  • devhardstart_xmit （抓接口发出包的点）

  • _netifreceiveskbcore（抓接口收包的点）

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

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

6 解决方案

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

因此，要解决这个问题，只需要把这个包提前丢掉，不让其进入目的 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. https://github.com/kubernetes/kubernetes/issues/25793

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

  3. https://github.com/iovisor/bcc/blob/master/docs/kernel-versions.md

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

  5. https://github.com/containernetworking/plugins/pull/42/commits/5e17bdf609ff76a5f7b382e3e58b561e4db1736b

文章来源：腾讯云容器团队，点击查看原文。

Docker_
关注
基于ebpf统计docker容器网络流量
xyin_kevin的博客
12-10 4848
Linux下统计网络带宽的工具很多，但大部分是按网卡、进程、IP维度进行统计。统计容器维度的网络流量，虽然可在容器的namespace查看，或者由cgroup提供的net_cls做标记再配合iptable统计，但使用起来并不方便，这里介绍一种基于ebpf来统计容器维度网络流量的办法，以及使用时遇到的坑。 原理与实现 ebpf的原理不再介绍了，用来做流量统计，最大的优势是十分灵活，能够根据需求对统计项目进行定制。基本原理就是记录内核中各网络相关函数的参数，再按不同维度，如 cgroupID， 进程，IP地
容器网络防火墙状态异常导致丢包排查记录
吉小白的博客
09-03 2072
0.导语 K8s容器网络涉及诸多内核子系统，IPVS，Iptable，3层路由，2层转发，TCP/IP协议栈，这些复杂的内核子系统在特定场景下可能会遇到设计者最初也想不到的问题。 本文分享了iptable防火墙状态异常导致丢包的排查记录，这个排查过程非常曲折，最后使用了在现在的作者看来非常落伍的工具：systemtap，才得以排查成功。其实依作者现有的经验，此问题现在仅需一条命令即可找到原因，这条命令就是作者之前分享过文章使用 ebpf 深入分析容器网络 dup 包问题中提到的skbtracker。时隔7个
eBPF BCC 实现UNIX socket抓包
RToax
08-27 1620
在之前，我写了一个《eBPF bpftrace 实现个UNIX socket抓包试试》，但是很受限啊，不能完整打印包数据信息，今天又写了一个BCC的，感觉没问题了。 不多说，直接上代码： #!/usr/bin/python # @lint-avoid-python-3-compatibility-imports # # undump Dump UNIX socket packets. # For Linux, uses BCC, eBPF. Embedded
eBPF实战教程二｜数据库网络流量最精准的量化方法(含源码)
最新发布
zhangjikuan的专栏
06-28 1063
自从DBdoctor率先将eBPF技术深度应用于数据库领域后，便迅速在业界引起了广泛的关注和讨论。阿里、美团、京东、字节跳动等众多头部企业纷纷主动与我们展开了深入的技术交流。与此同时，我们也收获了大量eBPF爱好者的关注，在第一篇关于uprobe的文章发布后，许多小伙伴都已按教程成功跑通代码并进行深入自学应用。应广大读者的热情催促，现推出第二篇eBPF的纯技术分享文章——如何手码一个Kprobe函数来分析MySQL数据库的网络流量。
eBPF bpftrace 实现个UNIX socket抓包试试
RToax
07-08 1229
https://github.com/Rtoax/test/tree/master/bpf/bpftrace/study #!/usr/bin/bpftrace // 荣涛 // UNIX socket STREAM 抓包 // 2021年7月8日 // 内核版本: 3.10.0-1062.el7.x86_64 #include <linux/aio.h> #include <linux/socket.h> #include <linux/net.h> #incl
探索网络世界的全新视角：ptcpdump——基于eBPF的高效TCP数据包捕获工具
gitblog_00039的博客
06-14 276
探索网络世界的全新视角：ptcpdump——基于eBPF的高效TCP数据包捕获工具 项目地址:https://gitcode.com/mozillazg/ptcpdump 在纷繁复杂的网络监控与分析领域中，一款名为ptcpdump的开源工具正以其独特的魅力脱颖而出。今天，我们将深入探索这一宝藏项目，看看它如何利用先进的eBPF技术，为我们的网络调试和监控带来革命性的变化。 项目介绍 ptcpdum...
记一次 tcpdump 抓包分析，Dup Ack
Fancyyuan的博客
09-25 9090
起因是 docker pull 镜像时有时卡住，然而 registry 一切正常，无奈只好一试抓包。 抓包命令 tcpdump -n -i en0 host 10.116.58.41 -w pull.pcap 参数说明： -n 不转换 ip 地址为 hostname -i 网卡 host &lt;host&gt; 过滤条件，抓符合 host 地址的包 -w &lt;filename&gt;...
dup工具使用说明.pdf
09-06
首先，你需要找到并双击运行"DUP工具使用说明.pdf"中提到的EXE执行文件，这将启动柯尼卡美能达DPU工具。 2. **安装驱动**： 在使用DPU工具之前，确保已在当前计算机上成功安装了柯尼卡美能达打印机的驱动程序。这...
网络抓包，分析基本功
07-11
网络抓包是网络分析的重要环节，它能让我们深入洞察网络数据传输的过程，找出潜在的问题。本文将围绕标题“网络抓包，分析基本功”，重点讲解tcpdump工具的抓包技能及Wireshark工具的分析方法。 首先，我们要理解...
DUP-Net：用于3D对抗点云防御的降噪器和上采样器网络
03-08
由于深度学习模型在机器学习问题上表现出色，尤其是在分类任务上，对抗性攻击已经成为一个严重的安全隐患。 在这一研究中，DUP-Net的设计包含两个主要模块：降噪器（denoiser）和上采样器（upsampler）。降噪器采用...
使用 eBPF 技术实现更快的网络数据包传输
hanfengzxh的博客
03-22 655
通过 eBPF 的引入，我们缩短了同节点通信数据包的 datapath，跳过了内核网络栈直接连接两个对端的 socket。这种设计适用于同 pod 两个应用的通信以及同节点上两个 pod 的通信。[^1]: 该辅助函数将引用的 socket 添加或者更新到 sockethashmap中，程序的输入作为键值对的值。详细信息可参考中的。[^2]: 该辅助函数将msg转发到 socket map 中key对应的 socket。关注"云原生指北"微信公众号（转载本站文章请注明作者和出处。
电脑抓整个路由器的包_基于eBPF实现对GRE keepalive包的回复
weixin_39760389的博客
11-26 455
最近我把一些跑在公有云上的RouterOS替换成了正常的Linux发行版。大多数RouterOS原有的路由功能都可以通过Linux标准的工具加以实现(虽然Linux当路由器总有一个令人诟病的问题就是不支持配置自动保存和开机自动恢复，需要自己写一大堆脚本和配置)，但是有一件事情让我头疼了一会儿：Linux的GRE隧道原生不支持keepalive。GRE Keepalive协议解析GRE是一...
强大的MATLAB机器人工具箱Matlab_Robotic_Toolbox_v9.8及教程
gumenghua_com1的博客
01-06 2611
强大的MATLAB机器人工具箱Matlab_Robotic_Toolbox_v9.8及教程 Matlab_Robotic_Toolbox_v9.8是一个功能强大的机器人工具箱，包含了机器人正、逆向运动学，正、逆向动力学，轨迹规划等等，其中的可视化仿真使得学习抽象的机器人学变得相对直观、好理解。学习这个工具箱，对理解机器人学很有帮助。 工具箱的安装：将Matlab_Robotic_Toolbox_v9.8.rar解压后，放在matlab的安装目录下，最好是放在toolbox文件夹里，利用matlab的工具栏
linux跟踪技术之ebpf
Innocence_0的博客
08-12 442
eBPF是一项革命性的技术，起源于 Linux内核，可以在操作系统内核等特权上下文中运行沙盒程序。它可以安全有效地扩展内核的功能，而无需更改内核源代码或加载内核模块。比如，使用ebpf可以追踪任何内核导出函数的参数，返回值，以实现kernel hook的效果；通过ebpf还可以在网络封包到达内核协议栈之前就进行处理，这可以实现流量控制，甚至隐蔽通信。
使用eBPF 技术进行四层网络监测
luisun66666的博客
11-17 1446
互联网的本质就是一系列的网络协议，按照功能不同，分工不同，其常被分为七层、五层、四层网络结构。七层，五层、四层的概念，只是人为的划分而已，是为了区分出哪一层是干什么用的。今天咱们主要讲“四层网络协议”，该协议族中最核心的两个协议分别为 TCP（传输控制协议）和 IP（网际协议），因此它也被称为 TCP/IP 协议族，它具有四层网络结构 ：应用层、传输层、网络层、网络接口层。eBPF是一个，提供了一种在内核事件和用户程序事件发生时安全注入代码的机制，使得非内核开发人员也可以对内核进行控制。
eBPF实践篇之环境搭建
https://github.com/zm50
02-24 637
你好，我是醉墨居士，本次我们学习一下eBPF🤗
EBPF入门--环境搭建
VCanna的博客
10-27 2118
EBPF入门--环境搭建
eBPF学习记录（一）eBPF介绍
热门推荐
jianjian的博客
02-18 1万+
一、什么是eBPF eBPF， 从它的全称“扩展的伯克利数据包过滤器 (Extended Berkeley Packet Filter)” 来看，它是一种数据包过滤技术，是从 BPF (Berkeley Packet Filter) 技术扩展而来的。BPF 提供了一种在内核事件和用户程序事件发生时安全注入代码的机制，这就让非内核开发人员也可以对内核进行控制。随着内核的发展，BPF 逐步从最初的数据包过滤扩展到了网络、内核、安全、跟踪等，而且它的功能特性还在快速发展中，这种扩展后的 BPF 被简称为 eBPF
TCP异常分析：抓包揭示网络问题
频繁的重传可能是网络问题的迹象，如丢包、延迟或路由问题。 在遇到抓包时的上述提示，IT专业人员需要进行深入分析，可能需要排查网络设备配置、路由、流量控制和拥塞控制等问题，以确定最佳解决方案。同时，也应...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值