[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080603104640.21026cdb@extreme>
Date: Tue, 3 Jun 2008 10:46:40 -0700
From: Stephen Hemminger <shemminger@...tta.com>
To: David Miller <davem@...emloft.net>
Cc: yoshfuji@...ux-ipv6.org, netdev@...r.kernel.org
Subject: Re: [PATCH 1/2] IPV6: remove addresses and routes when carrier is
lost
On Tue, 03 Jun 2008 10:30:59 -0700 (PDT)
David Miller <davem@...emloft.net> wrote:
> From: YOSHIFUJI Hideaki <yoshfuji@...ux-ipv6.org>
> Date: Wed, 04 Jun 2008 02:28:36 +0900 (JST)
>
> > In article <20080603.102501.193702820.davem@...emloft.net> (at Tue, 03 Jun 2008 10:25:01 -0700 (PDT)), David Miller <davem@...emloft.net> says:
> >
> > > From: Stephen Hemminger <shemminger@...tta.com>
> > > Date: Tue, 3 Jun 2008 10:21:44 -0700
> > >
> > > > The patch just makes carrier_off respond the same as doing 'ip link set dev eth0 down'
> > > > (or ifconfig eth0 down). A router needs to be able to re-route when link fails.
> > >
> > > But I can't see how this behavior makes sense for the normal desktop case
> > > and it disagrees with existing practice for many years.
> > >
> > > If I pull out my network cable while making some adjustments in my
> > > rack, and then plug it back in, I don't expect to lose my static
> > > routes on that interface.
> > >
> > > That doesn't make any sense at all.
> >
> > How about ignoring routes via down interface?
>
> Look at what happens now in my example case. The packets simply get
> queued in the device queue until the carrier comes back up. Once
> it comes back up, the packets go out with zero packet loss.
>
> With your suggestion, the packets will get dropped if there are no
> other devices with active routes to the destination, which is a very
> poor quality of implementation decision in my opinion, especially for
> this case.
It is not what desktop users want, that is why it is a dynamic configuration
option via /proc/sys/net/ipv6/conf/ethX/link_detect.
But it is what a router wants. So why not allow it? Obviously, Vyatta
users expect systems behave same as Cisco.
The problem with doing it all in user space are not impossible just more difficult:
* links bouncing lead to synchronization problems
* existing Quagga code avoids messing with "system routes"
* Quagga has to be portable to Solaris/BSD etc..
More at:
http://osdir.com/ml/network.quagga.devel/2004-08/msg00009.html
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists