Date: Tue, 13 Dec 2011 21:59:21 -0500 From: Pierre Lamy <pierre@userid.org> To: "Li, Qing" <qing.li@bluecoat.com> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, Joe Holden <lists@rewt.org.uk> Subject: Re: RADIX_MPATH / FreeBSD Routing Message-ID: <4EE81109.4000306@userid.org> In-Reply-To: <B143A8975061C446AD5E29742C5317231B6715@PWSVL-EXCMBX-01.internal.cacheflow.com> References: <4EE68CD7.5090106@rewt.org.uk> <B143A8975061C446AD5E29742C5317231B6715@PWSVL-EXCMBX-01.internal.cacheflow.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EE81109.4000306>