From owner-freebsd-net@FreeBSD.ORG Sun Jun 15 10:16:20 2008 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 77D7E106566B for ; Sun, 15 Jun 2008 10:16:20 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by mx1.freebsd.org (Postfix) with ESMTP id 53BBA8FC1F for ; Sun, 15 Jun 2008 10:16:20 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 71BC3116765; Sun, 15 Jun 2008 06:16:19 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Sun, 15 Jun 2008 06:16:19 -0400 X-Sasl-enc: pIq9jjJSAdOVnfd+QdqbSv+J7gw1rlvNX3nLCC0+Gv2i 1213524979 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id D0BB2108ED; Sun, 15 Jun 2008 06:16:18 -0400 (EDT) Message-ID: <4854EBF1.7020708@FreeBSD.org> Date: Sun, 15 Jun 2008 11:16:17 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.14 (X11/20080514) MIME-Version: 1.0 To: Paul References: <4852E23E.2040505@gtcomm.net> In-Reply-To: <4852E23E.2040505@gtcomm.net> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: Route 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: Sun, 15 Jun 2008 10:16:20 -0000 Paul wrote: > Get these with GRE tunnel on > FreeBSD 7.0-STABLE FreeBSD 7.0-STABLE #5: Sun May 11 19:00:57 EDT > 2008 :/usr/obj/usr/src/sys/ROUTER amd64 > But do not get them with 7.0-RELEASE > > Any ideas what changed? :) Wish there was some sort of changelog.. > # of messages per second seems consistent with packets per second on > GRE interface.. > No impact in routing, but definitely impact in cpu usage for all > processes monitoring the route messages. RTM_MISS is actually fairly common when you don't have a default route. Messages which get enqueued don't necessarily get delivered -- and very few processes actually listen to the routing socket actively like this, so I wouldn't worry about it. If it's a real concern for you then you could try hacking in a sysctl to tell the radix trie code not to issue RTM_MISS messages on the routing socket.