Date: Mon, 12 Dec 2011 23:23:03 +0000 From: Joe Holden <lists@rewt.org.uk> To: freebsd-net@freebsd.org Subject: RADIX_MPATH / FreeBSD Routing Message-ID: <4EE68CD7.5090106@rewt.org.uk>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EE68CD7.5090106>