Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 8 Nov 2011 17:14:45 -0500
From:      Alexander Wittig <wittigal@msu.edu>
To:        freebsd-net@freebsd.org
Subject:   FreeBSD 9 and ARP multicast source address error messages
Message-ID:  <96A5211A-398B-4773-8C6A-2D772D241CF0@msu.edu>

next in thread | raw e-mail | index | archive | help
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@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=3D1):
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.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?96A5211A-398B-4773-8C6A-2D772D241CF0>