[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101026082832.4c5af2ef@nehalam>
Date: Tue, 26 Oct 2010 08:28:32 -0700
From: Stephen Hemminger <shemminger@...tta.com>
To: Lorenzo Colitti <lorenzo@...gle.com>
Cc: netdev@...r.kernel.org
Subject: Re: [PATCH] ipv6: addrconf: clear IPv6 addresses and routes when
losing link
On Mon, 25 Oct 2010 22:44:03 -0700
Lorenzo Colitti <lorenzo@...gle.com> wrote:
> On Mon, Oct 25, 2010 at 9:38 PM, Stephen Hemminger
> <shemminger@...tta.com> wrote:
> > This is incorrect. When link is lost, routes and address should not be
> > flushed. They should be marked as tentative and then go through DAD again
> > on the new network.
>
> That won't help the case I am trying to fix, which is the case where
> the new link has a global prefix different than the old link. Marking
> the addresses as tentative will simply make them pass DAD and come
> back as soon as link comes back. But since they don't match the prefix
> that is assigned to the new link, they are unusable, because packets
> can't be routed back to them.
For IPv4 this is already handled by network manager.
Why couldn't the same apply to IPv6?
> > If you do it this way, you break routing protocols when link is brought
> > down and back up.
>
> The only addresses and routes flushed in this way should be ones that
> aren't manually configured, i.e., the ones created by autoconf
> (addrconf.c:2720 onwards). These won't be used by routing protocols,
> except for link-local addresses. So I assume you're talking about
> link-local here.
Not sure, let me do test it.
> Link-local addresses are immediately recreated in a tentative state as
> soon as link comes back, because on NETDEV_UP addrconf_notify calls
> addrconf_dev_config. So, this patch only makes it so that they become
> tentative when link goes away and comes back. In that time, the router
> that temporarily loses link is unable to send packets for the brief
> period of time that the link is performing DAD, but if the router has
> lost link, it will also fail to send the packet while link is lost.
> What's the additional failure scenario? Will it help if I make it so
> that link-local addresses aren't touched at all?
Link-local works fine.
--
--
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