From owner-freebsd-net@FreeBSD.ORG Wed Mar 14 16:00:17 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3F9E616A403; Wed, 14 Mar 2007 16:00:17 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id F032013C468; Wed, 14 Mar 2007 16:00:16 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 92CE81F7D07; Wed, 14 Mar 2007 12:00:16 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Wed, 14 Mar 2007 12:00:16 -0400 X-Sasl-enc: P3lmKnhmgCuiLGgo3DThDT6s9LQ74SnRxaCBy8MJtFqP 1173888016 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id CF5A320E0B; Wed, 14 Mar 2007 12:00:14 -0400 (EDT) Message-ID: <45F81C0D.2000608@FreeBSD.org> Date: Wed, 14 Mar 2007 16:00:13 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Gleb Smirnoff , freebsd-net@FreeBSD.org, Vladimir Ivanov , bug-followup@FreeBSD.org References: <20070314115916.GB2713@cell.sick.ru> In-Reply-To: <20070314115916.GB2713@cell.sick.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: kern/106722: [net] [patch] ifconfig may not connect an interface to known network X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2007 16:00:17 -0000 Gleb Smirnoff wrote: > AFAIK, the problem needs a more generic approach. I see two approaches. > > 1) Introduce RTM_CHANGEADD, a command that will forcibly add route, > deleting all conflicting ones. Use this command in in_addprefix(). > > 2) In rt_flags field we still have several extra bits. We can use > them to specify route source - RTS_CONNECTED, RTS_STATIC, RTS_XXX, > where XXX is a routing protocol. When issuing RTM_ADD a route with > a preferred source (e.g. CONNECTED vs STATIC) will override the old > one. > > The proposed changes also constitute a hack. I understand that they are being proposed to address problems we currently have in the stack, i.e. that we do not support multipathing, though it is more than likely they will be blown away in future when the architecture changes (and it has to change). Approach 1 is largely irrelevant if multiple paths are introduced to the network stack; there is then no concept of a conflicting forwarding entry, only preference derived from the interface, entry flags, or the entry ('route') itself. Approach 2 has some merit to it, although the forwarding plane should not care where the forwarding entry came from unless it needs to (e.g. next-hop resolution). It seems reasonable that the forwarding plane should tag entries as being 'CONNECTED' i.e. derived from the address configuration of an interface. I believe many implementations out there do this, and multi-path does not change this. We already have the RTF_PROTO1 flag to determine if the forwarding entry ('route') came from a routing protocol in userland, so there should be no need to change the existing flags. The RTF_STATIC flag only has special meaning in that it means 'the user added this forwarding entry manually via the route(8) command'. We should preserve these semantics, though I believe we should start implementing forwarding preference in the radix trie. I think it seems acceptable and reasonable that we use a limited form of Approach 2 to clobber 'routes' being aded in the case described in the PR, until such time as the network stack is re-engineered to support multiple paths and forwarding preference. I also believe it is useful if we start to use more modern technical jargon to discuss 'routes' in the network stack, because we are actually discussing the behaviour of entries in a forwarding table. Regards, BMS