From owner-freebsd-net@FreeBSD.ORG Mon Dec 12 23:23:07 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 7DBB1106564A for ; Mon, 12 Dec 2011 23:23:07 +0000 (UTC) (envelope-from lists@rewt.org.uk) Received: from abby.lhr1.as41113.net (abby.lhr1.as41113.net [91.208.177.20]) by mx1.freebsd.org (Postfix) with ESMTP id 41B888FC12 for ; Mon, 12 Dec 2011 23:23:06 +0000 (UTC) Received: from jasmine.internethq (unknown [91.208.177.192]) by abby.lhr1.as41113.net (Postfix) with ESMTP id 256AE22826 for ; Mon, 12 Dec 2011 23:23:06 +0000 (UTC) Received: from [172.16.11.44] (jwh-laptop.internethq [172.16.11.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jasmine.internethq (Postfix) with ESMTPS id E0B3F1187EA00 for ; Tue, 13 Dec 2011 00:22:21 +0000 (GMT) Message-ID: <4EE68CD7.5090106@rewt.org.uk> Date: Mon, 12 Dec 2011 23:23:03 +0000 From: Joe Holden User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: RADIX_MPATH / FreeBSD Routing 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: Mon, 12 Dec 2011 23:23:07 -0000 Hi guys, Is anyone aware of the state of mpath as it stands on stable/9? At the moment within a few seconds of OpenBGPD being fired up there is an rtfree: 2 panic, I have had a quick look through the code but don't understand why this panic() is triggered. On a related note, how does one successfully operate openospfd/openbgpd without having to filter all connected interfaces in the presence of 'redistribute [inet|inet6] connected', for example if there is a /30 between 2 openbgpd or openospfd speakers the /32 of the remote side will be installed and ultimately cause llinfo error messages and an eventual reset, or in the ospf case, the interface route to be changed or deleted. I understand this is due to the difference in stack behaviour, but would adding connected interface route protection to the kernel or the respective daemons be workable in the meantime, until mpath is fixed? At the moment I am having to use lots of filters to filter out all potential connected/interface routes for both address families, this seems to be a suboptimal solution. Quagga/Zebra seem to filter these changes out such that connectivity isn't broken but I am not familiar enough with C or the code to be able to deduce whats happening and how I could apply that to the kernel or bgp/ospf daemons. In my mind, connected/interface entries should only ever be changed when an interface state changes, or is created or destroyed? Should this be locked (perhaps with a sysctl toggle?) Any thoughts would be appreciated. Thanks, Joe