Date: Mon, 12 Dec 2011 23:46:47 +0000 From: "Li, Qing" <qing.li@bluecoat.com> To: Joe Holden <lists@rewt.org.uk>, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: RE: RADIX_MPATH / FreeBSD Routing Message-ID: <B143A8975061C446AD5E29742C5317231B6715@PWSVL-EXCMBX-01.internal.cacheflow.com> In-Reply-To: <4EE68CD7.5090106@rewt.org.uk> References: <4EE68CD7.5090106@rewt.org.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
So you have RADIX_MPATH option enabled in the kernel configuration, and boo= ting=0A= up OpenBGPD triggers the crash immediately ?=0A= =0A= --Qing=0A= ________________________________________=0A= From: owner-freebsd-net@freebsd.org [owner-freebsd-net@freebsd.org] on beha= lf of Joe Holden [lists@rewt.org.uk]=0A= Sent: Monday, December 12, 2011 3:23 PM=0A= To: freebsd-net@freebsd.org=0A= Subject: RADIX_MPATH / FreeBSD Routing=0A= =0A= Hi guys,=0A= =0A= Is anyone aware of the state of mpath as it stands on stable/9? At the=0A= moment within a few seconds of OpenBGPD being fired up there is an=0A= rtfree: 2 panic, I have had a quick look through the code but don't=0A= understand why this panic() is triggered.=0A= =0A= On a related note, how does one successfully operate openospfd/openbgpd=0A= without having to filter all connected interfaces in the presence of=0A= 'redistribute [inet|inet6] connected', for example if there is a /30=0A= between 2 openbgpd or openospfd speakers the /32 of the remote side will=0A= be installed and ultimately cause llinfo error messages and an eventual=0A= reset, or in the ospf case, the interface route to be changed or deleted.= =0A= =0A= I understand this is due to the difference in stack behaviour, but would=0A= adding connected interface route protection to the kernel or the=0A= respective daemons be workable in the meantime, until mpath is fixed?=0A= =0A= At the moment I am having to use lots of filters to filter out all=0A= potential connected/interface routes for both address families, this=0A= seems to be a suboptimal solution.=0A= =0A= Quagga/Zebra seem to filter these changes out such that connectivity=0A= isn't broken but I am not familiar enough with C or the code to be able=0A= to deduce whats happening and how I could apply that to the kernel or=0A= bgp/ospf daemons.=0A= =0A= In my mind, connected/interface entries should only ever be changed when=0A= an interface state changes, or is created or destroyed? Should this be=0A= locked (perhaps with a sysctl toggle?)=0A= =0A= Any thoughts would be appreciated.=0A= =0A= Thanks,=0A= Joe=0A= =0A= _______________________________________________=0A= freebsd-net@freebsd.org mailing list=0A= http://lists.freebsd.org/mailman/listinfo/freebsd-net=0A= To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"=0A=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B143A8975061C446AD5E29742C5317231B6715>