Linux的brctl addif命令可以将一个接口加入到既有的网桥中，接下来，这个接口就成了brport，属于一个从属的接口，然而你还是可以看到它的，并且可以为它添加IP地址，然后route命令会显示出它的新添加的IP地址的链路层路由已经生效，种种迹象都让人觉得这个brport仍然保有IP语义，然而如果此时你使用该IP(Linux内核会做源地址选择)去访问同一网段的其它地址的话，就会发现，不通，反过来从其它同一网段的地址访问该地址也是不通的，原因何在？听我分解。
网络不通的话，一般第一步是通过抓包来分析，发现是在arp这一步出问题的，arp是IPv4的生命源，arp出了问题，什么都别扯了！懂Linux网络实现的家伙们其实早就知道为何出错了，因为作为从属接口brport，它的一切都要被网桥接口接管，包括arp，也就是说arp期望的接口信息都是关于网桥接口的而不是基于brport的。总的来说是这样的。
IP地址配置在物理接口brport上，因此链路层路由显示的出口设备就是该brport，发送数据的时候，arp逻辑会将目标IP-Mac映射记录在该brport门下，然而arp回来的时候，网桥接口接收了它，内核发现网桥接口门下没有任何待解决的arp请求，因此丢弃之，因此根本不可能从本机访问和配置在brport上IP在同网段的任何目标。反过来也一样，arp请求从其它机器过来，被网桥接口接收，可是在arp_process中准备回复reply的时候，反向路由查找由于dev参数而无法通过，dev参数是网桥，而查询结果却是brport，因此failed。能分析到这个地步需要你十分精通网络协议的行为或者Linux内核协议栈。
那么怎么解决这个问题呢？easy啊easy，以下一条命令即可：
ebtables -t broute -A BROUTING -p ARP --arp-ip-dst 12.12.12.12 -j redirect --redirect-target DROP
网络不通的话，一般第一步是通过抓包来分析，发现是在arp这一步出问题的，arp是IPv4的生命源，arp出了问题，什么都别扯了！懂Linux网络实现的家伙们其实早就知道为何出错了，因为作为从属接口brport，它的一切都要被网桥接口接管，包括arp，也就是说arp期望的接口信息都是关于网桥接口的而不是基于brport的。总的来说是这样的。
IP地址配置在物理接口brport上，因此链路层路由显示的出口设备就是该brport，发送数据的时候，arp逻辑会将目标IP-Mac映射记录在该brport门下，然而arp回来的时候，网桥接口接收了它，内核发现网桥接口门下没有任何待解决的arp请求，因此丢弃之，因此根本不可能从本机访问和配置在brport上IP在同网段的任何目标。反过来也一样，arp请求从其它机器过来，被网桥接口接收，可是在arp_process中准备回复reply的时候，反向路由查找由于dev参数而无法通过，dev参数是网桥，而查询结果却是brport，因此failed。能分析到这个地步需要你十分精通网络协议的行为或者Linux内核协议栈。
那么怎么解决这个问题呢？easy啊easy，以下一条命令即可：
ebtables -t broute -A BROUTING -p ARP --arp-ip-dst 12.12.12.12 -j redirect --redirect-target DROP
这句话的意思就是，用物理接口，即brport接管arp，而不是用网桥接口。为了不影响网桥的正常流程，特意指定目标IP地址是这个添加到brport的地址。
本文转自 dog250 51CTO博客，原文链接:http://blog.51cto.com/dog250/1268894
