勾起了回忆，就想记录点什么。
再看刘经理的需求：
- 被bonding的eth0可以独立工作，eth0作为类似带内管理接口。
当然，现在看来，用macvlan实现这个非常容易：
ip link add link eth0 man0 type macvlan
brctl addbr br0
brctl addif br0 man0
brctl addif br0 eth1
ifconfig br0 1.1.1.1/8 up
ifconfig man0 4.4.4.4/8 up
OK，现在经理可以通过eth0来作为管理口访问管理地址4.4.4.4了，而eth0同时也和eth1一起作为br0的port存在。
但是如果不配置macvlan则何如？
我当年被告知不能变更 错误的配置脚本 ，因此我必须去适配类似下面的逻辑：
brctl addbr br0
brctl addif br0 eth0
brctl addif br0 eth1
ifconfig br0 1.1.1.1/8 up
ifconfig eth0 4.4.4.4/8 up
很明显，这个配置是错误的，eth0已经被br0给覆盖掉了，它作为br0的port不再对外可见，而且我也不能通过udev修改网卡的名字，总之就是系统的配置， 我不能动！
于是，我构建了超级复杂且不灵活的脚本化方案：
- 用arptables修改arp请求和回复。
- 用netfilter修改数据包。
- 结合iproute2用脚本联动手工配置arp条目。
- …
好像在这个blog里还能找到这篇文章，但我懒得去翻了。
很显然，经理是不会同意我这种自己一旦离职便无人可维护的trick的，直到现在我依然热衷于这种完全不可维护的奇技淫巧，眼前就有标准化的方案，在我看来却是无法展示技术水平的low点！这便是我的硬伤，我因此无法成为经理。
在当时，我真的是不能用macvlan啊，所以我才想到去炫耀arptables/netfilter/iproute2的，被否决了之后，我必须得想个稍微正经点的方案了。
但我可以动二进制代码，我可以重新编一版bridge.ko内核模块！
我觉得这个改动是有意义的，时隔这么多年，我还是觉得它是有意义的。
怎么说呢？
我不认为Linux bridge因为作为一个“可以通过IP访问本地接口”存在！
bridge就是个bridge啊，若干或物理的或虚拟的ethernet类型的网卡作为port连接到它，那么br0是什么？它本身也是一个port吗？这无疑增加了实现的复杂性。
在维护MAC/port映射表的时候，不得不区分is_local和!is_local，于是bridge的实现中，特意准备了下面这个函数：
static int br_pass_frame_up(struct sk_buff *skb);
用于区分这个帧是is_local的！
bridge的代码因此看起来一点都不清爽，是的，为此，到处都是if语句。
我当时在夏日很冷的机房忍受这巨大温差带来的刺到骨头里的难受之所以没有抱怨，是因为我受够了Linux bridge的实现！我决定就在这个令人难受的环境里修改掉它，带来一点舒服的感觉。嗯，现场编程！
我希望：
- 当有帧访问该bridge的port另一端的MAC时，bridge负责forward它；
- 当有帧访问该bridge的port本身的MAC时，像正常访问该网卡一样，bridge并不处理它。
- 我不引入外部任何类似macvlan之类的虚拟网卡的东西。
好吧，做法其实很简单：
- 让所有br_pass_frame_up的调用直接返回0。
- 在br_handle_frame中特殊bypass掉访问本port的流量。
br_handle_frame的取消很简单，return 0即可，br_handle_frame的改动也不麻烦：
rx_handler_result_t br_handle_frame(struct sk_buff **pskb)
{
...
if (unlikely(ether_addr_equal(skb->dev->dev_addr, dest))) {
return RX_HANDLER_PASS;
}
p = br_port_get_rcu(skb->dev);
...
case BR_STATE_LEARNING:
if (ether_addr_equal(p->br->dev->dev_addr, dest))
skb->pkt_type = PACKET_HOST;
if (is_broadcast_ether_addr(eth_hdr(skb)->h_dest))
// 增加引用，准备二次处理。
// 或者内部特殊处理br_pass_frame_up的NF_HOOK，不再stolen
atomic_inc(&skb->users);
NF_HOOK(NFPROTO_BRIDGE, NF_BR_PRE_ROUTING, NULL, skb,
skb->dev, NULL,
br_handle_frame_finish);
// 除了转发之外，让eth网卡自己也处理一份ARP，
if (is_broadcast_ether_addr(eth_hdr(skb)->h_dest))
return RX_HANDLER_PASS; // 二次处理，直接返回netif_receive_skb
break;
default:
}
OK，就是如此：
brctl addbr br0
brctl addif br0 eth0
brctl addif br0 eth1
ifconfig br0 1.1.1.1/8 up
ifconfig eth0 4.4.4.4/8 up
4.4.4.4可以通了，但是br0的1.1.1.1/8地址不再可达，为此，如果你非要它通，则需要将它配置在eth0即可：
brctl addbr br0
brctl addif br0 eth0
brctl addif br0 eth1
ifconfig br0 up
ip add add dev eth0 1.1.1.1/8
ip add add dev eth0 4.4.4.4/8
让bridge的归bridge，让eth0归eth0，这显然看起来更加清爽，于是我就再也不会为 “Linux bridge竟然可以自己把自己接入bridge本身” 而赛里布瑞特了。这很完美得实现了所谓的 带内管理 ，即让处理数据面的网卡同时跑管理流量和控制流量，对于接入层的中小型设备，中小型设备，中小型设备，中小型设备，即插即管，非常方便，而且ACL也可以灌输进去，实现带内安全策略。
当然了，这些可能一点意义都没有，没有就没有吧，本来就没什么意义。
浙江温州皮鞋湿，下雨进水不会胖！
来源：oschina
链接：https://my.oschina.net/u/4360480/blog/4317711