Date: Wed, 14 Mar 2007 19:10:23 +0300 From: Gleb Smirnoff <glebius@FreeBSD.org> To: "Bruce M. Simpson" <bms@FreeBSD.org> Cc: freebsd-net@FreeBSD.org, bug-followup@FreeBSD.org, Vladimir Ivanov <wawa@yandex-team.ru> Subject: Re: kern/106722: [net] [patch] ifconfig may not connect an interface to known network Message-ID: <20070314161023.GF2713@cell.sick.ru> In-Reply-To: <45F81C0D.2000608@FreeBSD.org> References: <20070314115916.GB2713@cell.sick.ru> <45F81C0D.2000608@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Mar 14, 2007 at 04:00:13PM +0000, Bruce M. Simpson wrote:
B> The proposed changes also constitute a hack.
B>
B> I understand that they are being proposed to address problems we
B> currently have in the stack, i.e. that we do not support multipathing,
B> though it is more than likely they will be blown away in future when the
B> architecture changes (and it has to change).
B>
B> Approach 1 is largely irrelevant if multiple paths are introduced to the
B> network stack; there is then no concept of a conflicting forwarding
B> entry, only preference derived from the interface, entry flags, or the
B> entry ('route') itself.
B>
B> Approach 2 has some merit to it, although the forwarding plane should
B> not care where the forwarding entry came from unless it needs to (e.g.
B> next-hop resolution).
B>
B> It seems reasonable that the forwarding plane should tag entries as
B> being 'CONNECTED' i.e. derived from the address configuration of an
B> interface. I believe many implementations out there do this, and
B> multi-path does not change this.
B>
B> We already have the RTF_PROTO1 flag to determine if the forwarding entry
B> ('route') came from a routing protocol in userland, so there should be
B> no need to change the existing flags.
B>
B> The RTF_STATIC flag only has special meaning in that it means 'the user
B> added this forwarding entry manually via the route(8) command'. We
B> should preserve these semantics, though I believe we should start
B> implementing forwarding preference in the radix trie.
B>
B> I think it seems acceptable and reasonable that we use a limited form of
B> Approach 2 to clobber 'routes' being aded in the case described in the
B> PR, until such time as the network stack is re-engineered to support
B> multiple paths and forwarding preference.
B>
B> I also believe it is useful if we start to use more modern technical
B> jargon to discuss 'routes' in the network stack, because we are actually
B> discussing the behaviour of entries in a forwarding table.
I was afraid that this would raise an argument on multipath routing. Let's
temporary do not speak about multipath but just decide what is the correct
way to remove conflicting routes when we are assigning an IP prefix to a
local interface?
--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070314161023.GF2713>