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-...@freebsd.org [owner-freebsd-...@freebsd.org] on behalf
of Joe Holden [li...@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-unsubscr...@freebsd.org"
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
