这是一个网络问题，主要涉及到 Linux Bridge，还涉及一点点 K8S （但我个人认为，这个问题可能呢和 K8S 本身无关）

先说一下背景吧
我用 linux bridge，配置 k8s 的 cni，将容器 IP，与宿主机 规划到大二层环境下。目的是，让容器 IP 不再是虚拟 IP。这样一来，Java 应用，也可以将容器 IP 暴露到注册中心。搭建完集群后，容器的 IP 访问什么的，都没有问题。但是我在抓包的时候，遇到一个现象。

比如说，有 3 个 K8S 的节点，分别是 A、B、C。
A 上有容器：a1、a2
B 上有容器：b1、b2。
C 上有容器：c1、c2。

我的期望是，在 b1 上抓包，只能抓到这个容器自己网络下的包。但实际上不是。
问题是，我在 B 节点的 b1 容器上抓包，居然可以抓到 A 主机发到 A 主机上的 a1 容器的包。
K8S 版本 1.13.7，CNI 都是官方的。没有任何定制化内容。google 和 baidu 完全找不到相关的问题描述。

你这 3 个母机是怎么连接的？上面是用集线器互通的？

是这样的，有一个背景我没有说。其实是生产环境有问题，生产环境，这 3 台物理机，是挂到一个交换机下的。因为生产环境有问题，我又在公司开发环境，起来 3 个 kvm 实例，发现依然是有这个问题。

那你用的什么网络方案？ overlay ？哪个 cni 插件？

具体是什么报文？是持续收到吗？
其他配置正确的情况下，有两种情况在 b1 上可能会收到这样的报文
1. 广播报文
2. 本地 linux bridge 还没有学习到这个目的 mac 地址，也会做广播处理（向所有端口复制发送一份报文）

网络方案没有虚拟网络，因为我的目的就是去除虚拟化，做到容器和宿主机在同一个大二层。网络方案，用的 bridge 网络。插件就是 CNI 官方的 bridge。

是 tcp 报文，是持续收到，但不是一直有（不是那种刷的很快的连续性能抓到的报文），但基本上每分钟内都能抓到一些。
有一个现象。如果我开 2 个终端抓包，也就是 b1 开一个终端，b2 开一个终端。如果我能在 b1 上抓到 a1 发往 c1 的报文。那么，同时（同时！）也能在 b2 上抓到 a1 发往 c1 的报文，而且，数据报文，一模一样。

交换机端口 mac 表老化，广播报文了。
正常现象

我顺着你的思路，梳理梳理


同步一下，我下午测了一下，我抓了一下 br0 网卡（ bridge ）的 mac table 数量，发现，当 mac table 瞬间变少的时候，一定会引起我原文提到的现象（节点抓到其他节点的数据包）。感觉这个现象，确实是 bridge 网桥 mac 表老化造成的正常现象。但是 mac table 数量的变化，没有一定规律。我看了下，mac table 老化的时间，是 300s，但是并非 300s 的时间点，就一定会瞬间让 mac table 数量归零。

mac 表老化应该不是 hard_timeout，是持续 300s 都收不到这个目的 mac 的报文才会清除。