From owner-freebsd-net@FreeBSD.ORG Sat Nov 26 05:24:16 2011 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D2691065670; Sat, 26 Nov 2011 05:24:16 +0000 (UTC) (envelope-from alexander@wittig.name) Received: from hotzenplotz.wittig.name (hotzenplotz.wittig.name [IPv6:2a02:180:1:1::5b8f:51e8]) by mx1.freebsd.org (Postfix) with ESMTP id D29098FC1E; Sat, 26 Nov 2011 05:24:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wittig.name; s=mail; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version:Subject; bh=Kr7ncebKl2bDLQ3PE7hHGYhCqLuHOK83QHcnx0M1Mp4=; b=MGS97tvVF1M9+FfBo7ujoZmNQi1sCZzHPJwII39XsPmh9ZQAj849JiBrriX8nnY9H5znIcoeJmNm+OyXOtlsj+Mnh/cSyYNQBMGVFx0fLqaCqOzDZPjTxvStGe4WiAiIW0SwQxpHjPOxNHrQwRpr929hxM74wPgTXgij5lm1UHM=; Received: from [99.18.86.240] (helo=[192.168.1.64]) by hotzenplotz.wittig.name with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RUAkG-000CVg-R7; Sat, 26 Nov 2011 06:24:14 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Alexander Wittig In-Reply-To: <20111121120123.GC81136@FreeBSD.org> Date: Sat, 26 Nov 2011 00:24:09 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <96A5211A-398B-4773-8C6A-2D772D241CF0@msu.edu> <20111110065135.GS71907@FreeBSD.org> <6A964045-2ADF-42EC-8AC4-00179FDBE4D9@msu.edu> <20111121120123.GC81136@FreeBSD.org> To: Gleb Smirnoff X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@FreeBSD.org Subject: Re: FreeBSD 9 and ARP multicast source address error messages X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 05:24:16 -0000 Gleb, > A> I'm not an expert on networking, but is this condition of ignoring = such an ARP packet really a noteworthy event? I.e. is this something = that should not occur in "normal" operation according to the ARP = specifications? If this is mostly for kernel developers, maybe it should = only be enabled in debug kernel builds? >=20 > Nope, this isn't for kernel developers only but for sysadmins. Some = bad traffic is present in your > network, and it should be noticed by sysadmin, that's why LOG_NOTICE = severity left. >=20 > However, I understand how annoying it is when you are in a bad = network, you don't admin it, you > can't fix it and your logging system is too chatty. I am thinking of = some generic way of supperssing > or ratelimiting all logged events that can be triggered by host on LAN = or even by remote host. That would be great. As you say, I don't administer the network or these = Windows cluster machines, so I can't make the offending ARP packages go = away. For me, filtering them out via ipfw (as described in my first = email) works just fine for now. An easier solution than some sort of = rate limiting may be a simple sysctl knob to disable the messages = manually at runtime? Something akin to the already existing = net.link.ether.inet.log_arp_permanent_modify, = net.link.ether.inet.log_arp_movements, = net.link.ether.inet.log_arp_wrong_iface, maybe. Alexander=