1

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?

3
  • To clarify, the arping command sends an ARP query to the specified MAC address for the specified IP address. Since the MAC address is unknown, this packet should be flooded over the network, and as such every host should see this packet.
    – Michel
    Jul 31, 2014 at 11:42
  • 3.14-0.bpo.1 from wheezy-backports (3.14.12-1~bpo70+1) shows the same problem. I'm getting the feeling that this is some kind of weird driver-related problem.
    – Michel
    Jul 31, 2014 at 13:49
  • Using an Intel NIC we had lying around, the problem disappears. So this is definitely a driver issue! I guess I'll submit a bug report somewhere.
    – Michel
    Jul 31, 2014 at 14:36

1 Answer 1

0

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 0 and b57udiag -c 1 -ipmi 0 to 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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .