I'm baffled by the following weird bridge/arp behavior under Linux. It somehow seems to filter directed ARP requests, whereas it should forward them to the other end of the bridge. To test, I run the following command on a workstation in the same network:
arping -t 00:de:ad:be:ef:00 xx.xx.xx.102
The address xx.xx.xx.102 does not exist anywhere on the network, neither does the MAC-address (obviously :P)
If the server is configured without bridging, the expected result happens: a tcpdump in promiscuous mode sees incoming ARP requests on the interface. Same for other machines in the network. This establishes that the network infrastructure is working, i.e., it's not a problem in the switch.
Now, if I add eth0 to a bridge interface, it stops working: tcpdump doesn't show these ARP requests anymore, not on eth0, nor on br0! It's as if the requests are filtered somewhere, but I'm completely stumped as to where this should happen.
More interesting, this is a Debian wheezy machine. A squeeze machine doesn't show this behavior. Both have Broadcom cards using the tg3 driver. Did anything change in 3.2-series kernels in comparison to 2.6-series with regard to bridging or MAC filtering or anything like that?
Best Answer
So, I've finally discovered the root cause of this issue. Disabling IMPI support for the network cards makes everything work magically! So for all fellow frustrated sysadmins googling for this issue: download the Broadcom diagnostic tool (see here), try to find something off which you can boot into DOS (that turned out to be a challenge), and run
b57udiag -c 0 -ipmi 0andb57udiag -c 1 -ipmi 0to turn off IMPI on both cards, and it's fixed! Note that turning off IPMI in the BMC is not enough, it has to be turned off in the network card itself.