Default route (IPv4) demolished by destroying clone (gif/gre)
interface
Andrew Thompson
thompsa at freebsd.org
Wed Aug 16 20:49:37 UTC 2006
On Wed, Aug 16, 2006 at 12:15:25PM -0500, Brooks Davis wrote:
> On Wed, Aug 16, 2006 at 07:58:44PM +0400, Yar Tikhiy wrote:
> > On Wed, Aug 16, 2006 at 09:54:19AM -0500, Brooks Davis wrote:
> > > On Wed, Aug 16, 2006 at 10:23:13AM +0200, Stefan Bethke wrote:
> > > >
> > > > Ouch. Don't ppp(8), OpenVPN etc. destroy the tun interface they're
> > > > using when they exit? Flushing all routes then would be rather
> > > > harmful. I'm glad I haven't updated to a newer -stable yet then :-)
> > >
> > > In general, no since tun interfaces can not be destroyed.
> >
> > Did you mean "in particular"? :-)
> >
> > The problem can be triggered by destroying any interface that can
> > be destroyed. Just imagine getting rid of a defunct gif tunnel on
> > a remote router, or removing an unused vlan, and totally losing
> > connectivity to the router due to its default route having been
> > flushed. The scenario still can be quite unpleasant. I'd rather
> > change the default for $removable_route_flush to NO and let the
> > kernel choose which routes should be flushed upon the physical
> > ejection or software destruction of an interface. Note that this
> > doesn't include static_routes_${ifn}, which are handled separately
> > by pccard_ether_stop().
>
> Agreed. That code shouldn't be on by default. I've disabled in it HEAD
> and will MFC in a few days. As another poster said, I'm not even sure
> it should exist as an option.
Thanks for fixing this up, it certainly was odd to be flushing routes in
userland. I have one more bug report from the ifnet/devd change to look
at where renamed interfaces give some sort of an error.
cheers,
Andrew
More information about the freebsd-stable
mailing list