RADIX_MPATH / FreeBSD Routing

[Pierre Lamy]

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 at freebsd.org [owner-freebsd-net at freebsd.org] on behalf of Joe Holden [lists at rewt.org.uk]
> Sent: Monday, December 12, 2011 3:23 PM
> To: freebsd-net at 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>