坑不能白跳，更不能白爬。

大家好，我是二哥。

周末在家继续完善公司内部培训课程《图解 VPC & K8s networking model》的课件。

课程中要用到一个课堂动手小实验：创建两个新的 network namespace ，每个 namespace 插入 veth 网卡的一端，再建一个新的 bridge ，将 veth 另一端插入到这个网桥中。

这本是一个非常成熟的实验，我仅仅是为了课堂演示的时候能更顺利一些，就把命令又练习了一遍。

不过，尴尬的事情发生了：我从 net1 里面没有办法 ping 通 net2，也就是图中 ping 192.168.0.102 不通。

这。。。反复了好几次，都不行。完蛋了，下周的课堂实验不是废了么？

但我明明上周准备小实验的时候是好的。咋过了几天就不行了呢？难道它也躺平了？

• ip netns exec net1 ip link list / brctl showmacs br0 / bridge fdb / tcpdump -i br0 -nn -vv
• reboot
• 此处省略一万字

一顿让人眼花缭乱的操作之后，它还是那么倔强地维持原状。看来它对我的热爱已经打了烊。算了，我决定先休息一下，这个时候还是得来一瓶啤酒压压惊。

我也不知道休息了多久。也不知道是谁在耳边轻声对我说：换个环境试试吧。

嗯，我拿了一个全新的 VM 测试了一下，鬼东西，它又好了！！

真是不错的消息，看来上课的时候一半的同学会有概率成功的

你们看过下面这张神图么？在我这个实验场景里，其实只涉及到图中链路层的一些事情。但为啥链路层也会用到网络层的 iptables 和 conntrack 呢？

我忽然想起来死活不通的那个环境已经安装了 K8s ，而 K8s 会开启一个关键的内核参数 bridge-nf-call-iptables 。

net.bridge.bridge-nf-call-iptable

这个参数开启后，会使得 bridge 设备在二层转发时也去使用 iptables 配置的三层规则 (包含 conntrack)。也就是说 bridge 设备用到了下图中的 iptables 。

干得漂亮！！

把这个内核选项关掉后，一切都正常了。二哥会在后面找个时间给大家剖析一下细节。坑不能白跳，更不能白爬。