Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 19 Jun 2005 13:22:07 +0200
From:      Jose M Rodriguez <josemi@freebsd.jazztel.es>
To:        Michal Vanco <vanco@satro.sk>
Cc:        freebsd-net@freebsd.org, Gleb Smirnoff <glebius@freebsd.org>, freebsd-stable@freebsd.org, Jose M Rodriguez <josemi@freebsd.jazztel.es>
Subject:   Re: Routes not deleted after link down
Message-ID:  <200506191322.08287.josemi@redesjm.local>
In-Reply-To: <200506191048.49883.vanco@satro.sk>
References:  <51688.147.175.8.5.1119105461.squirrel@webmail.satronet.sk> <20050619082944.GA11972@cell.sick.ru> <200506191048.49883.vanco@satro.sk>

next in thread | previous in thread | raw e-mail | index | archive | help
El Domingo, 19 de Junio de 2005 10:48, Michal Vanco escribi=F3:
> On Sunday 19 June 2005 10:29, Gleb Smirnoff wrote:
> > On Sat, Jun 18, 2005 at 10:14:32PM +0200, Jose M Rodriguez wrote:
> > J> Second, you may need a route daemon for this.  ospf is a well
> > known J> canditate where convergence in case of lost link is a
> > must.
> >
> > While an OSPF daemon may stop advertising the affected route to its
> > neighbors, the kernel will still have the route installed and thus
> > the box won't be able to contact other hosts on the connected net,
> > while they are reachable via alternate pass.
>
> Routing protocol should be responsible for removing affected routes
> from FIB. For example quagga should remove all routes learned via
> particular ospf neighbour when that neighbour is not reachable
> anymore due to link goes down. But in case when no daemons are used
> (`static' and `connected' are also `routing protocols'), kernel
> should be responsible for doing that.
>
> > I've checked that Cisco routers remove route from FIB when
> > interface link goes down. I haven't checked Junipers yet.
>
> Junipers do the same. It is the only feasible behaviour for router.
>
> > From my viewpoint, removing route (or marking it unusable) is a
> > correct behavior for router. Not sure it is correct for desktop.
>
> Sure.
>
> > My vote is that we should implement this functionality and make it
> > switchable via sysctl. I'd leave the default as is.
>

I'm not sure of this.  I also think that a devd or monitor daemon will=20
be enough and easy to implement.

I think NetBSD have allready some kinda of net monitor daemon for pppoe=20
support (via sppp).  Not sure if route support is included.

But seems easy and clean that a kernel based solution.

=2D-
  josemi
> Agree.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200506191322.08287.josemi>