From owner-freebsd-net@FreeBSD.ORG Wed Dec 14 13:00:17 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 E5DB11065676 for ; Wed, 14 Dec 2011 13:00:15 +0000 (UTC) (envelope-from pierre@userid.org) Received: from mail.storm.ca (unknown [IPv6:2607:f0b0:0:6:209:87:239:66]) by mx1.freebsd.org (Postfix) with ESMTP id 98B008FC0C for ; Wed, 14 Dec 2011 13:00:15 +0000 (UTC) Received: from mail.userid.org (pandora.userid.org [216.106.102.33]) by mail.storm.ca (8.14.2+Sun/8.14.2) with ESMTP id pBE2xZea009793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Dec 2011 21:59:40 -0500 (EST) Received: from [192.168.3.99] (unknown [192.168.3.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pierre) by mail.userid.org (Postfix) with ESMTP id 102112C7816; Tue, 13 Dec 2011 21:59:22 -0500 (EST) Message-ID: <4EE81109.4000306@userid.org> Date: Tue, 13 Dec 2011 21:59:21 -0500 From: Pierre Lamy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Li, Qing" References: <4EE68CD7.5090106@rewt.org.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-userid-MailScanner-Information: Please contact the ISP for more information X-userid-MailScanner-ID: 102112C7816.A094E X-userid-MailScanner: Found to be clean X-userid-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.44, required 6, autolearn=not spam, ALL_TRUSTED -1.44) X-userid-MailScanner-From: pierre@userid.org X-Spam-Status: No Cc: "freebsd-net@freebsd.org" , Joe Holden Subject: Re: 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: Wed, 14 Dec 2011 13:00:17 -0000 I believe the problem can be manually triggered by using a script that will mass-add and then mass-delete routes (the problem happens on delete). -Pierre On 12/12/2011 6:46 PM, Li, Qing wrote: > So you have RADIX_MPATH option enabled in the kernel configuration, and booting > up OpenBGPD triggers the crash immediately ? > > --Qing > ________________________________________ > From: owner-freebsd-net@freebsd.org [owner-freebsd-net@freebsd.org] on behalf of Joe Holden [lists@rewt.org.uk] > Sent: Monday, December 12, 2011 3:23 PM > To: freebsd-net@freebsd.org > Subject: RADIX_MPATH / FreeBSD Routing > > 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 > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >