RADIX_MPATH / FreeBSD Routing

[Joe Holden]

Hi Pierre,

Just realised I didn't reply-all when responding to Qing... it is 
definitely only during deletes although the volume of deletes doesn't 
need to be significant to trigger it, I'll report back to the list as 
and when.

Thanks,
Joe

Pierre Lamy wrote:
> 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"
>>
> 
>