![docker container混杂模式部分工作](https://linux22.com/image/777327/docker%20container%E6%B7%B7%E6%9D%82%E6%A8%A1%E5%BC%8F%E9%83%A8%E5%88%86%E5%B7%A5%E4%BD%9C.png)
我遇到了奇怪的虚拟(docker bridges)网络状况
我有两个 docker 通过 docker-compose 连接到同一个网桥。一个 docker 是“probe”,另一个是“injector”。Injector 使用 tcpreplay 重放捕获,而“probe”应该通过 tcpdump 接收它。不用说,重放的捕获与连接到网桥的 NICS 的 IP 或 mac 没有任何关系。主机之间的 ping 工作正常。
现在,docker 自动向主机公开了第三个 NIC。
+--->NIC1 ["injector" docker / uses tcpreplay to inject ]
bridge +--->NIC2 ["probe" docker / uses tcpdump to listen]
|
+--- NIC3 host [used for testing sometimes as injector and sometimes as listener]
现在实际发生的情况是,当从 HOST 运行 tcpreplay(通过 NIC3 注入捕获)时,一切都运行正常,并且“探测”上的 tcpdump 显示重放的流量。但是,当在注入器上使用 tcpreplay 并通过 NIC1 注入捕获时,在“探测”上只能看到捕获的前两个数据包,然后“探测”上的所有流量都会停止(从主机注入也将停止工作)。如果在 NIC3 上运行 tcpdump,它会正常接收来自注入器的所有捕获流量。
- “探测”上的 ifconfig 没有显示任何丢弃的数据包
- 主机上的 iptables 不会增加丢弃数据包的计数器(希望我做得正确“sudo iptables -L -v -n | grep -i drop”)
- tcpdump 在探测时自动启用混杂模式
有人能解释这种不对称行为吗?知道如何调试吗?
注入器和主机 - AlmaLinux:8,探测 -Centos:7 tcpreplay 版本 4.4.1
答案1
桥接器未传递帧的原因在于 mac 学习机制。假设我们想在注入器容器中将流量从 MAC1 注入到 NIC1 上的 MAC1->MAC2,桥接器过滤器将传递(泛洪到探测器)来自 MAC1 --> MAC2 的流量并获悉 MAC1 位于 NIC1 上,但随后它将拒绝泛洪来自同一端口上的 MAC2-->MAC1 的所有内容,因为它认为 MAC1 位于流量来自的同一端口上。再次说明,注入的流量记录在其他地方,与实际桥接器拓扑没有任何联系。
按照说明禁用网桥上的 mac 学习机制这里解决了该问题,从注入器注入的所有帧都将被淹没到探测器。
当流量从主机注入时,行为不对称的原因尚不清楚。但我发现,当流量从 NIC3 注入时,网桥并没有真正激活其学习机制,例如,出于某种原因,注入流量的 mac 从一开始就没有出现在学习的 mac 列表中。