FreeBSD 9 and ARP multicast source address error messages

Alexander Wittig wittigal at msu.edu
Tue Nov 8 22:40:17 UTC 2011


Hello

I upgraded one of my machines from FreeBSD 8 to 9.0-RC1 (FreeBSD bt.pa.msu.edu 9.0-RC1 FreeBSD 9.0-RC1 #3: Fri Oct 28 16:45:28 EDT 2011     root at bt.pa.msu.edu:/usr/obj/usr/src/sys/ALEX  i386), and ever since that upgrade the kernel keeps flooding my log files with messages like these:
Nov  7 16:40:01 bt kernel: in_arp: source hardware address is multicast.in_arp: source hardware address is multicast.
Nov  7 16:42:02 bt kernel: in_arp: source hardware address is multicast.in_arp: source hardware address is multicast.

A Google search for these didn't reveal any useful results as to why this happens or how to fix it. So I did a tcpdump and matched the time stamps with packets, and I found the ones causing problems (the only ones with a multicast bit set) to be like this:
16:40:01.099823 02:02:23:09:44:3c > 03:bf:23:09:44:87, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 35.9.68.228 is-at 03:bf:23:09:44:e4, length 46
        0x0000:  03bf 2309 4487 0202 2309 443c 0806 0001
        0x0010:  0800 0604 0002 03bf 2309 44e4 2309 44e4
        0x0020:  02bf 2309 443c 2309 4487 0000 0000 0000
        0x0030:  0000 0000 0000 0000 0000 0000

It appears the broadcast MAC 03:bf:23:09:44:87 is part of Microsoft's network load balancing mechanism, with the 03:bf indicating that much and the 23:09:44:87 containing the IP address of the load balance cluster (35.9.68.228). These types of MACs seem to be commonly used in their load balancing implementation.

To prevent these messages from producing thousands of lines of logs each day, I added the following two IPFW rules and enabled ethernet package filtering (sysctl net.link.ether.ipfw=1):
deny ip from any to any MAC 03:bf:00:00:00:00/16 any layer2
allow ip from any to any layer2

This effectively blocks those packages and the resulting error messages. But I'm wondering if the newly added(?) ARP code in FBSD 9 is a bit too fussy about these, or if MS is abusing the ARP protocol here. Either way, this was never a problem with FBSD 7 or 8.

Cheers,
Alexander

Please CC me on replies as I'm not subscribed to the freebsd-net list.


More information about the freebsd-net mailing list